Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 31 Mar 2006 21:25:35 +0000 Message-ID: <442D65D6.4050305@gmx.net> Date: Fri, 31 Mar 2006 19:24:38 +0200 From: Hannes Tschofenig User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) MIME-Version: 1.0 To: Bernard Aboba CC: radiusext@ops.ietf.org, paul_congdon@hp.com Subject: Re: Review of draft-ietf-radext-vlan-02.txt Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Bernard, thanks for the quick response. Please find some comments below: Bernard Aboba wrote: >> The document does not describe the semantic when the >> User-Priority-Table attribute is included in the Access-Request. > > > I was also a bit puzzled by this. Presumably the switch sends the > default configuration, but I am not sure. > >> Section 1.3 talks about the provisioning semantic when included in the >> Access-Accept. I think it is necessary to describe the semantical >> difference between these two approaches. > > > The document says that the attribute when included in the Access-Request > is a "hint". So I don't think that there is any provisioning going on > in the Access-Request. Do you think it would be useful to provide more description of what the semantic of the User-Priority-Table attribute in the Access-Request or the Access-Accept means? I know you as someone that wants to describe the behavior in great detail. > >> How is the data traffic mapped to the QoS class? Which attribute >> carries this flow identifier? I think it is necessary to provide a >> description. > > > My understanding is that we are only talking about remapping of priority > bits that are already set on inbound, and that this is described in IEEE > 802.1D. What type of remapping of priority bits do you have in mind? Note that the reference to Annex G in the draft is a bit misleading since this section of the IEEE 802.1D spec just gives the rational behind the selection of the traffic classes based on the number of queues being available. > >> Why is the length of the value carried in the User-Priority-Table >> attribute 10 bytes long? > > > It isn't. RADIUS includes the type and length fields in the total > length, so it's 8 bytes long. Why is it 8 bytes long? > >> You seem to assume that the RADIUS server knows something about the >> link specific properties. > > > The document specifies attributes for use with IEEE 802 networks. > Information on the specific link type is provided in the NAS-Port-Type > attribute. That's something you might want to mention in the document. I think you just want to delete the usage of the User-Priority-Table attribute in the Access-Request. > >> 1) What happens if the RADIUS server receives the User-Priority-Table >> attribute in the Access-Request but it has only Y.1541 QoS classes >> stored in the user's profile? > > > Since this would be a hint, I presume the server is free to ignore it. > >> Do you assume that the RADIUS server is able to provide a mapping? > > > Since it's a hint, I wouldn't think so. The RADIUS server isn't > compelled to include the User-Priority-Table attribute in the > Access-Accept. > >> Should the RADIUS server fail when it either does not understand the >> QoS classes or if it is unable to map them? > > > It is possible that implementations may not react well to the hint, but > if they do understand the hint, they shouldn't fail because they don't > return a User-Priority-Table in the Access-Accept. > >> Should the RADIUS client know what the RADIUS server understands? > > > I think that is only important if RADIUS servers won't react well to the > hint. If servers don't send the attribute, the client probably won't care. > >> 2) Is the an applicability problem with provisioning in a roaming >> environment when the RADIUS server of my home network sends the >> User-Priority-Table attribute to the visited network which might be a >> IEEE 802.16e network? > > > Presumably the attribute will only be sent if the NAS-Port-Type > attribute indicates that it would be useful. 802.16k implements > bridging, but 802.16e does not, so I don't think it would make sense to > send this attribute to a RADIUS client running 802.16e. However, it > appears there is no NAS-Port-Type for 802.16e, 802.16k, 802.20, etc. > There probably should be. > >> Would it be necessary for the RADIUS client to indicate that it is >> attached to a IEEE 802.1D network with support for the QoS classes in >> order to allow the Access-Accept message to be meaningful? > > > The NAS-Port-Type attribute should provide this information. > >> How long is the authoriziation decision valid when the >> User-Priority-Table attribute in sent in the Access-Request? > > > Presumably until the expiration of Session-Timeout. > >> Do you see a need to reflect the QoS decision in the interworking with >> accounting or RADIUS prepaid (e.g., cost of the reservation)? > > > The attributes are not indicated to be sent in Accounting-Request > packets, but perhaps they should be. It seems that you need to add a little bit more text to the draft to explain based on your response. Let me explain what I would do with the description of this specific attribute: The User-Priority-Table attribute is only used in the Access-Accept (and not in the Access-Request). You need to specify which traffic is assigned to a specific QoS class. Therefore, you need to add the NAS-Traffic-Rule. You need to add a normative reference to draft-ietf-radext-filter-rules-00.txt. Furthermore, you need to add the User-Priority-Table attribute to Accounting-Request messages. Without a description which traffic experiences the QoS treatment the entire stuff does not make sense. From a semantic point of view this is very similar to a DiffServ traffic marking. Here the rules for traffic marking is stored at the AAA server. This raises the question why you cannot just have a generic description with a set of QoS parameters. For IEEE 802.16e you would have to go through the same description just with different QoS parameters. The same for DiffServ, IntServ CL/GS, Y.1541, etc. Ciao Hannes -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 31 Mar 2006 18:08:36 +0000 Message-ID: From: "Bernard Aboba" To: Hannes.Tschofenig@gmx.net Cc: radiusext@ops.ietf.org, paul_congdon@hp.com Bcc: Subject: Re: Review of draft-ietf-radext-vlan-02.txt Date: Fri, 31 Mar 2006 10:08:05 -0800 Mime-Version: 1.0 Content-Type: text/plain; format=flowed >Do you think it would be useful to provide more description of what the >semantic of the User-Priority-Table attribute in the Access-Request or the >Access-Accept means? Since there is some confusion on that point, I think the answer is probably "yes". I also think there may be more text required to specify exactly what 802.1D management elements this corresponds to. >Note that the reference to Annex G in the draft is a bit misleading since >this section of the IEEE 802.1D spec just gives the rational behind the >selection of the traffic classes based on the number of queues being >available. I think that the correct reference may be Section 7.5.1 ("Regerating User Priority"). Annex G just provides some general background information. Table 7.1 specifies the default values of the User Priority Regeneration Table (no change). Clause 14.6.2 talks about modification of the default values by management. My assumption is that the User-Priority-Table attribute sent in an Access-Request would be the default in Table 7.1, absent changes via management. >Why is it 8 bytes long? Clause 14.6.2.3.3 specifies the regeneration table as 8 values, each an integer in the range of 0-7. >That's something you might want to mention in the document. Indeed. >I think you just want to delete the usage of the User-Priority-Table >attribute in the Access-Request. Personally, I'm not clear what a RADIUS server would do with it; unless it's been modified by management it is a known quantity (e.g. the default). >It seems that you need to add a little bit more text to the draft to >explain based on your response. I think so. This would include: a. References to specific sections of 802.1D, explaining how this attribute relates to existing management objects. b. Discussion of the semantics of inclusion in Access-Request (if this is in fact required) >The User-Priority-Table attribute is only used in the Access-Accept (and >not in the Access-Request). You need to specify which traffic is assigned >to a specific QoS class. Therefore, you need to add the NAS-Traffic-Rule. >You need to add a normative reference to >draft-ietf-radext-filter-rules-00.txt. As far as I can tell, the regeneration table doesn't assign traffic to a specific QoS class, it just remaps it. This isn't based on filters, but just on the incoming markings. Obviously this is not a very sophisticated usage model. >Furthermore, you need to add the User-Priority-Table attribute to >Accounting-Request messages. Probably. >Without a description which traffic experiences the QoS treatment the >entire stuff does not make sense. I think that regeneration is a separate issue from QoS treatment. I agree that it would not make much sense to do regeneration if you didn't have a QoS goal in mind, though. >From a semantic point of view this is very similar to a DiffServ traffic >marking. Here the rules for traffic marking is stored at the AAA server. Regeneration is a kind of remapping (though not a sophisticated one). >This raises the question why you cannot just have a generic description >with a set of QoS parameters. Clearly that would be useful, but I think it is outside the scope of what the regeneration table is attempting to achieve. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 31 Mar 2006 15:24:30 +0000 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: looking for advise on RFC-2618 and 2620 Date: Fri, 31 Mar 2006 09:22:42 -0600 Message-ID: <7221140AD3DA7C4DB2CD49771243D8DD0134801A@nrmail01.netrake.net> Thread-Topic: looking for advise on RFC-2618 and 2620 Thread-Index: AcZSkTMQOAT5dPExTHW9ppbGZgVniAAAli3gAJCbglA= From: "Carl Kalbfleisch" To: "Nelson, David" , > -----Original Message----- > From: owner-radiusext@ops.ietf.org > [mailto:owner-radiusext@ops.ietf.org]On Behalf Of Nelson, David > Sent: Tuesday, March 28, 2006 12:19 PM > To: radiusext@ops.ietf.org > Subject: RE: looking for advise on RFC-2618 and 2620 >=20 >=20 > Carl Kalbfleisch writes... >=20 > > I realize that these MIBs are being updated, > > so perhaps we can add a discontinuity timer in a future revision.=20 >=20 > This is already an open issue from Area Director review of the revised > MIB drafts, so will be included in the next draft version. >=20 Several more comments on discontinuity: 1) = http://www.ietf.org/internet-drafts/draft-ietf-radext-dynauth-client-mib-= 05.txt defines only one object. radiusDynAuthClientCounterDiscontinuity OBJECT-TYPE SYNTAX TimeTicks UNITS "hundredths of a second" MAX-ACCESS read-only STATUS current DESCRIPTION "The time (in hundredths of a second) since the DAC module was last re-initialized." ::=3D { radiusDynAuthClientScalars 3 } I recommend adding this attribute to the RadiusDynAuthServerEntry = instead. The issue is that (for example in our box) we have instances of = authentication MIB tables spread accross multiple nodes. Therefore it is = possible for a node to reboot and have discontinuities independent of = the mib as a whole. 2) The update to RFC-2618 = http://www.ietf.org/internet-drafts/draft-ietf-radext-rfc2618bis-02.txt = does not have a discontinuity timer. Again, I suggest adding the value = to the table. Also, it there some reason why the authors did not just = deprecate the radiusAuthServerAddress and then add the IPv6 attributes = to the existing table. IE, why deprecate the entire table. 3) same comments as 2 for the uptdate to RFC 2620 - = http://www.ietf.org/internet-drafts/draft-ietf-radext-rfc2620bis-02.txt I have not implemented the server side mibs or reviewed the updates to = them. The same or similar comments might apply. > > if so, I would suggest adding it per radius entry so that > > each server can have its own value. >=20 > That seems like a reasonable suggestion. >=20 Any idea when the next revision of the updates for 2618 and 2620 would = be published? > > One other point to note. We have found that radius servers respond > faster > > than 100th of a second. I'd suggest an update to the MIB where the > > response time is stored in micro-seconds. In addition, having the > minimum, > > maximum and average are also helpful. We are adding such=20 > values to our > > enterprise MIB, but would opt for standard attributes if=20 > they existed. >=20 > The revised MIBs have already been through WG last call and are now in > IESG review. Does the WG wish to recall the documents from the > publication requested state to consider adding this kind of=20 > new feature? >=20 >=20 Any one interested in this? Carl -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 29 Mar 2006 23:50:49 +0000 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: radiusext@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-radext-dynauth-client-mib-05.txt Message-Id: Date: Wed, 29 Mar 2006 18:50:02 -0500 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the RADIUS EXTensions Working Group of the IETF. Title : Dynamic Authorization Client MIB Author(s) : S. De Cnodder, et al. Filename : draft-ietf-radext-dynauth-client-mib-05.txt Pages : 30 Date : 2006-3-29 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes the Remote Authentication Dial In User Service (RADIUS) [RFC2865] Dynamic Authorization Client (DAC) functions that support the dynamic authorization extensions as defined in RFC 3576. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-radext-dynauth-client-mib-05.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-radext-dynauth-client-mib-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-radext-dynauth-client-mib-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-3-29160412.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-radext-dynauth-client-mib-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-radext-dynauth-client-mib-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-3-29160412.I-D@ietf.org> --OtherAccess-- --NextPart-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 29 Mar 2006 23:50:41 +0000 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: radiusext@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-radext-dynauth-server-mib-05.txt Message-Id: Date: Wed, 29 Mar 2006 18:50:02 -0500 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the RADIUS EXTensions Working Group of the IETF. Title : Dynamic Authorization Server MIB Author(s) : S. De Cnodder, et al. Filename : draft-ietf-radext-dynauth-server-mib-05.txt Pages : 28 Date : 2006-3-29 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes the Remote Authentication Dial In User Service (RADIUS) [RFC2865] Dynamic Authorization Server (DAS) functions that support the dynamic authorization extensions as defined in RFC 3576. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-radext-dynauth-server-mib-05.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-radext-dynauth-server-mib-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-radext-dynauth-server-mib-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-3-29160628.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-radext-dynauth-server-mib-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-radext-dynauth-server-mib-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-3-29160628.I-D@ietf.org> --OtherAccess-- --NextPart-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 29 Mar 2006 17:59:06 +0000 Message-ID: From: "Bernard Aboba" To: Hannes.Tschofenig@gmx.net, radiusext@ops.ietf.org Cc: paul_congdon@hp.com Bcc: Subject: RE: Review of draft-ietf-radext-vlan-02.txt Date: Wed, 29 Mar 2006 09:58:17 -0800 Mime-Version: 1.0 Content-Type: text/plain; format=flowed >The document does not describe the semantic when the User-Priority-Table >attribute is included in the Access-Request. I was also a bit puzzled by this. Presumably the switch sends the default configuration, but I am not sure. >Section 1.3 talks about the provisioning semantic when included in the >Access-Accept. I think it is necessary to describe the semantical >difference between these two approaches. The document says that the attribute when included in the Access-Request is a "hint". So I don't think that there is any provisioning going on in the Access-Request. >How is the data traffic mapped to the QoS class? Which attribute carries >this flow identifier? I think it is necessary to provide a description. My understanding is that we are only talking about remapping of priority bits that are already set on inbound, and that this is described in IEEE 802.1D. >Why is the length of the value carried in the User-Priority-Table attribute >10 bytes long? It isn't. RADIUS includes the type and length fields in the total length, so it's 8 bytes long. >You seem to assume that the RADIUS server knows something about the link >specific properties. The document specifies attributes for use with IEEE 802 networks. Information on the specific link type is provided in the NAS-Port-Type attribute. >1) What happens if the RADIUS server receives the User-Priority-Table >attribute in the Access-Request but it has only Y.1541 QoS classes stored >in the user's profile? Since this would be a hint, I presume the server is free to ignore it. >Do you assume that the RADIUS server is able to provide a mapping? Since it's a hint, I wouldn't think so. The RADIUS server isn't compelled to include the User-Priority-Table attribute in the Access-Accept. >Should the RADIUS server fail when it either does not understand the QoS >classes or if it is unable to map them? It is possible that implementations may not react well to the hint, but if they do understand the hint, they shouldn't fail because they don't return a User-Priority-Table in the Access-Accept. >Should the RADIUS client know what the RADIUS server understands? I think that is only important if RADIUS servers won't react well to the hint. If servers don't send the attribute, the client probably won't care. >2) Is the an applicability problem with provisioning in a roaming >environment when the RADIUS server of my home network sends the >User-Priority-Table attribute to the visited network which might be a IEEE >802.16e network? Presumably the attribute will only be sent if the NAS-Port-Type attribute indicates that it would be useful. 802.16k implements bridging, but 802.16e does not, so I don't think it would make sense to send this attribute to a RADIUS client running 802.16e. However, it appears there is no NAS-Port-Type for 802.16e, 802.16k, 802.20, etc. There probably should be. >Would it be necessary for the RADIUS client to indicate that it is attached >to a IEEE 802.1D network with support for the QoS classes in order to allow >the Access-Accept message to be meaningful? The NAS-Port-Type attribute should provide this information. >How long is the authoriziation decision valid when the User-Priority-Table >attribute in sent in the Access-Request? Presumably until the expiration of Session-Timeout. >Do you see a need to reflect the QoS decision in the interworking with >accounting or RADIUS prepaid (e.g., cost of the reservation)? The attributes are not indicated to be sent in Accounting-Request packets, but perhaps they should be. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 28 Mar 2006 18:19:28 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: RE: looking for advise on RFC-2618 and 2620 Date: Tue, 28 Mar 2006 13:19:13 -0500 Message-ID: <3CFB564E055A594B82C4FE89D215656021918A@MABOSEVS2.ets.enterasys.com> Thread-Topic: looking for advise on RFC-2618 and 2620 Thread-Index: AcZSkTMQOAT5dPExTHW9ppbGZgVniAAAli3g From: "Nelson, David" To: Carl Kalbfleisch writes... > I realize that these MIBs are being updated, > so perhaps we can add a discontinuity timer in a future revision.=20 This is already an open issue from Area Director review of the revised MIB drafts, so will be included in the next draft version. > if so, I would suggest adding it per radius entry so that > each server can have its own value. That seems like a reasonable suggestion. > One other point to note. We have found that radius servers respond faster > than 100th of a second. I'd suggest an update to the MIB where the > response time is stored in micro-seconds. In addition, having the minimum, > maximum and average are also helpful. We are adding such values to our > enterprise MIB, but would opt for standard attributes if they existed. The revised MIBs have already been through WG last call and are now in IESG review. Does the WG wish to recall the documents from the publication requested state to consider adding this kind of new feature? -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 28 Mar 2006 18:00:09 +0000 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: looking for advise on RFC-2618 and 2620 Date: Tue, 28 Mar 2006 11:58:20 -0600 Message-ID: <7221140AD3DA7C4DB2CD49771243D8DD0134800E@nrmail01.netrake.net> Thread-Topic: looking for advise on RFC-2618 and 2620 Thread-Index: AcZSkTMQOAT5dPExTHW9ppbGZgVniA== From: "Carl Kalbfleisch" To: Hi, I am a new subscriber to this group. I have implemented RFC-2618 and = RFC-2620 in our security gateway. We allow the user to configure two = accounting and two authentication servers. These show up as instances 1 = and 2 in the associated tables in these MIBs. Now an issue arises if the = user changes the IP or port of the radius servers. The system is now = pointing to a different server. However, the counters are still whatever = they are. I have a request to clear the counters, but this could cause = spikes in the NMS to think the counter wrapped. What is needed is some = discontinuity time value. I was thinking of overloading the IP and port = attributes for our implementation and telling end users that if those = values change then the counters should be treated as a discontinuity = event. I realize that this would be non-standard so wanted to get some = feedback on best practices. I realize that these MIBs are being updated, = so perhaps we can add a discontinuity timer in a future revision. if so, = I would suggest adding it per radius entry so that each server can have = its own value. One other point to note. We have found that radius servers respond = faster than 100th of a second. I'd suggest an update to the MIB where = the response time is stored in micro-seconds. In addition, having the = minimum, maximum and average are also helpful. We are adding such values = to our enterprise MIB, but would opt for standard attributes if they = existed. Thoughts and comments appreciated. Carl -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 28 Mar 2006 11:40:07 +0000 Message-Id: <1E4CCB2441C5C0409AD8A929482A09F31BB696@S4DE9JSAAIG.ost.t-com.de> From: "Beck01, Wolfgang" To: radiusext@ops.ietf.org Cc: miguel.an.garcia@nokia.com Subject: digest-auth surgery in Dallas Date: Tue, 28 Mar 2006 13:39:45 +0200 MIME-Version: 1.0 Content-Type: text/plain Hi, during the RADEXT meeting in Dallas, we came to the conclusion that removing the client nonce generation mode would solve most - if not all - of the remaining issues with draft-ietf-radext-digest-auth. Miguel would have to remove the relating parts from his Diameter draft as well (sorry). Anybody objecting to this proposal should speak up >>now<< and suggest how to address the issues as outlined in http://www3.ietf.org/proceedings/06mar/slides/radext-0.pdf Wolfgang -- T-Systems Next Generation IP Services and Systems +49 6151 937 2863 Am Kavalleriesand 3 64295 Darmstadt Germany -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 28 Mar 2006 11:38:15 +0000 Message-ID: <44292006.608@gmx.net> Date: Tue, 28 Mar 2006 05:37:42 -0600 From: Hannes Tschofenig User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) MIME-Version: 1.0 To: radiusext@ops.ietf.org Subject: Review of draft-ietf-radext-vlan-02.txt Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi all, I reviewed the draft and I came across a number of questions. I am referring only to the User-Priority-Table attribute. The document defines a QoS provisioning and authorization solution based on traffic classes. These classes are defined in IEEE 802.1D. The document does not describe the semantic when the User-Priority-Table attribute is included in the Access-Request. Section 1.3 talks about the provisioning semantic when included in the Access-Accept. I think it is necessary to describe the semantical difference between these two approaches. How is the data traffic mapped to the QoS class? Which attribute carries this flow identifier? I think it is necessary to provide a description. Why is the length of the value carried in the User-Priority-Table attribute 10 bytes long? (We are talking about 8 QoS classes, as I read from Annex G.) Why is the data type a string? You seem to assume that the RADIUS server knows something about the link specific properties. I got the feedback that this is not appreciated for QoS. Here are two examples: 1) What happens if the RADIUS server receives the User-Priority-Table attribute in the Access-Request but it has only Y.1541 QoS classes stored in the user's profile? Do you assume that the RADIUS server is able to provide a mapping? Should the RADIUS server fail when it either does not understand the QoS classes or if it is unable to map them? Should the RADIUS client know what the RADIUS server understands? 2) Is the an applicability problem with provisioning in a roaming environment when the RADIUS server of my home network sends the User-Priority-Table attribute to the visited network which might be a IEEE 802.16e network? According to your description the RADIUS client would fail according to the description in Section 1.3. Would it be necessary for the RADIUS client to indicate that it is attached to a IEEE 802.1D network with support for the QoS classes in order to allow the Access-Accept message to be meaningful? How long is the authoriziation decision valid when the User-Priority-Table attribute in sent in the Access-Request? Do you see a need to reflect the QoS decision in the interworking with accounting or RADIUS prepaid (e.g., cost of the reservation)? Ciao Hannes PS: It might be good to find a few QoS experts for review of this document. I could try to find someone, if you want. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Mon, 27 Mar 2006 20:50:22 +0000 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: radiusext@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-radext-vlan-02.txt Message-Id: Date: Mon, 27 Mar 2006 15:50:01 -0500 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the RADIUS EXTensions Working Group of the IETF. Title : RADIUS Attributes for Virtual LAN and Priority Support Author(s) : P. Congdon, et al. Filename : draft-ietf-radext-vlan-02.txt Pages : 14 Date : 2006-3-27 This document proposes additional RADIUS (Remote Authentication Dial In User Service) attributes for dynamic Virtual LAN assignment and prioritization, for use by IEEE 802.1X authenticators. These attributes are usable within either RADIUS or Diameter. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-radext-vlan-02.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-radext-vlan-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-radext-vlan-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-3-27135255.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-radext-vlan-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-radext-vlan-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-3-27135255.I-D@ietf.org> --OtherAccess-- --NextPart-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Sun, 26 Mar 2006 22:42:11 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: [Issue] Editorial nits on prefix delegation Date: Sun, 26 Mar 2006 17:41:42 -0500 Message-ID: <15B86BC7352F864BB53A47B540C089B601615AC4@xmb-rtp-20b.amer.cisco.com> Thread-Topic: [Issue] Editorial nits on prefix delegation Thread-Index: AcY+/XpvR564gH29SY+VgTiHrH4+NwSJvPBQ From: "Greg Weber \(gdweber\)" To: Description of issue: Editorial cmts on prefix delegation Submitter name: Greg Weber Submitter email address: gdweber@cisco.com Date first submitted: March 26th, 2006 Reference: n/a Document: draft-ietf-radext-delegated-prefix-00.txt Comment type: 'E'ditorial Priority: '2' May fix Section: 2 & 5 Rationale/Explanation of issue: The draft looks ok to me. A couple editorial nits: Section 5: "IP SEC" -> "IPsec" Section 2: The idnit checker at tools.ietf.org complains: Miscellaneous warnings: - The document seems to use RFC 2119 keywords,=20 but does not seem to contain the recommended=20 RFC 2119 boilerplate because the text of section 2 is not exactly like like the boilerplate in 2119 (missing quote marks). =20 Greg > -----Original Message----- > From: owner-radiusext@ops.ietf.org=20 > [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Bernard Aboba > Sent: Friday, March 03, 2006 3:02 PM > To: radiusext@ops.ietf.org > Subject: RADEXT WG Last Call on "RADIUS Delegated IPv6 Prefix=20 > Attribute" >=20 > This is an announcement of RADEXT WG last call on the "RADIUS=20 > Delegated-IPv6=20 > Prefix Attribute" > document, prior to sending this document on to the IESG for=20 > consideration as=20 > a Proposed > Standard. >=20 > The document is available for inspection here: > http://www.ietf.org/internet-drafts/draft-ietf-radext-delegated-prefix-0 0.txt >=20 > RADEXT WG last call will last until Monday March 27, 2006. =20 > Please send your > comments to the RADEXT WG list (radiusext@ops.ietf.org) in the format=20 > described > on the RADEXT Issues List: > http://www.drizzle.com/~aboba/RADEXT/ >=20 > Since all RADEXT WG last calls require at least 5 reviewers=20 > in order to=20 > advance > the document, please respond indicating that you have read=20 > the document and > find it acceptable, even if you have no issues to file. >=20 >=20 >=20 > -- > to unsubscribe send a message to radiusext-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: >=20 -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Sat, 25 Mar 2006 01:18:49 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Dime] RE: RADIUS to Diameter gateways & extended attributes Date: Sat, 25 Mar 2006 03:17:48 +0200 Message-ID: <1AA39B75171A7144A73216AED1D7478D0186A10E@esebe100.NOE.Nokia.com> Thread-Topic: [Dime] RE: RADIUS to Diameter gateways & extended attributes Thread-Index: AcZPTgr3lVZrqhFZTx2dtGV/E4mDrAABgofQABVvd3A= From: To: , , , Cc: , Jouni, >> > o how to provide Diameter's request redirecting on RADIUS side >> > (redirect-host etc + the functionality) >>=20 >> I was unaware of this request. I think that satisfying it > >Hmm.. I think 3GPP has not asked RADEXT to do anything on=20 >request redirecting, mostly because of the reasons you pointed out below. >It is just an open issue for 3GPP under the same topic and as=20 >far as I know it will also stay as their headache. > >However, I wouldn't mind having some documented guidelines or=20 >facts on this as I think 3GPP might not be the only SDO /=20 >entity having the same issue. > >> will be difficult >> since RADIUS (unlike Diameter) requires pre-set credentials and does not >> support DNS-based location of servers. Therefore redirection support alone >> will not make this work; it is necessary to enhance the RADIUS=20 >> protocol substantially. So, what is it that you want, in ways of guidelines - why it won't work? John -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 24 Mar 2006 16:11:26 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Dime] RE: RADIUS to Diameter gateways & extended attributes Date: Fri, 24 Mar 2006 17:11:01 +0100 Message-ID: <5D25AEFB114D034FBDC8B156FCA78E03BFADB4@SEHAN021MB.tcad.telia.se> Thread-Topic: [Dime] RE: RADIUS to Diameter gateways & extended attributes Thread-Index: AcZPTgr3lVZrqhFZTx2dtGV/E4mDrAABgofQ From: To: , , , Cc: , Bernand, > > o how to provide Diameter's request redirecting on RADIUS side > > (redirect-host etc + the functionality) >=20 > I was unaware of this request. I think that satisfying it=20 Hmm.. I think 3GPP has not asked RADEXT to do anything on request redirecting, mostly because of the reasons you pointed out below. It is just an open issue for 3GPP under the same topic and as far as I know it will also stay as their headache. However, I wouldn't mind having some documented guidelines or facts on this as I think 3GPP might not be the only SDO / entity having the same issue. > will be difficult=20 > since RADIUS (unlike Diameter) requires pre-set credentials=20 > and does not=20 > support DNS-based location of servers. Therefore=20 > redirection support alone=20 > will not make this work; it is necessary to enhance the=20 > RADIUS protocol=20 > substantially. Cheers, Jouni -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 24 Mar 2006 14:20:14 +0000 Message-ID: From: "Bernard Aboba" To: jouni.korhonen@teliasonera.com, john.loughney@nokia.com, aland@ox.org, david@mitton.com Cc: dime@ietf.org, radiusext@ops.ietf.org Bcc: Subject: RE: [Dime] RE: RADIUS to Diameter gateways & extended attributes Date: Fri, 24 Mar 2006 06:19:57 -0800 Mime-Version: 1.0 Content-Type: text/plain; format=flowed > o how to provide Diameter's NAS-Filter-Rule also on RADIUS > (current reference is to now splitted radext-ieee802 draft) As we discussed in the RADEXT WG meeting, it seems to make sense to define a NAS-Filter-Rule attribute in RADIUS, in addition to the Filter-ID and NAS-Traffic-Rule attributes. However, only one of these attributes can be included in a single packet. > o how to provide Diameter's request redirecting on RADIUS side > (redirect-host etc + the functionality) I was unaware of this request. I think that satisfying it will be difficult since RADIUS (unlike Diameter) requires pre-set credentials and does not support DNS-based location of servers. Therefore redirection support alone will not make this work; it is necessary to enhance the RADIUS protocol substantially. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 24 Mar 2006 14:00:47 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Dime] RE: RADIUS to Diameter gateways & extended attributes Date: Fri, 24 Mar 2006 15:00:09 +0100 Message-ID: <5D25AEFB114D034FBDC8B156FCA78E03BFADAA@SEHAN021MB.tcad.telia.se> Thread-Topic: [Dime] RE: RADIUS to Diameter gateways & extended attributes Thread-Index: AcZO3yhVi7m5tZtvQ8KH/uvD3R7TOwAADOIwABm9dcA= From: To: , , Cc: , Hi, The 3GPP I-WLAN spec 29.234 is the only place in 3GPP scope that I remember that has D->R and R->D cases (on Wa and Wd interfaces). Currently the spec only says that the D->R and R->D cases are done according to the NASREQ and the Diam-EAP. In 3GPP I-WLAN point of view there are couple open issues under this topic: o how to provide Diameter's NAS-Filter-Rule also on RADIUS (current reference is to now splitted radext-ieee802 draft) o how to provide Diameter's request redirecting on RADIUS side (redirect-host etc + the functionality) Cheers, Jouni =20 > -----Original Message----- > From: john.loughney@nokia.com [mailto:john.loughney@nokia.com]=20 > Sent: 24. maaliskuuta 2006 3:09 > To: aland@ox.org; david@mitton.com > Cc: dime@ietf.org; radiusext@ops.ietf.org > Subject: [Dime] RE: RADIUS to Diameter gateways & extended attributes=20 >=20 > Hi all, >=20 > >David Mitton wrote: > >> I'd like to hear from people that actually have such things, as we=20 > >> didn't get very many responses in the Dime meeting room. =20 > I'll chase=20 > >> that in a different thread. > > > > Knowing current D->R gateway practices would help, thanks. >=20 > Could some people on the DiME mailing list point out anything? I know > that 3GPP has some plans for such things. Maybe someone could explain > what is happening in 3GPP or other SD0s? >=20 > John >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime >=20 -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 24 Mar 2006 05:07:39 +0000 Message-ID: From: "Bernard Aboba" To: radiusext@ops.ietf.org Bcc: Subject: Last look at VLAN and Priority Document Date: Thu, 23 Mar 2006 21:07:23 -0800 Mime-Version: 1.0 Content-Type: text/plain; format=flowed RADEXT WG last call has completed on the RADIUS VLAN and Priority document, and all issues appear to have been resolved. The updated document is available here: http://www.ietf.org/internet-drafts/draft-ietf-radext-vlan-01.txt Please have a look at the document. If we do not hear about any additional issues we will send the document on to the iESG for consideration as a Proposed Standard by March 30, 2006. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 24 Mar 2006 04:51:13 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C64EFE.91449025" Subject: RE: Radius Dyn auth MIBs with the updates Date: Fri, 24 Mar 2006 10:20:29 +0530 Message-ID: <61D6551D82BC7149967B39B5C66879F8F58DB1@xmb-blr-416.apac.cisco.com> Thread-Topic: Radius Dyn auth MIBs with the updates Thread-Index: AcZORgt2cP+y8ReJRLWEosBADVoohgAtwf3A From: "Nagi Reddy Jonnala \(njonnala\)" To: "Nagi Reddy Jonnala \(njonnala\)" , , "Wijnen, Bert \(Bert\)" , This is a multi-part message in MIME format. ------_=_NextPart_001_01C64EFE.91449025 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable All, =20 We realized that the compliance statement doesn't say that this MIB support IPv4 addresses ONLY. May be this statement is OK for the other four MIBs since they had old IPv4-only MIBs. But even there since they obsolete(correct?) the old MIBs, should they also spell similar to the inline comment. =20 4. Compliance statements now say that we only support IPv4 and IPV6 =20 =20 Here is the compliance statement and the new objects. radiusDynAuthClientMIBCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for entities implementing the RADIUS Dynamic Authorization Client. Implementation of this module is for entities that support IPv6, or support IPv4 and IPv6." MODULE -- this module MANDATORY-GROUPS { radiusDynAuthClientMIBGroup } =20 Should it be something like "Implementation of this module is for entities that support IPv4 or IPv6 or both IPv4 and IPv6". Does this make sense? =20 Thanks Nagi. =20 =20 =20 =20 =20 =20 ------_=_NextPart_001_01C64EFE.91449025 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
All,
 
We = realized=20 that the compliance statement doesn't say that this MIB = support=20 IPv4 addresses ONLY. May be this statement is OK for = the=20 other four MIBs since they had old IPv4-only MIBs.  But even there since they obsolete(correct?) the = old MIBs,=20 should they also spell similar to the inline=20 comment.
 
 4. Compliance = statements now say that we only support IPv4 = and=20 IPV6  
 
 Here is the compliance statement and the new=20 objects.

radiusDynAuthClientMIBCompliance=20 MODULE-COMPLIANCE
       STATUS  = current
      =20 = DESCRIPTION
         &nbs= p;  =20 "The compliance statement for entities=20 = implementing
         &nb= sp;   =20 the RADIUS Dynamic Authorization Client.=20 Implementation
        of this = module is=20 for entities that support IPv6,=20 or
        support IPv4 and=20 IPv6."
       MODULE  -- this=20 module
       MANDATORY-GROUPS {=20 radiusDynAuthClientMIBGroup }

       

 <Nagi> Should it=20 be something like "Implementation of this module is for entities = that=20 support IPv4 or IPv6 or both IPv4 and IPv6". Does this make=20 sense?

 

Thanks

Nagi.

 

    

 
 
 
 
------_=_NextPart_001_01C64EFE.91449025-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 24 Mar 2006 01:09:03 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: RADIUS to Diameter gateways & extended attributes Date: Fri, 24 Mar 2006 03:08:49 +0200 Message-ID: <1AA39B75171A7144A73216AED1D7478D0186A0F0@esebe100.NOE.Nokia.com> Thread-Topic: RADIUS to Diameter gateways & extended attributes Thread-Index: AcZO3yhVi7m5tZtvQ8KH/uvD3R7TOwAADOIw From: To: , Cc: , Hi all, >David Mitton wrote: >> I'd like to hear from people that actually have such things, as we=20 >> didn't get very many responses in the Dime meeting room. I'll chase=20 >> that in a different thread. > > Knowing current D->R gateway practices would help, thanks. Could some people on the DiME mailing list point out anything? I know that 3GPP has some plans for such things. Maybe someone could explain what is happening in 3GPP or other SD0s? John -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 24 Mar 2006 01:05:22 +0000 From: "Alan DeKok" To: David Mitton Subject: Re: RADIUS to Diameter gateways & extended attributes cc: radiusext@ops.ietf.org Date: Thu, 23 Mar 2006 20:13:09 -0500 Message-Id: <20060324011309.535C116CC1@mail.nitros9.org> David Mitton wrote: > I'd like to hear from people that actually have such things, as we > didn't get very many responses in the Dime meeting room. I'll chase > that in a different thread. Knowing current D->R gateway practices would help, thanks. > We already have this. It's the Origin-AAA-Protocol AVP (AVP Code 408) > RFC 4005, Section 9.3.6 Which talks about the message origin, not attribute origin. Since Diameter servers can use RADIUS attributes in Diameter messages, D->R gateways may receive many "RADIUS" attributes in a Diameter message, and may not be able to encapsulate them all in RADIUS. This would appear to be a larger problem than just the Diameter attribute format in RADIUS that we've been discussing until now. I haven't been following Diameter, so I have no idea if this *is* a problem in practice, and if so, how do implementations deal with it. Alan DeKok. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 24 Mar 2006 00:16:16 +0000 Message-Id: <6.2.5.6.2.20060323190624.046eb6a0@mitton.com> Date: Thu, 23 Mar 2006 19:16:01 -0500 To: radiusext@ops.ietf.org From: David Mitton Subject: Re: RADIUS to Diameter gateways & extended attributes Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed At 3/21/2006 02:08 PM, you wrote: > Some issues were raised during the WG meeting today. I'll try to >address them here. > > The purpose behind using the Diameter format to carry extended >RADIUS attributes is to simplify the work done by RADIUS to Diameter >gateways. As a result, any issue of Diameter to RADIUS gatewaying and >attribute/message size is largely out of scope. > > That is, it doesn't matter so much that Diameter can carry much more >traffic per attribute/message than RADIUS can, because that is not the >purpose behind the use of the Diameter attribute format. If that is >true, we then have to ensure that Diameter to RADIUS gateways don't >pass large Diameter attributes/messages to RADIUS. > > Since we already have Diameter to RADIUS gateways that perform this >enforcement, it would appear that this worry is largely not a problem >in practice. I'd like to hear from people that actually have such things, as we didn't get very many responses in the Dime meeting room. I'll chase that in a different thread. > However... with the advent of many more RADIUS attributes being >carried in Diameter, it would be good to enable Diameter to RADIUS >gateways to tell which attributes *can* fit into RADIUS, and which >cannot. One suggestion in the "extended attribute" subgroup was to >allocate the Diameter-format RADIUS attributes from a subset of the >Diameter space. The gateways could then trivially tell which >attributes are RADIUS compatible. > > That suggestion may be problematic if a Diameter server adds >additional RADIUS compatible attributes to a Diameter message that >contains attributes previously taken from RADIUS. There is no way for >a Diameter to RADIUS gateway to be sure if the attributes fit into a >RADIUS packet. > > Another option would be to add a "RADIUS" bit to the Diameter >attribute. Any attribute that came from a RADIUS to Diameter gateway >would have that bit set, allowing later servers to handle them more >appropriately. We already have this. It's the Origin-AAA-Protocol AVP (AVP Code 408) RFC 4005, Section 9.3.6 > I think this addresses Glen's comments. It doesn't matter how large >Diameter messages/attributes are if RADIUS servers never see that >data. Since the Diameter format is used by the RADIUS servers only to >*generate* RADIUS compatible traffic, and not to receive Diameter >traffic, any compatibility issue is pushed to the Diameter side of the >protocol implementations. > > Alan DeKok. > >-- Right, but I don't think that's actually the problem Glen is chasing, but I'll leave that to him. Dave. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 23 Mar 2006 23:50:37 +0000 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: radiusext@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-radext-vlan-01.txt Message-Id: Date: Thu, 23 Mar 2006 18:50:01 -0500 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the RADIUS EXTensions Working Group of the IETF. Title : RADIUS Attributes for Virtual LAN and Priority Support Author(s) : P. Congdon, et al. Filename : draft-ietf-radext-vlan-01.txt Pages : 14 Date : 2006-3-23 This document proposes additional RADIUS (Remote Authentication Dial In User Service) attributes for dynamic Virtual LAN assignment and prioritization, for use by IEEE 802.1X authenticators. These attributes are usable within either RADIUS or Diameter. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-radext-vlan-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-radext-vlan-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-radext-vlan-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-3-23155149.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-radext-vlan-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-radext-vlan-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-3-23155149.I-D@ietf.org> --OtherAccess-- --NextPart-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 23 Mar 2006 06:51:05 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C64E46.0AB5C8D0" Subject: Radius Dyn auth MIBs with the updates Date: Thu, 23 Mar 2006 12:20:17 +0530 Message-ID: <61D6551D82BC7149967B39B5C66879F8F58C32@xmb-blr-416.apac.cisco.com> Thread-Topic: Radius Dyn auth MIBs with the updates Thread-Index: AcZORgt2cP+y8ReJRLWEosBADVoohg== From: "Nagi Reddy Jonnala \(njonnala\)" To: , "Wijnen, Bert \(Bert\)" , This is a multi-part message in MIME format. ------_=_NextPart_001_01C64E46.0AB5C8D0 Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01C64E46.0AB5C8D0" ------_=_NextPart_002_01C64E46.0AB5C8D0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable All, =20 I've attached the revised Dyn Auth client and server drafts. Could you please review if these are inline with your suggestions. =20 Here is a brief summary of changes for your quick reference =20 1. Replaced with "itself" in the cleint draft. Server draft was fine. 2. Added a new time stamp scalar. Juergen suggestion of having scalars group is helpful here. - Incremented the number of scalars in the Overview sections - Referred to this new object while updating the counter objects=20 - Mentioned the same in Compliance Here is the definition of the time stamp scalar. The same follows for the other draft. radiusDynAuthClientCounterDiscontinuity OBJECT-TYPE SYNTAX TimeTicks UNITS "hundredths of a second" MAX-ACCESS read-only STATUS current DESCRIPTION "The time (in hundredths of a second) since the DAC module was last re-initialized." ::=3D { radiusDynAuthClientScalars 3 } Each counter object has got a new sentence that says the below. "This counter may experience a discontinuity when the DAC module (re)starts as indicated by the value of radiusDynAuthClientCounterDiscontinuity." 3. "Port number 0 is invalid" mentioned for radiusDynAuthServerClientPortNumber object 4. Compliance statements now say that we only support IPv4 and IPV6 5. InetAddress objects are updated with what InetAddressType object determines the address Here is the compliance statement and the new objects. radiusDynAuthClientMIBCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for entities implementing the RADIUS Dynamic Authorization Client. Implementation of this module is for entities that support IPv6, or support IPv4 and IPv6." MODULE -- this module MANDATORY-GROUPS { radiusDynAuthClientMIBGroup } OBJECT radiusDynAuthServerAddressType SYNTAX InetAddressType { ipv4(1), ipv6(2) } DESCRIPTION "An implementation is only required to support IPv4 and globally unique IPv6 addresses." OBJECT radiusDynAuthServerAddress SYNTAX InetAddress (SIZE(4|16))=20 DESCRIPTION "An implementation is only required to support IPv4 and globally unique IPv6 addresses." GROUP radiusDynAuthClientAuthOnlyGroup DESCRIPTION "Only required for Dynamic Authorization Clients that are supporting Service-Type attributes with value 'Authorize-Only'." =20 GROUP radiusDynAuthClientNoSessGroup DESCRIPTION "This group is not required in case the Dynamic Authorization Server can not easily determine whether a session exists or not (e.g., in case of a RADIUS proxy)." ::=3D { radiusDynAuthClientMIBCompliances 1 } =20 Thanks Nagi =20 =20 =20 =20 =20 ------_=_NextPart_002_01C64E46.0AB5C8D0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
All,
 
I've = attached the=20 revised  Dyn Auth client and server drafts. Could you please = review if=20 these are inline with your suggestions.
 
Here = is a brief=20 summary of changes for your quick reference
 
1. Replaced=20 with "itself" in the cleint draft. Server draft was fine.

2. Added a new time stamp scalar. Juergen = suggestion of having scalars group = is=20 helpful here.

-=20 Incremented the number of scalars in = the Overview=20 sections

- Referred to this new object while = updating=20 the counter objects =

- Mentioned the same in = Compliance

Here is = the definition=20 of the time stamp scalar. The same follows for the other=20 draft.

radiusDynAuthClientCounterDiscontinuity=20 OBJECT-TYPE
          = SYNTAX=20 TimeTicks
          = UNITS =20 "hundredths of a=20 second"
          = MAX-ACCESS=20 read-only
          = STATUS=20 current
         =20 DESCRIPTION

       &nbs= p;       =20 "The time (in hundredths of a second) since=20 the
           =      =20 DAC module was last=20 re-initialized."
         = ; ::=3D {=20 radiusDynAuthClientScalars 3 }

Each = counter object=20 has got a new sentence that says the below.

"This = counter may=20 experience a discontinuity when the DAC module (re)starts = as indicated=20 by the value = of radiusDynAuthClientCounterDiscontinuity."

3. "Port number 0 is invalid"=20 mentioned for=20 radiusDynAuthServerClientPortNumber  = object

4. Compliance statements now say that we only support IPv4 = and IPV6 5.=20 InetAddress objects are updated with what InetAddressType object determines the address

Here is = the compliance=20 statement and the new objects.

radiusDynAuthClientMIBCompliance=20 MODULE-COMPLIANCE
       STATUS =20 current
      =20 DESCRIPTION
         &nbs= p;  =20 "The compliance statement for entities=20 implementing
         &nb= sp;   =20 the RADIUS Dynamic Authorization Client.=20 Implementation
        of this = module is=20 for entities that support IPv6, = or
       =20 support IPv4 and IPv6."
       = MODULE  --=20 this module
       MANDATORY-GROUPS {=20 radiusDynAuthClientMIBGroup }

       = OBJECT    =20   =20 radiusDynAuthServerAddressType
      =20 SYNTAX        InetAddressType { ipv4(1), = ipv6(2)=20 }
      =20 DESCRIPTION
         &nbs= p; "An=20 implementation is only required to support IPv4=20 and
           = =20 globally unique IPv6 addresses."

       = OBJECT    =20    = radiusDynAuthServerAddress
      =20 SYNTAX        InetAddress (SIZE(4|16))=20
      =20 DESCRIPTION
         &nbs= p; "An=20 implementation is only required to support IPv4=20 and
           = =20 globally unique IPv6 addresses."


      =20 GROUP           &n= bsp; =20 radiusDynAuthClientAuthOnlyGroup
       = DESCRIPTION
         &nbs= p;  =20 "Only required for Dynamic Authorization Clients=20 that
           = ;  =20 are supporting Service-Type attributes with=20 value
          &nbs= p;  =20 'Authorize-Only'."

 
      =20 GROUP           &n= bsp; =20 radiusDynAuthClientNoSessGroup
      =20 DESCRIPTION
         &nbs= p;  =20 "This group is not required in case the=20 Dynamic
          &n= bsp;  =20 Authorization Server can not easily determine=20 whether
          &n= bsp;  =20 a session exists or not (e.g., in case of a=20 RADIUS
          &nb= sp;  =20 proxy)."

       ::=3D { = radiusDynAuthClientMIBCompliances=20 1 }

 

Thanks

Nagi

 

 
 
 
 
------_=_NextPart_002_01C64E46.0AB5C8D0-- ------_=_NextPart_001_01C64E46.0AB5C8D0 Content-Type: text/plain; name="mib-client-15.txt" Content-Transfer-Encoding: base64 Content-Description: mib-client-15.txt Content-Disposition: attachment; filename="mib-client-15.txt" DQoNCg0KDQpOZXR3b3JrIFdvcmtpbmcgR3JvdXAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIFMuIERlIENub2RkZXINCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgQWxjYXRlbA0KRXhwaXJlczogU2VwdGVt YmVyIDIzLCAyMDA2ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBOLiBKb25uYWxh DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgTS4gQ2hpYmENCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgQ2lzY28gU3lzdGVtcywgSW5jLg0KICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIE1hcmNoIDIyLCAyMDA2DQoNCg0K ICAgICAgICAgICAgICAgICAgICBEeW5hbWljIEF1dGhvcml6YXRpb24gQ2xpZW50IE1JQg0KICAg ICAgICAgICAgICBkcmFmdC1pZXRmLXJhZGV4dC1keW5hdXRoLWNsaWVudC1taWItMDUudHh0DQoN ClN0YXR1cyBvZiB0aGlzIE1lbW8NCg0KICAgQnkgc3VibWl0dGluZyB0aGlzIEludGVybmV0LURy YWZ0LCBlYWNoIGF1dGhvciByZXByZXNlbnRzIHRoYXQgYW55DQogICBhcHBsaWNhYmxlIHBhdGVu dCBvciBvdGhlciBJUFIgY2xhaW1zIG9mIHdoaWNoIGhlIG9yIHNoZSBpcyBhd2FyZQ0KICAgaGF2 ZSBiZWVuIG9yIHdpbGwgYmUgZGlzY2xvc2VkLCBhbmQgYW55IG9mIHdoaWNoIGhlIG9yIHNoZSBi ZWNvbWVzDQogICBhd2FyZSB3aWxsIGJlIGRpc2Nsb3NlZCwgaW4gYWNjb3JkYW5jZSB3aXRoIFNl Y3Rpb24gNiBvZiBCQ1AgNzkuDQoNCiAgIEludGVybmV0LURyYWZ0cyBhcmUgd29ya2luZyBkb2N1 bWVudHMgb2YgdGhlIEludGVybmV0IEVuZ2luZWVyaW5nDQogICBUYXNrIEZvcmNlIChJRVRGKSwg aXRzIGFyZWFzLCBhbmQgaXRzIHdvcmtpbmcgZ3JvdXBzLiAgTm90ZSB0aGF0DQogICBvdGhlciBn cm91cHMgbWF5IGFsc28gZGlzdHJpYnV0ZSB3b3JraW5nIGRvY3VtZW50cyBhcyBJbnRlcm5ldC0N CiAgIERyYWZ0cy4NCg0KICAgSW50ZXJuZXQtRHJhZnRzIGFyZSBkcmFmdCBkb2N1bWVudHMgdmFs aWQgZm9yIGEgbWF4aW11bSBvZiBzaXggbW9udGhzDQogICBhbmQgbWF5IGJlIHVwZGF0ZWQsIHJl cGxhY2VkLCBvciBvYnNvbGV0ZWQgYnkgb3RoZXIgZG9jdW1lbnRzIGF0IGFueQ0KICAgdGltZS4g IEl0IGlzIGluYXBwcm9wcmlhdGUgdG8gdXNlIEludGVybmV0LURyYWZ0cyBhcyByZWZlcmVuY2UN CiAgIG1hdGVyaWFsIG9yIHRvIGNpdGUgdGhlbSBvdGhlciB0aGFuIGFzICJ3b3JrIGluIHByb2dy ZXNzLiINCg0KICAgVGhlIGxpc3Qgb2YgY3VycmVudCBJbnRlcm5ldC1EcmFmdHMgY2FuIGJlIGFj Y2Vzc2VkIGF0DQogICBodHRwOi8vd3d3LmlldGYub3JnL2lldGYvMWlkLWFic3RyYWN0cy50eHQu DQoNCiAgIFRoZSBsaXN0IG9mIEludGVybmV0LURyYWZ0IFNoYWRvdyBEaXJlY3RvcmllcyBjYW4g YmUgYWNjZXNzZWQgYXQNCiAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvc2hhZG93Lmh0bWwuDQoNCiAg IFRoaXMgSW50ZXJuZXQtRHJhZnQgd2lsbCBleHBpcmUgb24gU2VwdGVtYmVyIDIzLCAyMDA2Lg0K DQpDb3B5cmlnaHQgTm90aWNlDQoNCiAgIENvcHlyaWdodCAoQykgVGhlIEludGVybmV0IFNvY2ll dHkgKDIwMDYpLg0KDQpBYnN0cmFjdA0KDQogICBUaGlzIG1lbW8gZGVmaW5lcyBhIHBvcnRpb24g b2YgdGhlIE1hbmFnZW1lbnQgSW5mb3JtYXRpb24gQmFzZSAoTUlCKQ0KICAgZm9yIHVzZSB3aXRo IG5ldHdvcmsgbWFuYWdlbWVudCBwcm90b2NvbHMgaW4gdGhlIEludGVybmV0IGNvbW11bml0eS4N CiAgIEluIHBhcnRpY3VsYXIsIGl0IGRlc2NyaWJlcyB0aGUgUmVtb3RlIEF1dGhlbnRpY2F0aW9u IERpYWwgSW4gVXNlcg0KICAgU2VydmljZSAoUkFESVVTKSBbUkZDMjg2NV0gRHluYW1pYyBBdXRo b3JpemF0aW9uIENsaWVudCAoREFDKQ0KICAgZnVuY3Rpb25zIHRoYXQgc3VwcG9ydCB0aGUgZHlu YW1pYyBhdXRob3JpemF0aW9uIGV4dGVuc2lvbnMgYXMNCiAgIGRlZmluZWQgaW4gUkZDIDM1NzYu DQoNCg0KDQpEZSBDbm9kZGVyLCBldCBhbC4gICAgIEV4cGlyZXMgU2VwdGVtYmVyIDIzLCAyMDA2 ICAgICAgICAgICAgICAgW1BhZ2UgMV0NCgwNCkludGVybmV0LURyYWZ0ICAgICAgRHluYW1pYyBB dXRob3JpemF0aW9uIENsaWVudCBNSUIgICAgICAgICAgTWFyY2ggMjAwNg0KDQoNClRhYmxlIG9m IENvbnRlbnRzDQoNCiAgIDEuICBJbnRyb2R1Y3Rpb24gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgMw0KICAgICAxLjEuICBSZXF1aXJlbWVudHMgbm90 YXRpb24gIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAzDQogICAgIDEuMi4g IFRlcm1pbm9sb2d5ICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gIDMNCiAgIDIuICBUaGUgSW50ZXJuZXQtU3RhbmRhcmQgTWFuYWdlbWVudCBGcmFtZXdvcmsg LiAuIC4gLiAuIC4gLiAuIC4gLiAgNA0KICAgMy4gIE92ZXJ2aWV3IC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICA1DQogICA0LiAgUkFESVVTIER5 bmFtaWMgQXV0aG9yaXphdGlvbiBDbGllbnQgTUlCIERlZmluaXRpb25zICAuIC4gLiAuIC4gIDYN CiAgIDUuICBTZWN1cml0eSBDb25zaWRlcmF0aW9ucyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAyMw0KICAgNi4gIElBTkEgY29uc2lkZXJhdGlvbnMgIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDI1DQogICA3LiAgQWNrbm93bGVkZ2VtZW50 cyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMjYNCiAgIDgu ICBSZWZlcmVuY2VzIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAyNw0KICAgICA4LjEuICBOb3JtYXRpdmUgUmVmZXJlbmNlcyAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDI3DQogICAgIDguMi4gIEluZm9ybWF0aXZlIFJlZmVy ZW5jZXMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMjcNCiAgIEF1dGhvcnMn IEFkZHJlc3NlcyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAyOQ0KICAgSW50ZWxsZWN0dWFsIFByb3BlcnR5IGFuZCBDb3B5cmlnaHQgU3RhdGVtZW50cyAu IC4gLiAuIC4gLiAuIC4gLiAuIDMwDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KRGUgQ25vZGRlciwgZXQgYWwuICAg ICBFeHBpcmVzIFNlcHRlbWJlciAyMywgMjAwNiAgICAgICAgICAgICAgIFtQYWdlIDJdDQoMDQpJ bnRlcm5ldC1EcmFmdCAgICAgIER5bmFtaWMgQXV0aG9yaXphdGlvbiBDbGllbnQgTUlCICAgICAg ICAgIE1hcmNoIDIwMDYNCg0KDQoxLiAgSW50cm9kdWN0aW9uDQoNCiAgIFRoaXMgbWVtbyBkZWZp bmVzIGEgcG9ydGlvbiBvZiB0aGUgTWFuYWdlbWVudCBJbmZvcm1hdGlvbiBCYXNlIChNSUIpDQog ICBmb3IgdXNlIHdpdGggbmV0d29yayBtYW5hZ2VtZW50IHByb3RvY29scyBpbiB0aGUgSW50ZXJu ZXQgY29tbXVuaXR5Lg0KICAgSXQgaXMgYmVjb21pbmcgaW5jcmVhc2luZ2x5IGltcG9ydGFudCB0 byBzdXBwb3J0IER5bmFtaWMNCiAgIEF1dGhvcml6YXRpb24gZXh0ZW5zaW9ucyBvbiB0aGUgbmV0 d29yayBhY2Nlc3Mgc2VydmVyIChOQVMpIGRldmljZXMNCiAgIHRvIGhhbmRsZSB0aGUgRGlzY29u bmVjdCBhbmQgQ2hhbmdlLW9mLUF1dGhvcml6YXRpb24gKENvQSkgbWVzc2FnZXMNCiAgIGFzIGRl c2NyaWJlZCBpbiBbUkZDMzU3Nl0uICBBcyBhIHJlc3VsdCwgdGhlIGVmZmVjdGl2ZSBtYW5hZ2Vt ZW50IG9mDQogICBSQURJVVMgRHluYW1pYyBBdXRob3JpemF0aW9uIGVudGl0aWVzIGlzIG9mIGNv bnNpZGVyYWJsZSBpbXBvcnRhbmNlLg0KICAgVGhpcyBSQURJVVMgRHluYW1pYyBBdXRob3JpemF0 aW9uIENsaWVudCBNSUIgY29tcGxlbWVudHMgdGhlIG1hbmFnZWQNCiAgIG9iamVjdHMgdXNlZCBm b3IgbWFuYWdpbmcgUkFESVVTIGF1dGhlbnRpY2F0aW9uIGFuZCBhY2NvdW50aW5nDQogICBzZXJ2 ZXJzIGFzIGRlc2NyaWJlZCBpbiBbUkZDMjYxOWJpc10gYW5kIFtSRkMyNjIxYmlzXSwgcmVzcGVj dGl2ZWx5Lg0KDQoNCiAgIC0tIFJGQyBFZC46IHJlZmVyZW5jZXMgW0RZTlNFUlZdLCBbUkZDMjYx OWJpc10sIFtSRkMyNjIxYmlzXSBzaG91bGQNCiAgIC0tICAgICAgICAgIGJlIHJlcGxhY2VkIGJ5 IHJlZmVyZW5jZXMgdG8gdGhlIGNvcnJlc3BvbmRpbmcgUkZDLg0KDQoxLjEuICBSZXF1aXJlbWVu dHMgbm90YXRpb24NCg0KICAgVGhlIGtleSB3b3JkcyAiTVVTVCIsICJNVVNUIE5PVCIsICJSRVFV SVJFRCIsICJTSEFMTCIsICJTSEFMTCBOT1QiLA0KICAgIlNIT1VMRCIsICJTSE9VTEQgTk9UIiwg IlJFQ09NTUVOREVEIiwgIk1BWSIsIGFuZCAiT1BUSU9OQUwiIGluIHRoaXMNCiAgIGRvY3VtZW50 IGFyZSB0byBiZSBpbnRlcnByZXRlZCBhcyBkZXNjcmliZWQgaW4gW1JGQzIxMTldLg0KDQoxLjIu ICBUZXJtaW5vbG9neQ0KDQogICBEeW5hbWljIEF1dGhvcml6YXRpb24gU2VydmVyIChEQVMpDQoN CiAgIFRoZSBjb21wb25lbnQgdGhhdCByZXNpZGVzIG9uIHRoZSBOQVMgd2hpY2ggcHJvY2Vzc2Vz IHRoZSBEaXNjb25uZWN0DQogICBhbmQgQ2hhbmdlLW9mLUF1dGhvcml6YXRpb24gKENvQSkgUmVx dWVzdCBwYWNrZXRzIFtSRkMzNTc2XSBzZW50IGJ5DQogICB0aGUgRHluYW1pYyBBdXRob3JpemF0 aW9uIENsaWVudC4NCg0KICAgRHluYW1pYyBBdXRob3JpemF0aW9uIENsaWVudCAoREFDKQ0KDQog ICBUaGUgY29tcG9uZW50IHdoaWNoIHNlbmRzIERpc2Nvbm5lY3QgYW5kIENvQS1SZXF1ZXN0IHBh Y2tldHMgdG8gdGhlDQogICBEeW5hbWljIEF1dGhvcml6YXRpb24gU2VydmVyLiAgV2hpbGUgb2Z0 ZW4gcmVzaWRpbmcgb24gdGhlIFJBRElVUw0KICAgc2VydmVyLCBpdCBpcyBhbHNvIHBvc3NpYmxl IGZvciB0aGlzIGNvbXBvbmVudCB0byBiZSBsb2NhdGVkIG9uIGENCiAgIHNlcGFyYXRlIGhvc3Qs IHN1Y2ggYXMgYSBSYXRpbmcgRW5naW5lLg0KDQogICBEeW5hbWljIEF1dGhvcml6YXRpb24gU2Vy dmVyIFBvcnQNCg0KICAgVGhlIFVEUCBwb3J0IG9uIHdoaWNoIHRoZSBEeW5hbWljIEF1dGhvcml6 YXRpb24gU2VydmVyIGxpc3RlbnMgZm9yDQogICB0aGUgRGlzY29ubmVjdCBhbmQgQ29BIHJlcXVl c3RzIHNlbnQgYnkgdGhlIER5bmFtaWMgQXV0aG9yaXphdGlvbg0KICAgQ2xpZW50Lg0KDQoNCg0K DQoNCg0KDQoNCkRlIENub2RkZXIsIGV0IGFsLiAgICAgRXhwaXJlcyBTZXB0ZW1iZXIgMjMsIDIw MDYgICAgICAgICAgICAgICBbUGFnZSAzXQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICBEeW5hbWlj IEF1dGhvcml6YXRpb24gQ2xpZW50IE1JQiAgICAgICAgICBNYXJjaCAyMDA2DQoNCg0KMi4gIFRo ZSBJbnRlcm5ldC1TdGFuZGFyZCBNYW5hZ2VtZW50IEZyYW1ld29yaw0KDQogICBGb3IgYSBkZXRh aWxlZCBvdmVydmlldyBvZiB0aGUgZG9jdW1lbnRzIHRoYXQgZGVzY3JpYmUgdGhlIGN1cnJlbnQN CiAgIEludGVybmV0LVN0YW5kYXJkIE1hbmFnZW1lbnQgRnJhbWV3b3JrLCBwbGVhc2UgcmVmZXIg dG8gc2VjdGlvbiA3IG9mDQogICBbUkZDMzQxMF0uDQoNCiAgIE1hbmFnZWQgb2JqZWN0cyBhcmUg YWNjZXNzZWQgdmlhIGEgdmlydHVhbCBpbmZvcm1hdGlvbiBzdG9yZSwgdGVybWVkDQogICB0aGUg TWFuYWdlbWVudCBJbmZvcm1hdGlvbiBCYXNlIG9yIE1JQi4gIE1JQiBvYmplY3RzIGFyZSBnZW5l cmFsbHkNCiAgIGFjY2Vzc2VkIHRocm91Z2ggdGhlIFNpbXBsZSBOZXR3b3JrIE1hbmFnZW1lbnQg UHJvdG9jb2wgKFNOTVApLg0KICAgT2JqZWN0cyBpbiB0aGUgTUlCIGFyZSBkZWZpbmVkIHVzaW5n IHRoZSBtZWNoYW5pc21zIGRlZmluZWQgaW4gdGhlDQogICBTdHJ1Y3R1cmUgb2YgTWFuYWdlbWVu dCBJbmZvcm1hdGlvbiAoU01JKS4gIFRoaXMgbWVtbyBzcGVjaWZpZXMgYSBNSUINCiAgIG1vZHVs ZSB0aGF0IGlzIGNvbXBsaWFudCB0byB0aGUgU01JdjIsIHdoaWNoIGlzIGRlc2NyaWJlZCBpbiBT VEQgNTgsDQogICBSRkMyNTc4IFtSRkMyNTc4XSwgU1REIDU4LCBSRkMyNTc5IFtSRkMyNTc5XSBh bmQgU1REIDU4LCBSRkMyNTgwDQogICBbUkZDMjU4MF0uDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCkRlIENu b2RkZXIsIGV0IGFsLiAgICAgRXhwaXJlcyBTZXB0ZW1iZXIgMjMsIDIwMDYgICAgICAgICAgICAg ICBbUGFnZSA0XQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICBEeW5hbWljIEF1dGhvcml6YXRpb24g Q2xpZW50IE1JQiAgICAgICAgICBNYXJjaCAyMDA2DQoNCg0KMy4gIE92ZXJ2aWV3DQoNCiAgICJE eW5hbWljIEF1dGhvcml6YXRpb24gRXh0ZW5zaW9ucyB0byBSQURJVVMiIFtSRkMzNTc2XSBkZWZp bmVzIHRoZQ0KICAgb3BlcmF0aW9uIG9mIERpc2Nvbm5lY3QtUmVxdWVzdCwgRGlzY29ubmVjdC1B Q0ssIERpc2Nvbm5lY3QtTkFLLCBDb0EtDQogICBSZXF1ZXN0LCBDb0EtQUNLIGFuZCBDb0EtTkFL IHBhY2tldHMuICBbRFlOU0VSVl0gZGVmaW5lcyB0aGUgRHluYW1pYw0KICAgQXV0aG9yaXphdGlv biBTZXJ2ZXIgTUlCIGFuZCB0aGUgcmVsYXRpb25zaGlwIHdpdGggb3RoZXIgTUlCIG1vZHVsZXMu DQogICBUaGlzIE1JQiBtb2R1bGUgZm9yIHRoZSBEeW5hbWljIEF1dGhvcml6YXRpb24gQ2xpZW50 IGNvbnRhaW5zIHRoZQ0KICAgZm9sbG93aW5nOg0KDQogICAxLiAgVGhyZWUgc2NhbGFyIG9iamVj dHMsIGFuZA0KDQogICAyLiAgT25lIER5bmFtaWMgQXV0aG9yaXphdGlvbiBTZXJ2ZXIgdGFibGUu ICBUaGlzIHRhYmxlIGNvbnRhaW5zIG9uZQ0KICAgcm93IGZvciBlYWNoIERBUyB0aGF0IHRoZSBE QUMgc2hhcmVzIGEgc2VjcmV0IHdpdGguDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KRGUgQ25vZGRlciwg ZXQgYWwuICAgICBFeHBpcmVzIFNlcHRlbWJlciAyMywgMjAwNiAgICAgICAgICAgICAgIFtQYWdl IDVdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgIER5bmFtaWMgQXV0aG9yaXphdGlvbiBDbGllbnQg TUlCICAgICAgICAgIE1hcmNoIDIwMDYNCg0KDQo0LiAgUkFESVVTIER5bmFtaWMgQXV0aG9yaXph dGlvbiBDbGllbnQgTUlCIERlZmluaXRpb25zDQoNCiAgIFJBRElVUy1EWU5BVVRILUNMSUVOVC1N SUIgREVGSU5JVElPTlMgOjo9IEJFR0lODQoNCiAgIElNUE9SVFMNCiAgICAgICAgICBNT0RVTEUt SURFTlRJVFksIE9CSkVDVC1UWVBFLA0KICAgICAgICAgIENvdW50ZXIzMiwgR2F1Z2UzMiwgSW50 ZWdlcjMyLA0KICAgICAgICAgIG1pYi0yLCBUaW1lVGlja3MgICAgRlJPTSBTTk1QdjItU01JICAg ICAgICAgLS0gW1JGQzI1NzhdDQogICAgICAgICAgU25tcEFkbWluU3RyaW5nICAgICBGUk9NIFNO TVAtRlJBTUVXT1JLLU1JQiAtLSBbUkZDMzQxMV0NCiAgICAgICAgICBJbmV0QWRkcmVzc1R5cGUs IEluZXRBZGRyZXNzLA0KICAgICAgICAgIEluZXRQb3J0TnVtYmVyICAgICAgRlJPTSBJTkVULUFE RFJFU1MtTUlCICAgLS0gW1JGQzQwMDFdDQogICAgICAgICAgTU9EVUxFLUNPTVBMSUFOQ0UsDQog ICAgICAgICAgT0JKRUNULUdST1VQICAgICAgICBGUk9NIFNOTVB2Mi1DT05GOyAgICAgICAtLSBb UkZDMjU4MF0NCg0KICAgcmFkaXVzRHluQXV0aENsaWVudE1JQiBNT0RVTEUtSURFTlRJVFkNCiAg ICAgICAgICBMQVNULVVQREFURUQgIjIwMDYwMzIyMDAwMFoiIC0tIDIyIE1hcmNoIDIwMDYNCiAg ICAgICAgICBPUkdBTklaQVRJT04gIklFVEYgUkFERVhUIFdvcmtpbmcgR3JvdXAiDQogICAgICAg ICAgQ09OVEFDVC1JTkZPDQogICAgICAgICAgICAgICAgICIgU3RlZmFhbiBEZSBDbm9kZGVyDQog ICAgICAgICAgICAgICAgICAgQWxjYXRlbA0KICAgICAgICAgICAgICAgICAgIEZyYW5jaXMgV2Vs bGVzcGxlaW4gMQ0KICAgICAgICAgICAgICAgICAgIEItMjAxOCBBbnR3ZXJwDQogICAgICAgICAg ICAgICAgICAgQmVsZ2l1bQ0KDQogICAgICAgICAgICAgICAgICAgUGhvbmU6ICszMiAzIDI0MCA4 NSAxNQ0KICAgICAgICAgICAgICAgICAgIEVNYWlsOiBzdGVmYWFuLmRlX2Nub2RkZXJAYWxjYXRl bC5iZQ0KDQogICAgICAgICAgICAgICAgICAgTmFnaSBSZWRkeSBKb25uYWxhDQogICAgICAgICAg ICAgICAgICAgQ2lzY28gU3lzdGVtcywgSW5jLg0KICAgICAgICAgICAgICAgICAgIERpdnlhc3Jl ZSBDaGFtYmVycywgQiBXaW5nLA0KICAgICAgICAgICAgICAgICAgIE8nU2hhdWduZXNzeSBSb2Fk LA0KICAgICAgICAgICAgICAgICAgIEJhbmdhbG9yZS01NjAwMjcsIEluZGlhLg0KDQogICAgICAg ICAgICAgICAgICAgUGhvbmU6ICs5MSA5NDQ4NyA2MDgyOA0KICAgICAgICAgICAgICAgICAgIEVN YWlsOiBuam9ubmFsYUBjaXNjby5jb20NCg0KICAgICAgICAgICAgICAgICAgIE11cnRhemEgQ2hp YmENCiAgICAgICAgICAgICAgICAgICBDaXNjbyBTeXN0ZW1zLCBJbmMuDQogICAgICAgICAgICAg ICAgICAgMTcwIFdlc3QgVGFzbWFuIERyLg0KICAgICAgICAgICAgICAgICAgIFNhbiBKb3NlIENB LCA5NTEzNA0KDQogICAgICAgICAgICAgICAgICAgUGhvbmU6ICsxIDQwOCA1MjUgNzE5OA0KICAg ICAgICAgICAgICAgICAgIEVNYWlsOiBtY2hpYmFAY2lzY28uY29tICINCiAgICAgICAgICBERVND UklQVElPTg0KICAgICAgICAgICAgICAiVGhlIE1JQiBtb2R1bGUgZm9yIGVudGl0aWVzIGltcGxl bWVudGluZyB0aGUgY2xpZW50DQogICAgICAgICAgICAgICBzaWRlIG9mIHRoZSBEeW5hbWljIEF1 dGhvcml6YXRpb24gRXh0ZW5zaW9ucyB0byBSZW1vdGUNCiAgICAgICAgICAgICAgIEF1dGhlbnRp Y2F0aW9uIERpYWwgSW4gVXNlciBTZXJ2aWNlIChSQURJVVMpIHByb3RvY29sLg0KDQoNCg0KDQpE ZSBDbm9kZGVyLCBldCBhbC4gICAgIEV4cGlyZXMgU2VwdGVtYmVyIDIzLCAyMDA2ICAgICAgICAg ICAgICAgW1BhZ2UgNl0NCgwNCkludGVybmV0LURyYWZ0ICAgICAgRHluYW1pYyBBdXRob3JpemF0 aW9uIENsaWVudCBNSUIgICAgICAgICAgTWFyY2ggMjAwNg0KDQoNCiAgICAgICAgICAgICAgIENv cHlyaWdodCAoQykgVGhlIEludGVybmV0IFNvY2lldHkgKDIwMDYpLiAgSW5pdGlhbA0KICAgICAg ICAgICAgICAgdmVyc2lvbiBhcyBwdWJsaXNoZWQgaW4gUkZDIHl5eXk7DQogICAgICAgICAgICAg ICBmb3IgZnVsbCBsZWdhbCBub3RpY2VzIHNlZSB0aGUgUkZDIGl0c2VsZi4iDQogICAtLSBSRkMg RWQuOiByZXBsYWNlIHl5eXkgd2l0aCBhY3R1YWwgUkZDIG51bWJlciAmIHJlbW92ZSB0aGlzIG5v dGUNCg0KICAgICAgICAgIFJFVklTSU9OICIyMDA2MDMyMjAwMDBaIiAtLSAyMiBNYXJjaCAyMDA2 DQogICAgICAgICAgREVTQ1JJUFRJT04gIkluaXRpYWwgdmVyc2lvbiBhcyBwdWJsaXNoZWQgaW4g UkZDIHl5eXkiDQogICAtLSBSRkMgRWQuOiByZXBsYWNlIHl5eXkgd2l0aCBhY3R1YWwgUkZDIG51 bWJlciAmIHJlbW92ZSB0aGlzIG5vdGUNCiAgICAgICAgICA6Oj0geyBtaWItMiB4eHggfQ0KICAg LS0gVGhlIHZhbHVlIHh4eCB0byBiZSBhc3NpZ25lZCBieSBJQU5BLg0KDQogICByYWRpdXNEeW5B dXRoQ2xpZW50TUlCT2JqZWN0cyBPQkpFQ1QgSURFTlRJRklFUiA6Oj0NCiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgeyByYWRpdXNEeW5BdXRoQ2xpZW50TUlCIDEgfQ0K DQogICByYWRpdXNEeW5BdXRoQ2xpZW50U2NhbGFycyAgICBPQkpFQ1QgSURFTlRJRklFUiA6Oj0N CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB7IHJhZGl1c0R5bkF1dGhDbGllbnRN SUJPYmplY3RzIDEgfQ0KDQogICByYWRpdXNEeW5BdXRoQ2xpZW50RGlzY29uSW52YWxpZFNlcnZl ckFkZHJlc3NlcyBPQkpFQ1QtVFlQRQ0KICAgICAgICAgIFNZTlRBWCBDb3VudGVyMzINCiAgICAg ICAgICBNQVgtQUNDRVNTIHJlYWQtb25seQ0KICAgICAgICAgIFNUQVRVUyBjdXJyZW50DQogICAg ICAgICAgREVTQ1JJUFRJT04NCiAgICAgICAgICAgICAgICAiVGhlIG51bWJlciBvZiBEaXNjb25u ZWN0LUFjayBhbmQgRGlzY29ubmVjdC1OQUsgcGFja2V0cw0KICAgICAgICAgICAgICAgICByZWNl aXZlZCBmcm9tIHVua25vd24gYWRkcmVzc2VzLiBUaGlzIGNvdW50ZXIgbWF5DQogICAgICAgICAg ICAgICAgIGV4cGVyaWVuY2UgYSBkaXNjb250aW51aXR5IHdoZW4gdGhlIERBQyBtb2R1bGUNCiAg ICAgICAgICAgICAgICAgKHJlKXN0YXJ0cyBhcyBpbmRpY2F0ZWQgYnkgdGhlIHZhbHVlIG9mDQog ICAgICAgICAgICAgICAgIHJhZGl1c0R5bkF1dGhDbGllbnRDb3VudGVyRGlzY29udGludWl0eS4i DQogICAgICAgICAgOjo9IHsgcmFkaXVzRHluQXV0aENsaWVudFNjYWxhcnMgMSB9DQoNCiAgIHJh ZGl1c0R5bkF1dGhDbGllbnRDb0FJbnZhbGlkU2VydmVyQWRkcmVzc2VzIE9CSkVDVC1UWVBFDQog ICAgICAgICAgU1lOVEFYIENvdW50ZXIzMg0KICAgICAgICAgIE1BWC1BQ0NFU1MgcmVhZC1vbmx5 DQogICAgICAgICAgU1RBVFVTIGN1cnJlbnQNCiAgICAgICAgICBERVNDUklQVElPTg0KICAgICAg ICAgICAgICAgICJUaGUgbnVtYmVyIG9mIENvQS1BY2sgYW5kIENvQS1OQUsgcGFja2V0cyByZWNl aXZlZCBmcm9tDQogICAgICAgICAgICAgICAgIHVua25vd24gYWRkcmVzc2VzLiBEaXNjb25uZWN0 LU5BSyBwYWNrZXRzIHJlY2VpdmVkIGZyb20NCiAgICAgICAgICAgICAgICAgdW5rbm93biBhZGRy ZXNzZXMuIFRoaXMgY291bnRlciBtYXkgZXhwZXJpZW5jZSBhDQogICAgICAgICAgICAgICAgIGRp c2NvbnRpbnVpdHkgd2hlbiB0aGUgREFDIG1vZHVsZSAocmUpc3RhcnRzIGFzDQogICAgICAgICAg ICAgICAgIGluZGljYXRlZCBieSB0aGUgdmFsdWUgb2YNCiAgICAgICAgICAgICAgICAgcmFkaXVz RHluQXV0aENsaWVudENvdW50ZXJEaXNjb250aW51aXR5LiINCiAgICAgICAgICA6Oj0geyByYWRp dXNEeW5BdXRoQ2xpZW50U2NhbGFycyAyIH0NCg0KICAgcmFkaXVzRHluQXV0aENsaWVudENvdW50 ZXJEaXNjb250aW51aXR5IE9CSkVDVC1UWVBFDQogICAgICAgICAgU1lOVEFYIFRpbWVUaWNrcw0K ICAgICAgICAgIFVOSVRTICAiaHVuZHJlZHRocyBvZiBhIHNlY29uZCINCiAgICAgICAgICBNQVgt QUNDRVNTIHJlYWQtb25seQ0KICAgICAgICAgIFNUQVRVUyBjdXJyZW50DQogICAgICAgICAgREVT Q1JJUFRJT04NCg0KDQoNCkRlIENub2RkZXIsIGV0IGFsLiAgICAgRXhwaXJlcyBTZXB0ZW1iZXIg MjMsIDIwMDYgICAgICAgICAgICAgICBbUGFnZSA3XQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICBE eW5hbWljIEF1dGhvcml6YXRpb24gQ2xpZW50IE1JQiAgICAgICAgICBNYXJjaCAyMDA2DQoNCg0K ICAgICAgICAgICAgICAgICJUaGUgdGltZSAoaW4gaHVuZHJlZHRocyBvZiBhIHNlY29uZCkgc2lu Y2UgdGhlDQogICAgICAgICAgICAgICAgIERBQyBtb2R1bGUgd2FzIGxhc3QgcmUtaW5pdGlhbGl6 ZWQuIg0KICAgICAgICAgIDo6PSB7IHJhZGl1c0R5bkF1dGhDbGllbnRTY2FsYXJzIDMgfQ0KDQog ICByYWRpdXNEeW5BdXRoU2VydmVyVGFibGUgT0JKRUNULVRZUEUNCiAgICAgICAgICBTWU5UQVgg U0VRVUVOQ0UgT0YgUmFkaXVzRHluQXV0aFNlcnZlckVudHJ5DQogICAgICAgICAgTUFYLUFDQ0VT UyBub3QtYWNjZXNzaWJsZQ0KICAgICAgICAgIFNUQVRVUyAgICAgY3VycmVudA0KICAgICAgICAg IERFU0NSSVBUSU9ODQogICAgICAgICAgICAgICAgIlRoZSAoY29uY2VwdHVhbCkgdGFibGUgbGlz dGluZyB0aGUgUkFESVVTIER5bmFtaWMNCiAgICAgICAgICAgICAgICAgQXV0aG9yaXphdGlvbiBT ZXJ2ZXJzIHdpdGggd2hpY2ggdGhlIGNsaWVudCBzaGFyZXMgYQ0KICAgICAgICAgICAgICAgICBz ZWNyZXQuIg0KICAgICAgICAgIDo6PSB7IHJhZGl1c0R5bkF1dGhDbGllbnRNSUJPYmplY3RzIDIg fQ0KDQogICByYWRpdXNEeW5BdXRoU2VydmVyRW50cnkgT0JKRUNULVRZUEUNCiAgICAgICAgICBT WU5UQVggICAgIFJhZGl1c0R5bkF1dGhTZXJ2ZXJFbnRyeQ0KICAgICAgICAgIE1BWC1BQ0NFU1Mg bm90LWFjY2Vzc2libGUNCiAgICAgICAgICBTVEFUVVMgICAgIGN1cnJlbnQNCiAgICAgICAgICBE RVNDUklQVElPTg0KICAgICAgICAgICAgICAgICJBbiBlbnRyeSAoY29uY2VwdHVhbCByb3cpIHJl cHJlc2VudGluZyBvbmUgRHluYW1pYw0KICAgICAgICAgICAgICAgICBBdXRob3JpemF0aW9uIFNl cnZlciB3aXRoIHdoaWNoIHRoZSBjbGllbnQgc2hhcmVzIGENCiAgICAgICAgICAgICAgICAgc2Vj cmV0LiINCiAgICAgICAgICBJTkRFWCAgICAgIHsgcmFkaXVzRHluQXV0aFNlcnZlckluZGV4IH0N CiAgICAgICAgICA6Oj0geyByYWRpdXNEeW5BdXRoU2VydmVyVGFibGUgMSB9DQoNCiAgIFJhZGl1 c0R5bkF1dGhTZXJ2ZXJFbnRyeSA6Oj0gU0VRVUVOQ0Ugew0KICAgICAgICAgIHJhZGl1c0R5bkF1 dGhTZXJ2ZXJJbmRleCAgICAgICAgICAgICAgICAgICAgIEludGVnZXIzMiwNCiAgICAgICAgICBy YWRpdXNEeW5BdXRoU2VydmVyQWRkcmVzc1R5cGUgICAgICAgICAgICAgICBJbmV0QWRkcmVzc1R5 cGUsDQogICAgICAgICAgcmFkaXVzRHluQXV0aFNlcnZlckFkZHJlc3MgICAgICAgICAgICAgICAg ICAgSW5ldEFkZHJlc3MsDQogICAgICAgICAgcmFkaXVzRHluQXV0aFNlcnZlckNsaWVudFBvcnRO dW1iZXIgICAgICAgICAgSW5ldFBvcnROdW1iZXIsDQogICAgICAgICAgcmFkaXVzRHluQXV0aFNl cnZlcklEICAgICAgICAgICAgICAgICAgICAgICAgU25tcEFkbWluU3RyaW5nLA0KICAgICAgICAg IHJhZGl1c0R5bkF1dGhDbGllbnRSb3VuZFRyaXBUaW1lICAgICAgICAgICAgIFRpbWVUaWNrcywN CiAgICAgICAgICByYWRpdXNEeW5BdXRoQ2xpZW50RGlzY29uUmVxdWVzdHMgICAgICAgICAgICBD b3VudGVyMzIsDQogICAgICAgICAgcmFkaXVzRHluQXV0aENsaWVudERpc2NvbkF1dGhPbmx5UmVx dWVzdHMgICAgQ291bnRlcjMyLA0KICAgICAgICAgIHJhZGl1c0R5bkF1dGhDbGllbnREaXNjb25S ZXRyYW5zbWlzc2lvbnMgICAgIENvdW50ZXIzMiwNCiAgICAgICAgICByYWRpdXNEeW5BdXRoQ2xp ZW50RGlzY29uQWNrcyAgICAgICAgICAgICAgICBDb3VudGVyMzIsDQogICAgICAgICAgcmFkaXVz RHluQXV0aENsaWVudERpc2Nvbk5ha3MgICAgICAgICAgICAgICAgQ291bnRlcjMyLA0KICAgICAg ICAgIHJhZGl1c0R5bkF1dGhDbGllbnREaXNjb25OYWtBdXRoT25seVJlcXVlc3QgIENvdW50ZXIz MiwNCiAgICAgICAgICByYWRpdXNEeW5BdXRoQ2xpZW50RGlzY29uTmFrU2Vzc05vQ29udGV4dCAg ICBDb3VudGVyMzIsDQogICAgICAgICAgcmFkaXVzRHluQXV0aENsaWVudE1hbGZvcm1lZERpc2Nv blJlc3BvbnNlcyAgQ291bnRlcjMyLA0KICAgICAgICAgIHJhZGl1c0R5bkF1dGhDbGllbnREaXNj b25CYWRBdXRoZW50aWNhdG9ycyAgIENvdW50ZXIzMiwNCiAgICAgICAgICByYWRpdXNEeW5BdXRo Q2xpZW50RGlzY29uUGVuZGluZ1JlcXVlc3RzICAgICBHYXVnZTMyLA0KICAgICAgICAgIHJhZGl1 c0R5bkF1dGhDbGllbnREaXNjb25UaW1lb3V0cyAgICAgICAgICAgIENvdW50ZXIzMiwNCiAgICAg ICAgICByYWRpdXNEeW5BdXRoQ2xpZW50RGlzY29uUGFja2V0c0Ryb3BwZWQgICAgICBDb3VudGVy MzIsDQogICAgICAgICAgcmFkaXVzRHluQXV0aENsaWVudENvQVJlcXVlc3RzICAgICAgICAgICAg ICAgQ291bnRlcjMyLA0KICAgICAgICAgIHJhZGl1c0R5bkF1dGhDbGllbnRDb0FBdXRoT25seVJl cXVlc3QgICAgICAgIENvdW50ZXIzMiwNCiAgICAgICAgICByYWRpdXNEeW5BdXRoQ2xpZW50Q29B UmV0cmFuc21pc3Npb25zICAgICAgICBDb3VudGVyMzIsDQogICAgICAgICAgcmFkaXVzRHluQXV0 aENsaWVudENvQUFja3MgICAgICAgICAgICAgICAgICAgQ291bnRlcjMyLA0KDQoNCg0KRGUgQ25v ZGRlciwgZXQgYWwuICAgICBFeHBpcmVzIFNlcHRlbWJlciAyMywgMjAwNiAgICAgICAgICAgICAg IFtQYWdlIDhdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgIER5bmFtaWMgQXV0aG9yaXphdGlvbiBD bGllbnQgTUlCICAgICAgICAgIE1hcmNoIDIwMDYNCg0KDQogICAgICAgICAgcmFkaXVzRHluQXV0 aENsaWVudENvQU5ha3MgICAgICAgICAgICAgICAgICAgQ291bnRlcjMyLA0KICAgICAgICAgIHJh ZGl1c0R5bkF1dGhDbGllbnRDb0FOYWtBdXRoT25seVJlcXVlc3QgICAgIENvdW50ZXIzMiwNCiAg ICAgICAgICByYWRpdXNEeW5BdXRoQ2xpZW50Q29BTmFrU2Vzc05vQ29udGV4dCAgICAgICBDb3Vu dGVyMzIsDQogICAgICAgICAgcmFkaXVzRHluQXV0aENsaWVudE1hbGZvcm1lZENvQVJlc3BvbnNl cyAgICAgQ291bnRlcjMyLA0KICAgICAgICAgIHJhZGl1c0R5bkF1dGhDbGllbnRDb0FCYWRBdXRo ZW50aWNhdG9ycyAgICAgIENvdW50ZXIzMiwNCiAgICAgICAgICByYWRpdXNEeW5BdXRoQ2xpZW50 Q29BUGVuZGluZ1JlcXVlc3RzICAgICAgICBHYXVnZTMyLA0KICAgICAgICAgIHJhZGl1c0R5bkF1 dGhDbGllbnRDb0FUaW1lb3V0cyAgICAgICAgICAgICAgIENvdW50ZXIzMiwNCiAgICAgICAgICBy YWRpdXNEeW5BdXRoQ2xpZW50Q29BUGFja2V0c0Ryb3BwZWQgICAgICAgICBDb3VudGVyMzIsDQog ICAgICAgICAgcmFkaXVzRHluQXV0aENsaWVudFVua25vd25UeXBlcyAgICAgICAgICAgICAgQ291 bnRlcjMyDQogICB9DQoNCg0KICAgcmFkaXVzRHluQXV0aFNlcnZlckluZGV4IE9CSkVDVC1UWVBF DQogICAgICAgICAgU1lOVEFYICAgICBJbnRlZ2VyMzIgKDEuLjIxNDc0ODM2NDcpDQogICAgICAg ICAgTUFYLUFDQ0VTUyBub3QtYWNjZXNzaWJsZQ0KICAgICAgICAgIFNUQVRVUyAgICAgY3VycmVu dA0KICAgICAgICAgIERFU0NSSVBUSU9ODQogICAgICAgICAgICAgICAgIkEgbnVtYmVyIHVuaXF1 ZWx5IGlkZW50aWZ5aW5nIGVhY2ggUkFESVVTIER5bmFtaWMNCiAgICAgICAgICAgICAgICAgQXV0 aG9yaXphdGlvbiBTZXJ2ZXIgd2l0aCB3aGljaCB0aGlzIER5bmFtaWMNCiAgICAgICAgICAgICAg ICAgQXV0aG9yaXphdGlvbiBDbGllbnQgY29tbXVuaWNhdGVzLiBUaGlzIG51bWJlciBpcw0KICAg ICAgICAgICAgICAgICBhbGxvY2F0ZWQgYnkgdGhlIGFnZW50IGltcGxlbWVudGluZyB0aGlzIE1J QiBtb2R1bGUsDQogICAgICAgICAgICAgICAgIGFuZCBpcyB1bmlxdWUgaW4gdGhpcyBjb250ZXh0 LiINCiAgICAgICAgICA6Oj0geyByYWRpdXNEeW5BdXRoU2VydmVyRW50cnkgMSB9DQoNCiAgIHJh ZGl1c0R5bkF1dGhTZXJ2ZXJBZGRyZXNzVHlwZSBPQkpFQ1QtVFlQRQ0KICAgICAgICAgIFNZTlRB WCAgICAgSW5ldEFkZHJlc3NUeXBlDQogICAgICAgICAgTUFYLUFDQ0VTUyByZWFkLW9ubHkNCiAg ICAgICAgICBTVEFUVVMgICAgIGN1cnJlbnQNCiAgICAgICAgICBERVNDUklQVElPTg0KICAgICAg ICAgICAgICAgICJUaGUgdHlwZSBvZiBJUCBhZGRyZXNzIG9mIHRoZSBSQURJVVMgRHluYW1pYw0K ICAgICAgICAgICAgICAgICBBdXRob3JpemF0aW9uIFNlcnZlciByZWZlcnJlZCB0byBpbiB0aGlz IHRhYmxlIGVudHJ5LiINCiAgICAgICAgICA6Oj0geyByYWRpdXNEeW5BdXRoU2VydmVyRW50cnkg MiB9DQoNCiAgIHJhZGl1c0R5bkF1dGhTZXJ2ZXJBZGRyZXNzIE9CSkVDVC1UWVBFDQogICAgICAg ICAgU1lOVEFYICAgICBJbmV0QWRkcmVzcw0KICAgICAgICAgIE1BWC1BQ0NFU1MgcmVhZC1vbmx5 DQogICAgICAgICAgU1RBVFVTICAgICBjdXJyZW50DQogICAgICAgICAgREVTQ1JJUFRJT04NCiAg ICAgICAgICAgICAgICAiVGhlIElQIGFkZHJlc3MgdmFsdWUgb2YgdGhlIFJBRElVUyBEeW5hbWlj DQogICAgICAgICAgICAgICAgIEF1dGhvcml6YXRpb24gU2VydmVyIHJlZmVycmVkIHRvIGluIHRo aXMgdGFibGUgZW50cnkNCiAgICAgICAgICAgICAgICAgdXNpbmcgdGhlIHZlcnNpb24gbmV1dHJh bCBJUCBhZGRyZXNzIGZvcm1hdC4gVGhlIHR5cGUNCiAgICAgICAgICAgICAgICAgb2YgdGhpcyBh ZGRyZXNzIGlzIGRldGVybWluZWQgYnkgdGhlIHZhbHVlIG9mIHRoZQ0KICAgICAgICAgICAgICAg ICByYWRpdXNEeW5BdXRoU2VydmVyQWRkcmVzc1R5cGUgb2JqZWN0LiINCiAgICAgICAgICA6Oj0g eyByYWRpdXNEeW5BdXRoU2VydmVyRW50cnkgMyB9DQoNCiAgIHJhZGl1c0R5bkF1dGhTZXJ2ZXJD bGllbnRQb3J0TnVtYmVyIE9CSkVDVC1UWVBFDQogICAgICAgICAgU1lOVEFYICAgICBJbmV0UG9y dE51bWJlcg0KICAgICAgICAgIE1BWC1BQ0NFU1MgcmVhZC1vbmx5DQoNCg0KDQpEZSBDbm9kZGVy LCBldCBhbC4gICAgIEV4cGlyZXMgU2VwdGVtYmVyIDIzLCAyMDA2ICAgICAgICAgICAgICAgW1Bh Z2UgOV0NCgwNCkludGVybmV0LURyYWZ0ICAgICAgRHluYW1pYyBBdXRob3JpemF0aW9uIENsaWVu dCBNSUIgICAgICAgICAgTWFyY2ggMjAwNg0KDQoNCiAgICAgICAgICBTVEFUVVMgICAgIGN1cnJl bnQNCiAgICAgICAgICBERVNDUklQVElPTg0KICAgICAgICAgICAgICAgICJUaGUgVURQIGRlc3Rp bmF0aW9uIHBvcnQgdGhhdCB0aGUgUkFESVVTIER5bmFtaWMNCiAgICAgICAgICAgICAgICAgQXV0 aG9yaXphdGlvbiBDbGllbnQgaXMgdXNpbmcgdG8gc2VuZCByZXF1ZXN0cyB0byB0aGlzDQogICAg ICAgICAgICAgICAgIHNlcnZlci4gVGhlIHZhbHVlIHplcm8gaXMgaW52YWxpZC4iDQogICAgICAg ICAgOjo9IHsgcmFkaXVzRHluQXV0aFNlcnZlckVudHJ5IDQgfQ0KDQoNCiAgIHJhZGl1c0R5bkF1 dGhTZXJ2ZXJJRCBPQkpFQ1QtVFlQRQ0KICAgICAgICAgIFNZTlRBWCAgICAgU25tcEFkbWluU3Ry aW5nDQogICAgICAgICAgTUFYLUFDQ0VTUyByZWFkLW9ubHkNCiAgICAgICAgICBTVEFUVVMgICAg IGN1cnJlbnQNCiAgICAgICAgICBERVNDUklQVElPTg0KICAgICAgICAgICAgICAgICJUaGUgTkFT LUlkZW50aWZpZXIgb2YgdGhlIFJBRElVUyBEeW5hbWljIEF1dGhvcml6YXRpb24NCiAgICAgICAg ICAgICAgICAgU2VydmVyIHJlZmVycmVkIHRvIGluIHRoaXMgdGFibGUgZW50cnkuIFRoaXMgaXMg bm90DQogICAgICAgICAgICAgICAgIG5lY2Vzc2FyaWx5IHRoZSBzYW1lIGFzIHN5c05hbWUgaW4g TUlCIElJLiINCiAgICAgICAgICBSRUZFUkVOQ0UNCiAgICAgICAgICAgICAgICAiUkZDIDI4NjUs IFNlY3Rpb24gNS4zMiwgTkFTLUlkZW50aWZpZXIuIg0KICAgICAgICAgIDo6PSB7IHJhZGl1c0R5 bkF1dGhTZXJ2ZXJFbnRyeSA1IH0NCg0KICAgcmFkaXVzRHluQXV0aENsaWVudFJvdW5kVHJpcFRp bWUgT0JKRUNULVRZUEUNCiAgICAgICAgICBTWU5UQVggICAgIFRpbWVUaWNrcw0KICAgICAgICAg IFVOSVRTICAgICAgImh1bmRyZWR0aHMgb2YgYSBzZWNvbmQiDQogICAgICAgICAgTUFYLUFDQ0VT UyByZWFkLW9ubHkNCiAgICAgICAgICBTVEFUVVMgICAgIGN1cnJlbnQNCiAgICAgICAgICBERVND UklQVElPTg0KICAgICAgICAgICAgICAgICJUaGUgdGltZSBpbnRlcnZhbCAoaW4gaHVuZHJlZHRo cyBvZiBhIHNlY29uZCkgYmV0d2Vlbg0KICAgICAgICAgICAgICAgICB0aGUgbW9zdCByZWNlbnQg RGlzY29ubmVjdCBvciBDb0EgcmVxdWVzdCBhbmQgdGhlDQogICAgICAgICAgICAgICAgIHJlY2Vw dGlvbiBvZiB0aGUgY29ycmVzcG9uZGluZyBEaXNjb25uZWN0IG9yIENvQSByZXBseS4NCiAgICAg ICAgICAgICAgICAgQSB2YWx1ZSBvZiB6ZXJvIGlzIHJldHVybmVkIGluIGNhc2Ugbm8gcmVwbHkg aGFzIGJlZW4NCiAgICAgICAgICAgICAgICAgcmVjZWl2ZWQgeWV0IGZyb20gdGhpcyBzZXJ2ZXIu Ig0KICAgICAgICAgIDo6PSB7IHJhZGl1c0R5bkF1dGhTZXJ2ZXJFbnRyeSA2IH0NCg0KICAgcmFk aXVzRHluQXV0aENsaWVudERpc2NvblJlcXVlc3RzIE9CSkVDVC1UWVBFDQogICAgICAgICAgU1lO VEFYICAgICBDb3VudGVyMzINCiAgICAgICAgICBVTklUUyAgICAgICJyZXF1ZXN0cyINCiAgICAg ICAgICBNQVgtQUNDRVNTIHJlYWQtb25seQ0KICAgICAgICAgIFNUQVRVUyAgICAgY3VycmVudA0K ICAgICAgICAgIERFU0NSSVBUSU9ODQogICAgICAgICAgICAgICAgIlRoZSBudW1iZXIgb2YgUkFE SVVTIERpc2Nvbm5lY3QtUmVxdWVzdHMgc2VudA0KICAgICAgICAgICAgICAgICB0byB0aGlzIER5 bmFtaWMgQXV0aG9yaXphdGlvbiBTZXJ2ZXIuIFRoaXMgYWxzbw0KICAgICAgICAgICAgICAgICBp bmNsdWRlcyB0aGUgUkFESVVTIERpc2Nvbm5lY3QtUmVxdWVzdHMgdGhhdCBoYXZlIGENCiAgICAg ICAgICAgICAgICAgU2VydmljZS1UeXBlIGF0dHJpYnV0ZSB3aXRoIHZhbHVlICdBdXRob3JpemUg T25seScuDQogICAgICAgICAgICAgICAgIERpc2Nvbm5lY3QtTkFLIHBhY2tldHMgcmVjZWl2ZWQg ZnJvbSB1bmtub3duIGFkZHJlc3Nlcy4NCiAgICAgICAgICAgICAgICAgVGhpcyBjb3VudGVyIG1h eSBleHBlcmllbmNlIGEgZGlzY29udGludWl0eSB3aGVuIHRoZQ0KICAgICAgICAgICAgICAgICBE QUMgbW9kdWxlIChyZSlzdGFydHMgYXMgaW5kaWNhdGVkIGJ5IHRoZSB2YWx1ZSBvZg0KICAgICAg ICAgICAgICAgICByYWRpdXNEeW5BdXRoQ2xpZW50Q291bnRlckRpc2NvbnRpbnVpdHkuIg0KICAg ICAgICAgIFJFRkVSRU5DRQ0KDQoNCg0KRGUgQ25vZGRlciwgZXQgYWwuICAgICBFeHBpcmVzIFNl cHRlbWJlciAyMywgMjAwNiAgICAgICAgICAgICAgW1BhZ2UgMTBdDQoMDQpJbnRlcm5ldC1EcmFm dCAgICAgIER5bmFtaWMgQXV0aG9yaXphdGlvbiBDbGllbnQgTUlCICAgICAgICAgIE1hcmNoIDIw MDYNCg0KDQogICAgICAgICAgICAgICAgIlJGQyAzNTc2LCBTZWN0aW9uIDIuMSwgRGlzY29ubmVj dCBNZXNzYWdlcyAoRE0pLiINCiAgICAgICAgICA6Oj0geyByYWRpdXNEeW5BdXRoU2VydmVyRW50 cnkgNyB9DQoNCiAgIHJhZGl1c0R5bkF1dGhDbGllbnREaXNjb25BdXRoT25seVJlcXVlc3RzIE9C SkVDVC1UWVBFDQogICAgICAgICAgU1lOVEFYICAgICBDb3VudGVyMzINCiAgICAgICAgICBVTklU UyAgICAgICJyZXF1ZXN0cyINCiAgICAgICAgICBNQVgtQUNDRVNTIHJlYWQtb25seQ0KICAgICAg ICAgIFNUQVRVUyAgICAgY3VycmVudA0KICAgICAgICAgIERFU0NSSVBUSU9ODQogICAgICAgICAg ICAgICAgIlRoZSBudW1iZXIgb2YgUkFESVVTIERpc2Nvbm5lY3QtUmVxdWVzdHMgdGhhdCBpbmNs dWRlIGENCiAgICAgICAgICAgICAgICAgU2VydmljZS1UeXBlIGF0dHJpYnV0ZSB3aXRoIHZhbHVl ICdBdXRob3JpemUgT25seScNCiAgICAgICAgICAgICAgICAgc2VudCB0byB0aGlzIER5bmFtaWMg QXV0aG9yaXphdGlvbiBTZXJ2ZXIuDQogICAgICAgICAgICAgICAgIERpc2Nvbm5lY3QtTkFLIHBh Y2tldHMgcmVjZWl2ZWQgZnJvbSB1bmtub3duIGFkZHJlc3Nlcy4NCiAgICAgICAgICAgICAgICAg VGhpcyBjb3VudGVyIG1heSBleHBlcmllbmNlIGEgZGlzY29udGludWl0eSB3aGVuIHRoZQ0KICAg ICAgICAgICAgICAgICBEQUMgbW9kdWxlIChyZSlzdGFydHMgYXMgaW5kaWNhdGVkIGJ5IHRoZSB2 YWx1ZSBvZg0KICAgICAgICAgICAgICAgICByYWRpdXNEeW5BdXRoQ2xpZW50Q291bnRlckRpc2Nv bnRpbnVpdHkuIg0KICAgICAgICAgIFJFRkVSRU5DRQ0KICAgICAgICAgICAgICAgICJSRkMgMzU3 NiwgU2VjdGlvbiAyLjEsIERpc2Nvbm5lY3QgTWVzc2FnZXMgKERNKS4iDQogICAgICAgICAgOjo9 IHsgcmFkaXVzRHluQXV0aFNlcnZlckVudHJ5IDggfQ0KDQogICByYWRpdXNEeW5BdXRoQ2xpZW50 RGlzY29uUmV0cmFuc21pc3Npb25zIE9CSkVDVC1UWVBFDQogICAgICAgICAgU1lOVEFYICAgICBD b3VudGVyMzINCiAgICAgICAgICBVTklUUyAgICAgICJyZXRyYW5zbWlzc2lvbnMiDQogICAgICAg ICAgTUFYLUFDQ0VTUyByZWFkLW9ubHkNCiAgICAgICAgICBTVEFUVVMgICAgIGN1cnJlbnQNCiAg ICAgICAgICBERVNDUklQVElPTg0KICAgICAgICAgICAgICAgICJUaGUgbnVtYmVyIG9mIFJBRElV UyBEaXNjb25uZWN0LXJlcXVlc3QgcGFja2V0cw0KICAgICAgICAgICAgICAgICByZXRyYW5zbWl0 dGVkIHRvIHRoaXMgUkFESVVTIER5bmFtaWMgQXV0aG9yaXphdGlvbg0KICAgICAgICAgICAgICAg ICBTZXJ2ZXIuIERpc2Nvbm5lY3QtTkFLIHBhY2tldHMgcmVjZWl2ZWQgZnJvbSB1bmtub3duDQog ICAgICAgICAgICAgICAgIGFkZHJlc3Nlcy4gVGhpcyBjb3VudGVyIG1heSBleHBlcmllbmNlIGEg ZGlzY29udGludWl0eQ0KICAgICAgICAgICAgICAgICB3aGVuIHRoZSBEQUMgbW9kdWxlIChyZSlz dGFydHMgYXMgaW5kaWNhdGVkIGJ5IHRoZQ0KICAgICAgICAgICAgICAgICB2YWx1ZSBvZiByYWRp dXNEeW5BdXRoQ2xpZW50Q291bnRlckRpc2NvbnRpbnVpdHkuIg0KICAgICAgICAgIFJFRkVSRU5D RQ0KICAgICAgICAgICAgICAgICJSRkMgMzU3NiwgU2VjdGlvbiAyLjEsIERpc2Nvbm5lY3QgTWVz c2FnZXMgKERNKS4iDQogICAgICAgICAgOjo9IHsgcmFkaXVzRHluQXV0aFNlcnZlckVudHJ5IDkg fQ0KDQogICByYWRpdXNEeW5BdXRoQ2xpZW50RGlzY29uQWNrcyAgT0JKRUNULVRZUEUNCiAgICAg ICAgICBTWU5UQVggICAgIENvdW50ZXIzMg0KICAgICAgICAgIFVOSVRTICAgICAgInJlcGxpZXMi DQogICAgICAgICAgTUFYLUFDQ0VTUyByZWFkLW9ubHkNCiAgICAgICAgICBTVEFUVVMgICAgIGN1 cnJlbnQNCiAgICAgICAgICBERVNDUklQVElPTg0KICAgICAgICAgICAgICAgICJUaGUgbnVtYmVy IG9mIFJBRElVUyBEaXNjb25uZWN0LUFDSyBwYWNrZXRzDQogICAgICAgICAgICAgICAgIHJlY2Vp dmVkIGZyb20gdGhpcyBEeW5hbWljIEF1dGhvcml6YXRpb24gU2VydmVyLiBUaGlzDQogICAgICAg ICAgICAgICAgIGNvdW50ZXIgbWF5IGV4cGVyaWVuY2UgYSBkaXNjb250aW51aXR5IHdoZW4gdGhl IERBQw0KICAgICAgICAgICAgICAgICBtb2R1bGUgKHJlKXN0YXJ0cyBhcyBpbmRpY2F0ZWQgYnkg dGhlIHZhbHVlIG9mDQogICAgICAgICAgICAgICAgIHJhZGl1c0R5bkF1dGhDbGllbnRDb3VudGVy RGlzY29udGludWl0eS4iDQogICAgICAgICAgUkVGRVJFTkNFDQoNCg0KDQpEZSBDbm9kZGVyLCBl dCBhbC4gICAgIEV4cGlyZXMgU2VwdGVtYmVyIDIzLCAyMDA2ICAgICAgICAgICAgICBbUGFnZSAx MV0NCgwNCkludGVybmV0LURyYWZ0ICAgICAgRHluYW1pYyBBdXRob3JpemF0aW9uIENsaWVudCBN SUIgICAgICAgICAgTWFyY2ggMjAwNg0KDQoNCiAgICAgICAgICAgICAgICAiUkZDIDM1NzYsIFNl Y3Rpb24gMi4xLCBEaXNjb25uZWN0IE1lc3NhZ2VzIChETSkuIg0KICAgICAgICAgIDo6PSB7IHJh ZGl1c0R5bkF1dGhTZXJ2ZXJFbnRyeSAxMCB9DQoNCiAgIHJhZGl1c0R5bkF1dGhDbGllbnREaXNj b25OYWtzIE9CSkVDVC1UWVBFDQogICAgICAgICAgU1lOVEFYICAgICBDb3VudGVyMzINCiAgICAg ICAgICBVTklUUyAgICAgICJyZXBsaWVzIg0KICAgICAgICAgIE1BWC1BQ0NFU1MgcmVhZC1vbmx5 DQogICAgICAgICAgU1RBVFVTICAgICBjdXJyZW50DQogICAgICAgICAgREVTQ1JJUFRJT04NCiAg ICAgICAgICAgICAgICAiVGhlIG51bWJlciBvZiBSQURJVVMgRGlzY29ubmVjdC1OQUsgcGFja2V0 cw0KICAgICAgICAgICAgICAgICByZWNlaXZlZCBmcm9tIHRoaXMgRHluYW1pYyBBdXRob3JpemF0 aW9uIFNlcnZlci4NCiAgICAgICAgICAgICAgICAgVGhpcyBpbmNsdWRlcyB0aGUgUkFESVVTIERp c2Nvbm5lY3QtTkFLIHBhY2tldHMNCiAgICAgICAgICAgICAgICAgcmVjZWl2ZWQgd2l0aCBhIFNl cnZpY2UtVHlwZSBhdHRyaWJ1dGUgd2l0aCB2YWx1ZQ0KICAgICAgICAgICAgICAgICAnQXV0aG9y aXplIE9ubHknIGFuZCB0aGUgUkFESVVTIERpc2Nvbm5lY3QtTkFLDQogICAgICAgICAgICAgICAg IHBhY2tldHMgcmVjZWl2ZWQgbm8gc2Vzc2lvbiBjb250ZXh0IHdhcyBmb3VuZC4gVGhpcw0KICAg ICAgICAgICAgICAgICBjb3VudGVyIG1heSBleHBlcmllbmNlIGEgZGlzY29udGludWl0eSB3aGVu IHRoZSBEQUMNCiAgICAgICAgICAgICAgICAgbW9kdWxlIChyZSlzdGFydHMgYXMgaW5kaWNhdGVk IGJ5IHRoZSB2YWx1ZSBvZg0KICAgICAgICAgICAgICAgICByYWRpdXNEeW5BdXRoQ2xpZW50Q291 bnRlckRpc2NvbnRpbnVpdHkuIg0KICAgICAgICAgIFJFRkVSRU5DRQ0KICAgICAgICAgICAgICAg ICJSRkMgMzU3NiwgU2VjdGlvbiAyLjEsIERpc2Nvbm5lY3QgTWVzc2FnZXMgKERNKS4iDQogICAg ICAgICAgOjo9IHsgcmFkaXVzRHluQXV0aFNlcnZlckVudHJ5IDExIH0NCg0KICAgcmFkaXVzRHlu QXV0aENsaWVudERpc2Nvbk5ha0F1dGhPbmx5UmVxdWVzdCBPQkpFQ1QtVFlQRQ0KICAgICAgICAg IFNZTlRBWCAgICAgQ291bnRlcjMyDQogICAgICAgICAgVU5JVFMgICAgICAicmVwbGllcyINCiAg ICAgICAgICBNQVgtQUNDRVNTIHJlYWQtb25seQ0KICAgICAgICAgIFNUQVRVUyAgICAgY3VycmVu dA0KICAgICAgICAgIERFU0NSSVBUSU9ODQogICAgICAgICAgICAgICAgIlRoZSBudW1iZXIgb2Yg UkFESVVTIERpc2Nvbm5lY3QtTkFLIHBhY2tldHMNCiAgICAgICAgICAgICAgICAgdGhhdCBpbmNs dWRlIGEgU2VydmljZS1UeXBlIGF0dHJpYnV0ZSB3aXRoIHZhbHVlDQogICAgICAgICAgICAgICAg ICdBdXRob3JpemUgT25seScgcmVjZWl2ZWQgZnJvbSB0aGlzIER5bmFtaWMNCiAgICAgICAgICAg ICAgICAgQXV0aG9yaXphdGlvbiBTZXJ2ZXIuIFRoaXMgY291bnRlciBtYXkgZXhwZXJpZW5jZSBh DQogICAgICAgICAgICAgICAgIGRpc2NvbnRpbnVpdHkgd2hlbiB0aGUgREFDIG1vZHVsZSAocmUp c3RhcnRzIGFzDQogICAgICAgICAgICAgICAgIGluZGljYXRlZCBieSB0aGUgdmFsdWUgb2YNCiAg ICAgICAgICAgICAgICAgcmFkaXVzRHluQXV0aENsaWVudENvdW50ZXJEaXNjb250aW51aXR5LiIN CiAgICAgICAgICBSRUZFUkVOQ0UNCiAgICAgICAgICAgICAgICAiUkZDIDM1NzYsIFNlY3Rpb24g Mi4xLCBEaXNjb25uZWN0IE1lc3NhZ2VzIChETSkuIg0KICAgICAgICAgIDo6PSB7IHJhZGl1c0R5 bkF1dGhTZXJ2ZXJFbnRyeSAxMiB9DQoNCiAgIHJhZGl1c0R5bkF1dGhDbGllbnREaXNjb25OYWtT ZXNzTm9Db250ZXh0IE9CSkVDVC1UWVBFDQogICAgICAgICAgU1lOVEFYICAgICBDb3VudGVyMzIN CiAgICAgICAgICBVTklUUyAgICAgICJyZXBsaWVzIg0KICAgICAgICAgIE1BWC1BQ0NFU1MgcmVh ZC1vbmx5DQogICAgICAgICAgU1RBVFVTICAgICBjdXJyZW50DQogICAgICAgICAgREVTQ1JJUFRJ T04NCiAgICAgICAgICAgICAgICAiVGhlIG51bWJlciBvZiBSQURJVVMgRGlzY29ubmVjdC1OQUsg cGFja2V0cw0KICAgICAgICAgICAgICAgICByZWNlaXZlZCBmcm9tIHRoaXMgRHluYW1pYyBBdXRo b3JpemF0aW9uIFNlcnZlcg0KICAgICAgICAgICAgICAgICBiZWNhdXNlIG5vIHNlc3Npb24gY29u dGV4dCB3YXMgZm91bmQsIGkuZS4gaXQNCg0KDQoNCkRlIENub2RkZXIsIGV0IGFsLiAgICAgRXhw aXJlcyBTZXB0ZW1iZXIgMjMsIDIwMDYgICAgICAgICAgICAgIFtQYWdlIDEyXQ0KDA0KSW50ZXJu ZXQtRHJhZnQgICAgICBEeW5hbWljIEF1dGhvcml6YXRpb24gQ2xpZW50IE1JQiAgICAgICAgICBN YXJjaCAyMDA2DQoNCg0KICAgICAgICAgICAgICAgICBpbmNsdWRlcyBhbiBFcnJvci1DYXVzZSBh dHRyaWJ1dGUgd2l0aCB2YWx1ZSA1MDMNCiAgICAgICAgICAgICAgICAgKCdTZXNzaW9uIENvbnRl eHQgTm90IEZvdW5kJykuIFRoaXMgY291bnRlciBtYXkNCiAgICAgICAgICAgICAgICAgZXhwZXJp ZW5jZSBhIGRpc2NvbnRpbnVpdHkgd2hlbiB0aGUgREFDIG1vZHVsZQ0KICAgICAgICAgICAgICAg ICAocmUpc3RhcnRzIGFzIGluZGljYXRlZCBieSB0aGUgdmFsdWUgb2YNCiAgICAgICAgICAgICAg ICAgcmFkaXVzRHluQXV0aENsaWVudENvdW50ZXJEaXNjb250aW51aXR5LiINCiAgICAgICAgICBS RUZFUkVOQ0UNCiAgICAgICAgICAgICAgICAiUkZDIDM1NzYsIFNlY3Rpb24gMi4xLCBEaXNjb25u ZWN0IE1lc3NhZ2VzIChETSkuIg0KICAgICAgICAgIDo6PSB7IHJhZGl1c0R5bkF1dGhTZXJ2ZXJF bnRyeSAxMyB9DQoNCiAgIHJhZGl1c0R5bkF1dGhDbGllbnRNYWxmb3JtZWREaXNjb25SZXNwb25z ZXMgT0JKRUNULVRZUEUNCiAgICAgICAgICBTWU5UQVggICAgIENvdW50ZXIzMg0KICAgICAgICAg IFVOSVRTICAgICAgInJlcGxpZXMiDQogICAgICAgICAgTUFYLUFDQ0VTUyByZWFkLW9ubHkNCiAg ICAgICAgICBTVEFUVVMgICAgIGN1cnJlbnQNCiAgICAgICAgICBERVNDUklQVElPTg0KICAgICAg ICAgICAgICAgICJUaGUgbnVtYmVyIG9mIG1hbGZvcm1lZCBSQURJVVMgRGlzY29ubmVjdC1BY2sg YW5kDQogICAgICAgICAgICAgICAgIERpc2Nvbm5lY3QtTkFLIHBhY2tldHMgcmVjZWl2ZWQgZnJv bSB0aGlzIER5bmFtaWMNCiAgICAgICAgICAgICAgICAgQXV0aG9yaXphdGlvbiBTZXJ2ZXIuIEJh ZCBhdXRoZW50aWNhdG9ycyBhbmQgdW5rbm93bg0KICAgICAgICAgICAgICAgICB0eXBlcyBhcmUg bm90IGluY2x1ZGVkIGFzIG1hbGZvcm1lZCBEaXNjb25uZWN0LUFjayBhbmQNCiAgICAgICAgICAg ICAgICAgRGlzY29ubmVjdC1OQUsgcGFja2V0cy4gVGhpcyBjb3VudGVyIG1heSBleHBlcmllbmNl IGENCiAgICAgICAgICAgICAgICAgZGlzY29udGludWl0eSB3aGVuIHRoZSBEQUMgbW9kdWxlIChy ZSlzdGFydHMgYXMNCiAgICAgICAgICAgICAgICAgaW5kaWNhdGVkIGJ5IHRoZSB2YWx1ZSBvZg0K ICAgICAgICAgICAgICAgICByYWRpdXNEeW5BdXRoQ2xpZW50Q291bnRlckRpc2NvbnRpbnVpdHku Ig0KICAgICAgICAgIFJFRkVSRU5DRQ0KICAgICAgICAgICAgICAgICJSRkMgMzU3NiwgU2VjdGlv biAyLjEsIERpc2Nvbm5lY3QgTWVzc2FnZXMgKERNKSwgYW5kDQogICAgICAgICAgICAgICAgIFNl Y3Rpb24gMi4zLCBQYWNrZXQgRm9ybWF0LiINCiAgICAgICAgICA6Oj0geyByYWRpdXNEeW5BdXRo U2VydmVyRW50cnkgMTQgfQ0KDQogICByYWRpdXNEeW5BdXRoQ2xpZW50RGlzY29uQmFkQXV0aGVu dGljYXRvcnMgT0JKRUNULVRZUEUNCiAgICAgICAgICBTWU5UQVggICAgIENvdW50ZXIzMg0KICAg ICAgICAgIFVOSVRTICAgICAgInJlcGxpZXMiDQogICAgICAgICAgTUFYLUFDQ0VTUyByZWFkLW9u bHkNCiAgICAgICAgICBTVEFUVVMgICAgIGN1cnJlbnQNCiAgICAgICAgICBERVNDUklQVElPTg0K ICAgICAgICAgICAgICAgICJUaGUgbnVtYmVyIG9mIFJBRElVUyBEaXNjb25uZWN0LUFjayBhbmQg RGlzY29ubmVjdC1OQUsNCiAgICAgICAgICAgICAgICAgcGFja2V0cyB3aGljaCBjb250YWluZWQg aW52YWxpZCBBdXRoZW50aWNhdG9yIGZpZWxkDQogICAgICAgICAgICAgICAgIHJlY2VpdmVkIGZy b20gdGhpcyBEeW5hbWljIEF1dGhvcml6YXRpb24gU2VydmVyLiBUaGlzDQogICAgICAgICAgICAg ICAgIGNvdW50ZXIgbWF5IGV4cGVyaWVuY2UgYSBkaXNjb250aW51aXR5IHdoZW4gdGhlIERBQw0K ICAgICAgICAgICAgICAgICBtb2R1bGUgKHJlKXN0YXJ0cyBhcyBpbmRpY2F0ZWQgYnkgdGhlIHZh bHVlIG9mDQogICAgICAgICAgICAgICAgIHJhZGl1c0R5bkF1dGhDbGllbnRDb3VudGVyRGlzY29u dGludWl0eS4iDQogICAgICAgICAgUkVGRVJFTkNFDQogICAgICAgICAgICAgICAgIlJGQyAzNTc2 LCBTZWN0aW9uIDIuMSwgRGlzY29ubmVjdCBNZXNzYWdlcyAoRE0pLCBhbmQNCiAgICAgICAgICAg ICAgICAgU2VjdGlvbiAyLjMsIFBhY2tldCBGb3JtYXQuIg0KICAgICAgICAgIDo6PSB7IHJhZGl1 c0R5bkF1dGhTZXJ2ZXJFbnRyeSAxNSB9DQoNCiAgIHJhZGl1c0R5bkF1dGhDbGllbnREaXNjb25Q ZW5kaW5nUmVxdWVzdHMgT0JKRUNULVRZUEUNCiAgICAgICAgICBTWU5UQVggICAgIEdhdWdlMzIN CiAgICAgICAgICBVTklUUyAgICAgICJyZXF1ZXN0cyINCg0KDQoNCkRlIENub2RkZXIsIGV0IGFs LiAgICAgRXhwaXJlcyBTZXB0ZW1iZXIgMjMsIDIwMDYgICAgICAgICAgICAgIFtQYWdlIDEzXQ0K DA0KSW50ZXJuZXQtRHJhZnQgICAgICBEeW5hbWljIEF1dGhvcml6YXRpb24gQ2xpZW50IE1JQiAg ICAgICAgICBNYXJjaCAyMDA2DQoNCg0KICAgICAgICAgIE1BWC1BQ0NFU1MgcmVhZC1vbmx5DQog ICAgICAgICAgU1RBVFVTICAgICBjdXJyZW50DQogICAgICAgICAgREVTQ1JJUFRJT04NCiAgICAg ICAgICAgICAgICAiVGhlIG51bWJlciBvZiBSQURJVVMgRGlzY29ubmVjdC1yZXF1ZXN0IHBhY2tl dHMNCiAgICAgICAgICAgICAgICAgZGVzdGluZWQgZm9yIHRoaXMgc2VydmVyIHRoYXQgaGF2ZSBu b3QgeWV0IHRpbWVkIG91dA0KICAgICAgICAgICAgICAgICBvciByZWNlaXZlZCBhIHJlc3BvbnNl LiBUaGlzIHZhcmlhYmxlIGlzIGluY3JlbWVudGVkDQogICAgICAgICAgICAgICAgIHdoZW4gYW4g RGlzY29ubmVjdC1SZXF1ZXN0IGlzIHNlbnQgYW5kIGRlY3JlbWVudGVkDQogICAgICAgICAgICAg ICAgIGR1ZSB0byByZWNlaXB0IG9mIGFuIERpc2Nvbm5lY3QtQWNrLCBEaXNjb25uZWN0LU5BSw0K ICAgICAgICAgICAgICAgICBvciBhIHRpbWVvdXQgb3IgYSByZXRyYW5zbWlzc2lvbi4iDQogICAg ICAgICAgUkVGRVJFTkNFDQogICAgICAgICAgICAgICAgIlJGQyAzNTc2LCBTZWN0aW9uIDIuMSwg RGlzY29ubmVjdCBNZXNzYWdlcyAoRE0pLiINCiAgICAgICAgICA6Oj0geyByYWRpdXNEeW5BdXRo U2VydmVyRW50cnkgMTYgfQ0KDQogICByYWRpdXNEeW5BdXRoQ2xpZW50RGlzY29uVGltZW91dHMg T0JKRUNULVRZUEUNCiAgICAgICAgICBTWU5UQVggICAgIENvdW50ZXIzMg0KICAgICAgICAgIFVO SVRTICAgICAgInRpbWVvdXRzIg0KICAgICAgICAgIE1BWC1BQ0NFU1MgcmVhZC1vbmx5DQogICAg ICAgICAgU1RBVFVTICAgICBjdXJyZW50DQogICAgICAgICAgREVTQ1JJUFRJT04NCiAgICAgICAg ICAgICAgICAiVGhlIG51bWJlciBvZiBEaXNjb25uZWN0IHJlcXVlc3QgdGltZW91dHMgdG8gdGhp cw0KICAgICAgICAgICAgICAgICBzZXJ2ZXIuIEFmdGVyIGEgdGltZW91dCB0aGUgY2xpZW50IG1h eSByZXRyeSB0byB0aGUNCiAgICAgICAgICAgICAgICAgc2FtZSBzZXJ2ZXIgb3IgZ2l2ZSB1cC4g QSByZXRyeSB0byB0aGUgc2FtZSBzZXJ2ZXIgaXMNCiAgICAgICAgICAgICAgICAgY291bnRlZCBh cyBhIHJldHJhbnNtaXQgYXMgd2VsbCBhcyBhIHRpbWVvdXQuIEEgc2VuZA0KICAgICAgICAgICAg ICAgICB0byBhIGRpZmZlcmVudCBzZXJ2ZXIgaXMgY291bnRlZCBhcyBhDQogICAgICAgICAgICAg ICAgIERpc2Nvbm5lY3QtUmVxdWVzdCBhcyB3ZWxsIGFzIGEgdGltZW91dC4gVGhpcyBjb3VudGVy DQogICAgICAgICAgICAgICAgIG1heSBleHBlcmllbmNlIGEgZGlzY29udGludWl0eSB3aGVuIHRo ZSBEQUMgbW9kdWxlDQogICAgICAgICAgICAgICAgIChyZSlzdGFydHMgYXMgaW5kaWNhdGVkIGJ5 IHRoZSB2YWx1ZSBvZg0KICAgICAgICAgICAgICAgICByYWRpdXNEeW5BdXRoQ2xpZW50Q291bnRl ckRpc2NvbnRpbnVpdHkuIg0KICAgICAgICAgIFJFRkVSRU5DRQ0KICAgICAgICAgICAgICAgICJS RkMgMzU3NiwgU2VjdGlvbiAyLjEsIERpc2Nvbm5lY3QgTWVzc2FnZXMgKERNKS4iDQogICAgICAg ICAgOjo9IHsgcmFkaXVzRHluQXV0aFNlcnZlckVudHJ5IDE3IH0NCg0KICAgcmFkaXVzRHluQXV0 aENsaWVudERpc2NvblBhY2tldHNEcm9wcGVkIE9CSkVDVC1UWVBFDQogICAgICAgICAgU1lOVEFY ICAgICBDb3VudGVyMzINCiAgICAgICAgICBVTklUUyAgICAgICJyZXBsaWVzIg0KICAgICAgICAg IE1BWC1BQ0NFU1MgcmVhZC1vbmx5DQogICAgICAgICAgU1RBVFVTICAgICBjdXJyZW50DQogICAg ICAgICAgREVTQ1JJUFRJT04NCiAgICAgICAgICAgICAgICAiVGhlIG51bWJlciBvZiBpbmNvbWlu ZyBEaXNjb25uZWN0LUFjayBhbmQNCiAgICAgICAgICAgICAgICAgRGlzY29ubmVjdC1OQUsgcGFj a2V0cyBmcm9tIHRoaXMgRHluYW1pYyBBdXRob3JpemF0aW9uDQogICAgICAgICAgICAgICAgIFNl cnZlciBzaWxlbnRseSBkaXNjYXJkZWQgYnkgdGhlIGNsaWVudCBhcHBsaWNhdGlvbiBmb3INCiAg ICAgICAgICAgICAgICAgc29tZSByZWFzb24gb3RoZXIgdGhhbiBtYWxmb3JtZWQsIGJhZCBhdXRo ZW50aWNhdG9ycyBvcg0KICAgICAgICAgICAgICAgICB1bmtub3duIHR5cGVzLiBUaGlzIGNvdW50 ZXIgbWF5IGV4cGVyaWVuY2UgYQ0KICAgICAgICAgICAgICAgICBkaXNjb250aW51aXR5IHdoZW4g dGhlIERBQyBtb2R1bGUgKHJlKXN0YXJ0cyBhcw0KICAgICAgICAgICAgICAgICBpbmRpY2F0ZWQg YnkgdGhlIHZhbHVlIG9mDQogICAgICAgICAgICAgICAgIHJhZGl1c0R5bkF1dGhDbGllbnRDb3Vu dGVyRGlzY29udGludWl0eS4iDQogICAgICAgICAgUkVGRVJFTkNFDQogICAgICAgICAgICAgICAg IlJGQyAzNTc2LCBTZWN0aW9uIDIuMSwgRGlzY29ubmVjdCBNZXNzYWdlcyAoRE0pLCBhbmQNCg0K DQoNCkRlIENub2RkZXIsIGV0IGFsLiAgICAgRXhwaXJlcyBTZXB0ZW1iZXIgMjMsIDIwMDYgICAg ICAgICAgICAgIFtQYWdlIDE0XQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICBEeW5hbWljIEF1dGhv cml6YXRpb24gQ2xpZW50IE1JQiAgICAgICAgICBNYXJjaCAyMDA2DQoNCg0KICAgICAgICAgICAg ICAgICBTZWN0aW9uIDIuMywgUGFja2V0IEZvcm1hdC4iDQogICAgICAgICAgOjo9IHsgcmFkaXVz RHluQXV0aFNlcnZlckVudHJ5IDE4IH0NCg0KICAgcmFkaXVzRHluQXV0aENsaWVudENvQVJlcXVl c3RzIE9CSkVDVC1UWVBFDQogICAgICAgICAgU1lOVEFYICAgICBDb3VudGVyMzINCiAgICAgICAg ICBVTklUUyAgICAgICJyZXF1ZXN0cyINCiAgICAgICAgICBNQVgtQUNDRVNTIHJlYWQtb25seQ0K ICAgICAgICAgIFNUQVRVUyAgICAgY3VycmVudA0KICAgICAgICAgIERFU0NSSVBUSU9ODQogICAg ICAgICAgICAgICAgIlRoZSBudW1iZXIgb2YgUkFESVVTIENvQS1SZXF1ZXN0cyBzZW50IHRvIHRo aXMNCiAgICAgICAgICAgICAgICAgRHluYW1pYyBBdXRob3JpemF0aW9uIFNlcnZlci4gVGhpcyBh bHNvIGluY2x1ZGVzDQogICAgICAgICAgICAgICAgIHRoZSBDb0EgcmVxdWVzdHMgdGhhdCBoYXZl IGEgU2VydmljZS1UeXBlIGF0dHJpYnV0ZQ0KICAgICAgICAgICAgICAgICB3aXRoIHZhbHVlICdB dXRob3JpemUgT25seScuIFRoaXMgY291bnRlciBtYXkNCiAgICAgICAgICAgICAgICAgZXhwZXJp ZW5jZSBhIGRpc2NvbnRpbnVpdHkgd2hlbiB0aGUgREFDIG1vZHVsZQ0KICAgICAgICAgICAgICAg ICAocmUpc3RhcnRzIGFzIGluZGljYXRlZCBieSB0aGUgdmFsdWUgb2YNCiAgICAgICAgICAgICAg ICAgcmFkaXVzRHluQXV0aENsaWVudENvdW50ZXJEaXNjb250aW51aXR5LiINCiAgICAgICAgICBS RUZFUkVOQ0UNCiAgICAgICAgICAgICAgICAiUkZDIDM1NzYsIFNlY3Rpb24gMi4yLCBDaGFuZ2Ut b2YtQXV0aG9yaXphdGlvbg0KICAgICAgICAgICAgICAgICBNZXNzYWdlcyAoQ29BKS4iDQogICAg ICAgICAgOjo9IHsgcmFkaXVzRHluQXV0aFNlcnZlckVudHJ5IDE5IH0NCg0KICAgcmFkaXVzRHlu QXV0aENsaWVudENvQUF1dGhPbmx5UmVxdWVzdCBPQkpFQ1QtVFlQRQ0KICAgICAgICAgIFNZTlRB WCAgICAgQ291bnRlcjMyDQogICAgICAgICAgVU5JVFMgICAgICAicmVxdWVzdHMiDQogICAgICAg ICAgTUFYLUFDQ0VTUyByZWFkLW9ubHkNCiAgICAgICAgICBTVEFUVVMgICAgIGN1cnJlbnQNCiAg ICAgICAgICBERVNDUklQVElPTg0KICAgICAgICAgICAgICAgICJUaGUgbnVtYmVyIG9mIFJBRElV UyBDb0EtcmVxdWVzdHMgdGhhdCBpbmNsdWRlIGENCiAgICAgICAgICAgICAgICAgU2VydmljZS1U eXBlIGF0dHJpYnV0ZSB3aXRoIHZhbHVlICdBdXRob3JpemUgT25seScNCiAgICAgICAgICAgICAg ICAgc2VudCB0byB0aGlzIER5bmFtaWMgQXV0aG9yaXphdGlvbiBDbGllbnQuIFRoaXMgY291bnRl cg0KICAgICAgICAgICAgICAgICBtYXkgZXhwZXJpZW5jZSBhIGRpc2NvbnRpbnVpdHkgd2hlbiB0 aGUgREFDIG1vZHVsZQ0KICAgICAgICAgICAgICAgICAocmUpc3RhcnRzIGFzIGluZGljYXRlZCBi eSB0aGUgdmFsdWUgb2YNCiAgICAgICAgICAgICAgICAgcmFkaXVzRHluQXV0aENsaWVudENvdW50 ZXJEaXNjb250aW51aXR5LiINCiAgICAgICAgICBSRUZFUkVOQ0UNCiAgICAgICAgICAgICAgICAi UkZDIDM1NzYsIFNlY3Rpb24gMi4yLCBDaGFuZ2Utb2YtQXV0aG9yaXphdGlvbg0KICAgICAgICAg ICAgICAgICBNZXNzYWdlcyAoQ29BKS4iDQogICAgICAgICAgOjo9IHsgcmFkaXVzRHluQXV0aFNl cnZlckVudHJ5IDIwIH0NCg0KICAgcmFkaXVzRHluQXV0aENsaWVudENvQVJldHJhbnNtaXNzaW9u cyBPQkpFQ1QtVFlQRQ0KICAgICAgICAgIFNZTlRBWCAgICAgQ291bnRlcjMyDQogICAgICAgICAg VU5JVFMgICAgICAicmV0cmFuc21pc3Npb25zIg0KICAgICAgICAgIE1BWC1BQ0NFU1MgcmVhZC1v bmx5DQogICAgICAgICAgU1RBVFVTICAgICBjdXJyZW50DQogICAgICAgICAgREVTQ1JJUFRJT04N CiAgICAgICAgICAgICAgICAiVGhlIG51bWJlciBvZiBSQURJVVMgQ29BLXJlcXVlc3QgcGFja2V0 cw0KICAgICAgICAgICAgICAgICByZXRyYW5zbWl0dGVkIHRvIHRoaXMgUkFESVVTIER5bmFtaWMg QXV0aG9yaXphdGlvbg0KICAgICAgICAgICAgICAgICBTZXJ2ZXIuIFRoaXMgY291bnRlciBtYXkg ZXhwZXJpZW5jZSBhIGRpc2NvbnRpbnVpdHkNCiAgICAgICAgICAgICAgICAgd2hlbiB0aGUgREFD IG1vZHVsZSAocmUpc3RhcnRzIGFzIGluZGljYXRlZCBieSB0aGUNCg0KDQoNCkRlIENub2RkZXIs IGV0IGFsLiAgICAgRXhwaXJlcyBTZXB0ZW1iZXIgMjMsIDIwMDYgICAgICAgICAgICAgIFtQYWdl IDE1XQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICBEeW5hbWljIEF1dGhvcml6YXRpb24gQ2xpZW50 IE1JQiAgICAgICAgICBNYXJjaCAyMDA2DQoNCg0KICAgICAgICAgICAgICAgICB2YWx1ZSBvZiBy YWRpdXNEeW5BdXRoQ2xpZW50Q291bnRlckRpc2NvbnRpbnVpdHkuIg0KICAgICAgICAgIFJFRkVS RU5DRQ0KICAgICAgICAgICAgICAgICJSRkMgMzU3NiwgU2VjdGlvbiAyLjIsIENoYW5nZS1vZi1B dXRob3JpemF0aW9uDQogICAgICAgICAgICAgICAgIE1lc3NhZ2VzIChDb0EpLiINCiAgICAgICAg ICA6Oj0geyByYWRpdXNEeW5BdXRoU2VydmVyRW50cnkgMjEgfQ0KDQogICByYWRpdXNEeW5BdXRo Q2xpZW50Q29BQWNrcyAgT0JKRUNULVRZUEUNCiAgICAgICAgICBTWU5UQVggICAgIENvdW50ZXIz Mg0KICAgICAgICAgIFVOSVRTICAgICAgInJlcGxpZXMiDQogICAgICAgICAgTUFYLUFDQ0VTUyBy ZWFkLW9ubHkNCiAgICAgICAgICBTVEFUVVMgICAgIGN1cnJlbnQNCiAgICAgICAgICBERVNDUklQ VElPTg0KICAgICAgICAgICAgICAgICJUaGUgbnVtYmVyIG9mIFJBRElVUyBDb0EtQUNLIHBhY2tl dHMgcmVjZWl2ZWQgZnJvbQ0KICAgICAgICAgICAgICAgICB0aGlzIER5bmFtaWMgQXV0aG9yaXph dGlvbiBTZXJ2ZXIuIFRoaXMgY291bnRlciBtYXkNCiAgICAgICAgICAgICAgICAgZXhwZXJpZW5j ZSBhIGRpc2NvbnRpbnVpdHkgd2hlbiB0aGUgREFDIG1vZHVsZQ0KICAgICAgICAgICAgICAgICAo cmUpc3RhcnRzIGFzIGluZGljYXRlZCBieSB0aGUgdmFsdWUgb2YNCiAgICAgICAgICAgICAgICAg cmFkaXVzRHluQXV0aENsaWVudENvdW50ZXJEaXNjb250aW51aXR5LiINCiAgICAgICAgICBSRUZF UkVOQ0UNCiAgICAgICAgICAgICAgICAiUkZDIDM1NzYsIFNlY3Rpb24gMi4yLCBDaGFuZ2Utb2Yt QXV0aG9yaXphdGlvbg0KICAgICAgICAgICAgICAgICBNZXNzYWdlcyAoQ29BKS4iDQogICAgICAg ICAgOjo9IHsgcmFkaXVzRHluQXV0aFNlcnZlckVudHJ5IDIyIH0NCg0KICAgcmFkaXVzRHluQXV0 aENsaWVudENvQU5ha3MgT0JKRUNULVRZUEUNCiAgICAgICAgICBTWU5UQVggICAgIENvdW50ZXIz Mg0KICAgICAgICAgIFVOSVRTICAgICAgInJlcGxpZXMiDQogICAgICAgICAgTUFYLUFDQ0VTUyBy ZWFkLW9ubHkNCiAgICAgICAgICBTVEFUVVMgICAgIGN1cnJlbnQNCiAgICAgICAgICBERVNDUklQ VElPTg0KICAgICAgICAgICAgICAgICJUaGUgbnVtYmVyIG9mIFJBRElVUyBDb0EtTkFLIHBhY2tl dHMgcmVjZWl2ZWQgZnJvbQ0KICAgICAgICAgICAgICAgICB0aGlzIER5bmFtaWMgQXV0aG9yaXph dGlvbiBTZXJ2ZXIuIFRoaXMgaW5jbHVkZXMgdGhlDQogICAgICAgICAgICAgICAgIFJBRElVUyBD b0EtTkFLIHBhY2tldHMgcmVjZWl2ZWQgd2l0aCBhIFNlcnZpY2UtVHlwZQ0KICAgICAgICAgICAg ICAgICBhdHRyaWJ1dGUgd2l0aCB2YWx1ZSAnQXV0aG9yaXplIE9ubHknIGFuZCB0aGUgUkFESVVT DQogICAgICAgICAgICAgICAgIENvQS1OQUsgcGFja2V0cyByZWNlaXZlZCBiZWNhdXNlIG5vIHNl c3Npb24gY29udGV4dA0KICAgICAgICAgICAgICAgICB3YXMgZm91bmQuIFRoaXMgY291bnRlciBt YXkgZXhwZXJpZW5jZSBhIGRpc2NvbnRpbnVpdHkNCiAgICAgICAgICAgICAgICAgd2hlbiB0aGUg REFDIG1vZHVsZSAocmUpc3RhcnRzIGFzIGluZGljYXRlZCBieSB0aGUNCiAgICAgICAgICAgICAg ICAgdmFsdWUgb2YgcmFkaXVzRHluQXV0aENsaWVudENvdW50ZXJEaXNjb250aW51aXR5LiINCiAg ICAgICAgICBSRUZFUkVOQ0UNCiAgICAgICAgICAgICAgICAiUkZDIDM1NzYsIFNlY3Rpb24gMi4y LCBDaGFuZ2Utb2YtQXV0aG9yaXphdGlvbg0KICAgICAgICAgICAgICAgICBNZXNzYWdlcyAoQ29B KS4iDQogICAgICAgICAgOjo9IHsgcmFkaXVzRHluQXV0aFNlcnZlckVudHJ5IDIzIH0NCg0KICAg cmFkaXVzRHluQXV0aENsaWVudENvQU5ha0F1dGhPbmx5UmVxdWVzdCBPQkpFQ1QtVFlQRQ0KICAg ICAgICAgIFNZTlRBWCAgICAgQ291bnRlcjMyDQogICAgICAgICAgVU5JVFMgICAgICAicmVwbGll cyINCiAgICAgICAgICBNQVgtQUNDRVNTIHJlYWQtb25seQ0KICAgICAgICAgIFNUQVRVUyAgICAg Y3VycmVudA0KICAgICAgICAgIERFU0NSSVBUSU9ODQogICAgICAgICAgICAgICAgIlRoZSBudW1i ZXIgb2YgUkFESVVTIENvQS1OQUsgcGFja2V0cyB0aGF0IGluY2x1ZGUgYQ0KDQoNCg0KRGUgQ25v ZGRlciwgZXQgYWwuICAgICBFeHBpcmVzIFNlcHRlbWJlciAyMywgMjAwNiAgICAgICAgICAgICAg W1BhZ2UgMTZdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgIER5bmFtaWMgQXV0aG9yaXphdGlvbiBD bGllbnQgTUlCICAgICAgICAgIE1hcmNoIDIwMDYNCg0KDQogICAgICAgICAgICAgICAgIFNlcnZp Y2UtVHlwZSBhdHRyaWJ1dGUgd2l0aCB2YWx1ZSAnQXV0aG9yaXplIE9ubHknDQogICAgICAgICAg ICAgICAgIHJlY2VpdmVkIGZyb20gdGhpcyBEeW5hbWljIEF1dGhvcml6YXRpb24gU2VydmVyLiBU aGlzDQogICAgICAgICAgICAgICAgIGNvdW50ZXIgbWF5IGV4cGVyaWVuY2UgYSBkaXNjb250aW51 aXR5IHdoZW4gdGhlIERBQw0KICAgICAgICAgICAgICAgICBtb2R1bGUgKHJlKXN0YXJ0cyBhcyBp bmRpY2F0ZWQgYnkgdGhlIHZhbHVlIG9mDQogICAgICAgICAgICAgICAgIHJhZGl1c0R5bkF1dGhD bGllbnRDb3VudGVyRGlzY29udGludWl0eS4iDQogICAgICAgICAgUkVGRVJFTkNFDQogICAgICAg ICAgICAgICAgIlJGQyAzNTc2LCBTZWN0aW9uIDIuMiwgQ2hhbmdlLW9mLUF1dGhvcml6YXRpb24N CiAgICAgICAgICAgICAgICAgTWVzc2FnZXMgKENvQSkuIg0KICAgICAgICAgIDo6PSB7IHJhZGl1 c0R5bkF1dGhTZXJ2ZXJFbnRyeSAyNCB9DQoNCiAgIHJhZGl1c0R5bkF1dGhDbGllbnRDb0FOYWtT ZXNzTm9Db250ZXh0IE9CSkVDVC1UWVBFDQogICAgICAgICAgU1lOVEFYICAgICBDb3VudGVyMzIN CiAgICAgICAgICBVTklUUyAgICAgICJyZXBsaWVzIg0KICAgICAgICAgIE1BWC1BQ0NFU1MgcmVh ZC1vbmx5DQogICAgICAgICAgU1RBVFVTICAgICBjdXJyZW50DQogICAgICAgICAgREVTQ1JJUFRJ T04NCiAgICAgICAgICAgICAgICAiVGhlIG51bWJlciBvZiBSQURJVVMgQ29BLU5BSyBwYWNrZXRz IHJlY2VpdmVkIGZyb20NCiAgICAgICAgICAgICAgICAgdGhpcyBEeW5hbWljIEF1dGhvcml6YXRp b24gU2VydmVyIGJlY2F1c2Ugbm8gc2Vzc2lvbg0KICAgICAgICAgICAgICAgICBjb250ZXh0IHdh cyBmb3VuZCwgaS5lLiBpdCBpbmNsdWRlcyBhbiBFcnJvci1DYXVzZQ0KICAgICAgICAgICAgICAg ICBhdHRyaWJ1dGUgd2l0aCB2YWx1ZSA1MDMgKCdTZXNzaW9uIENvbnRleHQgTm90IEZvdW5kJyku DQogICAgICAgICAgICAgICAgIFRoaXMgY291bnRlciBtYXkgZXhwZXJpZW5jZSBhIGRpc2NvbnRp bnVpdHkgd2hlbiB0aGUNCiAgICAgICAgICAgICAgICAgREFDIG1vZHVsZSAocmUpc3RhcnRzIGFz IGluZGljYXRlZCBieSB0aGUgdmFsdWUgb2YNCiAgICAgICAgICAgICAgICAgcmFkaXVzRHluQXV0 aENsaWVudENvdW50ZXJEaXNjb250aW51aXR5LiINCiAgICAgICAgICBSRUZFUkVOQ0UNCiAgICAg ICAgICAgICAgICAiUkZDIDM1NzYsIFNlY3Rpb24gMi4yLCBDaGFuZ2Utb2YtQXV0aG9yaXphdGlv bg0KICAgICAgICAgICAgICAgICBNZXNzYWdlcyAoQ29BKS4iDQogICAgICAgICAgOjo9IHsgcmFk aXVzRHluQXV0aFNlcnZlckVudHJ5IDI1IH0NCg0KICAgcmFkaXVzRHluQXV0aENsaWVudE1hbGZv cm1lZENvQVJlc3BvbnNlcyBPQkpFQ1QtVFlQRQ0KICAgICAgICAgIFNZTlRBWCAgICAgQ291bnRl cjMyDQogICAgICAgICAgVU5JVFMgICAgICAicmVwbGllcyINCiAgICAgICAgICBNQVgtQUNDRVNT IHJlYWQtb25seQ0KICAgICAgICAgIFNUQVRVUyAgICAgY3VycmVudA0KICAgICAgICAgIERFU0NS SVBUSU9ODQogICAgICAgICAgICAgICAgIlRoZSBudW1iZXIgb2YgbWFsZm9ybWVkIFJBRElVUyBD b0EtQWNrIGFuZCBDb0EtTkFLDQogICAgICAgICAgICAgICAgIHBhY2tldHMgcmVjZWl2ZWQgZnJv bSB0aGlzIER5bmFtaWMgQXV0aG9yaXphdGlvbg0KICAgICAgICAgICAgICAgICBTZXJ2ZXIuIEJh ZCBhdXRoZW50aWNhdG9ycyBhbmQgdW5rbm93biB0eXBlcyBhcmUNCiAgICAgICAgICAgICAgICAg bm90IGluY2x1ZGVkIGFzIG1hbGZvcm1lZCBDb0EtQWNrIGFuZCBDb0EtTkFLIHBhY2tldHMuDQog ICAgICAgICAgICAgICAgIFRoaXMgY291bnRlciBtYXkgZXhwZXJpZW5jZSBhIGRpc2NvbnRpbnVp dHkgd2hlbiB0aGUNCiAgICAgICAgICAgICAgICAgREFDIG1vZHVsZSAocmUpc3RhcnRzIGFzIGlu ZGljYXRlZCBieSB0aGUgdmFsdWUgb2YNCiAgICAgICAgICAgICAgICAgcmFkaXVzRHluQXV0aENs aWVudENvdW50ZXJEaXNjb250aW51aXR5LiINCiAgICAgICAgICBSRUZFUkVOQ0UNCiAgICAgICAg ICAgICAgICAiUkZDIDM1NzYsIFNlY3Rpb24gMi4yLCBDaGFuZ2Utb2YtQXV0aG9yaXphdGlvbg0K ICAgICAgICAgICAgICAgICBNZXNzYWdlcyAoQ29BKSwgYW5kIFNlY3Rpb24gMi4zLCBQYWNrZXQg Rm9ybWF0LiINCiAgICAgICAgICA6Oj0geyByYWRpdXNEeW5BdXRoU2VydmVyRW50cnkgMjYgfQ0K DQogICByYWRpdXNEeW5BdXRoQ2xpZW50Q29BQmFkQXV0aGVudGljYXRvcnMgT0JKRUNULVRZUEUN CiAgICAgICAgICBTWU5UQVggICAgIENvdW50ZXIzMg0KDQoNCg0KRGUgQ25vZGRlciwgZXQgYWwu ICAgICBFeHBpcmVzIFNlcHRlbWJlciAyMywgMjAwNiAgICAgICAgICAgICAgW1BhZ2UgMTddDQoM DQpJbnRlcm5ldC1EcmFmdCAgICAgIER5bmFtaWMgQXV0aG9yaXphdGlvbiBDbGllbnQgTUlCICAg ICAgICAgIE1hcmNoIDIwMDYNCg0KDQogICAgICAgICAgVU5JVFMgICAgICAicmVwbGllcyINCiAg ICAgICAgICBNQVgtQUNDRVNTIHJlYWQtb25seQ0KICAgICAgICAgIFNUQVRVUyAgICAgY3VycmVu dA0KICAgICAgICAgIERFU0NSSVBUSU9ODQogICAgICAgICAgICAgICAgIlRoZSBudW1iZXIgb2Yg UkFESVVTIENvQS1BY2sgYW5kIENvQS1OQUsgcGFja2V0cw0KICAgICAgICAgICAgICAgICB3aGlj aCBjb250YWluZWQgaW52YWxpZCBBdXRoZW50aWNhdG9yIGZpZWxkDQogICAgICAgICAgICAgICAg IHJlY2VpdmVkIGZyb20gdGhpcyBEeW5hbWljIEF1dGhvcml6YXRpb24gU2VydmVyLg0KICAgICAg ICAgICAgICAgICBUaGlzIGNvdW50ZXIgbWF5IGV4cGVyaWVuY2UgYSBkaXNjb250aW51aXR5IHdo ZW4gdGhlDQogICAgICAgICAgICAgICAgIERBQyBtb2R1bGUgKHJlKXN0YXJ0cyBhcyBpbmRpY2F0 ZWQgYnkgdGhlIHZhbHVlIG9mDQogICAgICAgICAgICAgICAgIHJhZGl1c0R5bkF1dGhDbGllbnRD b3VudGVyRGlzY29udGludWl0eS4iDQogICAgICAgICAgUkVGRVJFTkNFDQogICAgICAgICAgICAg ICAgIlJGQyAzNTc2LCBTZWN0aW9uIDIuMiwgQ2hhbmdlLW9mLUF1dGhvcml6YXRpb24NCiAgICAg ICAgICAgICAgICAgTWVzc2FnZXMgKENvQSksIGFuZCBTZWN0aW9uIDIuMywgUGFja2V0IEZvcm1h dC4iDQogICAgICAgICAgOjo9IHsgcmFkaXVzRHluQXV0aFNlcnZlckVudHJ5IDI3IH0NCg0KICAg cmFkaXVzRHluQXV0aENsaWVudENvQVBlbmRpbmdSZXF1ZXN0cyBPQkpFQ1QtVFlQRQ0KICAgICAg ICAgIFNZTlRBWCAgICAgR2F1Z2UzMg0KICAgICAgICAgIFVOSVRTICAgICAgInJlcXVlc3RzIg0K ICAgICAgICAgIE1BWC1BQ0NFU1MgcmVhZC1vbmx5DQogICAgICAgICAgU1RBVFVTICAgICBjdXJy ZW50DQogICAgICAgICAgREVTQ1JJUFRJT04NCiAgICAgICAgICAgICAgICAiVGhlIG51bWJlciBv ZiBSQURJVVMgQ29BLXJlcXVlc3QgcGFja2V0cyBkZXN0aW5lZCBmb3INCiAgICAgICAgICAgICAg ICAgdGhpcyBzZXJ2ZXIgdGhhdCBoYXZlIG5vdCB5ZXQgdGltZWQgb3V0IG9yIHJlY2VpdmVkIGEN CiAgICAgICAgICAgICAgICAgcmVzcG9uc2UuIFRoaXMgdmFyaWFibGUgaXMgaW5jcmVtZW50ZWQg d2hlbiBhbg0KICAgICAgICAgICAgICAgICBDb0EtUmVxdWVzdCBpcyBzZW50IGFuZCBkZWNyZW1l bnRlZCBkdWUgdG8gcmVjZWlwdCBvZg0KICAgICAgICAgICAgICAgICBhIENvQS1BY2ssIENvQS1O QUsgb3IgYSB0aW1lb3V0IG9yIGEgcmV0cmFuc21pc3Npb24uIg0KICAgICAgICAgIFJFRkVSRU5D RQ0KICAgICAgICAgICAgICAgICJSRkMgMzU3NiwgU2VjdGlvbiAyLjIsIENoYW5nZS1vZi1BdXRo b3JpemF0aW9uDQogICAgICAgICAgICAgICAgIE1lc3NhZ2VzIChDb0EpLiINCiAgICAgICAgICA6 Oj0geyByYWRpdXNEeW5BdXRoU2VydmVyRW50cnkgMjggfQ0KDQogICByYWRpdXNEeW5BdXRoQ2xp ZW50Q29BVGltZW91dHMgT0JKRUNULVRZUEUNCiAgICAgICAgICBTWU5UQVggICAgIENvdW50ZXIz Mg0KICAgICAgICAgIFVOSVRTICAgICAgInRpbWVvdXRzIg0KICAgICAgICAgIE1BWC1BQ0NFU1Mg cmVhZC1vbmx5DQogICAgICAgICAgU1RBVFVTICAgICBjdXJyZW50DQogICAgICAgICAgREVTQ1JJ UFRJT04NCiAgICAgICAgICAgICAgICAiVGhlIG51bWJlciBvZiBDb0EgcmVxdWVzdCB0aW1lb3V0 cyB0byB0aGlzIHNlcnZlci4NCiAgICAgICAgICAgICAgICAgQWZ0ZXIgYSB0aW1lb3V0IHRoZSBj bGllbnQgbWF5IHJldHJ5IHRvIHRoZSBzYW1lDQogICAgICAgICAgICAgICAgIHNlcnZlciBvciBn aXZlIHVwLiBBIHJldHJ5IHRvIHRoZSBzYW1lIHNlcnZlciBpcw0KICAgICAgICAgICAgICAgICBj b3VudGVkIGFzIGEgcmV0cmFuc21pdCBhcyB3ZWxsIGFzIGEgdGltZW91dC4gQSBzZW5kIHRvDQog ICAgICAgICAgICAgICAgIGEgZGlmZmVyZW50IHNlcnZlciBpcyBjb3VudGVkIGFzIGEgQ29BLVJl cXVlc3QgYXMgd2VsbA0KICAgICAgICAgICAgICAgICBhcyBhIHRpbWVvdXQuIFRoaXMgY291bnRl ciBtYXkgZXhwZXJpZW5jZSBhDQogICAgICAgICAgICAgICAgIGRpc2NvbnRpbnVpdHkgd2hlbiB0 aGUgREFDIG1vZHVsZSAocmUpc3RhcnRzIGFzDQogICAgICAgICAgICAgICAgIGluZGljYXRlZCBi eSB0aGUgdmFsdWUgb2YNCiAgICAgICAgICAgICAgICAgcmFkaXVzRHluQXV0aENsaWVudENvdW50 ZXJEaXNjb250aW51aXR5LiINCiAgICAgICAgICBSRUZFUkVOQ0UNCiAgICAgICAgICAgICAgICAi UkZDIDM1NzYsIFNlY3Rpb24gMi4yLCBDaGFuZ2Utb2YtQXV0aG9yaXphdGlvbg0KDQoNCg0KRGUg Q25vZGRlciwgZXQgYWwuICAgICBFeHBpcmVzIFNlcHRlbWJlciAyMywgMjAwNiAgICAgICAgICAg ICAgW1BhZ2UgMThdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgIER5bmFtaWMgQXV0aG9yaXphdGlv biBDbGllbnQgTUlCICAgICAgICAgIE1hcmNoIDIwMDYNCg0KDQogICAgICAgICAgICAgICAgIE1l c3NhZ2VzIChDb0EpLiINCiAgICAgICAgICA6Oj0geyByYWRpdXNEeW5BdXRoU2VydmVyRW50cnkg MjkgfQ0KDQogICByYWRpdXNEeW5BdXRoQ2xpZW50Q29BUGFja2V0c0Ryb3BwZWQgT0JKRUNULVRZ UEUNCiAgICAgICAgICBTWU5UQVggICAgIENvdW50ZXIzMg0KICAgICAgICAgIFVOSVRTICAgICAg InJlcGxpZXMiDQogICAgICAgICAgTUFYLUFDQ0VTUyByZWFkLW9ubHkNCiAgICAgICAgICBTVEFU VVMgICAgIGN1cnJlbnQNCiAgICAgICAgICBERVNDUklQVElPTg0KICAgICAgICAgICAgICAgICJU aGUgbnVtYmVyIG9mIGluY29taW5nIENvQS1BY2sgYW5kIENvQS1OQUsgZnJvbSB0aGlzDQogICAg ICAgICAgICAgICAgIER5bmFtaWMgQXV0aG9yaXphdGlvbiBTZXJ2ZXIgc2lsZW50bHkgZGlzY2Fy ZGVkIGJ5IHRoZQ0KICAgICAgICAgICAgICAgICBjbGllbnQgYXBwbGljYXRpb24gZm9yIHNvbWUg cmVhc29uIG90aGVyIHRoYW4NCiAgICAgICAgICAgICAgICAgbWFsZm9ybWVkLCBiYWQgYXV0aGVu dGljYXRvcnMgb3IgdW5rbm93biB0eXBlcy4gVGhpcw0KICAgICAgICAgICAgICAgICBjb3VudGVy IG1heSBleHBlcmllbmNlIGEgZGlzY29udGludWl0eSB3aGVuIHRoZSBEQUMNCiAgICAgICAgICAg ICAgICAgbW9kdWxlIChyZSlzdGFydHMgYXMgaW5kaWNhdGVkIGJ5IHRoZSB2YWx1ZSBvZg0KICAg ICAgICAgICAgICAgICByYWRpdXNEeW5BdXRoQ2xpZW50Q291bnRlckRpc2NvbnRpbnVpdHkuIg0K ICAgICAgICAgIFJFRkVSRU5DRQ0KICAgICAgICAgICAgICAgICJSRkMgMzU3NiwgU2VjdGlvbiAy LjIsIENoYW5nZS1vZi1BdXRob3JpemF0aW9uDQogICAgICAgICAgICAgICAgIE1lc3NhZ2VzIChD b0EpLCBhbmQgU2VjdGlvbiAyLjMsIFBhY2tldCBGb3JtYXQuIg0KICAgICAgICAgIDo6PSB7IHJh ZGl1c0R5bkF1dGhTZXJ2ZXJFbnRyeSAzMCB9DQoNCiAgIHJhZGl1c0R5bkF1dGhDbGllbnRVbmtu b3duVHlwZXMgT0JKRUNULVRZUEUNCiAgICAgICAgICBTWU5UQVggICAgIENvdW50ZXIzMg0KICAg ICAgICAgIFVOSVRTICAgICAgInJlcGxpZXMiDQogICAgICAgICAgTUFYLUFDQ0VTUyByZWFkLW9u bHkNCiAgICAgICAgICBTVEFUVVMgICAgIGN1cnJlbnQNCiAgICAgICAgICBERVNDUklQVElPTg0K ICAgICAgICAgICAgICAgICJUaGUgbnVtYmVyIG9mIGluY29taW5nIHBhY2tldHMgb2YgdW5rbm93 biB0eXBlcw0KICAgICAgICAgICAgICAgICB3aGljaCB3ZXJlIHJlY2VpdmVkIG9uIHRoZSBEeW5h bWljIEF1dGhvcml6YXRpb24gcG9ydC4NCiAgICAgICAgICAgICAgICAgVGhpcyBjb3VudGVyIG1h eSBleHBlcmllbmNlIGEgZGlzY29udGludWl0eSB3aGVuIHRoZQ0KICAgICAgICAgICAgICAgICBE QUMgbW9kdWxlIChyZSlzdGFydHMgYXMgaW5kaWNhdGVkIGJ5IHRoZSB2YWx1ZSBvZg0KICAgICAg ICAgICAgICAgICByYWRpdXNEeW5BdXRoQ2xpZW50Q291bnRlckRpc2NvbnRpbnVpdHkuIg0KICAg ICAgICAgIFJFRkVSRU5DRQ0KICAgICAgICAgICAgICAgICJSRkMgMzU3NiwgU2VjdGlvbiAyLjMs IFBhY2tldCBGb3JtYXQuIg0KICAgICAgICAgIDo6PSB7IHJhZGl1c0R5bkF1dGhTZXJ2ZXJFbnRy eSAzMSB9DQoNCiAgIC0tIGNvbmZvcm1hbmNlIGluZm9ybWF0aW9uDQoNCiAgIHJhZGl1c0R5bkF1 dGhDbGllbnRNSUJDb25mb3JtYW5jZQ0KICAgICAgICAgIE9CSkVDVCBJREVOVElGSUVSIDo6PSB7 IHJhZGl1c0R5bkF1dGhDbGllbnRNSUIgMiB9DQogICByYWRpdXNEeW5BdXRoQ2xpZW50TUlCQ29t cGxpYW5jZXMNCiAgICAgICAgICBPQkpFQ1QgSURFTlRJRklFUiA6Oj0geyByYWRpdXNEeW5BdXRo Q2xpZW50TUlCQ29uZm9ybWFuY2UgMSB9DQogICByYWRpdXNEeW5BdXRoQ2xpZW50TUlCR3JvdXBz DQogICAgICAgICAgT0JKRUNUIElERU5USUZJRVIgOjo9IHsgcmFkaXVzRHluQXV0aENsaWVudE1J QkNvbmZvcm1hbmNlIDIgfQ0KDQogICAtLSBjb21wbGlhbmNlIHN0YXRlbWVudHMNCg0KICAgcmFk aXVzRHluQXV0aENsaWVudE1JQkNvbXBsaWFuY2UgTU9EVUxFLUNPTVBMSUFOQ0UNCg0KDQoNCkRl IENub2RkZXIsIGV0IGFsLiAgICAgRXhwaXJlcyBTZXB0ZW1iZXIgMjMsIDIwMDYgICAgICAgICAg ICAgIFtQYWdlIDE5XQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICBEeW5hbWljIEF1dGhvcml6YXRp b24gQ2xpZW50IE1JQiAgICAgICAgICBNYXJjaCAyMDA2DQoNCg0KICAgICAgICAgIFNUQVRVUyAg Y3VycmVudA0KICAgICAgICAgIERFU0NSSVBUSU9ODQogICAgICAgICAgICAgICAgIlRoZSBjb21w bGlhbmNlIHN0YXRlbWVudCBmb3IgZW50aXRpZXMgaW1wbGVtZW50aW5nDQogICAgICAgICAgICAg ICAgIHRoZSBSQURJVVMgRHluYW1pYyBBdXRob3JpemF0aW9uIENsaWVudC4gSW1wbGVtZW50YXRp b24NCiAgICAgICAgICAgICAgICAgb2YgdGhpcyBtb2R1bGUgaXMgZm9yIGVudGl0aWVzIHRoYXQg c3VwcG9ydCBJUHY2LCBvcg0KICAgICAgICAgICAgICAgICBzdXBwb3J0IElQdjQgYW5kIElQdjYu Ig0KICAgICAgICAgIE1PRFVMRSAgLS0gdGhpcyBtb2R1bGUNCiAgICAgICAgICBNQU5EQVRPUlkt R1JPVVBTIHsgcmFkaXVzRHluQXV0aENsaWVudE1JQkdyb3VwIH0NCg0KICAgICAgICAgIE9CSkVD VCAgICAgICAgICAgICByYWRpdXNEeW5BdXRoU2VydmVyQWRkcmVzc1R5cGUNCiAgICAgICAgICBT WU5UQVggICAgICAgICAgICAgSW5ldEFkZHJlc3NUeXBlIHsgaXB2NCgxKSwgaXB2NigyKSB9DQog ICAgICAgICAgREVTQ1JJUFRJT04NCiAgICAgICAgICAgICAgIkFuIGltcGxlbWVudGF0aW9uIGlz IG9ubHkgcmVxdWlyZWQgdG8gc3VwcG9ydCBJUHY0IGFuZA0KICAgICAgICAgICAgICAgZ2xvYmFs bHkgdW5pcXVlIElQdjYgYWRkcmVzc2VzLiINCg0KICAgICAgICAgIE9CSkVDVCAgICAgICAgICAg ICByYWRpdXNEeW5BdXRoU2VydmVyQWRkcmVzcw0KICAgICAgICAgIFNZTlRBWCAgICAgICAgICAg ICBJbmV0QWRkcmVzcyAoU0laRSg0fDE2KSkNCiAgICAgICAgICBERVNDUklQVElPTg0KICAgICAg ICAgICAgICAiQW4gaW1wbGVtZW50YXRpb24gaXMgb25seSByZXF1aXJlZCB0byBzdXBwb3J0IElQ djQgYW5kDQogICAgICAgICAgICAgICBnbG9iYWxseSB1bmlxdWUgSVB2NiBhZGRyZXNzZXMuIg0K DQoNCiAgICAgICAgICBHUk9VUCAgICAgICAgICAgICAgcmFkaXVzRHluQXV0aENsaWVudEF1dGhP bmx5R3JvdXANCiAgICAgICAgICBERVNDUklQVElPTg0KICAgICAgICAgICAgICAgICJPbmx5IHJl cXVpcmVkIGZvciBEeW5hbWljIEF1dGhvcml6YXRpb24gQ2xpZW50cyB0aGF0DQogICAgICAgICAg ICAgICAgIGFyZSBzdXBwb3J0aW5nIFNlcnZpY2UtVHlwZSBhdHRyaWJ1dGVzIHdpdGggdmFsdWUN CiAgICAgICAgICAgICAgICAgJ0F1dGhvcml6ZS1Pbmx5Jy4iDQoNCg0KICAgICAgICAgIEdST1VQ ICAgICAgICAgICAgICByYWRpdXNEeW5BdXRoQ2xpZW50Tm9TZXNzR3JvdXANCiAgICAgICAgICBE RVNDUklQVElPTg0KICAgICAgICAgICAgICAgICJUaGlzIGdyb3VwIGlzIG5vdCByZXF1aXJlZCBp biBjYXNlIHRoZSBEeW5hbWljDQogICAgICAgICAgICAgICAgIEF1dGhvcml6YXRpb24gU2VydmVy IGNhbiBub3QgZWFzaWx5IGRldGVybWluZSB3aGV0aGVyDQogICAgICAgICAgICAgICAgIGEgc2Vz c2lvbiBleGlzdHMgb3Igbm90IChlLmcuLCBpbiBjYXNlIG9mIGEgUkFESVVTDQogICAgICAgICAg ICAgICAgIHByb3h5KS4iDQoNCiAgICAgICAgICA6Oj0geyByYWRpdXNEeW5BdXRoQ2xpZW50TUlC Q29tcGxpYW5jZXMgMSB9DQoNCiAgIC0tIHVuaXRzIG9mIGNvbmZvcm1hbmNlDQoNCiAgIHJhZGl1 c0R5bkF1dGhDbGllbnRNSUJHcm91cCBPQkpFQ1QtR1JPVVANCiAgICAgICAgICBPQkpFQ1RTIHsg cmFkaXVzRHluQXV0aENsaWVudERpc2NvbkludmFsaWRTZXJ2ZXJBZGRyZXNzZXMsDQogICAgICAg ICAgICAgICAgICAgIHJhZGl1c0R5bkF1dGhDbGllbnRDb0FJbnZhbGlkU2VydmVyQWRkcmVzc2Vz LA0KICAgICAgICAgICAgICAgICAgICByYWRpdXNEeW5BdXRoQ2xpZW50Q291bnRlckRpc2NvbnRp bnVpdHksDQogICAgICAgICAgICAgICAgICAgIHJhZGl1c0R5bkF1dGhTZXJ2ZXJBZGRyZXNzVHlw ZSwNCiAgICAgICAgICAgICAgICAgICAgcmFkaXVzRHluQXV0aFNlcnZlckFkZHJlc3MsDQogICAg ICAgICAgICAgICAgICAgIHJhZGl1c0R5bkF1dGhTZXJ2ZXJDbGllbnRQb3J0TnVtYmVyLA0KICAg ICAgICAgICAgICAgICAgICByYWRpdXNEeW5BdXRoU2VydmVySUQsDQoNCg0KDQpEZSBDbm9kZGVy LCBldCBhbC4gICAgIEV4cGlyZXMgU2VwdGVtYmVyIDIzLCAyMDA2ICAgICAgICAgICAgICBbUGFn ZSAyMF0NCgwNCkludGVybmV0LURyYWZ0ICAgICAgRHluYW1pYyBBdXRob3JpemF0aW9uIENsaWVu dCBNSUIgICAgICAgICAgTWFyY2ggMjAwNg0KDQoNCiAgICAgICAgICAgICAgICAgICAgcmFkaXVz RHluQXV0aENsaWVudFJvdW5kVHJpcFRpbWUsDQogICAgICAgICAgICAgICAgICAgIHJhZGl1c0R5 bkF1dGhDbGllbnREaXNjb25SZXF1ZXN0cywNCiAgICAgICAgICAgICAgICAgICAgcmFkaXVzRHlu QXV0aENsaWVudERpc2NvblJldHJhbnNtaXNzaW9ucywNCiAgICAgICAgICAgICAgICAgICAgcmFk aXVzRHluQXV0aENsaWVudERpc2NvbkFja3MsDQogICAgICAgICAgICAgICAgICAgIHJhZGl1c0R5 bkF1dGhDbGllbnREaXNjb25OYWtzLA0KICAgICAgICAgICAgICAgICAgICByYWRpdXNEeW5BdXRo Q2xpZW50TWFsZm9ybWVkRGlzY29uUmVzcG9uc2VzLA0KICAgICAgICAgICAgICAgICAgICByYWRp dXNEeW5BdXRoQ2xpZW50RGlzY29uQmFkQXV0aGVudGljYXRvcnMsDQogICAgICAgICAgICAgICAg ICAgIHJhZGl1c0R5bkF1dGhDbGllbnREaXNjb25QZW5kaW5nUmVxdWVzdHMsDQogICAgICAgICAg ICAgICAgICAgIHJhZGl1c0R5bkF1dGhDbGllbnREaXNjb25UaW1lb3V0cywNCiAgICAgICAgICAg ICAgICAgICAgcmFkaXVzRHluQXV0aENsaWVudERpc2NvblBhY2tldHNEcm9wcGVkLA0KICAgICAg ICAgICAgICAgICAgICByYWRpdXNEeW5BdXRoQ2xpZW50Q29BUmVxdWVzdHMsDQogICAgICAgICAg ICAgICAgICAgIHJhZGl1c0R5bkF1dGhDbGllbnRDb0FSZXRyYW5zbWlzc2lvbnMsDQogICAgICAg ICAgICAgICAgICAgIHJhZGl1c0R5bkF1dGhDbGllbnRDb0FBY2tzLA0KICAgICAgICAgICAgICAg ICAgICByYWRpdXNEeW5BdXRoQ2xpZW50Q29BTmFrcywNCiAgICAgICAgICAgICAgICAgICAgcmFk aXVzRHluQXV0aENsaWVudE1hbGZvcm1lZENvQVJlc3BvbnNlcywNCiAgICAgICAgICAgICAgICAg ICAgcmFkaXVzRHluQXV0aENsaWVudENvQUJhZEF1dGhlbnRpY2F0b3JzLA0KICAgICAgICAgICAg ICAgICAgICByYWRpdXNEeW5BdXRoQ2xpZW50Q29BUGVuZGluZ1JlcXVlc3RzLA0KICAgICAgICAg ICAgICAgICAgICByYWRpdXNEeW5BdXRoQ2xpZW50Q29BVGltZW91dHMsDQogICAgICAgICAgICAg ICAgICAgIHJhZGl1c0R5bkF1dGhDbGllbnRDb0FQYWNrZXRzRHJvcHBlZCwNCiAgICAgICAgICAg ICAgICAgICAgcmFkaXVzRHluQXV0aENsaWVudFVua25vd25UeXBlcw0KICAgICAgICAgICAgICAg ICAgfQ0KICAgICAgICAgIFNUQVRVUyAgY3VycmVudA0KICAgICAgICAgIERFU0NSSVBUSU9ODQog ICAgICAgICAgICAgICAgIlRoZSBjb2xsZWN0aW9uIG9mIG9iamVjdHMgcHJvdmlkaW5nIG1hbmFn ZW1lbnQgb2YNCiAgICAgICAgICAgICAgICAgYSBSQURJVVMgRHluYW1pYyBBdXRob3JpemF0aW9u IENsaWVudC4iDQogICAgICAgICAgOjo9IHsgcmFkaXVzRHluQXV0aENsaWVudE1JQkdyb3VwcyAx IH0NCg0KICAgcmFkaXVzRHluQXV0aENsaWVudEF1dGhPbmx5R3JvdXAgT0JKRUNULUdST1VQDQog ICAgICAgICAgT0JKRUNUUyB7IHJhZGl1c0R5bkF1dGhDbGllbnREaXNjb25BdXRoT25seVJlcXVl c3RzLA0KICAgICAgICAgICAgICAgICAgICByYWRpdXNEeW5BdXRoQ2xpZW50RGlzY29uTmFrQXV0 aE9ubHlSZXF1ZXN0LA0KICAgICAgICAgICAgICAgICAgICByYWRpdXNEeW5BdXRoQ2xpZW50Q29B QXV0aE9ubHlSZXF1ZXN0LA0KICAgICAgICAgICAgICAgICAgICByYWRpdXNEeW5BdXRoQ2xpZW50 Q29BTmFrQXV0aE9ubHlSZXF1ZXN0DQogICAgICAgICAgICAgICAgICB9DQogICAgICAgICAgU1RB VFVTICBjdXJyZW50DQogICAgICAgICAgREVTQ1JJUFRJT04NCiAgICAgICAgICAgICAgICAiVGhl IGNvbGxlY3Rpb24gb2Ygb2JqZWN0cyBzdXBwb3J0aW5nIHRoZSBSQURJVVMNCiAgICAgICAgICAg ICAgICAgbWVzc2FnZXMgaW5jbHVkaW5nIFNlcnZpY2UtVHlwZSBhdHRyaWJ1dGUgd2l0aA0KICAg ICAgICAgICAgICAgICB2YWx1ZSAnQXV0aG9yaXplIE9ubHknLiINCiAgICAgICAgICA6Oj0geyBy YWRpdXNEeW5BdXRoQ2xpZW50TUlCR3JvdXBzIDIgfQ0KDQogICByYWRpdXNEeW5BdXRoQ2xpZW50 Tm9TZXNzR3JvdXAgT0JKRUNULUdST1VQDQogICAgICAgICAgT0JKRUNUUyB7IHJhZGl1c0R5bkF1 dGhDbGllbnREaXNjb25OYWtTZXNzTm9Db250ZXh0LA0KICAgICAgICAgICAgICAgICAgICByYWRp dXNEeW5BdXRoQ2xpZW50Q29BTmFrU2Vzc05vQ29udGV4dA0KICAgICAgICAgICAgICAgICAgfQ0K ICAgICAgICAgIFNUQVRVUyAgY3VycmVudA0KICAgICAgICAgIERFU0NSSVBUSU9ODQogICAgICAg ICAgICAgICAgIlRoZSBjb2xsZWN0aW9uIG9mIG9iamVjdHMgc3VwcG9ydGluZyB0aGUgUkFESVVT DQogICAgICAgICAgICAgICAgIG1lc3NhZ2VzIHRoYXQgYXJlIHJlZmVycmluZyB0byBub24gZXhp c3Rpbmcgc2Vzc2lvbnMuIg0KDQoNCg0KRGUgQ25vZGRlciwgZXQgYWwuICAgICBFeHBpcmVzIFNl cHRlbWJlciAyMywgMjAwNiAgICAgICAgICAgICAgW1BhZ2UgMjFdDQoMDQpJbnRlcm5ldC1EcmFm dCAgICAgIER5bmFtaWMgQXV0aG9yaXphdGlvbiBDbGllbnQgTUlCICAgICAgICAgIE1hcmNoIDIw MDYNCg0KDQogICAgICAgICAgOjo9IHsgcmFkaXVzRHluQXV0aENsaWVudE1JQkdyb3VwcyAzIH0N Cg0KDQoNCiAgIEVORA0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQpEZSBDbm9k ZGVyLCBldCBhbC4gICAgIEV4cGlyZXMgU2VwdGVtYmVyIDIzLCAyMDA2ICAgICAgICAgICAgICBb UGFnZSAyMl0NCgwNCkludGVybmV0LURyYWZ0ICAgICAgRHluYW1pYyBBdXRob3JpemF0aW9uIENs aWVudCBNSUIgICAgICAgICAgTWFyY2ggMjAwNg0KDQoNCjUuICBTZWN1cml0eSBDb25zaWRlcmF0 aW9ucw0KDQogICBUaGVyZSBhcmUgbm8gbWFuYWdlbWVudCBvYmplY3RzIGRlZmluZWQgaW4gdGhp cyBNSUIgbW9kdWxlIHRoYXQgaGF2ZQ0KICAgYSBNQVgtQUNDRVNTIGNsYXVzZSBvZiByZWFkLXdy aXRlIGFuZC9vciByZWFkLWNyZWF0ZS4gIFNvLCBpZiB0aGlzDQogICBNSUIgbW9kdWxlIGlzIGlt cGxlbWVudGVkIGNvcnJlY3RseSwgdGhlbiB0aGVyZSBpcyBubyByaXNrIHRoYXQgYW4NCiAgIGlu dHJ1ZGVyIGNhbiBhbHRlciBvciBjcmVhdGUgYW55IG1hbmFnZW1lbnQgb2JqZWN0cyBvZiB0aGlz IE1JQg0KICAgbW9kdWxlIHZpYSBkaXJlY3QgU05NUCBTRVQgb3BlcmF0aW9ucw0KDQogICBTb21l IG9mIHRoZSByZWFkYWJsZSBvYmplY3RzIGluIHRoaXMgTUlCIG1vZHVsZSAoaS5lLiwgb2JqZWN0 cyB3aXRoIGENCiAgIE1BWC1BQ0NFU1Mgb3RoZXIgdGhhbiBub3QtYWNjZXNzaWJsZSkgbWF5IGJl IGNvbnNpZGVyZWQgc2Vuc2l0aXZlIG9yDQogICB2dWxuZXJhYmxlIGluIHNvbWUgbmV0d29yayBl bnZpcm9ubWVudHMuICBJdCBpcyB0aHVzIGltcG9ydGFudCB0bw0KICAgY29udHJvbCBldmVuIEdF VCBhbmQvb3IgTk9USUZZIGFjY2VzcyB0byB0aGVzZSBvYmplY3RzIGFuZCBwb3NzaWJseQ0KICAg dG8gZXZlbiBlbmNyeXB0IHRoZSB2YWx1ZXMgb2YgdGhlc2Ugb2JqZWN0cyB3aGVuIHNlbmRpbmcg dGhlbSBvdmVyDQogICB0aGUgbmV0d29yayB2aWEgU05NUC4gIFRoZXNlIGFyZSB0aGUgdGFibGVz IGFuZCBvYmplY3RzIGFuZCB0aGVpcg0KICAgc2Vuc2l0aXZpdHkvdnVsbmVyYWJpbGl0eToNCg0K ICAgcmFkaXVzRHluQXV0aFNlcnZlckFkZHJlc3MgYW5kIHJhZGl1c0R5bkF1dGhTZXJ2ZXJBZGRy ZXNzVHlwZQ0KDQogICBUaGVzZSBjYW4gYmUgdXNlZCB0byBkZXRlcm1pbmUgdGhlIGFkZHJlc3Mg b2YgdGhlIERBUyB3aXRoIHdoaWNoIHRoZQ0KICAgREFDIGlzIGNvbW11bmljYXRpbmcuICBUaGlz IGluZm9ybWF0aW9uIGNvdWxkIGJlIHVzZWZ1bCBpbiBtb3VudGluZw0KICAgYW4gYXR0YWNrIG9u IHRoZSBEQVMuDQoNCiAgIHJhZGl1c0R5bkF1dGhTZXJ2ZXJJRA0KDQogICBUaGlzIGNhbiBiZSB1 c2VkIHRvIGRldGVybWluZSB0aGUgSWRlbnRpZmllciBvZiB0aGUgREFTLiAgVGhpcw0KICAgaW5m b3JtYXRpb24gY291bGQgYmUgdXNlZnVsIGluIGltcGVyc29uYXRpbmcgdGhlIERBUy4NCg0KICAg cmFkaXVzRHluQXV0aFNlcnZlckNsaWVudFBvcnROdW1iZXINCg0KICAgVGhpcyBjYW4gYmUgdXNl ZCB0byBkZXRlcm1pbmUgdGhlIGRlc3RpbmF0aW9uIHBvcnQgbnVtYmVyIHRvIHdoaWNoDQogICB0 aGUgREFDIGlzIHNlbmRpbmcuICBUaGlzIGluZm9ybWF0aW9uIGNvdWxkIGJlIHVzZWZ1bCBpbiBt b3VudGluZyBhbg0KICAgYXR0YWNrIG9uIHRoZSBEQVMuDQoNCiAgIFNOTVAgdmVyc2lvbnMgcHJp b3IgdG8gU05NUHYzIGRpZCBub3QgaW5jbHVkZSBhZGVxdWF0ZSBzZWN1cml0eS4NCiAgIEV2ZW4g aWYgdGhlIG5ldHdvcmsgaXRzZWxmIGlzIHNlY3VyZSAoZm9yIGV4YW1wbGUgYnkgdXNpbmcgSVBz ZWMpLA0KICAgZXZlbiB0aGVuLCB0aGVyZSBpcyBubyBjb250cm9sIGFzIHRvIHdobyBvbiB0aGUg c2VjdXJlIG5ldHdvcmsgaXMNCiAgIGFsbG93ZWQgdG8gYWNjZXNzIGFuZCBHRVQvU0VUIChyZWFk L2NoYW5nZS9jcmVhdGUvZGVsZXRlKSB0aGUgb2JqZWN0cw0KICAgaW4gdGhpcyBNSUIgbW9kdWxl Lg0KDQogICBJdCBpcyBSRUNPTU1FTkRFRCB0aGF0IGltcGxlbWVudGVycyBjb25zaWRlciB0aGUg c2VjdXJpdHkgZmVhdHVyZXMgYXMNCiAgIHByb3ZpZGVkIGJ5IHRoZSBTTk1QdjMgZnJhbWV3b3Jr IChzZWUgW1JGQzM0MTBdLCBzZWN0aW9uIDgpLA0KICAgaW5jbHVkaW5nIGZ1bGwgc3VwcG9ydCBm b3IgdGhlIFNOTVB2MyBjcnlwdG9ncmFwaGljIG1lY2hhbmlzbXMgKGZvcg0KICAgYXV0aGVudGlj YXRpb24gYW5kIHByaXZhY3kpLg0KDQogICBGdXJ0aGVyLCBkZXBsb3ltZW50IG9mIFNOTVAgdmVy c2lvbnMgcHJpb3IgdG8gU05NUHYzIGlzIE5PVA0KICAgUkVDT01NRU5ERUQuICBJbnN0ZWFkLCBp dCBpcyBSRUNPTU1FTkRFRCB0byBkZXBsb3kgU05NUHYzIGFuZCB0bw0KICAgZW5hYmxlIGNyeXB0 b2dyYXBoaWMgc2VjdXJpdHkuICBJdCBpcyB0aGVuIGEgY3VzdG9tZXIvb3BlcmF0b3INCiAgIHJl c3BvbnNpYmlsaXR5IHRvIGVuc3VyZSB0aGF0IHRoZSBTTk1QIGVudGl0eSBnaXZpbmcgYWNjZXNz IHRvIGFuDQoNCg0KDQpEZSBDbm9kZGVyLCBldCBhbC4gICAgIEV4cGlyZXMgU2VwdGVtYmVyIDIz LCAyMDA2ICAgICAgICAgICAgICBbUGFnZSAyM10NCgwNCkludGVybmV0LURyYWZ0ICAgICAgRHlu YW1pYyBBdXRob3JpemF0aW9uIENsaWVudCBNSUIgICAgICAgICAgTWFyY2ggMjAwNg0KDQoNCiAg IGluc3RhbmNlIG9mIHRoaXMgTUlCIG1vZHVsZSBpcyBwcm9wZXJseSBjb25maWd1cmVkIHRvIGdp dmUgYWNjZXNzIHRvDQogICB0aGUgb2JqZWN0cyBvbmx5IHRvIHRob3NlIHByaW5jaXBhbHMgKHVz ZXJzKSB0aGF0IGhhdmUgbGVnaXRpbWF0ZQ0KICAgcmlnaHRzIHRvIGluZGVlZCBHRVQgb3IgU0VU IChjaGFuZ2UvY3JlYXRlL2RlbGV0ZSkgdGhlbS4NCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCkRlIENub2RkZXIsIGV0IGFsLiAgICAgRXhwaXJlcyBTZXB0ZW1iZXIgMjMs IDIwMDYgICAgICAgICAgICAgIFtQYWdlIDI0XQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICBEeW5h bWljIEF1dGhvcml6YXRpb24gQ2xpZW50IE1JQiAgICAgICAgICBNYXJjaCAyMDA2DQoNCg0KNi4g IElBTkEgY29uc2lkZXJhdGlvbnMNCg0KICAgSUFOQSBpcyByZXF1ZXN0ZWQgdG8gYXNzaWduIGFu IE9JRCB1bmRlciBtaWItMi4NCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN CkRlIENub2RkZXIsIGV0IGFsLiAgICAgRXhwaXJlcyBTZXB0ZW1iZXIgMjMsIDIwMDYgICAgICAg ICAgICAgIFtQYWdlIDI1XQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICBEeW5hbWljIEF1dGhvcml6 YXRpb24gQ2xpZW50IE1JQiAgICAgICAgICBNYXJjaCAyMDA2DQoNCg0KNy4gIEFja25vd2xlZGdl bWVudHMNCg0KICAgVGhlIGF1dGhvcnMgd291bGQgYWxzbyBsaWtlIHRvIGFja25vd2xlZGdlIHRo ZSBmb2xsb3dpbmcgcGVvcGxlIGZvcg0KICAgdGhlaXIgY29tbWVudHMgb24gdGhpcyBkb2N1bWVu dDogQmVybmFyZCBBYm9iYSwgQWxhbiBEZUtvaywgRGF2aWQNCiAgIE5lbHNvbiwgQW5qYW5leXVs dSBQYXRhLCBEYW4gUm9tYXNjYW51LCBKdWVyZ2VuIFNjaG9lbndhZWxkZXIsIEdyZWcNCiAgIFdl YmVyLCBCZXJ0IFdpam5lbiBhbmQgR2xlbiBab3JuLg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KRGUgQ25vZGRlciwgZXQgYWwuICAgICBFeHBpcmVzIFNlcHRlbWJlciAyMywgMjAw NiAgICAgICAgICAgICAgW1BhZ2UgMjZdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgIER5bmFtaWMg QXV0aG9yaXphdGlvbiBDbGllbnQgTUlCICAgICAgICAgIE1hcmNoIDIwMDYNCg0KDQo4LiAgUmVm ZXJlbmNlcw0KDQo4LjEuICBOb3JtYXRpdmUgUmVmZXJlbmNlcw0KDQogICBbUkZDMjExOV0gIEJy YWRuZXIsIFMuLCAiS2V5IHdvcmRzIGZvciB1c2UgaW4gUkZDcyB0byBJbmRpY2F0ZQ0KICAgICAg ICAgICAgICBSZXF1aXJlbWVudCBMZXZlbHMiLCBSRkMgMjExOSwgTWFyY2ggMTk5Ny4NCg0KICAg W1JGQzI1NzhdICBNY0Nsb2docmllLCBLLiwgUGVya2lucywgRC4sIFNjaG9lbndhZWxkZXIsIEou LCBDYXNlLCBKLiwNCiAgICAgICAgICAgICAgUm9zZSwgTS4sIGFuZCBTLiBXYWxkYnVzc2VyLCAi U3RydWN0dXJlIG9mIE1hbmFnZW1lbnQNCiAgICAgICAgICAgICAgSW5mb3JtYXRpb24gVmVyc2lv biAyIChTTUl2MikiLCBTVEQgNTgsIFJGQyAyNTc4LA0KICAgICAgICAgICAgICBBcHJpbCAxOTk5 Lg0KDQogICBbUkZDMjU3OV0gIE1jQ2xvZ2hyaWUsIEsuLCBQZXJraW5zLCBELiwgU2Nob2Vud2Fl bGRlciwgSi4sIENhc2UsIEouLA0KICAgICAgICAgICAgICBSb3NlLCBNLiwgYW5kIFMuIFdhbGRi dXNzZXIsICJUZXh0dWFsIENvbnZlbnRpb25zIGZvcg0KICAgICAgICAgICAgICBTTUl2MiIsIFNU RCA1OCwgUkZDIDI1NzksIEFwcmlsIDE5OTkuDQoNCiAgIFtSRkMyNTgwXSAgTWNDbG9naHJpZSwg Sy4sIFBlcmtpbnMsIEQuLCBTY2hvZW53YWVsZGVyLCBKLiwgQ2FzZSwgSi4sDQogICAgICAgICAg ICAgIFJvc2UsIE0uLCBhbmQgUy4gV2FsZGJ1c3NlciwgIkNvbmZvcm1hbmNlIFN0YXRlbWVudHMg Zm9yDQogICAgICAgICAgICAgIFNNSXYyIiwgU1REIDU4LCBSRkMgMjU4MCwgQXByaWwgMTk5OS4N Cg0KICAgW1JGQzM0MTFdICBIYXJyaW5ndG9uLCBELiwgUHJlc3VobiwgUi4sIGFuZCBCLiBXaWpu ZW4sICJBbg0KICAgICAgICAgICAgICBBcmNoaXRlY3R1cmUgZm9yIERlc2NyaWJpbmcgU2ltcGxl IE5ldHdvcmsgTWFuYWdlbWVudA0KICAgICAgICAgICAgICBQcm90b2NvbCAoU05NUCkgTWFuYWdl bWVudCBGcmFtZXdvcmtzIiwgU1REIDYyLCBSRkMgMzQxMSwNCiAgICAgICAgICAgICAgRGVjZW1i ZXIgMjAwMi4NCg0KICAgW1JGQzM1NzZdICBDaGliYSwgTS4sIERvbW1ldHksIEcuLCBFa2x1bmQs IE0uLCBNaXR0b24sIEQuLCBhbmQgQi4NCiAgICAgICAgICAgICAgQWJvYmEsICJEeW5hbWljIEF1 dGhvcml6YXRpb24gRXh0ZW5zaW9ucyB0byBSZW1vdGUNCiAgICAgICAgICAgICAgQXV0aGVudGlj YXRpb24gRGlhbCBJbiBVc2VyIFNlcnZpY2UgKFJBRElVUykiLCBSRkMgMzU3NiwNCiAgICAgICAg ICAgICAgSnVseSAyMDAzLg0KDQogICBbUkZDNDAwMV0gIERhbmllbGUsIE0uIGFuZCBldCBhbC4s ICJUZXh0dWFsIENvbnZlbnRpb25zIGZvciBJbnRlcm5ldA0KICAgICAgICAgICAgICBOZXR3b3Jr IEFkZHJlc3NlcyIsIFJGQyA0MDAxLCBGZWJydWFyeSAyMDA1Lg0KDQo4LjIuICBJbmZvcm1hdGl2 ZSBSZWZlcmVuY2VzDQoNCiAgIFtEWU5TRVJWXSAgRGUgQ25vZGRlciwgUy4sIEpvbm5hbGEsIE4u LCBhbmQgTS4gQ2hpYmEsICJSQURJVVMgRHluYW1pYw0KICAgICAgICAgICAgICBBdXRob3JpemF0 aW9uIFNlcnZlciBNSUIiLA0KICAgICAgICAgICAgICBkcmFmdC1pZXRmLXJhZGV4dC1keW5hdXRo LXNlcnZlci1taWItMDUudHh0LCB3b3JrIGluDQogICAgICAgICAgICAgIHByb2dyZXNzLCBEZWNl bWJlciAyMDA1Lg0KDQogICBbUkZDMjYxOWJpc10NCiAgICAgICAgICAgICAgTmVsc29uLCBELiwg IlJBRElVUyBBdXRoIFNlcnZlciBNSUIgKElQdjYpIiwNCiAgICAgICAgICAgICAgZHJhZnQtaWV0 Zi1yYWRleHQtcmZjMjYxOWJpcy0wMS50eHQgd29yayBpbiBwcm9ncmVzcywNCiAgICAgICAgICAg ICAgT2N0b2JlciAyMDA1Lg0KDQogICBbUkZDMjYyMWJpc10NCiAgICAgICAgICAgICAgTmVsc29u LCBELiwgIlJBRElVUyBBY2N0IFNlcnZlciBNSUIgKElQdjYpIiwNCiAgICAgICAgICAgICAgZHJh ZnQtaWV0Zi1yYWRleHQtcmZjMjYyMWJpcy0wMS50eHQgd29yayBpbiBwcm9ncmVzcywNCg0KDQoN CkRlIENub2RkZXIsIGV0IGFsLiAgICAgRXhwaXJlcyBTZXB0ZW1iZXIgMjMsIDIwMDYgICAgICAg ICAgICAgIFtQYWdlIDI3XQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICBEeW5hbWljIEF1dGhvcml6 YXRpb24gQ2xpZW50IE1JQiAgICAgICAgICBNYXJjaCAyMDA2DQoNCg0KICAgICAgICAgICAgICBP Y3RvYmVyIDIwMDUuDQoNCiAgIFtSRkMyODY1XSAgUmlnbmV5LCBDLiwgV2lsbGVucywgUy4sIFJ1 YmVucywgQS4sIGFuZCBXLiBTaW1wc29uLA0KICAgICAgICAgICAgICAiUmVtb3RlIEF1dGhlbnRp Y2F0aW9uIERpYWwgSW4gVXNlciBTZXJ2aWNlIChSQURJVVMpIiwNCiAgICAgICAgICAgICAgUkZD IDI4NjUsIEp1bmUgMjAwMC4NCg0KICAgW1JGQzM0MTBdICBDYXNlLCBKLiwgTXVuZHksIFIuLCBQ YXJ0YWluLCBELiwgYW5kIEIuIFN0ZXdhcnQsDQogICAgICAgICAgICAgICJJbnRyb2R1Y3Rpb24g YW5kIEFwcGxpY2FiaWxpdHkgU3RhdGVtZW50cyBmb3IgSW50ZXJuZXQtDQogICAgICAgICAgICAg IFN0YW5kYXJkIE1hbmFnZW1lbnQgRnJhbWV3b3JrIiwgUkZDIDM0MTAsIERlY2VtYmVyIDIwMDIu DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQpEZSBDbm9kZGVyLCBldCBhbC4gICAgIEV4cGly ZXMgU2VwdGVtYmVyIDIzLCAyMDA2ICAgICAgICAgICAgICBbUGFnZSAyOF0NCgwNCkludGVybmV0 LURyYWZ0ICAgICAgRHluYW1pYyBBdXRob3JpemF0aW9uIENsaWVudCBNSUIgICAgICAgICAgTWFy Y2ggMjAwNg0KDQoNCkF1dGhvcnMnIEFkZHJlc3Nlcw0KDQogICBTdGVmYWFuIERlIENub2RkZXIN CiAgIEFsY2F0ZWwNCiAgIEZyYW5jaXMgV2VsbGVzcGxlaW4gMQ0KICAgQi0yMDE4IEFudHdlcnAN CiAgIEJlbGdpdW0NCg0KICAgUGhvbmU6ICszMiAzIDI0MCA4NSAxNQ0KICAgRW1haWw6IHN0ZWZh YW4uZGVfY25vZGRlckBhbGNhdGVsLmJlDQoNCg0KICAgTmFnaSBSZWRkeSBKb25uYWxhDQogICBD aXNjbyBTeXN0ZW1zLCBJbmMuDQogICBEaXZ5YXNyZWUgQ2hhbWJlcnMsICBCIFdpbmcsIE8nU2hh dWduZXNzeSBSb2FkDQogICBCYW5nYWxvcmUtNTYwMDI3LCBJbmRpYQ0KDQogICBQaG9uZTogKzkx IDk0NDg3IDYwODI4DQogICBFbWFpbDogbmpvbm5hbGFAY2lzY28uY29tDQoNCg0KICAgTXVydGF6 YSBDaGliYQ0KICAgQ2lzY28gU3lzdGVtcywgSW5jLg0KICAgMTcwIFdlc3QgVGFzbWFuIERyLg0K ICAgU2FuIEpvc2UgQ0EsIDk1MTM0DQoNCiAgIFBob25lOiArMSA0MDggNTI1IDcxOTgNCiAgIEVt YWlsOiBtY2hpYmFAY2lzY28uY29tDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KRGUgQ25vZGRlciwgZXQgYWwuICAgICBFeHBpcmVzIFNlcHRlbWJlciAyMywg MjAwNiAgICAgICAgICAgICAgW1BhZ2UgMjldDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgIER5bmFt aWMgQXV0aG9yaXphdGlvbiBDbGllbnQgTUlCICAgICAgICAgIE1hcmNoIDIwMDYNCg0KDQpJbnRl bGxlY3R1YWwgUHJvcGVydHkgU3RhdGVtZW50DQoNCiAgIFRoZSBJRVRGIHRha2VzIG5vIHBvc2l0 aW9uIHJlZ2FyZGluZyB0aGUgdmFsaWRpdHkgb3Igc2NvcGUgb2YgYW55DQogICBJbnRlbGxlY3R1 YWwgUHJvcGVydHkgUmlnaHRzIG9yIG90aGVyIHJpZ2h0cyB0aGF0IG1pZ2h0IGJlIGNsYWltZWQg dG8NCiAgIHBlcnRhaW4gdG8gdGhlIGltcGxlbWVudGF0aW9uIG9yIHVzZSBvZiB0aGUgdGVjaG5v bG9neSBkZXNjcmliZWQgaW4NCiAgIHRoaXMgZG9jdW1lbnQgb3IgdGhlIGV4dGVudCB0byB3aGlj aCBhbnkgbGljZW5zZSB1bmRlciBzdWNoIHJpZ2h0cw0KICAgbWlnaHQgb3IgbWlnaHQgbm90IGJl IGF2YWlsYWJsZTsgbm9yIGRvZXMgaXQgcmVwcmVzZW50IHRoYXQgaXQgaGFzDQogICBtYWRlIGFu eSBpbmRlcGVuZGVudCBlZmZvcnQgdG8gaWRlbnRpZnkgYW55IHN1Y2ggcmlnaHRzLiAgSW5mb3Jt YXRpb24NCiAgIG9uIHRoZSBwcm9jZWR1cmVzIHdpdGggcmVzcGVjdCB0byByaWdodHMgaW4gUkZD IGRvY3VtZW50cyBjYW4gYmUNCiAgIGZvdW5kIGluIEJDUCA3OCBhbmQgQkNQIDc5Lg0KDQogICBD b3BpZXMgb2YgSVBSIGRpc2Nsb3N1cmVzIG1hZGUgdG8gdGhlIElFVEYgU2VjcmV0YXJpYXQgYW5k IGFueQ0KICAgYXNzdXJhbmNlcyBvZiBsaWNlbnNlcyB0byBiZSBtYWRlIGF2YWlsYWJsZSwgb3Ig dGhlIHJlc3VsdCBvZiBhbg0KICAgYXR0ZW1wdCBtYWRlIHRvIG9idGFpbiBhIGdlbmVyYWwgbGlj ZW5zZSBvciBwZXJtaXNzaW9uIGZvciB0aGUgdXNlIG9mDQogICBzdWNoIHByb3ByaWV0YXJ5IHJp Z2h0cyBieSBpbXBsZW1lbnRlcnMgb3IgdXNlcnMgb2YgdGhpcw0KICAgc3BlY2lmaWNhdGlvbiBj YW4gYmUgb2J0YWluZWQgZnJvbSB0aGUgSUVURiBvbi1saW5lIElQUiByZXBvc2l0b3J5IGF0DQog ICBodHRwOi8vd3d3LmlldGYub3JnL2lwci4NCg0KICAgVGhlIElFVEYgaW52aXRlcyBhbnkgaW50 ZXJlc3RlZCBwYXJ0eSB0byBicmluZyB0byBpdHMgYXR0ZW50aW9uIGFueQ0KICAgY29weXJpZ2h0 cywgcGF0ZW50cyBvciBwYXRlbnQgYXBwbGljYXRpb25zLCBvciBvdGhlciBwcm9wcmlldGFyeQ0K ICAgcmlnaHRzIHRoYXQgbWF5IGNvdmVyIHRlY2hub2xvZ3kgdGhhdCBtYXkgYmUgcmVxdWlyZWQg dG8gaW1wbGVtZW50DQogICB0aGlzIHN0YW5kYXJkLiAgUGxlYXNlIGFkZHJlc3MgdGhlIGluZm9y bWF0aW9uIHRvIHRoZSBJRVRGIGF0DQogICBpZXRmLWlwckBpZXRmLm9yZy4NCg0KDQpEaXNjbGFp bWVyIG9mIFZhbGlkaXR5DQoNCiAgIFRoaXMgZG9jdW1lbnQgYW5kIHRoZSBpbmZvcm1hdGlvbiBj b250YWluZWQgaGVyZWluIGFyZSBwcm92aWRlZCBvbiBhbg0KICAgIkFTIElTIiBiYXNpcyBhbmQg VEhFIENPTlRSSUJVVE9SLCBUSEUgT1JHQU5JWkFUSU9OIEhFL1NIRSBSRVBSRVNFTlRTDQogICBP UiBJUyBTUE9OU09SRUQgQlkgKElGIEFOWSksIFRIRSBJTlRFUk5FVCBTT0NJRVRZIEFORCBUSEUg SU5URVJORVQNCiAgIEVOR0lORUVSSU5HIFRBU0sgRk9SQ0UgRElTQ0xBSU0gQUxMIFdBUlJBTlRJ RVMsIEVYUFJFU1MgT1IgSU1QTElFRCwNCiAgIElOQ0xVRElORyBCVVQgTk9UIExJTUlURUQgVE8g QU5ZIFdBUlJBTlRZIFRIQVQgVEhFIFVTRSBPRiBUSEUNCiAgIElORk9STUFUSU9OIEhFUkVJTiBX SUxMIE5PVCBJTkZSSU5HRSBBTlkgUklHSFRTIE9SIEFOWSBJTVBMSUVEDQogICBXQVJSQU5USUVT IE9GIE1FUkNIQU5UQUJJTElUWSBPUiBGSVRORVNTIEZPUiBBIFBBUlRJQ1VMQVIgUFVSUE9TRS4N Cg0KDQpDb3B5cmlnaHQgU3RhdGVtZW50DQoNCiAgIENvcHlyaWdodCAoQykgVGhlIEludGVybmV0 IFNvY2lldHkgKDIwMDYpLiAgVGhpcyBkb2N1bWVudCBpcyBzdWJqZWN0DQogICB0byB0aGUgcmln aHRzLCBsaWNlbnNlcyBhbmQgcmVzdHJpY3Rpb25zIGNvbnRhaW5lZCBpbiBCQ1AgNzgsIGFuZA0K ICAgZXhjZXB0IGFzIHNldCBmb3J0aCB0aGVyZWluLCB0aGUgYXV0aG9ycyByZXRhaW4gYWxsIHRo ZWlyIHJpZ2h0cy4NCg0KDQpBY2tub3dsZWRnbWVudA0KDQogICBGdW5kaW5nIGZvciB0aGUgUkZD IEVkaXRvciBmdW5jdGlvbiBpcyBjdXJyZW50bHkgcHJvdmlkZWQgYnkgdGhlDQogICBJbnRlcm5l dCBTb2NpZXR5Lg0KDQoNCg0KDQpEZSBDbm9kZGVyLCBldCBhbC4gICAgIEV4cGlyZXMgU2VwdGVt YmVyIDIzLCAyMDA2ICAgICAgICAgICAgICBbUGFnZSAzMF0NCgwNCg0K ------_=_NextPart_001_01C64E46.0AB5C8D0 Content-Type: text/plain; name="mib-server-15.txt" Content-Transfer-Encoding: base64 Content-Description: mib-server-15.txt Content-Disposition: attachment; filename="mib-server-15.txt" DQoNCg0KDQpOZXR3b3JrIFdvcmtpbmcgR3JvdXAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIFMuIERlIENub2RkZXINCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgQWxjYXRlbA0KRXhwaXJlczogU2VwdGVt YmVyIDIzLCAyMDA2ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBOLiBKb25uYWxh DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgTS4gQ2hpYmENCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgQ2lzY28gU3lzdGVtcywgSW5jLg0KICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIE1hcmNoIDIyLCAyMDA2DQoNCg0K ICAgICAgICAgICAgICAgICAgICBEeW5hbWljIEF1dGhvcml6YXRpb24gU2VydmVyIE1JQg0KICAg ICAgICAgICAgICBkcmFmdC1pZXRmLXJhZGV4dC1keW5hdXRoLXNlcnZlci1taWItMDUudHh0DQoN ClN0YXR1cyBvZiB0aGlzIE1lbW8NCg0KICAgQnkgc3VibWl0dGluZyB0aGlzIEludGVybmV0LURy YWZ0LCBlYWNoIGF1dGhvciByZXByZXNlbnRzIHRoYXQgYW55DQogICBhcHBsaWNhYmxlIHBhdGVu dCBvciBvdGhlciBJUFIgY2xhaW1zIG9mIHdoaWNoIGhlIG9yIHNoZSBpcyBhd2FyZQ0KICAgaGF2 ZSBiZWVuIG9yIHdpbGwgYmUgZGlzY2xvc2VkLCBhbmQgYW55IG9mIHdoaWNoIGhlIG9yIHNoZSBi ZWNvbWVzDQogICBhd2FyZSB3aWxsIGJlIGRpc2Nsb3NlZCwgaW4gYWNjb3JkYW5jZSB3aXRoIFNl Y3Rpb24gNiBvZiBCQ1AgNzkuDQoNCiAgIEludGVybmV0LURyYWZ0cyBhcmUgd29ya2luZyBkb2N1 bWVudHMgb2YgdGhlIEludGVybmV0IEVuZ2luZWVyaW5nDQogICBUYXNrIEZvcmNlIChJRVRGKSwg aXRzIGFyZWFzLCBhbmQgaXRzIHdvcmtpbmcgZ3JvdXBzLiAgTm90ZSB0aGF0DQogICBvdGhlciBn cm91cHMgbWF5IGFsc28gZGlzdHJpYnV0ZSB3b3JraW5nIGRvY3VtZW50cyBhcyBJbnRlcm5ldC0N CiAgIERyYWZ0cy4NCg0KICAgSW50ZXJuZXQtRHJhZnRzIGFyZSBkcmFmdCBkb2N1bWVudHMgdmFs aWQgZm9yIGEgbWF4aW11bSBvZiBzaXggbW9udGhzDQogICBhbmQgbWF5IGJlIHVwZGF0ZWQsIHJl cGxhY2VkLCBvciBvYnNvbGV0ZWQgYnkgb3RoZXIgZG9jdW1lbnRzIGF0IGFueQ0KICAgdGltZS4g IEl0IGlzIGluYXBwcm9wcmlhdGUgdG8gdXNlIEludGVybmV0LURyYWZ0cyBhcyByZWZlcmVuY2UN CiAgIG1hdGVyaWFsIG9yIHRvIGNpdGUgdGhlbSBvdGhlciB0aGFuIGFzICJ3b3JrIGluIHByb2dy ZXNzLiINCg0KICAgVGhlIGxpc3Qgb2YgY3VycmVudCBJbnRlcm5ldC1EcmFmdHMgY2FuIGJlIGFj Y2Vzc2VkIGF0DQogICBodHRwOi8vd3d3LmlldGYub3JnL2lldGYvMWlkLWFic3RyYWN0cy50eHQu DQoNCiAgIFRoZSBsaXN0IG9mIEludGVybmV0LURyYWZ0IFNoYWRvdyBEaXJlY3RvcmllcyBjYW4g YmUgYWNjZXNzZWQgYXQNCiAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvc2hhZG93Lmh0bWwuDQoNCiAg IFRoaXMgSW50ZXJuZXQtRHJhZnQgd2lsbCBleHBpcmUgb24gU2VwdGVtYmVyIDIzLCAyMDA2Lg0K DQpDb3B5cmlnaHQgTm90aWNlDQoNCiAgIENvcHlyaWdodCAoQykgVGhlIEludGVybmV0IFNvY2ll dHkgKDIwMDYpLg0KDQpBYnN0cmFjdA0KDQogICBUaGlzIG1lbW8gZGVmaW5lcyBhIHBvcnRpb24g b2YgdGhlIE1hbmFnZW1lbnQgSW5mb3JtYXRpb24gQmFzZSAoTUlCKQ0KICAgZm9yIHVzZSB3aXRo IG5ldHdvcmsgbWFuYWdlbWVudCBwcm90b2NvbHMgaW4gdGhlIEludGVybmV0IGNvbW11bml0eS4N CiAgIEluIHBhcnRpY3VsYXIsIGl0IGRlc2NyaWJlcyB0aGUgUmVtb3RlIEF1dGhlbnRpY2F0aW9u IERpYWwgSW4gVXNlcg0KICAgU2VydmljZSAoUkFESVVTKSBbUkZDMjg2NV0gRHluYW1pYyBBdXRo b3JpemF0aW9uIFNlcnZlciAoREFTKQ0KICAgZnVuY3Rpb25zIHRoYXQgc3VwcG9ydCB0aGUgZHlu YW1pYyBhdXRob3JpemF0aW9uIGV4dGVuc2lvbnMgYXMNCiAgIGRlZmluZWQgaW4gUkZDIDM1NzYu DQoNCg0KDQpEZSBDbm9kZGVyLCBldCBhbC4gICAgIEV4cGlyZXMgU2VwdGVtYmVyIDIzLCAyMDA2 ICAgICAgICAgICAgICAgW1BhZ2UgMV0NCgwNCkludGVybmV0LURyYWZ0ICAgICAgRHluYW1pYyBB dXRob3JpemF0aW9uIFNlcnZlciBNSUIgICAgICAgICAgTWFyY2ggMjAwNg0KDQoNClRhYmxlIG9m IENvbnRlbnRzDQoNCiAgIDEuICBJbnRyb2R1Y3Rpb24gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgMw0KICAgICAxLjEuICBSZXF1aXJlbWVudHMgbm90 YXRpb24gIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAzDQogICAgIDEuMi4g IFRlcm1pbm9sb2d5ICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gIDMNCiAgIDIuICBUaGUgSW50ZXJuZXQtU3RhbmRhcmQgTWFuYWdlbWVudCBGcmFtZXdvcmsg LiAuIC4gLiAuIC4gLiAuIC4gLiAgNA0KICAgMy4gIE92ZXJ2aWV3IC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICA1DQogICA0LiAgUkFESVVTIER5 bmFtaWMgQXV0aG9yaXphdGlvbiBTZXJ2ZXIgTUlCIERlZmluaXRpb25zICAuIC4gLiAuIC4gIDcN CiAgIDUuICBTZWN1cml0eSBDb25zaWRlcmF0aW9ucyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAyMg0KICAgNi4gIElBTkEgY29uc2lkZXJhdGlvbnMgIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDIzDQogICA3LiAgQWNrbm93bGVkZ2VtZW50 cyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMjQNCiAgIDgu ICBSZWZlcmVuY2VzIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAyNQ0KICAgICA4LjEuICBOb3JtYXRpdmUgUmVmZXJlbmNlcyAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDI1DQogICAgIDguMi4gIEluZm9ybWF0aXZlIFJlZmVy ZW5jZXMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMjUNCiAgIEF1dGhvcnMn IEFkZHJlc3NlcyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAyNw0KICAgSW50ZWxsZWN0dWFsIFByb3BlcnR5IGFuZCBDb3B5cmlnaHQgU3RhdGVtZW50cyAu IC4gLiAuIC4gLiAuIC4gLiAuIDI4DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KRGUgQ25vZGRlciwgZXQgYWwuICAg ICBFeHBpcmVzIFNlcHRlbWJlciAyMywgMjAwNiAgICAgICAgICAgICAgIFtQYWdlIDJdDQoMDQpJ bnRlcm5ldC1EcmFmdCAgICAgIER5bmFtaWMgQXV0aG9yaXphdGlvbiBTZXJ2ZXIgTUlCICAgICAg ICAgIE1hcmNoIDIwMDYNCg0KDQoxLiAgSW50cm9kdWN0aW9uDQoNCiAgIFRoaXMgbWVtbyBkZWZp bmVzIGEgcG9ydGlvbiBvZiB0aGUgTWFuYWdlbWVudCBJbmZvcm1hdGlvbiBCYXNlIChNSUIpDQog ICBmb3IgdXNlIHdpdGggbmV0d29yayBtYW5hZ2VtZW50IHByb3RvY29scyBpbiB0aGUgSW50ZXJu ZXQgY29tbXVuaXR5Lg0KICAgSXQgaXMgYmVjb21pbmcgaW5jcmVhc2luZ2x5IGltcG9ydGFudCB0 byBzdXBwb3J0IER5bmFtaWMNCiAgIEF1dGhvcml6YXRpb24gZXh0ZW5zaW9ucyBvbiB0aGUgbmV0 d29yayBhY2Nlc3Mgc2VydmVyIChOQVMpIGRldmljZXMNCiAgIHRvIGhhbmRsZSB0aGUgRGlzY29u bmVjdCBhbmQgQ2hhbmdlLW9mLUF1dGhvcml6YXRpb24gKENvQSkgbWVzc2FnZXMNCiAgIGFzIGRl c2NyaWJlZCBpbiBbUkZDMzU3Nl0uICBBcyBhIHJlc3VsdCwgdGhlIGVmZmVjdGl2ZSBtYW5hZ2Vt ZW50IG9mDQogICBSQURJVVMgRHluYW1pYyBBdXRob3JpemF0aW9uIGVudGl0aWVzIGlzIG9mIGNv bnNpZGVyYWJsZSBpbXBvcnRhbmNlLg0KICAgVGhpcyBSQURJVVMgRHluYW1pYyBBdXRob3JpemF0 aW9uIFNlcnZlciAoREFTKSBNSUIgY29tcGxlbWVudHMgdGhlDQogICBtYW5hZ2VkIG9iamVjdHMg dXNlZCBmb3IgbWFuYWdpbmcgUkFESVVTIGF1dGhlbnRpY2F0aW9uIGFuZA0KICAgYWNjb3VudGlu ZyBjbGllbnRzIGFzIGRlc2NyaWJlZCBpbiBbUkZDMjYxOGJpc10gYW5kIFtSRkMyNjIwYmlzXSwN CiAgIHJlc3BlY3RpdmVseS4NCg0KDQogICAtLSBSRkMgRWQuOiByZWZlcmVuY2VzIFtEWU5TRVJW XSwgW1JGQzI2MThiaXNdLCBbUkZDMjYxOWJpc10sDQogICAtLSAgICAgICAgICBbUkZDMjYyMGJp c10sIGFuZCBbUkZDMjYyMWJpc10gc2hvdWxkIGJlIHJlcGxhY2VkIGJ5DQogICAtLSAgICAgICAg ICByZWZlcmVuY2VzIHRvIHRoZSBjb3JyZXNwb25kaW5nIFJGQy4NCg0KMS4xLiAgUmVxdWlyZW1l bnRzIG5vdGF0aW9uDQoNCiAgIFRoZSBrZXkgd29yZHMgIk1VU1QiLCAiTVVTVCBOT1QiLCAiUkVR VUlSRUQiLCAiU0hBTEwiLCAiU0hBTEwgTk9UIiwNCiAgICJTSE9VTEQiLCAiU0hPVUxEIE5PVCIs ICJSRUNPTU1FTkRFRCIsICJNQVkiLCBhbmQgIk9QVElPTkFMIiBpbiB0aGlzDQogICBkb2N1bWVu dCBhcmUgdG8gYmUgaW50ZXJwcmV0ZWQgYXMgZGVzY3JpYmVkIGluIFtSRkMyMTE5XS4NCg0KMS4y LiAgVGVybWlub2xvZ3kNCg0KICAgRHluYW1pYyBBdXRob3JpemF0aW9uIFNlcnZlciAoREFTKQ0K DQogICBUaGUgY29tcG9uZW50IHRoYXQgcmVzaWRlcyBvbiB0aGUgTkFTIHdoaWNoIHByb2Nlc3Nl cyB0aGUgRGlzY29ubmVjdA0KICAgYW5kIENoYW5nZS1vZi1BdXRob3JpemF0aW9uIChDb0EpIFJl cXVlc3QgcGFja2V0cyBbUkZDMzU3Nl0gc2VudCBieQ0KICAgdGhlIER5bmFtaWMgQXV0aG9yaXph dGlvbiBDbGllbnQuDQoNCiAgIER5bmFtaWMgQXV0aG9yaXphdGlvbiBDbGllbnQgKERBQykNCg0K ICAgVGhlIGNvbXBvbmVudCB3aGljaCBzZW5kcyBEaXNjb25uZWN0IGFuZCBDb0EtUmVxdWVzdCBw YWNrZXRzIHRvIHRoZQ0KICAgRHluYW1pYyBBdXRob3JpemF0aW9uIFNlcnZlci4gIFdoaWxlIG9m dGVuIHJlc2lkaW5nIG9uIHRoZSBSQURJVVMNCiAgIHNlcnZlciwgaXQgaXMgYWxzbyBwb3NzaWJs ZSBmb3IgdGhpcyBjb21wb25lbnQgdG8gYmUgbG9jYXRlZCBvbiBhDQogICBzZXBhcmF0ZSBob3N0 LCBzdWNoIGFzIGEgUmF0aW5nIEVuZ2luZS4NCg0KICAgRHluYW1pYyBBdXRob3JpemF0aW9uIFNl cnZlciBQb3J0DQoNCiAgIFRoZSBVRFAgcG9ydCBvbiB3aGljaCB0aGUgRHluYW1pYyBBdXRob3Jp emF0aW9uIFNlcnZlciBsaXN0ZW5zIGZvcg0KICAgdGhlIERpc2Nvbm5lY3QgYW5kIENvQSByZXF1 ZXN0cyBzZW50IGJ5IHRoZSBEeW5hbWljIEF1dGhvcml6YXRpb24NCiAgIENsaWVudC4NCg0KDQoN Cg0KDQoNCkRlIENub2RkZXIsIGV0IGFsLiAgICAgRXhwaXJlcyBTZXB0ZW1iZXIgMjMsIDIwMDYg ICAgICAgICAgICAgICBbUGFnZSAzXQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICBEeW5hbWljIEF1 dGhvcml6YXRpb24gU2VydmVyIE1JQiAgICAgICAgICBNYXJjaCAyMDA2DQoNCg0KMi4gIFRoZSBJ bnRlcm5ldC1TdGFuZGFyZCBNYW5hZ2VtZW50IEZyYW1ld29yaw0KDQogICBGb3IgYSBkZXRhaWxl ZCBvdmVydmlldyBvZiB0aGUgZG9jdW1lbnRzIHRoYXQgZGVzY3JpYmUgdGhlIGN1cnJlbnQNCiAg IEludGVybmV0LVN0YW5kYXJkIE1hbmFnZW1lbnQgRnJhbWV3b3JrLCBwbGVhc2UgcmVmZXIgdG8g c2VjdGlvbiA3IG9mDQogICBbUkZDMzQxMF0uDQoNCiAgIE1hbmFnZWQgb2JqZWN0cyBhcmUgYWNj ZXNzZWQgdmlhIGEgdmlydHVhbCBpbmZvcm1hdGlvbiBzdG9yZSwgdGVybWVkDQogICB0aGUgTWFu YWdlbWVudCBJbmZvcm1hdGlvbiBCYXNlIG9yIE1JQi4gIE1JQiBvYmplY3RzIGFyZSBnZW5lcmFs bHkNCiAgIGFjY2Vzc2VkIHRocm91Z2ggdGhlIFNpbXBsZSBOZXR3b3JrIE1hbmFnZW1lbnQgUHJv dG9jb2wgKFNOTVApLg0KICAgT2JqZWN0cyBpbiB0aGUgTUlCIGFyZSBkZWZpbmVkIHVzaW5nIHRo ZSBtZWNoYW5pc21zIGRlZmluZWQgaW4gdGhlDQogICBTdHJ1Y3R1cmUgb2YgTWFuYWdlbWVudCBJ bmZvcm1hdGlvbiAoU01JKS4gIFRoaXMgbWVtbyBzcGVjaWZpZXMgYSBNSUINCiAgIG1vZHVsZSB0 aGF0IGlzIGNvbXBsaWFudCB0byB0aGUgU01JdjIsIHdoaWNoIGlzIGRlc2NyaWJlZCBpbiBTVEQg NTgsDQogICBSRkMyNTc4IFtSRkMyNTc4XSwgU1REIDU4LCBSRkMyNTc5IFtSRkMyNTc5XSBhbmQg U1REIDU4LCBSRkMyNTgwDQogICBbUkZDMjU4MF0uDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCkRlIENub2Rk ZXIsIGV0IGFsLiAgICAgRXhwaXJlcyBTZXB0ZW1iZXIgMjMsIDIwMDYgICAgICAgICAgICAgICBb UGFnZSA0XQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICBEeW5hbWljIEF1dGhvcml6YXRpb24gU2Vy dmVyIE1JQiAgICAgICAgICBNYXJjaCAyMDA2DQoNCg0KMy4gIE92ZXJ2aWV3DQoNCiAgICJEeW5h bWljIEF1dGhvcml6YXRpb24gRXh0ZW5zaW9ucyB0byBSQURJVVMiIFtSRkMzNTc2XSBkZWZpbmVz IHRoZQ0KICAgb3BlcmF0aW9uIG9mIERpc2Nvbm5lY3QtUmVxdWVzdCwgRGlzY29ubmVjdC1BQ0ss IERpc2Nvbm5lY3QtTkFLLCBDb0EtDQogICBSZXF1ZXN0LCBDb0EtQUNLIGFuZCBDb0EtTkFLIHBh Y2tldHMuICBUeXBpY2FsbHkgTkFTIGRldmljZXMNCiAgIGltcGxlbWVudCB0aGUgREFTIGZ1bmN0 aW9uLCBhbmQgdGh1cyB3b3VsZCBiZSBleHBlY3RlZCB0byBpbXBsZW1lbnQNCiAgIHRoZSBSQURJ VVMgRHluYW1pYyBBdXRob3JpemF0aW9uIFNlcnZlciBNSUIsIHdoaWxlIERBQ3MgaW1wbGVtZW50 IHRoZQ0KICAgY2xpZW50IGZ1bmN0aW9uLCBhbmQgdGh1cyB3b3VsZCBiZSBleHBlY3RlZCB0byBp bXBsZW1lbnQgdGhlIFJBRElVUw0KICAgRHluYW1pYyBBdXRob3JpemF0aW9uIENsaWVudCBNSUIu DQoNCiAgIEhvd2V2ZXIsIGl0IGlzIHBvc3NpYmxlIGZvciBhIFJBRElVUyBEeW5hbWljIEF1dGhv cml6YXRpb24gZW50aXR5IHRvDQogICBwZXJmb3JtIGJvdGggY2xpZW50IGFuZCBzZXJ2ZXIgZnVu Y3Rpb25zLiAgRm9yIGV4YW1wbGUsIGEgUkFESVVTDQogICBwcm94eSBtYXkgYWN0IGFzIGEgREFT IHRvIG9uZSBvciBtb3JlIERBQ3MsIHdoaWxlIHNpbXVsdGFuZW91c2x5DQogICBhY3RpbmcgYXMg YSBEQUMgdG8gb25lIG9yIG1vcmUgREFTcy4gIEluIHN1Y2ggc2l0dWF0aW9ucywgaXQgaXMNCiAg IGV4cGVjdGVkIHRoYXQgUkFESVVTIGVudGl0aWVzIGNvbWJpbmluZyBjbGllbnQgYW5kIHNlcnZl cg0KICAgZnVuY3Rpb25hbGl0eSB3aWxsIHN1cHBvcnQgYm90aCB0aGUgY2xpZW50IGFuZCBzZXJ2 ZXIgTUlCcy4NCg0KICAgVGhpcyBtZW1vIGRlc2NyaWJlcyB0aGUgTUlCIGZvciBEeW5hbWljIEF1 dGhvcml6YXRpb24gU2VydmVycyBhbmQNCiAgIHJlbGF0ZXMgdG8gdGhlIGZvbGxvd2luZyBkb2N1 bWVudHMgYXMgZm9sbG93czoNCg0KICAgW1JGQzI2MThiaXNdIGRlc2NyaWJlcyB0aGUgTUlCIGZv ciBhIFJBRElVUyBBdXRoIENsaWVudCBNSUIuDQoNCiAgIFtSRkMyNjE5YmlzXSBkZXNjcmliZXMg dGhlIE1JQiBmb3IgYSBSQURJVVMgQXV0aCBTZXJ2ZXIgTUlCLg0KDQogICBbUkZDMjYyMGJpc10g ZGVzY3JpYmVzIHRoZSBNSUIgZm9yIGEgUkFESVVTIEFjY3QgQ2xpZW50IE1JQi4NCg0KICAgW1JG QzI2MjFiaXNdIGRlc2NyaWJlcyB0aGUgTUlCIGZvciBhIFJBRElVUyBBY2N0IFNlcnZlciBNSUIu DQoNCiAgIFtEWU5DTE5UXSBkZXNjcmliZXMgdGhlIE1JQiBmb3IgYSBSQURJVVMgRHluYW1pYyBB dXRob3JpemF0aW9uDQogICBDbGllbnQuDQoNCiAgIEEgTkFTIHR5cGljYWxseSBpbXBsZW1lbnRz IHRoZSBNSUJzIGZvciBhIFJBRElVUyBBdXRoZW50aWNhdGlvbg0KICAgQ2xpZW50LCBhIFJBRElV UyBhY2NvdW50aW5nIGNsaWVudCwgYW5kIGEgUkFESVVTIER5bmFtaWMNCiAgIEF1dGhvcml6YXRp b24gU2VydmVyLiAgSG93ZXZlciwgYW55IG9uZSBNSUIgY2FuIGJlIGltcGxlbWVudGVkDQogICB3 aXRob3V0IGltcGxlbWVudGluZyBhbnkgb2YgdGhlIG90aGVyIE1JQnMsIGkuZS4gdGhlIE1JQnMg aGF2ZSBubw0KICAgZGVwZW5kZW5jaWVzIG9uIGVhY2ggb3RoZXIuICBBIHR5cGljYWwgY2FzZSB3 b3VsZCBiZSBmb3IgYSBkZXZpY2UgdG8NCiAgIGltcGxlbWVudCB0aGUgTUlCcyBSQURJVVMgYXV0 aGVudGljYXRpb24gc2VydmVyLCBSQURJVVMgYWNjb3VudGluZw0KICAgc2VydmVyIGFuZCBSQURJ VVMgRHluYW1pYyBBdXRob3JpemF0aW9uIENsaWVudC4gIEEgUkFESVVTIHByb3h5IG1pZ2h0DQog ICBpbXBsZW1lbnQgYW55LCBhbGwgb3IgYSBzdWJzZXQgb2YgdGhlIE1JQnMgbGlzdGVkIGFib3Zl IGFuZCB0aGUgTUlCDQogICBhcyBkZWZpbmVkIGluIHRoaXMgZG9jdW1lbnQuDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KRGUgQ25vZGRlciwgZXQgYWwuICAgICBFeHBpcmVzIFNlcHRlbWJlciAyMywg MjAwNiAgICAgICAgICAgICAgIFtQYWdlIDVdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgIER5bmFt aWMgQXV0aG9yaXphdGlvbiBTZXJ2ZXIgTUlCICAgICAgICAgIE1hcmNoIDIwMDYNCg0KDQogICAg ICAgICAgICAgICstLS0tLS0tLS0tLS0tLS0rICAgICAgICAgICAgICAgICAgICAgICstLS0tLS0t LS0tLS0tLS0rDQogICAgVXNlciAxLS0tLXwgICAgICAgICAgICAgICB8ICBEaXNjb25uZWN0LVJl cXVlc3QgIHwgICAgICAgICAgICAgICB8DQogICAgICAgICAgICAgIHwgICAgRHluYW1pYyAgICB8 ICAgICBDb0EtUmVxdWVzdCAgICAgIHwgICAgRHluYW1pYyAgICB8DQogICAgVXNlciAyLS0tLXwg QXV0aG9yaXphdGlvbiB8PC0tLS0tLS0tLS0tLS0tLS0tLS0tLXwgQXV0aG9yaXphdGlvbiB8DQog ICAgICAgICAgICAgIHwgICAgU2VydmVyICAgICB8LS0tLS0tLS0tLS0tLS0tLS0tLS0tPnwgICAg Q2xpZW50ICAgICB8DQogICAgVXNlciAzLS0tLXwgICAgIChEQVMpICAgICB8ICAgIERpc2Nvbm5l Y3QtQWNrICAgIHwgICAgIChEQUMpICAgICB8DQogICAgICAgICAgICAgIHwgICAgICAgICAgICAg ICB8ICAgIERpc2Nvbm5lY3QtTkFLICAgIHwgICAgICAgICAgICAgICB8DQogICAgICAgICAgICAg ICstLS0tLS0tLS0tLS0tLS0rICAgIENvQS1BY2svQ29BLU5BSyAgICstLS0tLS0tLS0tLS0tLS0r DQoNCiAgIEZpZ3VyZSAxOiBNYXBwaW5nIG9mIGNsaWVudHMgYW5kIHNlcnZlcnMuDQoNCiAgIFRo aXMgTUlCIG1vZHVsZSBmb3IgdGhlIER5bmFtaWMgQXV0aG9yaXphdGlvbiBTZXJ2ZXIgY29udGFp bnMgdGhlDQogICBmb2xsb3dpbmc6DQoNCiAgIDEuICBGb3VyIHNjYWxhciBvYmplY3RzLCBhbmQN Cg0KICAgMi4gIE9uZSBEeW5hbWljIEF1dGhvcml6YXRpb24gQ2xpZW50IFRhYmxlLiAgVGhpcyB0 YWJsZSBjb250YWlucyBvbmUNCiAgIHJvdyBmb3IgZWFjaCBEQUMgd2l0aCB3aGljaCB0aGUgREFT IHNoYXJlcyBhIHNlY3JldC4NCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCkRlIENub2RkZXIsIGV0IGFsLiAgICAgRXhwaXJl cyBTZXB0ZW1iZXIgMjMsIDIwMDYgICAgICAgICAgICAgICBbUGFnZSA2XQ0KDA0KSW50ZXJuZXQt RHJhZnQgICAgICBEeW5hbWljIEF1dGhvcml6YXRpb24gU2VydmVyIE1JQiAgICAgICAgICBNYXJj aCAyMDA2DQoNCg0KNC4gIFJBRElVUyBEeW5hbWljIEF1dGhvcml6YXRpb24gU2VydmVyIE1JQiBE ZWZpbml0aW9ucw0KDQogICBSQURJVVMtRFlOQVVUSC1TRVJWRVItTUlCIERFRklOSVRJT05TIDo6 PSBCRUdJTg0KDQogICBJTVBPUlRTDQogICAgICAgICAgTU9EVUxFLUlERU5USVRZLCBPQkpFQ1Qt VFlQRSwNCiAgICAgICAgICBDb3VudGVyMzIsIEludGVnZXIzMiwgbWliLTIsDQogICAgICAgICAg VGltZVRpY2tzICAgICAgICAgRlJPTSBTTk1QdjItU01JICAgICAgICAgICAgIC0tIFtSRkMyNTc4 XQ0KICAgICAgICAgIFNubXBBZG1pblN0cmluZyAgIEZST00gU05NUC1GUkFNRVdPUkstTUlCICAg ICAtLSBbUkZDMzQxMV0NCiAgICAgICAgICBJbmV0QWRkcmVzc1R5cGUsDQogICAgICAgICAgSW5l dEFkZHJlc3MgICAgICAgRlJPTSBJTkVULUFERFJFU1MtTUlCICAgICAgIC0tIFtSRkM0MDAxXQ0K ICAgICAgICAgIE1PRFVMRS1DT01QTElBTkNFLA0KICAgICAgICAgIE9CSkVDVC1HUk9VUCAgRlJP TSBTTk1QdjItQ09ORjsgICAgICAgICAgICAgICAtLSBbUkZDMjU4MF0NCg0KICAgcmFkaXVzRHlu QXV0aFNlcnZlck1JQiBNT0RVTEUtSURFTlRJVFkNCiAgICAgICAgICBMQVNULVVQREFURUQgIjIw MDYwMzIyMDAwMFoiIC0tIDIyIE1hcmNoIDIwMDYNCiAgICAgICAgICBPUkdBTklaQVRJT04gIklF VEYgUkFERVhUIFdvcmtpbmcgR3JvdXAiDQogICAgICAgICAgQ09OVEFDVC1JTkZPDQogICAgICAg ICAgICAgICAgICIgU3RlZmFhbiBEZSBDbm9kZGVyDQogICAgICAgICAgICAgICAgICAgQWxjYXRl bA0KICAgICAgICAgICAgICAgICAgIEZyYW5jaXMgV2VsbGVzcGxlaW4gMQ0KICAgICAgICAgICAg ICAgICAgIEItMjAxOCBBbnR3ZXJwDQogICAgICAgICAgICAgICAgICAgQmVsZ2l1bQ0KDQogICAg ICAgICAgICAgICAgICAgUGhvbmU6ICszMiAzIDI0MCA4NSAxNQ0KICAgICAgICAgICAgICAgICAg IEVNYWlsOiBzdGVmYWFuLmRlX2Nub2RkZXJAYWxjYXRlbC5iZQ0KDQogICAgICAgICAgICAgICAg ICAgTmFnaSBSZWRkeSBKb25uYWxhDQogICAgICAgICAgICAgICAgICAgQ2lzY28gU3lzdGVtcywg SW5jLg0KICAgICAgICAgICAgICAgICAgIERpdnlhc3JlZSBDaGFtYmVycywgQiBXaW5nLA0KICAg ICAgICAgICAgICAgICAgIE8nU2hhdWduZXNzeSBSb2FkLA0KICAgICAgICAgICAgICAgICAgIEJh bmdhbG9yZS01NjAwMjcsIEluZGlhLg0KDQogICAgICAgICAgICAgICAgICAgUGhvbmU6ICs5MSA5 NDQ4NyA2MDgyOA0KICAgICAgICAgICAgICAgICAgIEVNYWlsOiBuam9ubmFsYUBjaXNjby5jb20N Cg0KICAgICAgICAgICAgICAgICAgIE11cnRhemEgQ2hpYmENCiAgICAgICAgICAgICAgICAgICBD aXNjbyBTeXN0ZW1zLCBJbmMuDQogICAgICAgICAgICAgICAgICAgMTcwIFdlc3QgVGFzbWFuIERy Lg0KICAgICAgICAgICAgICAgICAgIFNhbiBKb3NlIENBLCA5NTEzNA0KDQogICAgICAgICAgICAg ICAgICAgUGhvbmU6ICsxIDQwOCA1MjUgNzE5OA0KICAgICAgICAgICAgICAgICAgIEVNYWlsOiBt Y2hpYmFAY2lzY28uY29tICINCiAgICAgICAgICBERVNDUklQVElPTg0KICAgICAgICAgICAgICAi VGhlIE1JQiBtb2R1bGUgZm9yIGVudGl0aWVzIGltcGxlbWVudGluZyB0aGUgc2VydmVyDQogICAg ICAgICAgICAgICBzaWRlIG9mIHRoZSBEeW5hbWljIEF1dGhvcml6YXRpb24gRXh0ZW5zaW9ucyB0 byBSZW1vdGUNCiAgICAgICAgICAgICAgIEF1dGhlbnRpY2F0aW9uIERpYWwgSW4gVXNlciBTZXJ2 aWNlIChSQURJVVMpIHByb3RvY29sLg0KDQoNCg0KDQpEZSBDbm9kZGVyLCBldCBhbC4gICAgIEV4 cGlyZXMgU2VwdGVtYmVyIDIzLCAyMDA2ICAgICAgICAgICAgICAgW1BhZ2UgN10NCgwNCkludGVy bmV0LURyYWZ0ICAgICAgRHluYW1pYyBBdXRob3JpemF0aW9uIFNlcnZlciBNSUIgICAgICAgICAg TWFyY2ggMjAwNg0KDQoNCiAgICAgICAgICAgICAgIENvcHlyaWdodCAoQykgVGhlIEludGVybmV0 IFNvY2lldHkgKDIwMDYpLiAgSW5pdGlhbA0KICAgICAgICAgICAgICAgdmVyc2lvbiBhcyBwdWJs aXNoZWQgaW4gUkZDIHl5eXk7DQogICAgICAgICAgICAgICBmb3IgZnVsbCBsZWdhbCBub3RpY2Vz IHNlZSB0aGUgUkZDIGl0c2VsZi4iDQogICAtLSBSRkMgRWQuOiByZXBsYWNlIHl5eXkgd2l0aCBh Y3R1YWwgUkZDIG51bWJlciAmIHJlbW92ZSB0aGlzIG5vdGUNCg0KICAgICAgICAgIFJFVklTSU9O ICIyMDA2MDMyMjAwMDBaIiAtLSAyMiBNYXJjaCAyMDA2DQogICAgICAgICAgREVTQ1JJUFRJT04g IkluaXRpYWwgdmVyc2lvbiBhcyBwdWJsaXNoZWQgaW4gUkZDIHl5eXkuIg0KICAgLS0gUkZDIEVk LjogcmVwbGFjZSB5eXl5IHdpdGggYWN0dWFsIFJGQyBudW1iZXIgJiByZW1vdmUgdGhpcyBub3Rl DQogICAgICAgICAgOjo9IHsgbWliLTIgeHh4IH0NCiAgIC0tIFRoZSB2YWx1ZSB4eHggdG8gYmUg YXNzaWduZWQgYnkgSUFOQS4NCg0KICAgcmFkaXVzRHluQXV0aFNlcnZlck1JQk9iamVjdHMgT0JK RUNUIElERU5USUZJRVIgOjo9DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIHsgcmFkaXVzRHluQXV0aFNlcnZlck1JQiAxIH0NCg0KICAgcmFkaXVzRHluQXV0aFNlcnZl clNjYWxhcnMgICAgT0JKRUNUIElERU5USUZJRVIgOjo9DQogICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgeyByYWRpdXNEeW5BdXRoU2VydmVyTUlCT2JqZWN0cyAxIH0NCg0KICAgcmFk aXVzRHluQXV0aFNlcnZlckRpc2NvbkludmFsaWRDbGllbnRBZGRyZXNzZXMgT0JKRUNULVRZUEUN CiAgICAgICAgIFNZTlRBWCBDb3VudGVyMzINCiAgICAgICAgIE1BWC1BQ0NFU1MgcmVhZC1vbmx5 DQogICAgICAgICBTVEFUVVMgY3VycmVudA0KICAgICAgICAgREVTQ1JJUFRJT04NCiAgICAgICAg ICAgICAgICJUaGUgbnVtYmVyIG9mIERpc2Nvbm5lY3QtUmVxdWVzdCBwYWNrZXRzIHJlY2VpdmVk IGZyb20NCiAgICAgICAgICAgICAgICB1bmtub3duIGFkZHJlc3Nlcy4gVGhpcyBjb3VudGVyIG1h eSBleHBlcmllbmNlIGENCiAgICAgICAgICAgICAgICBkaXNjb250aW51aXR5IHdoZW4gdGhlIERB UyBtb2R1bGUgKHJlKXN0YXJ0cyBhcw0KICAgICAgICAgICAgICAgIGluZGljYXRlZCBieSB0aGUg dmFsdWUgb2YNCiAgICAgICAgICAgICAgICByYWRpdXNEeW5BdXRoU2VydmVyQ291bnRlckRpc2Nv bnRpbnVpdHkuIg0KICAgICAgICAgOjo9IHsgcmFkaXVzRHluQXV0aFNlcnZlclNjYWxhcnMgMSB9 DQoNCiAgIHJhZGl1c0R5bkF1dGhTZXJ2ZXJDb0FJbnZhbGlkQ2xpZW50QWRkcmVzc2VzIE9CSkVD VC1UWVBFDQogICAgICAgICBTWU5UQVggQ291bnRlcjMyDQogICAgICAgICBNQVgtQUNDRVNTIHJl YWQtb25seQ0KICAgICAgICAgU1RBVFVTIGN1cnJlbnQNCiAgICAgICAgIERFU0NSSVBUSU9ODQog ICAgICAgICAgICAgICAiVGhlIG51bWJlciBvZiBDb0EtUmVxdWVzdCBwYWNrZXRzIHJlY2VpdmVk IGZyb20gdW5rbm93bg0KICAgICAgICAgICAgICAgIGFkZHJlc3Nlcy4gVGhpcyBjb3VudGVyIG1h eSBleHBlcmllbmNlIGEgZGlzY29udGludWl0eQ0KICAgICAgICAgICAgICAgIHdoZW4gdGhlIERB UyBtb2R1bGUgKHJlKXN0YXJ0cyBhcyBpbmRpY2F0ZWQgYnkgdGhlIHZhbHVlDQogICAgICAgICAg ICAgICAgb2YgcmFkaXVzRHluQXV0aFNlcnZlckNvdW50ZXJEaXNjb250aW51aXR5LiINCiAgICAg ICAgIDo6PSB7IHJhZGl1c0R5bkF1dGhTZXJ2ZXJTY2FsYXJzIDIgfQ0KDQogICByYWRpdXNEeW5B dXRoU2VydmVySWRlbnRpZmllciBPQkpFQ1QtVFlQRQ0KICAgICAgICAgU1lOVEFYIFNubXBBZG1p blN0cmluZw0KICAgICAgICAgTUFYLUFDQ0VTUyByZWFkLW9ubHkNCiAgICAgICAgIFNUQVRVUyBj dXJyZW50DQogICAgICAgICBERVNDUklQVElPTg0KICAgICAgICAgICAgICAgICJUaGUgTkFTLUlk ZW50aWZpZXIgb2YgdGhlIFJBRElVUyBEeW5hbWljIEF1dGhvcml6YXRpb24NCiAgICAgICAgICAg ICAgICAgU2VydmVyLiBUaGlzIGlzIG5vdCBuZWNlc3NhcmlseSB0aGUgc2FtZSBhcyBzeXNOYW1l IGluDQogICAgICAgICAgICAgICAgIE1JQiBJSS4iDQoNCg0KDQpEZSBDbm9kZGVyLCBldCBhbC4g ICAgIEV4cGlyZXMgU2VwdGVtYmVyIDIzLCAyMDA2ICAgICAgICAgICAgICAgW1BhZ2UgOF0NCgwN CkludGVybmV0LURyYWZ0ICAgICAgRHluYW1pYyBBdXRob3JpemF0aW9uIFNlcnZlciBNSUIgICAg ICAgICAgTWFyY2ggMjAwNg0KDQoNCiAgICAgICAgIFJFRkVSRU5DRQ0KICAgICAgICAgICAgICAg ICJSRkMgMjg2NSwgU2VjdGlvbiA1LjMyLCBOQVMtSWRlbnRpZmllci4iDQogICAgICAgICA6Oj0g eyByYWRpdXNEeW5BdXRoU2VydmVyU2NhbGFycyAzIH0NCg0KICAgcmFkaXVzRHluQXV0aFNlcnZl ckNvdW50ZXJEaXNjb250aW51aXR5IE9CSkVDVC1UWVBFDQogICAgICAgICAgU1lOVEFYIFRpbWVU aWNrcw0KICAgICAgICAgIFVOSVRTICAiaHVuZHJlZHRocyBvZiBhIHNlY29uZCINCiAgICAgICAg ICBNQVgtQUNDRVNTIHJlYWQtb25seQ0KICAgICAgICAgIFNUQVRVUyBjdXJyZW50DQogICAgICAg ICAgREVTQ1JJUFRJT04NCiAgICAgICAgICAgICAgICAiVGhlIHRpbWUgKGluIGh1bmRyZWR0aHMg b2YgYSBzZWNvbmQpIHNpbmNlIHRoZQ0KICAgICAgICAgICAgICAgICBEQVMgbW9kdWxlIHdhcyBs YXN0IHJlLWluaXRpYWxpemVkLiINCiAgICAgICAgICA6Oj0geyByYWRpdXNEeW5BdXRoU2VydmVy U2NhbGFycyA0IH0NCg0KICAgcmFkaXVzRHluQXV0aENsaWVudFRhYmxlIE9CSkVDVC1UWVBFDQog ICAgICAgICBTWU5UQVggU0VRVUVOQ0UgT0YgUmFkaXVzRHluQXV0aENsaWVudEVudHJ5DQogICAg ICAgICBNQVgtQUNDRVNTIG5vdC1hY2Nlc3NpYmxlDQogICAgICAgICBTVEFUVVMgICAgIGN1cnJl bnQNCiAgICAgICAgIERFU0NSSVBUSU9ODQogICAgICAgICAgICAgICAiVGhlIChjb25jZXB0dWFs KSB0YWJsZSBsaXN0aW5nIHRoZSBSQURJVVMgRHluYW1pYw0KICAgICAgICAgICAgICAgIEF1dGhv cml6YXRpb24gQ2xpZW50cyB3aXRoIHdoaWNoIHRoZSBzZXJ2ZXIgc2hhcmVzIGENCiAgICAgICAg ICAgICAgICBzZWNyZXQuIg0KICAgICAgICAgOjo9IHsgcmFkaXVzRHluQXV0aFNlcnZlck1JQk9i amVjdHMgMiB9DQoNCiAgIHJhZGl1c0R5bkF1dGhDbGllbnRFbnRyeSBPQkpFQ1QtVFlQRQ0KICAg ICAgICAgIFNZTlRBWCAgICAgUmFkaXVzRHluQXV0aENsaWVudEVudHJ5DQogICAgICAgICAgTUFY LUFDQ0VTUyBub3QtYWNjZXNzaWJsZQ0KICAgICAgICAgIFNUQVRVUyAgICAgY3VycmVudA0KICAg ICAgICAgIERFU0NSSVBUSU9ODQogICAgICAgICAgICAgICAgIkFuIGVudHJ5IChjb25jZXB0dWFs IHJvdykgcmVwcmVzZW50aW5nIG9uZSBEeW5hbWljDQogICAgICAgICAgICAgICAgIEF1dGhvcml6 YXRpb24gQ2xpZW50IHdpdGggd2hpY2ggdGhlIHNlcnZlciBzaGFyZXMgYQ0KICAgICAgICAgICAg ICAgICBzZWNyZXQuIg0KICAgICAgICAgIElOREVYICAgICAgeyByYWRpdXNEeW5BdXRoQ2xpZW50 SW5kZXggfQ0KICAgICAgICAgIDo6PSB7IHJhZGl1c0R5bkF1dGhDbGllbnRUYWJsZSAxIH0NCg0K ICAgUmFkaXVzRHluQXV0aENsaWVudEVudHJ5IDo6PSBTRVFVRU5DRSB7DQogICAgICAgICAgcmFk aXVzRHluQXV0aENsaWVudEluZGV4ICAgICAgICAgICAgICAgICAgICAgSW50ZWdlcjMyLA0KICAg ICAgICAgIHJhZGl1c0R5bkF1dGhDbGllbnRBZGRyZXNzVHlwZSAgICAgICAgICAgICAgIEluZXRB ZGRyZXNzVHlwZSwNCiAgICAgICAgICByYWRpdXNEeW5BdXRoQ2xpZW50QWRkcmVzcyAgICAgICAg ICAgICAgICAgICBJbmV0QWRkcmVzcywNCiAgICAgICAgICByYWRpdXNEeW5BdXRoU2VydkRpc2Nv blJlcXVlc3RzICAgICAgICAgICAgICBDb3VudGVyMzIsDQogICAgICAgICAgcmFkaXVzRHluQXV0 aFNlcnZEaXNjb25BdXRoT25seVJlcXVlc3RzICAgICAgQ291bnRlcjMyLA0KICAgICAgICAgIHJh ZGl1c0R5bkF1dGhTZXJ2RHVwRGlzY29uUmVxdWVzdHMgICAgICAgICAgIENvdW50ZXIzMiwNCiAg ICAgICAgICByYWRpdXNEeW5BdXRoU2VydkRpc2NvbkFja3MgICAgICAgICAgICAgICAgICBDb3Vu dGVyMzIsDQogICAgICAgICAgcmFkaXVzRHluQXV0aFNlcnZEaXNjb25OYWtzICAgICAgICAgICAg ICAgICAgQ291bnRlcjMyLA0KICAgICAgICAgIHJhZGl1c0R5bkF1dGhTZXJ2RGlzY29uTmFrQXV0 aE9ubHlSZXF1ZXN0cyAgIENvdW50ZXIzMiwNCiAgICAgICAgICByYWRpdXNEeW5BdXRoU2VydkRp c2Nvbk5ha1Nlc3NOb0NvbnRleHQgICAgICBDb3VudGVyMzIsDQogICAgICAgICAgcmFkaXVzRHlu QXV0aFNlcnZEaXNjb25Vc2VyU2Vzc1JlbW92ZWQgICAgICAgQ291bnRlcjMyLA0KICAgICAgICAg IHJhZGl1c0R5bkF1dGhTZXJ2TWFsZm9ybWVkRGlzY29uUmVxdWVzdHMgICAgIENvdW50ZXIzMiwN Cg0KDQoNCkRlIENub2RkZXIsIGV0IGFsLiAgICAgRXhwaXJlcyBTZXB0ZW1iZXIgMjMsIDIwMDYg ICAgICAgICAgICAgICBbUGFnZSA5XQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICBEeW5hbWljIEF1 dGhvcml6YXRpb24gU2VydmVyIE1JQiAgICAgICAgICBNYXJjaCAyMDA2DQoNCg0KICAgICAgICAg IHJhZGl1c0R5bkF1dGhTZXJ2RGlzY29uQmFkQXV0aGVudGljYXRvcnMgICAgIENvdW50ZXIzMiwN CiAgICAgICAgICByYWRpdXNEeW5BdXRoU2VydkRpc2NvblBhY2tldHNEcm9wcGVkICAgICAgICBD b3VudGVyMzIsDQogICAgICAgICAgcmFkaXVzRHluQXV0aFNlcnZDb0FSZXF1ZXN0cyAgICAgICAg ICAgICAgICAgQ291bnRlcjMyLA0KICAgICAgICAgIHJhZGl1c0R5bkF1dGhTZXJ2Q29BQXV0aE9u bHlSZXF1ZXN0cyAgICAgICAgIENvdW50ZXIzMiwNCiAgICAgICAgICByYWRpdXNEeW5BdXRoU2Vy dkR1cENvQVJlcXVlc3RzICAgICAgICAgICAgICBDb3VudGVyMzIsDQogICAgICAgICAgcmFkaXVz RHluQXV0aFNlcnZDb0FBY2tzICAgICAgICAgICAgICAgICAgICAgQ291bnRlcjMyLA0KICAgICAg ICAgIHJhZGl1c0R5bkF1dGhTZXJ2Q29BTmFrcyAgICAgICAgICAgICAgICAgICAgIENvdW50ZXIz MiwNCiAgICAgICAgICByYWRpdXNEeW5BdXRoU2VydkNvQU5ha0F1dGhPbmx5UmVxdWVzdHMgICAg ICBDb3VudGVyMzIsDQogICAgICAgICAgcmFkaXVzRHluQXV0aFNlcnZDb0FOYWtTZXNzTm9Db250 ZXh0ICAgICAgICAgQ291bnRlcjMyLA0KICAgICAgICAgIHJhZGl1c0R5bkF1dGhTZXJ2Q29BVXNl clNlc3NDaGFuZ2VkICAgICAgICAgIENvdW50ZXIzMiwNCiAgICAgICAgICByYWRpdXNEeW5BdXRo U2Vydk1hbGZvcm1lZENvQVJlcXVlc3RzICAgICAgICBDb3VudGVyMzIsDQogICAgICAgICAgcmFk aXVzRHluQXV0aFNlcnZDb0FCYWRBdXRoZW50aWNhdG9ycyAgICAgICAgQ291bnRlcjMyLA0KICAg ICAgICAgIHJhZGl1c0R5bkF1dGhTZXJ2Q29BUGFja2V0c0Ryb3BwZWQgICAgICAgICAgIENvdW50 ZXIzMiwNCiAgICAgICAgICByYWRpdXNEeW5BdXRoU2VydlVua25vd25UeXBlcyAgICAgICAgICAg ICAgICBDb3VudGVyMzINCiAgIH0NCg0KDQogICByYWRpdXNEeW5BdXRoQ2xpZW50SW5kZXggT0JK RUNULVRZUEUNCiAgICAgICAgICBTWU5UQVggICAgIEludGVnZXIzMiAoMS4uMjE0NzQ4MzY0NykN CiAgICAgICAgICBNQVgtQUNDRVNTIG5vdC1hY2Nlc3NpYmxlDQogICAgICAgICAgU1RBVFVTICAg ICBjdXJyZW50DQogICAgICAgICAgREVTQ1JJUFRJT04NCiAgICAgICAgICAgICAgICAiQSBudW1i ZXIgdW5pcXVlbHkgaWRlbnRpZnlpbmcgZWFjaCBSQURJVVMgRHluYW1pYw0KICAgICAgICAgICAg ICAgICBBdXRob3JpemF0aW9uIENsaWVudCB3aXRoIHdoaWNoIHRoaXMgRHluYW1pYw0KICAgICAg ICAgICAgICAgICBBdXRob3JpemF0aW9uIFNlcnZlciBjb21tdW5pY2F0ZXMuIFRoaXMgbnVtYmVy IGlzDQogICAgICAgICAgICAgICAgIGFsbG9jYXRlZCBieSB0aGUgYWdlbnQgaW1wbGVtZW50aW5n IHRoaXMgTUlCIG1vZHVsZSwNCiAgICAgICAgICAgICAgICAgYW5kIGlzIHVuaXF1ZSBpbiB0aGlz IGNvbnRleHQuIg0KICAgICAgICAgIDo6PSB7IHJhZGl1c0R5bkF1dGhDbGllbnRFbnRyeSAxIH0N Cg0KICAgcmFkaXVzRHluQXV0aENsaWVudEFkZHJlc3NUeXBlIE9CSkVDVC1UWVBFDQogICAgICAg ICAgU1lOVEFYICAgICBJbmV0QWRkcmVzc1R5cGUNCiAgICAgICAgICBNQVgtQUNDRVNTIHJlYWQt b25seQ0KICAgICAgICAgIFNUQVRVUyAgICAgY3VycmVudA0KICAgICAgICAgIERFU0NSSVBUSU9O DQogICAgICAgICAgICAgICAgIlRoZSB0eXBlIG9mIElQIGFkZHJlc3Mgb2YgdGhlIFJBRElVUyBE eW5hbWljDQogICAgICAgICAgICAgICAgIEF1dGhvcml6YXRpb24gQ2xpZW50IHJlZmVycmVkIHRv IGluIHRoaXMgdGFibGUgZW50cnkuIg0KICAgICAgICAgIDo6PSB7IHJhZGl1c0R5bkF1dGhDbGll bnRFbnRyeSAyIH0NCg0KICAgcmFkaXVzRHluQXV0aENsaWVudEFkZHJlc3MgT0JKRUNULVRZUEUN CiAgICAgICAgICBTWU5UQVggICAgIEluZXRBZGRyZXNzDQogICAgICAgICAgTUFYLUFDQ0VTUyBy ZWFkLW9ubHkNCiAgICAgICAgICBTVEFUVVMgICAgIGN1cnJlbnQNCiAgICAgICAgICBERVNDUklQ VElPTg0KICAgICAgICAgICAgICAgICJUaGUgSVAgYWRkcmVzcyB2YWx1ZSBvZiB0aGUgUkFESVVT IER5bmFtaWMNCiAgICAgICAgICAgICAgICAgQXV0aG9yaXphdGlvbiBDbGllbnQgcmVmZXJyZWQg dG8gaW4gdGhpcyB0YWJsZSBlbnRyeSwNCiAgICAgICAgICAgICAgICAgdXNpbmcgdGhlIHZlcnNp b24gbmV1dHJhbCBJUCBhZGRyZXNzIGZvcm1hdC4gVGhlIHR5cGUNCiAgICAgICAgICAgICAgICAg b2YgdGhpcyBhZGRyZXNzIGlzIGRldGVybWluZWQgYnkgdGhlIHZhbHVlIG9mDQogICAgICAgICAg ICAgICAgIHRoZSByYWRpdXNEeW5BdXRoQ2xpZW50QWRkcmVzc1R5cGUgb2JqZWN0LiINCg0KDQoN CkRlIENub2RkZXIsIGV0IGFsLiAgICAgRXhwaXJlcyBTZXB0ZW1iZXIgMjMsIDIwMDYgICAgICAg ICAgICAgIFtQYWdlIDEwXQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICBEeW5hbWljIEF1dGhvcml6 YXRpb24gU2VydmVyIE1JQiAgICAgICAgICBNYXJjaCAyMDA2DQoNCg0KICAgICAgICAgIDo6PSB7 IHJhZGl1c0R5bkF1dGhDbGllbnRFbnRyeSAzIH0NCg0KICAgcmFkaXVzRHluQXV0aFNlcnZEaXNj b25SZXF1ZXN0cyBPQkpFQ1QtVFlQRQ0KICAgICAgICAgIFNZTlRBWCAgICAgQ291bnRlcjMyDQog ICAgICAgICAgVU5JVFMgICAgICAicmVxdWVzdHMiDQogICAgICAgICAgTUFYLUFDQ0VTUyByZWFk LW9ubHkNCiAgICAgICAgICBTVEFUVVMgICAgIGN1cnJlbnQNCiAgICAgICAgICBERVNDUklQVElP Tg0KICAgICAgICAgICAgICAgICJUaGUgbnVtYmVyIG9mIFJBRElVUyBEaXNjb25uZWN0LVJlcXVl c3RzIHJlY2VpdmVkDQogICAgICAgICAgICAgICAgIGZyb20gdGhpcyBEeW5hbWljIEF1dGhvcml6 YXRpb24gQ2xpZW50LiBUaGlzIGFsc28NCiAgICAgICAgICAgICAgICAgaW5jbHVkZXMgdGhlIFJB RElVUyBEaXNjb25uZWN0LVJlcXVlc3RzIHRoYXQgaGF2ZSBhDQogICAgICAgICAgICAgICAgIFNl cnZpY2UtVHlwZSBhdHRyaWJ1dGUgd2l0aCB2YWx1ZSAnQXV0aG9yaXplIE9ubHknLg0KICAgICAg ICAgICAgICAgICBUaGlzIGNvdW50ZXIgbWF5IGV4cGVyaWVuY2UgYSBkaXNjb250aW51aXR5IHdo ZW4gdGhlDQogICAgICAgICAgICAgICAgIERBUyBtb2R1bGUgKHJlKXN0YXJ0cyBhcyBpbmRpY2F0 ZWQgYnkgdGhlIHZhbHVlIG9mDQogICAgICAgICAgICAgICAgIHJhZGl1c0R5bkF1dGhTZXJ2ZXJD b3VudGVyRGlzY29udGludWl0eS4iDQogICAgICAgICAgUkVGRVJFTkNFDQogICAgICAgICAgICAg ICAgIlJGQyAzNTc2LCBTZWN0aW9uIDIuMSwgRGlzY29ubmVjdCBNZXNzYWdlcyAoRE0pLiINCiAg ICAgICAgICA6Oj0geyByYWRpdXNEeW5BdXRoQ2xpZW50RW50cnkgNCB9DQoNCiAgIHJhZGl1c0R5 bkF1dGhTZXJ2RGlzY29uQXV0aE9ubHlSZXF1ZXN0cyBPQkpFQ1QtVFlQRQ0KICAgICAgICAgIFNZ TlRBWCAgICAgQ291bnRlcjMyDQogICAgICAgICAgVU5JVFMgICAgICAicmVxdWVzdHMiDQogICAg ICAgICAgTUFYLUFDQ0VTUyByZWFkLW9ubHkNCiAgICAgICAgICBTVEFUVVMgICAgIGN1cnJlbnQN CiAgICAgICAgICBERVNDUklQVElPTg0KICAgICAgICAgICAgICAgICJUaGUgbnVtYmVyIG9mIFJB RElVUyBEaXNjb25uZWN0LVJlcXVlc3RzIHRoYXQgaW5jbHVkZQ0KICAgICAgICAgICAgICAgICBh IFNlcnZpY2UtVHlwZSBhdHRyaWJ1dGUgd2l0aCB2YWx1ZSAnQXV0aG9yaXplIE9ubHknDQogICAg ICAgICAgICAgICAgIHJlY2VpdmVkIGZyb20gdGhpcyBEeW5hbWljIEF1dGhvcml6YXRpb24gQ2xp ZW50LiBUaGlzDQogICAgICAgICAgICAgICAgIGNvdW50ZXIgbWF5IGV4cGVyaWVuY2UgYSBkaXNj b250aW51aXR5IHdoZW4gdGhlIERBUw0KICAgICAgICAgICAgICAgICBtb2R1bGUgKHJlKXN0YXJ0 cyBhcyBpbmRpY2F0ZWQgYnkgdGhlIHZhbHVlIG9mDQogICAgICAgICAgICAgICAgIHJhZGl1c0R5 bkF1dGhTZXJ2ZXJDb3VudGVyRGlzY29udGludWl0eS4iDQogICAgICAgICAgUkVGRVJFTkNFDQog ICAgICAgICAgICAgICAgIlJGQyAzNTc2LCBTZWN0aW9uIDIuMSwgRGlzY29ubmVjdCBNZXNzYWdl cyAoRE0pLiINCiAgICAgICAgICA6Oj0geyByYWRpdXNEeW5BdXRoQ2xpZW50RW50cnkgNSB9DQoN CiAgIHJhZGl1c0R5bkF1dGhTZXJ2RHVwRGlzY29uUmVxdWVzdHMgT0JKRUNULVRZUEUNCiAgICAg ICAgICBTWU5UQVggICAgIENvdW50ZXIzMg0KICAgICAgICAgIFVOSVRTICAgICAgInJlcXVlc3Rz Ig0KICAgICAgICAgIE1BWC1BQ0NFU1MgcmVhZC1vbmx5DQogICAgICAgICAgU1RBVFVTICAgICBj dXJyZW50DQogICAgICAgICAgREVTQ1JJUFRJT04NCiAgICAgICAgICAgICAgICAiVGhlIG51bWJl ciBvZiBkdXBsaWNhdGUgUkFESVVTIERpc2Nvbm5lY3QtUmVxdWVzdA0KICAgICAgICAgICAgICAg ICBwYWNrZXRzIHJlY2VpdmVkIGZyb20gdGhpcyBEeW5hbWljIEF1dGhvcml6YXRpb24NCiAgICAg ICAgICAgICAgICAgQ2xpZW50LiBUaGlzIGNvdW50ZXIgbWF5IGV4cGVyaWVuY2UgYSBkaXNjb250 aW51aXR5DQogICAgICAgICAgICAgICAgIHdoZW4gdGhlIERBUyBtb2R1bGUgKHJlKXN0YXJ0cyBh cyBpbmRpY2F0ZWQgYnkgdGhlDQogICAgICAgICAgICAgICAgIHZhbHVlIG9mIHJhZGl1c0R5bkF1 dGhTZXJ2ZXJDb3VudGVyRGlzY29udGludWl0eS4iDQogICAgICAgICAgUkVGRVJFTkNFDQogICAg ICAgICAgICAgICAgIlJGQyAzNTc2LCBTZWN0aW9uIDIuMSwgRGlzY29ubmVjdCBNZXNzYWdlcyAo RE0pLiINCg0KDQoNCkRlIENub2RkZXIsIGV0IGFsLiAgICAgRXhwaXJlcyBTZXB0ZW1iZXIgMjMs IDIwMDYgICAgICAgICAgICAgIFtQYWdlIDExXQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICBEeW5h bWljIEF1dGhvcml6YXRpb24gU2VydmVyIE1JQiAgICAgICAgICBNYXJjaCAyMDA2DQoNCg0KICAg ICAgICAgIDo6PSB7IHJhZGl1c0R5bkF1dGhDbGllbnRFbnRyeSA2IH0NCg0KICAgcmFkaXVzRHlu QXV0aFNlcnZEaXNjb25BY2tzICBPQkpFQ1QtVFlQRQ0KICAgICAgICAgIFNZTlRBWCAgICAgQ291 bnRlcjMyDQogICAgICAgICAgVU5JVFMgICAgICAicmVwbGllcyINCiAgICAgICAgICBNQVgtQUND RVNTIHJlYWQtb25seQ0KICAgICAgICAgIFNUQVRVUyAgICAgY3VycmVudA0KICAgICAgICAgIERF U0NSSVBUSU9ODQogICAgICAgICAgICAgICAgIlRoZSBudW1iZXIgb2YgUkFESVVTIERpc2Nvbm5l Y3QtQUNLIHBhY2tldHMgc2VudCB0bw0KICAgICAgICAgICAgICAgICB0aGlzIER5bmFtaWMgQXV0 aG9yaXphdGlvbiBDbGllbnQuIFRoaXMgY291bnRlciBtYXkNCiAgICAgICAgICAgICAgICAgZXhw ZXJpZW5jZSBhIGRpc2NvbnRpbnVpdHkgd2hlbiB0aGUgREFTIG1vZHVsZQ0KICAgICAgICAgICAg ICAgICAocmUpc3RhcnRzIGFzIGluZGljYXRlZCBieSB0aGUgdmFsdWUgb2YNCiAgICAgICAgICAg ICAgICAgcmFkaXVzRHluQXV0aFNlcnZlckNvdW50ZXJEaXNjb250aW51aXR5LiINCiAgICAgICAg ICBSRUZFUkVOQ0UNCiAgICAgICAgICAgICAgICAiUkZDIDM1NzYsIFNlY3Rpb24gMi4xLCBEaXNj b25uZWN0IE1lc3NhZ2VzIChETSkuIg0KICAgICAgICAgIDo6PSB7IHJhZGl1c0R5bkF1dGhDbGll bnRFbnRyeSA3IH0NCg0KICAgcmFkaXVzRHluQXV0aFNlcnZEaXNjb25OYWtzIE9CSkVDVC1UWVBF DQogICAgICAgICAgU1lOVEFYICAgICBDb3VudGVyMzINCiAgICAgICAgICBVTklUUyAgICAgICJy ZXBsaWVzIg0KICAgICAgICAgIE1BWC1BQ0NFU1MgcmVhZC1vbmx5DQogICAgICAgICAgU1RBVFVT ICAgICBjdXJyZW50DQogICAgICAgICAgREVTQ1JJUFRJT04NCiAgICAgICAgICAgICAgICAiVGhl IG51bWJlciBvZiBSQURJVVMgRGlzY29ubmVjdC1OQUsgcGFja2V0cw0KICAgICAgICAgICAgICAg ICBzZW50IHRvIHRoaXMgRHluYW1pYyBBdXRob3JpemF0aW9uIENsaWVudC4gVGhpcw0KICAgICAg ICAgICAgICAgICBpbmNsdWRlcyB0aGUgUkFESVVTIERpc2Nvbm5lY3QtTkFLIHBhY2tldHMgc2Vu dA0KICAgICAgICAgICAgICAgICB3aXRoIGEgU2VydmljZS1UeXBlIGF0dHJpYnV0ZSB3aXRoIHZh bHVlICdBdXRob3JpemUNCiAgICAgICAgICAgICAgICAgT25seScgYW5kIHRoZSBSQURJVVMgRGlz Y29ubmVjdC1OQUsgcGFja2V0cyBzZW50DQogICAgICAgICAgICAgICAgIGJlY2F1c2Ugbm8gc2Vz c2lvbiBjb250ZXh0IHdhcyBmb3VuZC4gVGhpcyBjb3VudGVyDQogICAgICAgICAgICAgICAgIG1h eSBleHBlcmllbmNlIGEgZGlzY29udGludWl0eSB3aGVuIHRoZSBEQVMgbW9kdWxlDQogICAgICAg ICAgICAgICAgIChyZSlzdGFydHMgYXMgaW5kaWNhdGVkIGJ5IHRoZSB2YWx1ZSBvZg0KICAgICAg ICAgICAgICAgICByYWRpdXNEeW5BdXRoU2VydmVyQ291bnRlckRpc2NvbnRpbnVpdHkuIg0KICAg ICAgICAgIFJFRkVSRU5DRQ0KICAgICAgICAgICAgICAgICJSRkMgMzU3NiwgU2VjdGlvbiAyLjEs IERpc2Nvbm5lY3QgTWVzc2FnZXMgKERNKS4iDQogICAgICAgICAgOjo9IHsgcmFkaXVzRHluQXV0 aENsaWVudEVudHJ5IDggfQ0KDQogICByYWRpdXNEeW5BdXRoU2VydkRpc2Nvbk5ha0F1dGhPbmx5 UmVxdWVzdHMgT0JKRUNULVRZUEUNCiAgICAgICAgICBTWU5UQVggICAgIENvdW50ZXIzMg0KICAg ICAgICAgIFVOSVRTICAgICAgInJlcGxpZXMiDQogICAgICAgICAgTUFYLUFDQ0VTUyByZWFkLW9u bHkNCiAgICAgICAgICBTVEFUVVMgICAgIGN1cnJlbnQNCiAgICAgICAgICBERVNDUklQVElPTg0K ICAgICAgICAgICAgICAgICJUaGUgbnVtYmVyIG9mIFJBRElVUyBEaXNjb25uZWN0LU5BSyBwYWNr ZXRzIHRoYXQNCiAgICAgICAgICAgICAgICAgaW5jbHVkZSBhIFNlcnZpY2UtVHlwZSBhdHRyaWJ1 dGUgd2l0aCB2YWx1ZQ0KICAgICAgICAgICAgICAgICAnQXV0aG9yaXplIE9ubHknIHNlbnQgdG8g dGhpcyBEeW5hbWljIEF1dGhvcml6YXRpb24NCiAgICAgICAgICAgICAgICAgQ2xpZW50LiBUaGlz IGNvdW50ZXIgbWF5IGV4cGVyaWVuY2UgYSBkaXNjb250aW51aXR5DQogICAgICAgICAgICAgICAg IHdoZW4gdGhlIERBUyBtb2R1bGUgKHJlKXN0YXJ0cyBhcyBpbmRpY2F0ZWQgYnkgdGhlDQogICAg ICAgICAgICAgICAgIHZhbHVlIG9mIHJhZGl1c0R5bkF1dGhTZXJ2ZXJDb3VudGVyRGlzY29udGlu dWl0eS4iDQoNCg0KDQpEZSBDbm9kZGVyLCBldCBhbC4gICAgIEV4cGlyZXMgU2VwdGVtYmVyIDIz LCAyMDA2ICAgICAgICAgICAgICBbUGFnZSAxMl0NCgwNCkludGVybmV0LURyYWZ0ICAgICAgRHlu YW1pYyBBdXRob3JpemF0aW9uIFNlcnZlciBNSUIgICAgICAgICAgTWFyY2ggMjAwNg0KDQoNCiAg ICAgICAgICBSRUZFUkVOQ0UNCiAgICAgICAgICAgICAgICAiUkZDIDM1NzYsIFNlY3Rpb24gMi4x LCBEaXNjb25uZWN0IE1lc3NhZ2VzIChETSkuIg0KICAgICAgICAgIDo6PSB7IHJhZGl1c0R5bkF1 dGhDbGllbnRFbnRyeSA5IH0NCg0KICAgcmFkaXVzRHluQXV0aFNlcnZEaXNjb25OYWtTZXNzTm9D b250ZXh0IE9CSkVDVC1UWVBFDQogICAgICAgICAgU1lOVEFYICAgICBDb3VudGVyMzINCiAgICAg ICAgICBVTklUUyAgICAgICJyZXBsaWVzIg0KICAgICAgICAgIE1BWC1BQ0NFU1MgcmVhZC1vbmx5 DQogICAgICAgICAgU1RBVFVTICAgICBjdXJyZW50DQogICAgICAgICAgREVTQ1JJUFRJT04NCiAg ICAgICAgICAgICAgICAiVGhlIG51bWJlciBvZiBSQURJVVMgRGlzY29ubmVjdC1OQUsgcGFja2V0 cw0KICAgICAgICAgICAgICAgICBzZW50IHRvIHRoaXMgRHluYW1pYyBBdXRob3JpemF0aW9uIENs aWVudA0KICAgICAgICAgICAgICAgICBiZWNhdXNlIG5vIHNlc3Npb24gY29udGV4dCB3YXMgZm91 bmQuIFRoaXMgY291bnRlciBtYXkNCiAgICAgICAgICAgICAgICAgZXhwZXJpZW5jZSBhIGRpc2Nv bnRpbnVpdHkgd2hlbiB0aGUgREFTIG1vZHVsZQ0KICAgICAgICAgICAgICAgICAocmUpc3RhcnRz IGFzIGluZGljYXRlZCBieSB0aGUgdmFsdWUgb2YNCiAgICAgICAgICAgICAgICAgcmFkaXVzRHlu QXV0aFNlcnZlckNvdW50ZXJEaXNjb250aW51aXR5LiINCiAgICAgICAgICBSRUZFUkVOQ0UNCiAg ICAgICAgICAgICAgICAiUkZDIDM1NzYsIFNlY3Rpb24gMi4xLCBEaXNjb25uZWN0IE1lc3NhZ2Vz IChETSkuIg0KICAgICAgICAgIDo6PSB7IHJhZGl1c0R5bkF1dGhDbGllbnRFbnRyeSAxMCB9DQoN CiAgIHJhZGl1c0R5bkF1dGhTZXJ2RGlzY29uVXNlclNlc3NSZW1vdmVkIE9CSkVDVC1UWVBFDQog ICAgICAgICAgU1lOVEFYICAgICBDb3VudGVyMzINCiAgICAgICAgICBVTklUUyAgICAgICJzZXNz aW9ucyINCiAgICAgICAgICBNQVgtQUNDRVNTIHJlYWQtb25seQ0KICAgICAgICAgIFNUQVRVUyAg ICAgY3VycmVudA0KICAgICAgICAgIERFU0NSSVBUSU9ODQogICAgICAgICAgICAgICAgIlRoZSBu dW1iZXIgb2YgdXNlciBzZXNzaW9ucyByZW1vdmVkIGZvciB0aGUNCiAgICAgICAgICAgICAgICAg RGlzY29ubmVjdC1SZXF1ZXN0cyByZWNlaXZlZCBmcm9tIHRoaXMNCiAgICAgICAgICAgICAgICAg RHluYW1pYyBBdXRob3JpemF0aW9uIENsaWVudC4gRGVwZW5kaW5nIG9uIHNpdGUNCiAgICAgICAg ICAgICAgICAgc3BlY2lmaWMgcG9saWNpZXMsIGEgc2luZ2xlIERpc2Nvbm5lY3QgcmVxdWVzdA0K ICAgICAgICAgICAgICAgICBjYW4gcmVtb3ZlIG11bHRpcGxlIHVzZXIgc2Vzc2lvbnMuIEluIHRo ZSBjYXNlDQogICAgICAgICAgICAgICAgIHRoYXQgdGhpcyBEeW5hbWljIEF1dGhvcml6YXRpb24g U2VydmVyIGhhcyBubw0KICAgICAgICAgICAgICAgICBrbm93bGVkZ2Ugb2YgdGhlIG51bWJlciBv ZiB1c2VyIHNlc3Npb25zIHRoYXQNCiAgICAgICAgICAgICAgICAgYXJlIGFmZmVjdGVkIGJ5IGEg c2luZ2xlIHJlcXVlc3QsIGZvciBlYWNoIHN1Y2gNCiAgICAgICAgICAgICAgICAgRGlzY29ubmVj dC1SZXF1ZXN0LCBpdCB3aWxsIGNvdW50IGFzIGEgc2luZ2xlDQogICAgICAgICAgICAgICAgIGFm ZmVjdGVkIHVzZXIgc2Vzc2lvbiBvbmx5LiBUaGlzIGNvdW50ZXIgbWF5IGV4cGVyaWVuY2UNCiAg ICAgICAgICAgICAgICAgYSBkaXNjb250aW51aXR5IHdoZW4gdGhlIERBUyBtb2R1bGUgKHJlKXN0 YXJ0cyBhcw0KICAgICAgICAgICAgICAgICBpbmRpY2F0ZWQgYnkgdGhlIHZhbHVlIG9mDQogICAg ICAgICAgICAgICAgIHJhZGl1c0R5bkF1dGhTZXJ2ZXJDb3VudGVyRGlzY29udGludWl0eS4iDQog ICAgICAgICAgUkVGRVJFTkNFDQogICAgICAgICAgICAgICAgIlJGQyAzNTc2LCBTZWN0aW9uIDIu MSwgRGlzY29ubmVjdCBNZXNzYWdlcyAoRE0pLiINCiAgICAgICAgICA6Oj0geyByYWRpdXNEeW5B dXRoQ2xpZW50RW50cnkgMTEgfQ0KDQogICByYWRpdXNEeW5BdXRoU2Vydk1hbGZvcm1lZERpc2Nv blJlcXVlc3RzIE9CSkVDVC1UWVBFDQogICAgICAgICAgU1lOVEFYICAgICBDb3VudGVyMzINCiAg ICAgICAgICBVTklUUyAgICAgICJyZXF1ZXN0cyINCiAgICAgICAgICBNQVgtQUNDRVNTIHJlYWQt b25seQ0KICAgICAgICAgIFNUQVRVUyAgICAgY3VycmVudA0KDQoNCg0KRGUgQ25vZGRlciwgZXQg YWwuICAgICBFeHBpcmVzIFNlcHRlbWJlciAyMywgMjAwNiAgICAgICAgICAgICAgW1BhZ2UgMTNd DQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgIER5bmFtaWMgQXV0aG9yaXphdGlvbiBTZXJ2ZXIgTUlC ICAgICAgICAgIE1hcmNoIDIwMDYNCg0KDQogICAgICAgICAgREVTQ1JJUFRJT04NCiAgICAgICAg ICAgICAgICAiVGhlIG51bWJlciBvZiBtYWxmb3JtZWQgUkFESVVTIERpc2Nvbm5lY3QtUmVxdWVz dA0KICAgICAgICAgICAgICAgICBwYWNrZXRzIHJlY2VpdmVkIGZyb20gdGhpcyBEeW5hbWljIEF1 dGhvcml6YXRpb24NCiAgICAgICAgICAgICAgICAgQ2xpZW50LiBCYWQgYXV0aGVudGljYXRvcnMg YW5kIHVua25vd24gdHlwZXMgYXJlIG5vdA0KICAgICAgICAgICAgICAgICBpbmNsdWRlZCBhcyBt YWxmb3JtZWQgRGlzY29ubmVjdC1SZXF1ZXN0cy4gVGhpcyBjb3VudGVyDQogICAgICAgICAgICAg ICAgIG1heSBleHBlcmllbmNlIGEgZGlzY29udGludWl0eSB3aGVuIHRoZSBEQVMgbW9kdWxlDQog ICAgICAgICAgICAgICAgIChyZSlzdGFydHMgYXMgaW5kaWNhdGVkIGJ5IHRoZSB2YWx1ZSBvZg0K ICAgICAgICAgICAgICAgICByYWRpdXNEeW5BdXRoU2VydmVyQ291bnRlckRpc2NvbnRpbnVpdHku Ig0KICAgICAgICAgIFJFRkVSRU5DRQ0KICAgICAgICAgICAgICAgICJSRkMgMzU3NiwgU2VjdGlv biAyLjEsIERpc2Nvbm5lY3QgTWVzc2FnZXMgKERNKSwgYW5kDQogICAgICAgICAgICAgICAgIFNl Y3Rpb24gMi4zLCBQYWNrZXQgRm9ybWF0LiINCiAgICAgICAgICA6Oj0geyByYWRpdXNEeW5BdXRo Q2xpZW50RW50cnkgMTIgfQ0KDQogICByYWRpdXNEeW5BdXRoU2VydkRpc2NvbkJhZEF1dGhlbnRp Y2F0b3JzIE9CSkVDVC1UWVBFDQogICAgICAgICAgU1lOVEFYICAgICBDb3VudGVyMzINCiAgICAg ICAgICBVTklUUyAgICAgICJyZXF1ZXN0cyINCiAgICAgICAgICBNQVgtQUNDRVNTIHJlYWQtb25s eQ0KICAgICAgICAgIFNUQVRVUyAgICAgY3VycmVudA0KICAgICAgICAgIERFU0NSSVBUSU9ODQog ICAgICAgICAgICAgICAgIlRoZSBudW1iZXIgb2YgUkFESVVTIERpc2Nvbm5lY3QtUmVxdWVzdCBw YWNrZXRzDQogICAgICAgICAgICAgICAgIHdoaWNoIGNvbnRhaW5lZCBpbnZhbGlkIEF1dGhlbnRp Y2F0b3IgZmllbGQNCiAgICAgICAgICAgICAgICAgcmVjZWl2ZWQgZnJvbSB0aGlzIER5bmFtaWMg QXV0aG9yaXphdGlvbiBDbGllbnQuIFRoaXMNCiAgICAgICAgICAgICAgICAgY291bnRlciBtYXkg ZXhwZXJpZW5jZSBhIGRpc2NvbnRpbnVpdHkgd2hlbiB0aGUgREFTDQogICAgICAgICAgICAgICAg IG1vZHVsZSAocmUpc3RhcnRzIGFzIGluZGljYXRlZCBieSB0aGUgdmFsdWUgb2YNCiAgICAgICAg ICAgICAgICAgcmFkaXVzRHluQXV0aFNlcnZlckNvdW50ZXJEaXNjb250aW51aXR5LiINCiAgICAg ICAgICBSRUZFUkVOQ0UNCiAgICAgICAgICAgICAgICAiUkZDIDM1NzYsIFNlY3Rpb24gMi4xLCBE aXNjb25uZWN0IE1lc3NhZ2VzIChETSksIGFuZA0KICAgICAgICAgICAgICAgICBTZWN0aW9uIDIu MywgUGFja2V0IEZvcm1hdC4iDQogICAgICAgICAgOjo9IHsgcmFkaXVzRHluQXV0aENsaWVudEVu dHJ5IDEzIH0NCg0KICAgcmFkaXVzRHluQXV0aFNlcnZEaXNjb25QYWNrZXRzRHJvcHBlZCBPQkpF Q1QtVFlQRQ0KICAgICAgICAgIFNZTlRBWCAgICAgQ291bnRlcjMyDQogICAgICAgICAgVU5JVFMg ICAgICAicmVxdWVzdHMiDQogICAgICAgICAgTUFYLUFDQ0VTUyByZWFkLW9ubHkNCiAgICAgICAg ICBTVEFUVVMgICAgIGN1cnJlbnQNCiAgICAgICAgICBERVNDUklQVElPTg0KICAgICAgICAgICAg ICAgICJUaGUgbnVtYmVyIG9mIGluY29taW5nIERpc2Nvbm5lY3QtUmVxdWVzdHMNCiAgICAgICAg ICAgICAgICAgZnJvbSB0aGlzIER5bmFtaWMgQXV0aG9yaXphdGlvbiBDbGllbnQgc2lsZW50bHkN CiAgICAgICAgICAgICAgICAgZGlzY2FyZGVkIGJ5IHRoZSBzZXJ2ZXIgYXBwbGljYXRpb24gZm9y IHNvbWUgcmVhc29uDQogICAgICAgICAgICAgICAgIG90aGVyIHRoYW4gbWFsZm9ybWVkLCBiYWQg YXV0aGVudGljYXRvcnMgb3IgdW5rbm93bg0KICAgICAgICAgICAgICAgICB0eXBlcy4gVGhpcyBj b3VudGVyIG1heSBleHBlcmllbmNlIGEgZGlzY29udGludWl0eQ0KICAgICAgICAgICAgICAgICB3 aGVuIHRoZSBEQVMgbW9kdWxlIChyZSlzdGFydHMgYXMgaW5kaWNhdGVkIGJ5IHRoZQ0KICAgICAg ICAgICAgICAgICB2YWx1ZSBvZiByYWRpdXNEeW5BdXRoU2VydmVyQ291bnRlckRpc2NvbnRpbnVp dHkuIg0KICAgICAgICAgIFJFRkVSRU5DRQ0KICAgICAgICAgICAgICAgICJSRkMgMzU3NiwgU2Vj dGlvbiAyLjEsIERpc2Nvbm5lY3QgTWVzc2FnZXMgKERNKSwgYW5kDQogICAgICAgICAgICAgICAg IFNlY3Rpb24gMi4zLCBQYWNrZXQgRm9ybWF0LiINCiAgICAgICAgICA6Oj0geyByYWRpdXNEeW5B dXRoQ2xpZW50RW50cnkgMTQgfQ0KDQoNCg0KDQpEZSBDbm9kZGVyLCBldCBhbC4gICAgIEV4cGly ZXMgU2VwdGVtYmVyIDIzLCAyMDA2ICAgICAgICAgICAgICBbUGFnZSAxNF0NCgwNCkludGVybmV0 LURyYWZ0ICAgICAgRHluYW1pYyBBdXRob3JpemF0aW9uIFNlcnZlciBNSUIgICAgICAgICAgTWFy Y2ggMjAwNg0KDQoNCiAgIHJhZGl1c0R5bkF1dGhTZXJ2Q29BUmVxdWVzdHMgT0JKRUNULVRZUEUN CiAgICAgICAgICBTWU5UQVggICAgIENvdW50ZXIzMg0KICAgICAgICAgIFVOSVRTICAgICAgInJl cXVlc3RzIg0KICAgICAgICAgIE1BWC1BQ0NFU1MgcmVhZC1vbmx5DQogICAgICAgICAgU1RBVFVT ICAgICBjdXJyZW50DQogICAgICAgICAgREVTQ1JJUFRJT04NCiAgICAgICAgICAgICAgICAiVGhl IG51bWJlciBvZiBSQURJVVMgQ29BLXJlcXVlc3RzIHJlY2VpdmVkIGZyb20gdGhpcw0KICAgICAg ICAgICAgICAgICBEeW5hbWljIEF1dGhvcml6YXRpb24gQ2xpZW50LiBUaGlzIGFsc28gaW5jbHVk ZXMNCiAgICAgICAgICAgICAgICAgdGhlIENvQSByZXF1ZXN0cyB0aGF0IGhhdmUgYSBTZXJ2aWNl LVR5cGUgYXR0cmlidXRlDQogICAgICAgICAgICAgICAgIHdpdGggdmFsdWUgJ0F1dGhvcml6ZSBP bmx5Jy4gVGhpcyBjb3VudGVyIG1heQ0KICAgICAgICAgICAgICAgICBleHBlcmllbmNlIGEgZGlz Y29udGludWl0eSB3aGVuIHRoZSBEQVMgbW9kdWxlDQogICAgICAgICAgICAgICAgIChyZSlzdGFy dHMgYXMgaW5kaWNhdGVkIGJ5IHRoZSB2YWx1ZSBvZg0KICAgICAgICAgICAgICAgICByYWRpdXNE eW5BdXRoU2VydmVyQ291bnRlckRpc2NvbnRpbnVpdHkuIg0KICAgICAgICAgIFJFRkVSRU5DRQ0K ICAgICAgICAgICAgICAgICJSRkMgMzU3NiwgU2VjdGlvbiAyLjIsIENoYW5nZS1vZi1BdXRob3Jp emF0aW9uDQogICAgICAgICAgICAgICAgIE1lc3NhZ2VzIChDb0EpLiINCiAgICAgICAgICA6Oj0g eyByYWRpdXNEeW5BdXRoQ2xpZW50RW50cnkgMTUgfQ0KDQogICByYWRpdXNEeW5BdXRoU2VydkNv QUF1dGhPbmx5UmVxdWVzdHMgT0JKRUNULVRZUEUNCiAgICAgICAgICBTWU5UQVggICAgIENvdW50 ZXIzMg0KICAgICAgICAgIFVOSVRTICAgICAgInJlcXVlc3RzIg0KICAgICAgICAgIE1BWC1BQ0NF U1MgcmVhZC1vbmx5DQogICAgICAgICAgU1RBVFVTICAgICBjdXJyZW50DQogICAgICAgICAgREVT Q1JJUFRJT04NCiAgICAgICAgICAgICAgICAiVGhlIG51bWJlciBvZiBSQURJVVMgQ29BLXJlcXVl c3RzIHRoYXQgaW5jbHVkZSBhDQogICAgICAgICAgICAgICAgIFNlcnZpY2UtVHlwZSBhdHRyaWJ1 dGUgd2l0aCB2YWx1ZSAnQXV0aG9yaXplIE9ubHknDQogICAgICAgICAgICAgICAgIHJlY2VpdmVk IGZyb20gdGhpcyBEeW5hbWljIEF1dGhvcml6YXRpb24gQ2xpZW50LiBUaGlzDQogICAgICAgICAg ICAgICAgIGNvdW50ZXIgbWF5IGV4cGVyaWVuY2UgYSBkaXNjb250aW51aXR5IHdoZW4gdGhlIERB Uw0KICAgICAgICAgICAgICAgICBtb2R1bGUgKHJlKXN0YXJ0cyBhcyBpbmRpY2F0ZWQgYnkgdGhl IHZhbHVlIG9mDQogICAgICAgICAgICAgICAgIHJhZGl1c0R5bkF1dGhTZXJ2ZXJDb3VudGVyRGlz Y29udGludWl0eS4iDQogICAgICAgICAgUkVGRVJFTkNFDQogICAgICAgICAgICAgICAgIlJGQyAz NTc2LCBTZWN0aW9uIDIuMiwgQ2hhbmdlLW9mLUF1dGhvcml6YXRpb24NCiAgICAgICAgICAgICAg ICAgTWVzc2FnZXMgKENvQSkuIg0KICAgICAgICAgIDo6PSB7IHJhZGl1c0R5bkF1dGhDbGllbnRF bnRyeSAxNiB9DQoNCg0KICAgcmFkaXVzRHluQXV0aFNlcnZEdXBDb0FSZXF1ZXN0cyBPQkpFQ1Qt VFlQRQ0KICAgICAgICAgIFNZTlRBWCAgICAgQ291bnRlcjMyDQogICAgICAgICAgVU5JVFMgICAg ICAicmVxdWVzdHMiDQogICAgICAgICAgTUFYLUFDQ0VTUyByZWFkLW9ubHkNCiAgICAgICAgICBT VEFUVVMgICAgIGN1cnJlbnQNCiAgICAgICAgICBERVNDUklQVElPTg0KICAgICAgICAgICAgICAg ICJUaGUgbnVtYmVyIG9mIGR1cGxpY2F0ZSBSQURJVVMgQ29BLVJlcXVlc3QgcGFja2V0cw0KICAg ICAgICAgICAgICAgICByZWNlaXZlZCBmcm9tIHRoaXMgRHluYW1pYyBBdXRob3JpemF0aW9uIENs aWVudC4gVGhpcw0KICAgICAgICAgICAgICAgICBjb3VudGVyIG1heSBleHBlcmllbmNlIGEgZGlz Y29udGludWl0eSB3aGVuIHRoZSBEQVMNCiAgICAgICAgICAgICAgICAgbW9kdWxlIChyZSlzdGFy dHMgYXMgaW5kaWNhdGVkIGJ5IHRoZSB2YWx1ZSBvZg0KICAgICAgICAgICAgICAgICByYWRpdXNE eW5BdXRoU2VydmVyQ291bnRlckRpc2NvbnRpbnVpdHkuIg0KICAgICAgICAgIFJFRkVSRU5DRQ0K DQoNCg0KRGUgQ25vZGRlciwgZXQgYWwuICAgICBFeHBpcmVzIFNlcHRlbWJlciAyMywgMjAwNiAg ICAgICAgICAgICAgW1BhZ2UgMTVdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgIER5bmFtaWMgQXV0 aG9yaXphdGlvbiBTZXJ2ZXIgTUlCICAgICAgICAgIE1hcmNoIDIwMDYNCg0KDQogICAgICAgICAg ICAgICAgIlJGQyAzNTc2LCBTZWN0aW9uIDIuMiwgQ2hhbmdlLW9mLUF1dGhvcml6YXRpb24NCiAg ICAgICAgICAgICAgICAgTWVzc2FnZXMgKENvQSkuIg0KICAgICAgICAgIDo6PSB7IHJhZGl1c0R5 bkF1dGhDbGllbnRFbnRyeSAxNyB9DQoNCiAgIHJhZGl1c0R5bkF1dGhTZXJ2Q29BQWNrcyAgT0JK RUNULVRZUEUNCiAgICAgICAgICBTWU5UQVggICAgIENvdW50ZXIzMg0KICAgICAgICAgIFVOSVRT ICAgICAgInJlcGxpZXMiDQogICAgICAgICAgTUFYLUFDQ0VTUyByZWFkLW9ubHkNCiAgICAgICAg ICBTVEFUVVMgICAgIGN1cnJlbnQNCiAgICAgICAgICBERVNDUklQVElPTg0KICAgICAgICAgICAg ICAgICJUaGUgbnVtYmVyIG9mIFJBRElVUyBDb0EtQUNLIHBhY2tldHMgc2VudCB0byB0aGlzDQog ICAgICAgICAgICAgICAgIER5bmFtaWMgQXV0aG9yaXphdGlvbiBDbGllbnQuIFRoaXMgY291bnRl ciBtYXkNCiAgICAgICAgICAgICAgICAgZXhwZXJpZW5jZSBhIGRpc2NvbnRpbnVpdHkgd2hlbiB0 aGUgREFTIG1vZHVsZQ0KICAgICAgICAgICAgICAgICAocmUpc3RhcnRzIGFzIGluZGljYXRlZCBi eSB0aGUgdmFsdWUgb2YNCiAgICAgICAgICAgICAgICAgcmFkaXVzRHluQXV0aFNlcnZlckNvdW50 ZXJEaXNjb250aW51aXR5LiINCiAgICAgICAgICBSRUZFUkVOQ0UNCiAgICAgICAgICAgICAgICAi UkZDIDM1NzYsIFNlY3Rpb24gMi4yLCBDaGFuZ2Utb2YtQXV0aG9yaXphdGlvbg0KICAgICAgICAg ICAgICAgICBNZXNzYWdlcyAoQ29BKS4iDQogICAgICAgICAgOjo9IHsgcmFkaXVzRHluQXV0aENs aWVudEVudHJ5IDE4IH0NCg0KICAgcmFkaXVzRHluQXV0aFNlcnZDb0FOYWtzIE9CSkVDVC1UWVBF DQogICAgICAgICAgU1lOVEFYICAgICBDb3VudGVyMzINCiAgICAgICAgICBVTklUUyAgICAgICJy ZXBsaWVzIg0KICAgICAgICAgIE1BWC1BQ0NFU1MgcmVhZC1vbmx5DQogICAgICAgICAgU1RBVFVT ICAgICBjdXJyZW50DQogICAgICAgICAgREVTQ1JJUFRJT04NCiAgICAgICAgICAgICAgICAiVGhl IG51bWJlciBvZiBSQURJVVMgQ29BLU5BSyBwYWNrZXRzIHNlbnQgdG8NCiAgICAgICAgICAgICAg ICAgdGhpcyBEeW5hbWljIEF1dGhvcml6YXRpb24gQ2xpZW50LiBUaGlzIGluY2x1ZGVzDQogICAg ICAgICAgICAgICAgIHRoZSBSQURJVVMgQ29BLU5BSyBwYWNrZXRzIHNlbnQgd2l0aCBhIFNlcnZp Y2UtVHlwZQ0KICAgICAgICAgICAgICAgICBhdHRyaWJ1dGUgd2l0aCB2YWx1ZSAnQXV0aG9yaXpl IE9ubHknIGFuZCB0aGUgUkFESVVTDQogICAgICAgICAgICAgICAgIENvQS1OQUsgcGFja2V0cyBz ZW50IGJlY2F1c2Ugbm8gc2Vzc2lvbiBjb250ZXh0IHdhcw0KICAgICAgICAgICAgICAgICBmb3Vu ZC4gVGhpcyBjb3VudGVyIG1heSBleHBlcmllbmNlIGEgZGlzY29udGludWl0eQ0KICAgICAgICAg ICAgICAgICB3aGVuIHRoZSBEQVMgbW9kdWxlIChyZSlzdGFydHMgYXMgaW5kaWNhdGVkIGJ5IHRo ZQ0KICAgICAgICAgICAgICAgICB2YWx1ZSBvZiByYWRpdXNEeW5BdXRoU2VydmVyQ291bnRlckRp c2NvbnRpbnVpdHkuIg0KICAgICAgICAgIFJFRkVSRU5DRQ0KICAgICAgICAgICAgICAgICJSRkMg MzU3NiwgU2VjdGlvbiAyLjIsIENoYW5nZS1vZi1BdXRob3JpemF0aW9uDQogICAgICAgICAgICAg ICAgIE1lc3NhZ2VzIChDb0EpLiINCiAgICAgICAgICA6Oj0geyByYWRpdXNEeW5BdXRoQ2xpZW50 RW50cnkgMTkgfQ0KDQogICByYWRpdXNEeW5BdXRoU2VydkNvQU5ha0F1dGhPbmx5UmVxdWVzdHMg T0JKRUNULVRZUEUNCiAgICAgICAgICBTWU5UQVggICAgIENvdW50ZXIzMg0KICAgICAgICAgIFVO SVRTICAgICAgInJlcGxpZXMiDQogICAgICAgICAgTUFYLUFDQ0VTUyByZWFkLW9ubHkNCiAgICAg ICAgICBTVEFUVVMgICAgIGN1cnJlbnQNCiAgICAgICAgICBERVNDUklQVElPTg0KICAgICAgICAg ICAgICAgICJUaGUgbnVtYmVyIG9mIFJBRElVUyBDb0EtTkFLIHBhY2tldHMgdGhhdCBpbmNsdWRl IGENCiAgICAgICAgICAgICAgICAgU2VydmljZS1UeXBlIGF0dHJpYnV0ZSB3aXRoIHZhbHVlICdB dXRob3JpemUgT25seScNCiAgICAgICAgICAgICAgICAgc2VudCB0byB0aGlzIER5bmFtaWMgQXV0 aG9yaXphdGlvbiBDbGllbnQuIFRoaXMgY291bnRlcg0KDQoNCg0KRGUgQ25vZGRlciwgZXQgYWwu ICAgICBFeHBpcmVzIFNlcHRlbWJlciAyMywgMjAwNiAgICAgICAgICAgICAgW1BhZ2UgMTZdDQoM DQpJbnRlcm5ldC1EcmFmdCAgICAgIER5bmFtaWMgQXV0aG9yaXphdGlvbiBTZXJ2ZXIgTUlCICAg ICAgICAgIE1hcmNoIDIwMDYNCg0KDQogICAgICAgICAgICAgICAgIG1heSBleHBlcmllbmNlIGEg ZGlzY29udGludWl0eSB3aGVuIHRoZSBEQVMgbW9kdWxlDQogICAgICAgICAgICAgICAgIChyZSlz dGFydHMgYXMgaW5kaWNhdGVkIGJ5IHRoZSB2YWx1ZSBvZg0KICAgICAgICAgICAgICAgICByYWRp dXNEeW5BdXRoU2VydmVyQ291bnRlckRpc2NvbnRpbnVpdHkuIg0KICAgICAgICAgIFJFRkVSRU5D RQ0KICAgICAgICAgICAgICAgICJSRkMgMzU3NiwgU2VjdGlvbiAyLjIsIENoYW5nZS1vZi1BdXRo b3JpemF0aW9uDQogICAgICAgICAgICAgICAgIE1lc3NhZ2VzIChDb0EpLiINCiAgICAgICAgICA6 Oj0geyByYWRpdXNEeW5BdXRoQ2xpZW50RW50cnkgMjAgfQ0KDQogICByYWRpdXNEeW5BdXRoU2Vy dkNvQU5ha1Nlc3NOb0NvbnRleHQgT0JKRUNULVRZUEUNCiAgICAgICAgICBTWU5UQVggICAgIENv dW50ZXIzMg0KICAgICAgICAgIFVOSVRTICAgICAgInJlcGxpZXMiDQogICAgICAgICAgTUFYLUFD Q0VTUyByZWFkLW9ubHkNCiAgICAgICAgICBTVEFUVVMgICAgIGN1cnJlbnQNCiAgICAgICAgICBE RVNDUklQVElPTg0KICAgICAgICAgICAgICAgICJUaGUgbnVtYmVyIG9mIFJBRElVUyBDb0EtTkFL IHBhY2tldHMgc2VudCB0byB0aGlzDQogICAgICAgICAgICAgICAgIER5bmFtaWMgQXV0aG9yaXph dGlvbiBDbGllbnQgYmVjYXVzZSBubyBzZXNzaW9uIGNvbnRleHQNCiAgICAgICAgICAgICAgICAg d2FzIGZvdW5kLiBUaGlzIGNvdW50ZXIgbWF5IGV4cGVyaWVuY2UgYSBkaXNjb250aW51aXR5DQog ICAgICAgICAgICAgICAgIHdoZW4gdGhlIERBUyBtb2R1bGUgKHJlKXN0YXJ0cyBhcyBpbmRpY2F0 ZWQgYnkgdGhlDQogICAgICAgICAgICAgICAgIHZhbHVlIG9mIHJhZGl1c0R5bkF1dGhTZXJ2ZXJD b3VudGVyRGlzY29udGludWl0eS4iDQogICAgICAgICAgUkVGRVJFTkNFDQogICAgICAgICAgICAg ICAgIlJGQyAzNTc2LCBTZWN0aW9uIDIuMiwgQ2hhbmdlLW9mLUF1dGhvcml6YXRpb24NCiAgICAg ICAgICAgICAgICAgTWVzc2FnZXMgKENvQSkuIg0KICAgICAgICAgIDo6PSB7IHJhZGl1c0R5bkF1 dGhDbGllbnRFbnRyeSAyMSB9DQoNCiAgIHJhZGl1c0R5bkF1dGhTZXJ2Q29BVXNlclNlc3NDaGFu Z2VkIE9CSkVDVC1UWVBFDQogICAgICAgICAgU1lOVEFYICAgICBDb3VudGVyMzINCiAgICAgICAg ICBVTklUUyAgICAgICJzZXNzaW9ucyINCiAgICAgICAgICBNQVgtQUNDRVNTIHJlYWQtb25seQ0K ICAgICAgICAgIFNUQVRVUyAgICAgY3VycmVudA0KICAgICAgICAgIERFU0NSSVBUSU9ODQogICAg ICAgICAgICAgICAgIlRoZSBudW1iZXIgb2YgdXNlciBzZXNzaW9ucyBhdXRob3JpemF0aW9uDQog ICAgICAgICAgICAgICAgIGNoYW5nZWQgZm9yIHRoZSBDb0EtUmVxdWVzdHMgcmVjZWl2ZWQgZnJv bSB0aGlzDQogICAgICAgICAgICAgICAgIER5bmFtaWMgQXV0aG9yaXphdGlvbiBDbGllbnQuIERl cGVuZGluZyBvbiBzaXRlDQogICAgICAgICAgICAgICAgIHNwZWNpZmljIHBvbGljaWVzLCBhIHNp bmdsZSBDb0EgcmVxdWVzdCBjYW4gY2hhbmdlDQogICAgICAgICAgICAgICAgIG11bHRpcGxlIHVz ZXIgc2Vzc2lvbnMnIGF1dGhvcml6YXRpb24uICBJbiB0aGUgY2FzZQ0KICAgICAgICAgICAgICAg ICB0aGlzIER5bmFtaWMgQXV0aG9yaXphdGlvbiBTZXJ2ZXIgaGFzIG5vIGtub3dsZWRnZSBvZg0K ICAgICAgICAgICAgICAgICB0aGUgbnVtYmVyIG9mIHVzZXIgc2Vzc2lvbnMgdGhhdCBhcmUgYWZm ZWN0ZWQgYnkgYQ0KICAgICAgICAgICAgICAgICBzaW5nbGUgcmVxdWVzdCwgZm9yIGVhY2ggc3Vj aCBDb0EtUmVxdWVzdCwgaXQgd2lsbA0KICAgICAgICAgICAgICAgICBjb3VudCBhcyBhIHNpbmds ZSBhZmZlY3RlZCB1c2VyIHNlc3Npb24gb25seS4gVGhpcw0KICAgICAgICAgICAgICAgICBjb3Vu dGVyIG1heSBleHBlcmllbmNlIGEgZGlzY29udGludWl0eSB3aGVuIHRoZSBEQVMNCiAgICAgICAg ICAgICAgICAgbW9kdWxlIChyZSlzdGFydHMgYXMgaW5kaWNhdGVkIGJ5IHRoZSB2YWx1ZSBvZg0K ICAgICAgICAgICAgICAgICByYWRpdXNEeW5BdXRoU2VydmVyQ291bnRlckRpc2NvbnRpbnVpdHku Ig0KICAgICAgICAgIFJFRkVSRU5DRQ0KICAgICAgICAgICAgICAgICJSRkMgMzU3NiwgU2VjdGlv biAyLjIsIENoYW5nZS1vZi1BdXRob3JpemF0aW9uDQogICAgICAgICAgICAgICAgIE1lc3NhZ2Vz IChDb0EpLiINCiAgICAgICAgICA6Oj0geyByYWRpdXNEeW5BdXRoQ2xpZW50RW50cnkgMjIgfQ0K DQogICByYWRpdXNEeW5BdXRoU2Vydk1hbGZvcm1lZENvQVJlcXVlc3RzIE9CSkVDVC1UWVBFDQoN Cg0KDQpEZSBDbm9kZGVyLCBldCBhbC4gICAgIEV4cGlyZXMgU2VwdGVtYmVyIDIzLCAyMDA2ICAg ICAgICAgICAgICBbUGFnZSAxN10NCgwNCkludGVybmV0LURyYWZ0ICAgICAgRHluYW1pYyBBdXRo b3JpemF0aW9uIFNlcnZlciBNSUIgICAgICAgICAgTWFyY2ggMjAwNg0KDQoNCiAgICAgICAgICBT WU5UQVggICAgIENvdW50ZXIzMg0KICAgICAgICAgIFVOSVRTICAgICAgInJlcXVlc3RzIg0KICAg ICAgICAgIE1BWC1BQ0NFU1MgcmVhZC1vbmx5DQogICAgICAgICAgU1RBVFVTICAgICBjdXJyZW50 DQogICAgICAgICAgREVTQ1JJUFRJT04NCiAgICAgICAgICAgICAgICAiVGhlIG51bWJlciBvZiBt YWxmb3JtZWQgUkFESVVTIENvQS1SZXF1ZXN0IHBhY2tldHMNCiAgICAgICAgICAgICAgICAgcmVj ZWl2ZWQgZnJvbSB0aGlzIER5bmFtaWMgQXV0aG9yaXphdGlvbiBDbGllbnQuIEJhZA0KICAgICAg ICAgICAgICAgICBhdXRoZW50aWNhdG9ycyBhbmQgdW5rbm93biB0eXBlcyBhcmUgbm90IGluY2x1 ZGVkIGFzDQogICAgICAgICAgICAgICAgIG1hbGZvcm1lZCBDb0EtUmVxdWVzdHMuIFRoaXMgY291 bnRlciBtYXkgZXhwZXJpZW5jZSBhDQogICAgICAgICAgICAgICAgIGRpc2NvbnRpbnVpdHkgd2hl biB0aGUgREFTIG1vZHVsZSAocmUpc3RhcnRzIGFzDQogICAgICAgICAgICAgICAgIGluZGljYXRl ZCBieSB0aGUgdmFsdWUgb2YNCiAgICAgICAgICAgICAgICAgcmFkaXVzRHluQXV0aFNlcnZlckNv dW50ZXJEaXNjb250aW51aXR5LiINCiAgICAgICAgICBSRUZFUkVOQ0UNCiAgICAgICAgICAgICAg ICAiUkZDIDM1NzYsIFNlY3Rpb24gMi4yLCBDaGFuZ2Utb2YtQXV0aG9yaXphdGlvbg0KICAgICAg ICAgICAgICAgICBNZXNzYWdlcyAoQ29BKSwgYW5kIFNlY3Rpb24gMi4zLCBQYWNrZXQgRm9ybWF0 LiINCiAgICAgICAgICA6Oj0geyByYWRpdXNEeW5BdXRoQ2xpZW50RW50cnkgIDIzIH0NCg0KICAg cmFkaXVzRHluQXV0aFNlcnZDb0FCYWRBdXRoZW50aWNhdG9ycyBPQkpFQ1QtVFlQRQ0KICAgICAg ICAgIFNZTlRBWCAgICAgQ291bnRlcjMyDQogICAgICAgICAgVU5JVFMgICAgICAicmVxdWVzdHMi DQogICAgICAgICAgTUFYLUFDQ0VTUyByZWFkLW9ubHkNCiAgICAgICAgICBTVEFUVVMgICAgIGN1 cnJlbnQNCiAgICAgICAgICBERVNDUklQVElPTg0KICAgICAgICAgICAgICAgICJUaGUgbnVtYmVy IG9mIFJBRElVUyBDb0EtUmVxdWVzdCBwYWNrZXRzIHdoaWNoDQogICAgICAgICAgICAgICAgIGNv bnRhaW5lZCBpbnZhbGlkIEF1dGhlbnRpY2F0b3IgZmllbGQgcmVjZWl2ZWQNCiAgICAgICAgICAg ICAgICAgZnJvbSB0aGlzIER5bmFtaWMgQXV0aG9yaXphdGlvbiBDbGllbnQuIFRoaXMgY291bnRl cg0KICAgICAgICAgICAgICAgICBtYXkgZXhwZXJpZW5jZSBhIGRpc2NvbnRpbnVpdHkgd2hlbiB0 aGUgREFTIG1vZHVsZQ0KICAgICAgICAgICAgICAgICAocmUpc3RhcnRzIGFzIGluZGljYXRlZCBi eSB0aGUgdmFsdWUgb2YNCiAgICAgICAgICAgICAgICAgICByYWRpdXNEeW5BdXRoU2VydmVyQ291 bnRlckRpc2NvbnRpbnVpdHkuIg0KICAgICAgICAgIFJFRkVSRU5DRQ0KICAgICAgICAgICAgICAg ICJSRkMgMzU3NiwgU2VjdGlvbiAyLjIsIENoYW5nZS1vZi1BdXRob3JpemF0aW9uDQogICAgICAg ICAgICAgICAgIE1lc3NhZ2VzIChDb0EpLCBhbmQgU2VjdGlvbiAyLjMsIFBhY2tldCBGb3JtYXQu Ig0KICAgICAgICAgIDo6PSB7IHJhZGl1c0R5bkF1dGhDbGllbnRFbnRyeSAyNCB9DQoNCiAgIHJh ZGl1c0R5bkF1dGhTZXJ2Q29BUGFja2V0c0Ryb3BwZWQgT0JKRUNULVRZUEUNCiAgICAgICAgICBT WU5UQVggICAgIENvdW50ZXIzMg0KICAgICAgICAgIFVOSVRTICAgICAgInJlcXVlc3RzIg0KICAg ICAgICAgIE1BWC1BQ0NFU1MgcmVhZC1vbmx5DQogICAgICAgICAgU1RBVFVTICAgICBjdXJyZW50 DQogICAgICAgICAgREVTQ1JJUFRJT04NCiAgICAgICAgICAgICAgICAiVGhlIG51bWJlciBvZiBp bmNvbWluZyBDb0EgcGFja2V0cyBmcm9tIHRoaXMNCiAgICAgICAgICAgICAgICAgRHluYW1pYyBB dXRob3JpemF0aW9uIENsaWVudCBzaWxlbnRseSBkaXNjYXJkZWQNCiAgICAgICAgICAgICAgICAg YnkgdGhlIHNlcnZlciBhcHBsaWNhdGlvbiBmb3Igc29tZSByZWFzb24gb3RoZXIgdGhhbg0KICAg ICAgICAgICAgICAgICBtYWxmb3JtZWQsIGJhZCBhdXRoZW50aWNhdG9ycyBvciB1bmtub3duIHR5 cGVzLiBUaGlzDQogICAgICAgICAgICAgICAgIGNvdW50ZXIgbWF5IGV4cGVyaWVuY2UgYSBkaXNj b250aW51aXR5IHdoZW4gdGhlIERBUw0KICAgICAgICAgICAgICAgICBtb2R1bGUgKHJlKXN0YXJ0 cyBhcyBpbmRpY2F0ZWQgYnkgdGhlIHZhbHVlIG9mDQogICAgICAgICAgICAgICAgIHJhZGl1c0R5 bkF1dGhTZXJ2ZXJDb3VudGVyRGlzY29udGludWl0eS4iDQogICAgICAgICAgUkVGRVJFTkNFDQoN Cg0KDQpEZSBDbm9kZGVyLCBldCBhbC4gICAgIEV4cGlyZXMgU2VwdGVtYmVyIDIzLCAyMDA2ICAg ICAgICAgICAgICBbUGFnZSAxOF0NCgwNCkludGVybmV0LURyYWZ0ICAgICAgRHluYW1pYyBBdXRo b3JpemF0aW9uIFNlcnZlciBNSUIgICAgICAgICAgTWFyY2ggMjAwNg0KDQoNCiAgICAgICAgICAg ICAgICAiUkZDIDM1NzYsIFNlY3Rpb24gMi4yLCBDaGFuZ2Utb2YtQXV0aG9yaXphdGlvbg0KICAg ICAgICAgICAgICAgICBNZXNzYWdlcyAoQ29BKSwgYW5kIFNlY3Rpb24gMi4zLCBQYWNrZXQgRm9y bWF0LiINCiAgICAgICAgICA6Oj0geyByYWRpdXNEeW5BdXRoQ2xpZW50RW50cnkgMjUgfQ0KDQog ICByYWRpdXNEeW5BdXRoU2VydlVua25vd25UeXBlcyBPQkpFQ1QtVFlQRQ0KICAgICAgICAgIFNZ TlRBWCAgICAgQ291bnRlcjMyDQogICAgICAgICAgVU5JVFMgICAgICAicmVxdWVzdHMiDQogICAg ICAgICAgTUFYLUFDQ0VTUyByZWFkLW9ubHkNCiAgICAgICAgICBTVEFUVVMgICAgIGN1cnJlbnQN CiAgICAgICAgICBERVNDUklQVElPTg0KICAgICAgICAgICAgICAgICJUaGUgbnVtYmVyIG9mIGlu Y29taW5nIHBhY2tldHMgb2YgdW5rbm93biB0eXBlcyB3aGljaA0KICAgICAgICAgICAgICAgICB3 ZXJlIHJlY2VpdmVkIG9uIHRoZSBEeW5hbWljIEF1dGhvcml6YXRpb24gcG9ydC4gVGhpcw0KICAg ICAgICAgICAgICAgICBjb3VudGVyIG1heSBleHBlcmllbmNlIGEgZGlzY29udGludWl0eSB3aGVu IHRoZSBEQVMNCiAgICAgICAgICAgICAgICAgbW9kdWxlIChyZSlzdGFydHMgYXMgaW5kaWNhdGVk IGJ5IHRoZSB2YWx1ZSBvZg0KICAgICAgICAgICAgICAgICByYWRpdXNEeW5BdXRoU2VydmVyQ291 bnRlckRpc2NvbnRpbnVpdHkuIg0KICAgICAgICAgIFJFRkVSRU5DRQ0KICAgICAgICAgICAgICAg ICJSRkMgMzU3NiwgU2VjdGlvbiAyLjMsIFBhY2tldCBGb3JtYXQuIg0KICAgICAgICAgIDo6PSB7 IHJhZGl1c0R5bkF1dGhDbGllbnRFbnRyeSAyNiB9DQoNCiAgIC0tIGNvbmZvcm1hbmNlIGluZm9y bWF0aW9uDQoNCiAgIHJhZGl1c0R5bkF1dGhTZXJ2ZXJNSUJDb25mb3JtYW5jZQ0KICAgICAgICAg IE9CSkVDVCBJREVOVElGSUVSIDo6PSB7IHJhZGl1c0R5bkF1dGhTZXJ2ZXJNSUIgMiB9DQogICBy YWRpdXNEeW5BdXRoU2VydmVyTUlCQ29tcGxpYW5jZXMNCiAgICAgICAgICBPQkpFQ1QgSURFTlRJ RklFUiA6Oj0geyByYWRpdXNEeW5BdXRoU2VydmVyTUlCQ29uZm9ybWFuY2UgMSB9DQogICByYWRp dXNEeW5BdXRoU2VydmVyTUlCR3JvdXBzDQogICAgICAgICAgT0JKRUNUIElERU5USUZJRVIgOjo9 IHsgcmFkaXVzRHluQXV0aFNlcnZlck1JQkNvbmZvcm1hbmNlIDIgfQ0KDQogICAtLSBjb21wbGlh bmNlIHN0YXRlbWVudHMNCg0KICAgcmFkaXVzQXV0aFNlcnZlck1JQkNvbXBsaWFuY2UgTU9EVUxF LUNPTVBMSUFOQ0UNCiAgICAgICAgICBTVEFUVVMgIGN1cnJlbnQNCiAgICAgICAgICBERVNDUklQ VElPTg0KICAgICAgICAgICAgICAgICJUaGUgY29tcGxpYW5jZSBzdGF0ZW1lbnQgZm9yIGVudGl0 aWVzIGltcGxlbWVudGluZw0KICAgICAgICAgICAgICAgICB0aGUgUkFESVVTIER5bmFtaWMgQXV0 aG9yaXphdGlvbiBTZXJ2ZXIuIEltcGxlbWVudGF0aW9uDQogICAgICAgICAgICAgICAgIG9mIHRo aXMgbW9kdWxlIGlzIGZvciBlbnRpdGllcyB0aGF0IHN1cHBvcnQgSVB2Niwgb3INCiAgICAgICAg ICAgICAgICAgc3VwcG9ydCBJUHY0IGFuZCBJUHY2LiINCiAgICAgICAgICBNT0RVTEUgIC0tIHRo aXMgbW9kdWxlDQogICAgICAgICAgTUFOREFUT1JZLUdST1VQUyB7IHJhZGl1c0R5bkF1dGhTZXJ2 ZXJNSUJHcm91cCB9DQoNCiAgICAgICAgICBPQkpFQ1QgICAgICAgICAgICAgcmFkaXVzRHluQXV0 aENsaWVudEFkZHJlc3NUeXBlDQogICAgICAgICAgU1lOVEFYICAgICAgICAgICAgIEluZXRBZGRy ZXNzVHlwZSB7IGlwdjQoMSksIGlwdjYoMikgfQ0KICAgICAgICAgIERFU0NSSVBUSU9ODQogICAg ICAgICAgICAgICJBbiBpbXBsZW1lbnRhdGlvbiBpcyBvbmx5IHJlcXVpcmVkIHRvIHN1cHBvcnQg SVB2NCBhbmQNCiAgICAgICAgICAgICAgIGdsb2JhbGx5IHVuaXF1ZSBJUHY2IGFkZHJlc3Nlcy4i DQoNCiAgICAgICAgICBPQkpFQ1QgICAgICAgICAgICAgcmFkaXVzRHluQXV0aENsaWVudEFkZHJl c3MNCiAgICAgICAgICBTWU5UQVggICAgICAgICAgICAgSW5ldEFkZHJlc3MgKFNJWkUoNHwxNikp DQoNCg0KDQpEZSBDbm9kZGVyLCBldCBhbC4gICAgIEV4cGlyZXMgU2VwdGVtYmVyIDIzLCAyMDA2 ICAgICAgICAgICAgICBbUGFnZSAxOV0NCgwNCkludGVybmV0LURyYWZ0ICAgICAgRHluYW1pYyBB dXRob3JpemF0aW9uIFNlcnZlciBNSUIgICAgICAgICAgTWFyY2ggMjAwNg0KDQoNCiAgICAgICAg ICBERVNDUklQVElPTg0KICAgICAgICAgICAgICAiQW4gaW1wbGVtZW50YXRpb24gaXMgb25seSBy ZXF1aXJlZCB0byBzdXBwb3J0IElQdjQgYW5kDQogICAgICAgICAgICAgICBnbG9iYWxseSB1bmlx dWUgSVB2NiBhZGRyZXNzZXMuIg0KDQogICAgICAgICAgR1JPVVAgICAgICAgICAgICAgIHJhZGl1 c0R5bkF1dGhTZXJ2ZXJBdXRoT25seUdyb3VwDQogICAgICAgICAgREVTQ1JJUFRJT04NCiAgICAg ICAgICAgICAgICAiT25seSByZXF1aXJlZCBmb3IgRHluYW1pYyBBdXRob3JpemF0aW9uIENsaWVu dHMgdGhhdA0KICAgICAgICAgICAgICAgICBhcmUgc3VwcG9ydGluZyBTZXJ2aWNlLVR5cGUgYXR0 cmlidXRlcyB3aXRoIHZhbHVlDQogICAgICAgICAgICAgICAgICdBdXRob3JpemUtT25seScuIg0K DQoNCiAgICAgICAgICBHUk9VUCAgICAgICAgICAgICAgcmFkaXVzRHluQXV0aFNlcnZlck5vU2Vz c0dyb3VwDQogICAgICAgICAgREVTQ1JJUFRJT04NCiAgICAgICAgICAgICAgICAiVGhpcyBncm91 cCBpcyBub3QgcmVxdWlyZWQgaW4gY2FzZSB0aGUgRHluYW1pYw0KICAgICAgICAgICAgICAgICBB dXRob3JpemF0aW9uIFNlcnZlciBjYW4gbm90IGVhc2lseSBkZXRlcm1pbmUgd2hldGhlcg0KICAg ICAgICAgICAgICAgICBhIHNlc3Npb24gZXhpc3RzIG9yIG5vdCAoZS5nLiwgaW4gY2FzZSBvZiBh IFJBRElVUw0KICAgICAgICAgICAgICAgICBwcm94eSkuIg0KDQogICAgICAgICAgOjo9IHsgcmFk aXVzRHluQXV0aFNlcnZlck1JQkNvbXBsaWFuY2VzIDEgfQ0KDQogICAtLSB1bml0cyBvZiBjb25m b3JtYW5jZQ0KDQogICByYWRpdXNEeW5BdXRoU2VydmVyTUlCR3JvdXAgT0JKRUNULUdST1VQDQog ICAgICAgICAgT0JKRUNUUyB7IHJhZGl1c0R5bkF1dGhTZXJ2ZXJEaXNjb25JbnZhbGlkQ2xpZW50 QWRkcmVzc2VzLA0KICAgICAgICAgICAgICAgICAgICByYWRpdXNEeW5BdXRoU2VydmVyQ29BSW52 YWxpZENsaWVudEFkZHJlc3NlcywNCiAgICAgICAgICAgICAgICAgICAgcmFkaXVzRHluQXV0aFNl cnZlcklkZW50aWZpZXIsDQogICAgICAgICAgICAgICAgICAgIHJhZGl1c0R5bkF1dGhTZXJ2ZXJD b3VudGVyRGlzY29udGludWl0eSwNCiAgICAgICAgICAgICAgICAgICAgcmFkaXVzRHluQXV0aENs aWVudEFkZHJlc3NUeXBlLA0KICAgICAgICAgICAgICAgICAgICByYWRpdXNEeW5BdXRoQ2xpZW50 QWRkcmVzcywNCiAgICAgICAgICAgICAgICAgICAgcmFkaXVzRHluQXV0aFNlcnZEaXNjb25SZXF1 ZXN0cywNCiAgICAgICAgICAgICAgICAgICAgcmFkaXVzRHluQXV0aFNlcnZEdXBEaXNjb25SZXF1 ZXN0cywNCiAgICAgICAgICAgICAgICAgICAgcmFkaXVzRHluQXV0aFNlcnZEaXNjb25BY2tzLA0K ICAgICAgICAgICAgICAgICAgICByYWRpdXNEeW5BdXRoU2VydkRpc2Nvbk5ha3MsDQogICAgICAg ICAgICAgICAgICAgIHJhZGl1c0R5bkF1dGhTZXJ2RGlzY29uVXNlclNlc3NSZW1vdmVkLA0KICAg ICAgICAgICAgICAgICAgICByYWRpdXNEeW5BdXRoU2Vydk1hbGZvcm1lZERpc2NvblJlcXVlc3Rz LA0KICAgICAgICAgICAgICAgICAgICByYWRpdXNEeW5BdXRoU2VydkRpc2NvbkJhZEF1dGhlbnRp Y2F0b3JzLA0KICAgICAgICAgICAgICAgICAgICByYWRpdXNEeW5BdXRoU2VydkRpc2NvblBhY2tl dHNEcm9wcGVkLA0KICAgICAgICAgICAgICAgICAgICByYWRpdXNEeW5BdXRoU2VydkNvQVJlcXVl c3RzLA0KICAgICAgICAgICAgICAgICAgICByYWRpdXNEeW5BdXRoU2VydkR1cENvQVJlcXVlc3Rz LA0KICAgICAgICAgICAgICAgICAgICByYWRpdXNEeW5BdXRoU2VydkNvQUFja3MsDQogICAgICAg ICAgICAgICAgICAgIHJhZGl1c0R5bkF1dGhTZXJ2Q29BTmFrcywNCiAgICAgICAgICAgICAgICAg ICAgcmFkaXVzRHluQXV0aFNlcnZDb0FVc2VyU2Vzc0NoYW5nZWQsDQogICAgICAgICAgICAgICAg ICAgIHJhZGl1c0R5bkF1dGhTZXJ2TWFsZm9ybWVkQ29BUmVxdWVzdHMsDQogICAgICAgICAgICAg ICAgICAgIHJhZGl1c0R5bkF1dGhTZXJ2Q29BQmFkQXV0aGVudGljYXRvcnMsDQogICAgICAgICAg ICAgICAgICAgIHJhZGl1c0R5bkF1dGhTZXJ2Q29BUGFja2V0c0Ryb3BwZWQsDQogICAgICAgICAg ICAgICAgICAgIHJhZGl1c0R5bkF1dGhTZXJ2VW5rbm93blR5cGVzDQogICAgICAgICAgICAgICAg ICB9DQogICAgICAgICAgU1RBVFVTICBjdXJyZW50DQoNCg0KDQpEZSBDbm9kZGVyLCBldCBhbC4g ICAgIEV4cGlyZXMgU2VwdGVtYmVyIDIzLCAyMDA2ICAgICAgICAgICAgICBbUGFnZSAyMF0NCgwN CkludGVybmV0LURyYWZ0ICAgICAgRHluYW1pYyBBdXRob3JpemF0aW9uIFNlcnZlciBNSUIgICAg ICAgICAgTWFyY2ggMjAwNg0KDQoNCiAgICAgICAgICBERVNDUklQVElPTg0KICAgICAgICAgICAg ICAgICJUaGUgY29sbGVjdGlvbiBvZiBvYmplY3RzIHByb3ZpZGluZyBtYW5hZ2VtZW50IG9mDQog ICAgICAgICAgICAgICAgIGEgUkFESVVTIER5bmFtaWMgQXV0aG9yaXphdGlvbiBTZXJ2ZXIuIg0K ICAgICAgICAgIDo6PSB7IHJhZGl1c0R5bkF1dGhTZXJ2ZXJNSUJHcm91cHMgMSB9DQoNCiAgIHJh ZGl1c0R5bkF1dGhTZXJ2ZXJBdXRoT25seUdyb3VwIE9CSkVDVC1HUk9VUA0KICAgICAgICAgIE9C SkVDVFMgeyByYWRpdXNEeW5BdXRoU2VydkRpc2NvbkF1dGhPbmx5UmVxdWVzdHMsDQogICAgICAg ICAgICAgICAgICAgIHJhZGl1c0R5bkF1dGhTZXJ2RGlzY29uTmFrQXV0aE9ubHlSZXF1ZXN0cywN CiAgICAgICAgICAgICAgICAgICAgcmFkaXVzRHluQXV0aFNlcnZDb0FBdXRoT25seVJlcXVlc3Rz LA0KICAgICAgICAgICAgICAgICAgICByYWRpdXNEeW5BdXRoU2VydkNvQU5ha0F1dGhPbmx5UmVx dWVzdHMNCiAgICAgICAgICAgICAgICAgIH0NCiAgICAgICAgICBTVEFUVVMgIGN1cnJlbnQNCiAg ICAgICAgICBERVNDUklQVElPTg0KICAgICAgICAgICAgICAgICJUaGUgY29sbGVjdGlvbiBvZiBv YmplY3RzIHN1cHBvcnRpbmcgdGhlIFJBRElVUw0KICAgICAgICAgICAgICAgICBtZXNzYWdlcyBp bmNsdWRpbmcgU2VydmljZS1UeXBlIGF0dHJpYnV0ZSB3aXRoDQogICAgICAgICAgICAgICAgIHZh bHVlICdBdXRob3JpemUgT25seScuIg0KICAgICAgICAgIDo6PSB7IHJhZGl1c0R5bkF1dGhTZXJ2 ZXJNSUJHcm91cHMgMiB9DQoNCiAgIHJhZGl1c0R5bkF1dGhTZXJ2ZXJOb1Nlc3NHcm91cCBPQkpF Q1QtR1JPVVANCiAgICAgICAgICBPQkpFQ1RTIHsgcmFkaXVzRHluQXV0aFNlcnZEaXNjb25OYWtT ZXNzTm9Db250ZXh0LA0KICAgICAgICAgICAgICAgICAgICByYWRpdXNEeW5BdXRoU2VydkNvQU5h a1Nlc3NOb0NvbnRleHQNCiAgICAgICAgICAgICAgICAgIH0NCiAgICAgICAgICBTVEFUVVMgIGN1 cnJlbnQNCiAgICAgICAgICBERVNDUklQVElPTg0KICAgICAgICAgICAgICAgICJUaGUgY29sbGVj dGlvbiBvZiBvYmplY3RzIHN1cHBvcnRpbmcgdGhlIFJBRElVUw0KICAgICAgICAgICAgICAgICBt ZXNzYWdlcyB0aGF0IGFyZSByZWZlcnJpbmcgdG8gbm9uIGV4aXN0aW5nIHNlc3Npb25zLiINCiAg ICAgICAgICA6Oj0geyByYWRpdXNEeW5BdXRoU2VydmVyTUlCR3JvdXBzIDMgfQ0KDQoNCg0KICAg RU5EDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KRGUgQ25vZGRlciwg ZXQgYWwuICAgICBFeHBpcmVzIFNlcHRlbWJlciAyMywgMjAwNiAgICAgICAgICAgICAgW1BhZ2Ug MjFdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgIER5bmFtaWMgQXV0aG9yaXphdGlvbiBTZXJ2ZXIg TUlCICAgICAgICAgIE1hcmNoIDIwMDYNCg0KDQo1LiAgU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMN Cg0KICAgVGhlcmUgYXJlIG5vIG1hbmFnZW1lbnQgb2JqZWN0cyBkZWZpbmVkIGluIHRoaXMgTUlC IG1vZHVsZSB0aGF0IGhhdmUNCiAgIGEgTUFYLUFDQ0VTUyBjbGF1c2Ugb2YgcmVhZC13cml0ZSBh bmQvb3IgcmVhZC1jcmVhdGUuICBTbywgaWYgdGhpcw0KICAgTUlCIG1vZHVsZSBpcyBpbXBsZW1l bnRlZCBjb3JyZWN0bHksIHRoZW4gdGhlcmUgaXMgbm8gcmlzayB0aGF0IGFuDQogICBpbnRydWRl ciBjYW4gYWx0ZXIgb3IgY3JlYXRlIGFueSBtYW5hZ2VtZW50IG9iamVjdHMgb2YgdGhpcyBNSUIN CiAgIG1vZHVsZSB2aWEgZGlyZWN0IFNOTVAgU0VUIG9wZXJhdGlvbnMNCg0KICAgU29tZSBvZiB0 aGUgcmVhZGFibGUgb2JqZWN0cyBpbiB0aGlzIE1JQiBtb2R1bGUgKGkuZS4sIG9iamVjdHMgd2l0 aCBhDQogICBNQVgtQUNDRVNTIG90aGVyIHRoYW4gbm90LWFjY2Vzc2libGUpIG1heSBiZSBjb25z aWRlcmVkIHNlbnNpdGl2ZSBvcg0KICAgdnVsbmVyYWJsZSBpbiBzb21lIG5ldHdvcmsgZW52aXJv bm1lbnRzLiAgSXQgaXMgdGh1cyBpbXBvcnRhbnQgdG8NCiAgIGNvbnRyb2wgZXZlbiBHRVQgYW5k L29yIE5PVElGWSBhY2Nlc3MgdG8gdGhlc2Ugb2JqZWN0cyBhbmQgcG9zc2libHkNCiAgIHRvIGV2 ZW4gZW5jcnlwdCB0aGUgdmFsdWVzIG9mIHRoZXNlIG9iamVjdHMgd2hlbiBzZW5kaW5nIHRoZW0g b3Zlcg0KICAgdGhlIG5ldHdvcmsgdmlhIFNOTVAuICBUaGVzZSBhcmUgdGhlIHRhYmxlcyBhbmQg b2JqZWN0cyBhbmQgdGhlaXINCiAgIHNlbnNpdGl2aXR5L3Z1bG5lcmFiaWxpdHk6DQoNCiAgIHJh ZGl1c0R5bkF1dGhDbGllbnRBZGRyZXNzIGFuZCByYWRpdXNEeW5BdXRoQ2xpZW50QWRkcmVzc1R5 cGUNCg0KICAgVGhlc2UgY2FuIGJlIHVzZWQgdG8gZGV0ZXJtaW5lIHRoZSBhZGRyZXNzIG9mIHRo ZSBEQUMgd2l0aCB3aGljaCB0aGUNCiAgIERBUyBpcyBjb21tdW5pY2F0aW5nLiAgVGhpcyBpbmZv cm1hdGlvbiBjb3VsZCBiZSB1c2VmdWwgaW4gbW91bnRpbmcNCiAgIGFuIGF0dGFjayBvbiB0aGUg REFDLg0KDQogICByYWRpdXNEeW5BdXRoU2VydmVySWRlbnRpZmllcg0KDQogICBUaGlzIGNhbiBi ZSB1c2VkIHRvIGRldGVybWluZSB0aGUgSWRlbnRpZmllciBvZiB0aGUgREFTLiAgVGhpcw0KICAg aW5mb3JtYXRpb24gY291bGQgYmUgdXNlZnVsIGluIGltcGVyc29uYXRpbmcgdGhlIERBUy4NCg0K ICAgU05NUCB2ZXJzaW9ucyBwcmlvciB0byBTTk1QdjMgZGlkIG5vdCBpbmNsdWRlIGFkZXF1YXRl IHNlY3VyaXR5Lg0KICAgRXZlbiBpZiB0aGUgbmV0d29yayBpdHNlbGYgaXMgc2VjdXJlIChmb3Ig ZXhhbXBsZSBieSB1c2luZyBJUHNlYyksDQogICBldmVuIHRoZW4sIHRoZXJlIGlzIG5vIGNvbnRy b2wgYXMgdG8gd2hvIG9uIHRoZSBzZWN1cmUgbmV0d29yayBpcw0KICAgYWxsb3dlZCB0byBhY2Nl c3MgYW5kIEdFVC9TRVQgKHJlYWQvY2hhbmdlL2NyZWF0ZS9kZWxldGUpIHRoZSBvYmplY3RzDQog ICBpbiB0aGlzIE1JQiBtb2R1bGUuDQoNCiAgIEl0IGlzIFJFQ09NTUVOREVEIHRoYXQgaW1wbGVt ZW50ZXJzIGNvbnNpZGVyIHRoZSBzZWN1cml0eSBmZWF0dXJlcyBhcw0KICAgcHJvdmlkZWQgYnkg dGhlIFNOTVB2MyBmcmFtZXdvcmsgKHNlZSBbUkZDMzQxMF0sIHNlY3Rpb24gOCksDQogICBpbmNs dWRpbmcgZnVsbCBzdXBwb3J0IGZvciB0aGUgU05NUHYzIGNyeXB0b2dyYXBoaWMgbWVjaGFuaXNt cyAoZm9yDQogICBhdXRoZW50aWNhdGlvbiBhbmQgcHJpdmFjeSkuDQoNCiAgIEZ1cnRoZXIsIGRl cGxveW1lbnQgb2YgU05NUCB2ZXJzaW9ucyBwcmlvciB0byBTTk1QdjMgaXMgTk9UDQogICBSRUNP TU1FTkRFRC4gIEluc3RlYWQsIGl0IGlzIFJFQ09NTUVOREVEIHRvIGRlcGxveSBTTk1QdjMgYW5k IHRvDQogICBlbmFibGUgY3J5cHRvZ3JhcGhpYyBzZWN1cml0eS4gIEl0IGlzIHRoZW4gYSBjdXN0 b21lci9vcGVyYXRvcg0KICAgcmVzcG9uc2liaWxpdHkgdG8gZW5zdXJlIHRoYXQgdGhlIFNOTVAg ZW50aXR5IGdpdmluZyBhY2Nlc3MgdG8gYW4NCiAgIGluc3RhbmNlIG9mIHRoaXMgTUlCIG1vZHVs ZSBpcyBwcm9wZXJseSBjb25maWd1cmVkIHRvIGdpdmUgYWNjZXNzIHRvDQogICB0aGUgb2JqZWN0 cyBvbmx5IHRvIHRob3NlIHByaW5jaXBhbHMgKHVzZXJzKSB0aGF0IGhhdmUgbGVnaXRpbWF0ZQ0K ICAgcmlnaHRzIHRvIGluZGVlZCBHRVQgb3IgU0VUIChjaGFuZ2UvY3JlYXRlL2RlbGV0ZSkgdGhl bS4NCg0KDQoNCg0KDQoNCkRlIENub2RkZXIsIGV0IGFsLiAgICAgRXhwaXJlcyBTZXB0ZW1iZXIg MjMsIDIwMDYgICAgICAgICAgICAgIFtQYWdlIDIyXQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICBE eW5hbWljIEF1dGhvcml6YXRpb24gU2VydmVyIE1JQiAgICAgICAgICBNYXJjaCAyMDA2DQoNCg0K Ni4gIElBTkEgY29uc2lkZXJhdGlvbnMNCg0KICAgSUFOQSBpcyByZXF1ZXN0ZWQgdG8gYXNzaWdu IGFuIE9JRCB4eHggdW5kZXIgbWliLTIuDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQpEZSBDbm9kZGVyLCBldCBhbC4gICAgIEV4cGlyZXMgU2VwdGVtYmVyIDIzLCAyMDA2 ICAgICAgICAgICAgICBbUGFnZSAyM10NCgwNCkludGVybmV0LURyYWZ0ICAgICAgRHluYW1pYyBB dXRob3JpemF0aW9uIFNlcnZlciBNSUIgICAgICAgICAgTWFyY2ggMjAwNg0KDQoNCjcuICBBY2tu b3dsZWRnZW1lbnRzDQoNCiAgIFRoZSBhdXRob3JzIHdvdWxkIGFsc28gbGlrZSB0byBhY2tub3ds ZWRnZSB0aGUgZm9sbG93aW5nIHBlb3BsZSBmb3INCiAgIHRoZWlyIGNvbW1lbnRzIG9uIHRoaXMg ZG9jdW1lbnQ6IEJlcm5hcmQgQWJvYmEsIEFsYW4gRGVLb2ssIERhdmlkDQogICBOZWxzb24sIEFu amFuZXl1bHUgUGF0YSwgRGFuIFJvbWFzY2FudSwgSnVlcmdlbiBTY2hvZW53YWVsZGVyLCBHcmVn DQogICBXZWJlciwgQmVydCBXaWpuZW4gYW5kIEdsZW4gWm9ybi4NCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCkRlIENub2RkZXIsIGV0IGFsLiAgICAgRXhwaXJlcyBTZXB0ZW1iZXIg MjMsIDIwMDYgICAgICAgICAgICAgIFtQYWdlIDI0XQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICBE eW5hbWljIEF1dGhvcml6YXRpb24gU2VydmVyIE1JQiAgICAgICAgICBNYXJjaCAyMDA2DQoNCg0K OC4gIFJlZmVyZW5jZXMNCg0KOC4xLiAgTm9ybWF0aXZlIFJlZmVyZW5jZXMNCg0KICAgW1JGQzIx MTldICBCcmFkbmVyLCBTLiwgIktleSB3b3JkcyBmb3IgdXNlIGluIFJGQ3MgdG8gSW5kaWNhdGUN CiAgICAgICAgICAgICAgUmVxdWlyZW1lbnQgTGV2ZWxzIiwgUkZDIDIxMTksIE1hcmNoIDE5OTcu DQoNCiAgIFtSRkMyNTc4XSAgTWNDbG9naHJpZSwgSy4sIFBlcmtpbnMsIEQuLCBTY2hvZW53YWVs ZGVyLCBKLiwgQ2FzZSwgSi4sDQogICAgICAgICAgICAgIFJvc2UsIE0uLCBhbmQgUy4gV2FsZGJ1 c3NlciwgIlN0cnVjdHVyZSBvZiBNYW5hZ2VtZW50DQogICAgICAgICAgICAgIEluZm9ybWF0aW9u IFZlcnNpb24gMiAoU01JdjIpIiwgU1REIDU4LCBSRkMgMjU3OCwNCiAgICAgICAgICAgICAgQXBy aWwgMTk5OS4NCg0KICAgW1JGQzI1NzldICBNY0Nsb2docmllLCBLLiwgUGVya2lucywgRC4sIFNj aG9lbndhZWxkZXIsIEouLCBDYXNlLCBKLiwNCiAgICAgICAgICAgICAgUm9zZSwgTS4sIGFuZCBT LiBXYWxkYnVzc2VyLCAiVGV4dHVhbCBDb252ZW50aW9ucyBmb3INCiAgICAgICAgICAgICAgU01J djIiLCBTVEQgNTgsIFJGQyAyNTc5LCBBcHJpbCAxOTk5Lg0KDQogICBbUkZDMjU4MF0gIE1jQ2xv Z2hyaWUsIEsuLCBQZXJraW5zLCBELiwgU2Nob2Vud2FlbGRlciwgSi4sIENhc2UsIEouLA0KICAg ICAgICAgICAgICBSb3NlLCBNLiwgYW5kIFMuIFdhbGRidXNzZXIsICJDb25mb3JtYW5jZSBTdGF0 ZW1lbnRzIGZvcg0KICAgICAgICAgICAgICBTTUl2MiIsIFNURCA1OCwgUkZDIDI1ODAsIEFwcmls IDE5OTkuDQoNCiAgIFtSRkMzNDExXSAgSGFycmluZ3RvbiwgRC4sIFByZXN1aG4sIFIuLCBhbmQg Qi4gV2lqbmVuLCAiQW4NCiAgICAgICAgICAgICAgQXJjaGl0ZWN0dXJlIGZvciBEZXNjcmliaW5n IFNpbXBsZSBOZXR3b3JrIE1hbmFnZW1lbnQNCiAgICAgICAgICAgICAgUHJvdG9jb2wgKFNOTVAp IE1hbmFnZW1lbnQgRnJhbWV3b3JrcyIsIFNURCA2MiwgUkZDIDM0MTEsDQogICAgICAgICAgICAg IERlY2VtYmVyIDIwMDIuDQoNCiAgIFtSRkMzNTc2XSAgQ2hpYmEsIE0uLCBEb21tZXR5LCBHLiwg RWtsdW5kLCBNLiwgTWl0dG9uLCBELiwgYW5kIEIuDQogICAgICAgICAgICAgIEFib2JhLCAiRHlu YW1pYyBBdXRob3JpemF0aW9uIEV4dGVuc2lvbnMgdG8gUmVtb3RlDQogICAgICAgICAgICAgIEF1 dGhlbnRpY2F0aW9uIERpYWwgSW4gVXNlciBTZXJ2aWNlIChSQURJVVMpIiwgUkZDIDM1NzYsDQog ICAgICAgICAgICAgIEp1bHkgMjAwMy4NCg0KICAgW1JGQzQwMDFdICBEYW5pZWxlLCBNLiBhbmQg ZXQgYWwuLCAiVGV4dHVhbCBDb252ZW50aW9ucyBmb3IgSW50ZXJuZXQNCiAgICAgICAgICAgICAg TmV0d29yayBBZGRyZXNzZXMiLCBSRkMgNDAwMSwgRmVicnVhcnkgMjAwNS4NCg0KOC4yLiAgSW5m b3JtYXRpdmUgUmVmZXJlbmNlcw0KDQogICBbRFlOQ0xOVF0gIERlIENub2RkZXIsIFMuLCBKb25u YWxhLCBOLiwgYW5kIE0uIENoaWJhLCAiUkFESVVTIER5bmFtaWMNCiAgICAgICAgICAgICAgQXV0 aG9yaXphdGlvbiBDbGllbnQgTUlCIiwNCiAgICAgICAgICAgICAgZHJhZnQtaWV0Zi1yYWRleHQt ZHluYXV0aC1jbGllbnQtbWliLTA1LnR4dCwgd29yayBpbg0KICAgICAgICAgICAgICBwcm9ncmVz cywgRGVjZW1iZXIgMjAwNS4NCg0KICAgW1JGQzI2MThiaXNdDQogICAgICAgICAgICAgIE5lbHNv biwgRC4sICJSQURJVVMgQXV0aCBDbGllbnQgTUlCIChJUHY2KSIsDQogICAgICAgICAgICAgIGRy YWZ0LWlldGYtcmFkZXh0LXJmYzI2MThiaXMtMDEudHh0IHdvcmsgaW4gcHJvZ3Jlc3MsDQogICAg ICAgICAgICAgIE9jdG9iZXIgMjAwNS4NCg0KICAgW1JGQzI2MTliaXNdDQogICAgICAgICAgICAg IE5lbHNvbiwgRC4sICJSQURJVVMgQXV0aCBTZXJ2ZXIgTUlCIChJUHY2KSIsDQogICAgICAgICAg ICAgIGRyYWZ0LWlldGYtcmFkZXh0LXJmYzI2MTliaXMtMDEudHh0IHdvcmsgaW4gcHJvZ3Jlc3Ms DQoNCg0KDQpEZSBDbm9kZGVyLCBldCBhbC4gICAgIEV4cGlyZXMgU2VwdGVtYmVyIDIzLCAyMDA2 ICAgICAgICAgICAgICBbUGFnZSAyNV0NCgwNCkludGVybmV0LURyYWZ0ICAgICAgRHluYW1pYyBB dXRob3JpemF0aW9uIFNlcnZlciBNSUIgICAgICAgICAgTWFyY2ggMjAwNg0KDQoNCiAgICAgICAg ICAgICAgT2N0b2JlciAyMDA1Lg0KDQogICBbUkZDMjYyMGJpc10NCiAgICAgICAgICAgICAgTmVs c29uLCBELiwgIlJBRElVUyBBY2N0IENsaWVudCBNSUIgKElQdjYpIiwNCiAgICAgICAgICAgICAg ZHJhZnQtaWV0Zi1yYWRleHQtcmZjMjYyMGJpcy0wMS50eHQgd29yayBpbiBwcm9ncmVzcywNCiAg ICAgICAgICAgICAgT2N0b2JlciAyMDA1Lg0KDQogICBbUkZDMjYyMWJpc10NCiAgICAgICAgICAg ICAgTmVsc29uLCBELiwgIlJBRElVUyBBY2N0IFNlcnZlciBNSUIgKElQdjYpIiwNCiAgICAgICAg ICAgICAgZHJhZnQtaWV0Zi1yYWRleHQtcmZjMjYyMWJpcy0wMS50eHQgd29yayBpbiBwcm9ncmVz cywNCiAgICAgICAgICAgICAgT2N0b2JlciAyMDA1Lg0KDQogICBbUkZDMjg2NV0gIFJpZ25leSwg Qy4sIFdpbGxlbnMsIFMuLCBSdWJlbnMsIEEuLCBhbmQgVy4gU2ltcHNvbiwNCiAgICAgICAgICAg ICAgIlJlbW90ZSBBdXRoZW50aWNhdGlvbiBEaWFsIEluIFVzZXIgU2VydmljZSAoUkFESVVTKSIs DQogICAgICAgICAgICAgIFJGQyAyODY1LCBKdW5lIDIwMDAuDQoNCiAgIFtSRkMzNDEwXSAgQ2Fz ZSwgSi4sIE11bmR5LCBSLiwgUGFydGFpbiwgRC4sIGFuZCBCLiBTdGV3YXJ0LA0KICAgICAgICAg ICAgICAiSW50cm9kdWN0aW9uIGFuZCBBcHBsaWNhYmlsaXR5IFN0YXRlbWVudHMgZm9yIEludGVy bmV0LQ0KICAgICAgICAgICAgICBTdGFuZGFyZCBNYW5hZ2VtZW50IEZyYW1ld29yayIsIFJGQyAz NDEwLCBEZWNlbWJlciAyMDAyLg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCkRlIENub2RkZXIsIGV0IGFsLiAgICAgRXhwaXJl cyBTZXB0ZW1iZXIgMjMsIDIwMDYgICAgICAgICAgICAgIFtQYWdlIDI2XQ0KDA0KSW50ZXJuZXQt RHJhZnQgICAgICBEeW5hbWljIEF1dGhvcml6YXRpb24gU2VydmVyIE1JQiAgICAgICAgICBNYXJj aCAyMDA2DQoNCg0KQXV0aG9ycycgQWRkcmVzc2VzDQoNCiAgIFN0ZWZhYW4gRGUgQ25vZGRlcg0K ICAgQWxjYXRlbA0KICAgRnJhbmNpcyBXZWxsZXNwbGVpbiAxDQogICBCLTIwMTggQW50d2VycA0K ICAgQmVsZ2l1bQ0KDQogICBQaG9uZTogKzMyIDMgMjQwIDg1IDE1DQogICBFbWFpbDogc3RlZmFh bi5kZV9jbm9kZGVyQGFsY2F0ZWwuYmUNCg0KDQogICBOYWdpIFJlZGR5IEpvbm5hbGENCiAgIENp c2NvIFN5c3RlbXMsIEluYy4NCiAgIERpdnlhc3JlZSBDaGFtYmVycywgIEIgV2luZywgTydTaGF1 Z25lc3N5IFJvYWQNCiAgIEJhbmdhbG9yZS01NjAwMjcsIEluZGlhDQoNCiAgIFBob25lOiArOTEg OTQ0ODcgNjA4MjgNCiAgIEVtYWlsOiBuam9ubmFsYUBjaXNjby5jb20NCg0KDQogICBNdXJ0YXph IENoaWJhDQogICBDaXNjbyBTeXN0ZW1zLCBJbmMuDQogICAxNzAgV2VzdCBUYXNtYW4gRHIuDQog ICBTYW4gSm9zZSBDQSwgOTUxMzQNCg0KICAgUGhvbmU6ICsxIDQwOCA1MjUgNzE5OA0KICAgRW1h aWw6IG1jaGliYUBjaXNjby5jb20NCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQpEZSBDbm9kZGVyLCBldCBhbC4gICAgIEV4cGlyZXMgU2VwdGVtYmVyIDIzLCAy MDA2ICAgICAgICAgICAgICBbUGFnZSAyN10NCgwNCkludGVybmV0LURyYWZ0ICAgICAgRHluYW1p YyBBdXRob3JpemF0aW9uIFNlcnZlciBNSUIgICAgICAgICAgTWFyY2ggMjAwNg0KDQoNCkludGVs bGVjdHVhbCBQcm9wZXJ0eSBTdGF0ZW1lbnQNCg0KICAgVGhlIElFVEYgdGFrZXMgbm8gcG9zaXRp b24gcmVnYXJkaW5nIHRoZSB2YWxpZGl0eSBvciBzY29wZSBvZiBhbnkNCiAgIEludGVsbGVjdHVh bCBQcm9wZXJ0eSBSaWdodHMgb3Igb3RoZXIgcmlnaHRzIHRoYXQgbWlnaHQgYmUgY2xhaW1lZCB0 bw0KICAgcGVydGFpbiB0byB0aGUgaW1wbGVtZW50YXRpb24gb3IgdXNlIG9mIHRoZSB0ZWNobm9s b2d5IGRlc2NyaWJlZCBpbg0KICAgdGhpcyBkb2N1bWVudCBvciB0aGUgZXh0ZW50IHRvIHdoaWNo IGFueSBsaWNlbnNlIHVuZGVyIHN1Y2ggcmlnaHRzDQogICBtaWdodCBvciBtaWdodCBub3QgYmUg YXZhaWxhYmxlOyBub3IgZG9lcyBpdCByZXByZXNlbnQgdGhhdCBpdCBoYXMNCiAgIG1hZGUgYW55 IGluZGVwZW5kZW50IGVmZm9ydCB0byBpZGVudGlmeSBhbnkgc3VjaCByaWdodHMuICBJbmZvcm1h dGlvbg0KICAgb24gdGhlIHByb2NlZHVyZXMgd2l0aCByZXNwZWN0IHRvIHJpZ2h0cyBpbiBSRkMg ZG9jdW1lbnRzIGNhbiBiZQ0KICAgZm91bmQgaW4gQkNQIDc4IGFuZCBCQ1AgNzkuDQoNCiAgIENv cGllcyBvZiBJUFIgZGlzY2xvc3VyZXMgbWFkZSB0byB0aGUgSUVURiBTZWNyZXRhcmlhdCBhbmQg YW55DQogICBhc3N1cmFuY2VzIG9mIGxpY2Vuc2VzIHRvIGJlIG1hZGUgYXZhaWxhYmxlLCBvciB0 aGUgcmVzdWx0IG9mIGFuDQogICBhdHRlbXB0IG1hZGUgdG8gb2J0YWluIGEgZ2VuZXJhbCBsaWNl bnNlIG9yIHBlcm1pc3Npb24gZm9yIHRoZSB1c2Ugb2YNCiAgIHN1Y2ggcHJvcHJpZXRhcnkgcmln aHRzIGJ5IGltcGxlbWVudGVycyBvciB1c2VycyBvZiB0aGlzDQogICBzcGVjaWZpY2F0aW9uIGNh biBiZSBvYnRhaW5lZCBmcm9tIHRoZSBJRVRGIG9uLWxpbmUgSVBSIHJlcG9zaXRvcnkgYXQNCiAg IGh0dHA6Ly93d3cuaWV0Zi5vcmcvaXByLg0KDQogICBUaGUgSUVURiBpbnZpdGVzIGFueSBpbnRl cmVzdGVkIHBhcnR5IHRvIGJyaW5nIHRvIGl0cyBhdHRlbnRpb24gYW55DQogICBjb3B5cmlnaHRz LCBwYXRlbnRzIG9yIHBhdGVudCBhcHBsaWNhdGlvbnMsIG9yIG90aGVyIHByb3ByaWV0YXJ5DQog ICByaWdodHMgdGhhdCBtYXkgY292ZXIgdGVjaG5vbG9neSB0aGF0IG1heSBiZSByZXF1aXJlZCB0 byBpbXBsZW1lbnQNCiAgIHRoaXMgc3RhbmRhcmQuICBQbGVhc2UgYWRkcmVzcyB0aGUgaW5mb3Jt YXRpb24gdG8gdGhlIElFVEYgYXQNCiAgIGlldGYtaXByQGlldGYub3JnLg0KDQoNCkRpc2NsYWlt ZXIgb2YgVmFsaWRpdHkNCg0KICAgVGhpcyBkb2N1bWVudCBhbmQgdGhlIGluZm9ybWF0aW9uIGNv bnRhaW5lZCBoZXJlaW4gYXJlIHByb3ZpZGVkIG9uIGFuDQogICAiQVMgSVMiIGJhc2lzIGFuZCBU SEUgQ09OVFJJQlVUT1IsIFRIRSBPUkdBTklaQVRJT04gSEUvU0hFIFJFUFJFU0VOVFMNCiAgIE9S IElTIFNQT05TT1JFRCBCWSAoSUYgQU5ZKSwgVEhFIElOVEVSTkVUIFNPQ0lFVFkgQU5EIFRIRSBJ TlRFUk5FVA0KICAgRU5HSU5FRVJJTkcgVEFTSyBGT1JDRSBESVNDTEFJTSBBTEwgV0FSUkFOVElF UywgRVhQUkVTUyBPUiBJTVBMSUVELA0KICAgSU5DTFVESU5HIEJVVCBOT1QgTElNSVRFRCBUTyBB TlkgV0FSUkFOVFkgVEhBVCBUSEUgVVNFIE9GIFRIRQ0KICAgSU5GT1JNQVRJT04gSEVSRUlOIFdJ TEwgTk9UIElORlJJTkdFIEFOWSBSSUdIVFMgT1IgQU5ZIElNUExJRUQNCiAgIFdBUlJBTlRJRVMg T0YgTUVSQ0hBTlRBQklMSVRZIE9SIEZJVE5FU1MgRk9SIEEgUEFSVElDVUxBUiBQVVJQT1NFLg0K DQoNCkNvcHlyaWdodCBTdGF0ZW1lbnQNCg0KICAgQ29weXJpZ2h0IChDKSBUaGUgSW50ZXJuZXQg U29jaWV0eSAoMjAwNikuICBUaGlzIGRvY3VtZW50IGlzIHN1YmplY3QNCiAgIHRvIHRoZSByaWdo dHMsIGxpY2Vuc2VzIGFuZCByZXN0cmljdGlvbnMgY29udGFpbmVkIGluIEJDUCA3OCwgYW5kDQog ICBleGNlcHQgYXMgc2V0IGZvcnRoIHRoZXJlaW4sIHRoZSBhdXRob3JzIHJldGFpbiBhbGwgdGhl aXIgcmlnaHRzLg0KDQoNCkFja25vd2xlZGdtZW50DQoNCiAgIEZ1bmRpbmcgZm9yIHRoZSBSRkMg RWRpdG9yIGZ1bmN0aW9uIGlzIGN1cnJlbnRseSBwcm92aWRlZCBieSB0aGUNCiAgIEludGVybmV0 IFNvY2lldHkuDQoNCg0KDQoNCkRlIENub2RkZXIsIGV0IGFsLiAgICAgRXhwaXJlcyBTZXB0ZW1i ZXIgMjMsIDIwMDYgICAgICAgICAgICAgIFtQYWdlIDI4XQ0KDA0KDQo= ------_=_NextPart_001_01C64E46.0AB5C8D0-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 22 Mar 2006 21:36:43 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: RE: Location draft issues raised today Date: Wed, 22 Mar 2006 16:36:28 -0500 Message-ID: <3CFB564E055A594B82C4FE89D215656021917D@MABOSEVS2.ets.enterasys.com> Thread-Topic: Location draft issues raised today Thread-Index: AcZN2FCEgjXT1cEMQ3qbpqK+o9A90gAH1dIg From: "Nelson, David" To: Alan DeKok writes... > RADIUS has transported poorly formatted data, and made policy > decisions on it for a very long time now. I just don't see why > location is so special that we have to enforce the RADIUS data > model now. I've avoided responding to many of your specific items of reasoning in this message, because in this last paragraph it seems that you don't see any value in having any kind of formalized RADIUS data model. This seems to contradict some of your previous postings. Am I summarizing your thoughts correctly here? Or do you simply see location data as a special case? -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 22 Mar 2006 20:50:42 +0000 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: radiusext@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-radext-dynauth-server-mib-04.txt Message-Id: Date: Wed, 22 Mar 2006 15:50:01 -0500 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the RADIUS EXTensions Working Group of the IETF. Title : Dynamic Authorization Server MIB Author(s) : S. De Cnodder, et al. Filename : draft-ietf-radext-dynauth-server-mib-04.txt Pages : 27 Date : 2006-3-22 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes the Remote Authentication Dial In User Service (RADIUS) [RFC2865] Dynamic Authorization Server (DAS) functions that support the dynamic authorization extensions as defined in RFC 3576. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-radext-dynauth-server-mib-04.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-radext-dynauth-server-mib-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-radext-dynauth-server-mib-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-3-22145543.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-radext-dynauth-server-mib-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-radext-dynauth-server-mib-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-3-22145543.I-D@ietf.org> --OtherAccess-- --NextPart-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 22 Mar 2006 17:57:40 +0000 From: "Alan DeKok" To: Emile van Bergen Subject: Re: RADIUS to Diameter gateways & extended attributes cc: radiusext@ops.ietf.org Date: Wed, 22 Mar 2006 13:05:29 -0500 Message-Id: <20060322180529.C1EE316CC1@mail.nitros9.org> Emile van Bergen wrote: > I think the size related issue can be resolved in a much simpler way. > Also note that it's not individual attributes that are the problem, as > much as the total size of the attributes combined. Diameter to RADIUS gateways *already* have to enforce: a) per-attribute size for RADIUS-compatible Diameter attributes (1..255) b) total message size for RADIUS packets For *any* format of RADIUS extended attribute, Diameter to RADIUS gateways will still have to enforce the above restrictions. > So making the DIAMETER to RADIUS gateway to know what the maximum size > is for each attribute does not help. It's the total response packet that > may or may not fit after reencoding using any Extended Attribute > format. Diameter to RADIUS gateways already have this problem when administrators use Diameter attributes from the RADIUS space (1..255). They have already implement solutions to this problem. Adding a new RADIUS extended attribute changes nothing, except that the above restrictions must also be applied to the new attributes. > If the DIAMETER home server allows requests that ultimately come from a > RADIUS client, then it must expect that any response attribute that > RADIUS allows to be ignored, can be ignored, with the session being > allowed to start -- unless the proxy chain and the NAS make certain > promises in the request regarding the passing and applying of response > attributes. Yes. It appears we need information in the Diameter message that "this message is coming from, or going to, a RADIUS system". I don't know if Diameter already has that capability. If not, it would make the above decisions much easier for Diameter servers. > The problem does not lie on the attribute number level. A short IP > filtering attribute would be perfectly fine, whereas a longer one would > not. Would you want to prohibit the gatewaying of any filtering > attributes a priori, just because they *can* be longer than the RADIUS > limit of 4096 minus some? No. But the Diameter server must be able to make an informed decision. Failing that, Diameter to RADIUS gateways become almost impossible to implement robustly. Alan DeKok. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 22 Mar 2006 17:44:18 +0000 From: "Alan DeKok" To: Emile van Bergen Subject: Re: Location draft issues raised today cc: radiusext@ops.ietf.org Date: Wed, 22 Mar 2006 12:51:53 -0500 Message-Id: <20060322175153.3A3B716CC1@mail.nitros9.org> Emile van Bergen wrote: > I agree that it would support the packing as it is, but I think the > overriding criterium is whether or not the server wants access to > individual members in order to apply administrator defined policy. I am hesitant to make gratuitous changes to existing location data structures just to satisfy RADIUS historical practices. Doing so would affect interoperability and implementation. It would make location-based systems harder to implement, because of the pointless translation from location structures to RADIUS-friendly structures. In addition, there is presumably already code to parse and process the location data structures. RADIUS implementations should be able to re-use that code to abstract access to the information they need for policy. This is *no* different than implementing EAP. EAP implementors were not forced to re-pack their data into RADIUS friendly structures. I do not believe it's necessary to require the location structures to be re-pack, either. > The repacking by the RADIUS client can be well defined and nonambiguous. > I don't see any problem with that. It's more code. It's gratuitous re-packing just to make location data fit into the RADIUS data model (such as it is). > It's in our scope anyway. It's not that "if there's any other encoding > for this information, in any other protocol, we have nothing to say > anymore". This is also what I seemed to hear from Bert as well as > Bernard. It's not "if there's any other encoding", but: If RADIUS is being (ab)used as a transport protocol for data, it should *not* mangle that data. Nearly every transport implementation that has massaged the data it transported has created bugs, interoperability issues, implementation problems, and security breaches. Much as I think the location structure is a *terrible* one, I think mangling the data causes more problems than it solves. > It depends on whether there's any meaning to be attached to the elements > *at our level*, that is, the RADIUS proxy or endpoint. Like EAP? While the canonical diagrams of RADIUS to EAP authenticators show separate RADIUS & EAP systems, in reality they're almost always implemented in the RADIUS server. RADIUS is just transport for EAP data, which people *do* use to make policy decisions. There are precedents for RADIUS being used as a transport protocol for data that doesn't match the RADIUS data model. There are precedents for RADIUS servers implementing policy based on that data. > It depends on whether there's any meaning to be attached to the elements > *at our level*, that is, the RADIUS proxy or endpoint. Like the ARAP attributes? Or the Login-LAT-* attributes? RADIUS has transported poorly formatted data, and made policy decisions on it for a very long time now. I just don't see why location is so special that we have to enforce the RADIUS data model now. Alan DeKok. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 22 Mar 2006 08:34:37 +0000 Date: Wed, 22 Mar 2006 09:34:27 +0100 From: Emile van Bergen To: Alan DeKok Cc: radiusext@ops.ietf.org Subject: Re: RADIUS to Diameter gateways & extended attributes Message-ID: <20060322083426.GB3625@note.evbergen.xs4all.nl> Mail-Followup-To: Alan DeKok , radiusext@ops.ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.9i Hi, On Tue, Mar 21, 2006 at 02:08:11PM -0500, Alan DeKok wrote: > That is, it doesn't matter so much that Diameter can carry much more > traffic per attribute/message than RADIUS can, because that is not the > purpose behind the use of the Diameter attribute format. If that is > true, we then have to ensure that Diameter to RADIUS gateways don't > pass large Diameter attributes/messages to RADIUS. > > Since we already have Diameter to RADIUS gateways that perform this > enforcement, it would appear that this worry is largely not a problem > in practice. > > However... with the advent of many more RADIUS attributes being > carried in Diameter, it would be good to enable Diameter to RADIUS > gateways to tell which attributes *can* fit into RADIUS, and which > cannot. One suggestion in the "extended attribute" subgroup was to > allocate the Diameter-format RADIUS attributes from a subset of the > Diameter space. The gateways could then trivially tell which > attributes are RADIUS compatible. I think the size related issue can be resolved in a much simpler way. Also note that it's not individual attributes that are the problem, as much as the total size of the attributes combined. So making the DIAMETER to RADIUS gateway to know what the maximum size is for each attribute does not help. It's the total response packet that may or may not fit after reencoding using any Extended Attribute format. However, a DIAMETER client has a concept of clients NAKing server responses, if I remember correctly, because there is a class of attributes for which a server may set the M bit, but that are not required to be supported on the NAS by the base specification or NASREQ. Because DIAMETER servers already have to handle such situations gracefully, having a gateway NAK overlength responses, longest attributes first would seem a good approach. Alternatively, the DIAMETER gateway could first retry by ignoring all non-M attribute from the DIAMETER response to see if the recoded RADIUS response fits the limit. If it still doesn't fit, the gateway will still have to NAK the response. But if the home DIAMETER server wants to know *in advance* that the policy it is about to send will actually be applied in full, the whole generic issue of NAS hints and promises appears, and that's a generic problem that has little to do with DIAMETER or gatewaying per se. A DIAMETER gateway in that respect is nothing but a special case of an response attribute filtering proxy. And all RADIUS proxies do that in some form or another. This has come up before, and we never finished that discussion, although I still think that the concept of a client's promises-to-apply, however encoded, would solve the problem. If the DIAMETER home server allows requests that ultimately come from a RADIUS client, then it must expect that any response attribute that RADIUS allows to be ignored, can be ignored, with the session being allowed to start -- unless the proxy chain and the NAS make certain promises in the request regarding the passing and applying of response attributes. > That suggestion may be problematic if a Diameter server adds > additional RADIUS compatible attributes to a Diameter message that > contains attributes previously taken from RADIUS. There is no way for > a Diameter to RADIUS gateway to be sure if the attributes fit into a > RADIUS packet. > > Another option would be to add a "RADIUS" bit to the Diameter > attribute. Any attribute that came from a RADIUS to Diameter gateway > would have that bit set, allowing later servers to handle them more > appropriately. > > I think this addresses Glen's comments. It doesn't matter how large > Diameter messages/attributes are if RADIUS servers never see that > data. Since the Diameter format is used by the RADIUS servers only to > *generate* RADIUS compatible traffic, and not to receive Diameter > traffic, any compatibility issue is pushed to the Diameter side of the > protocol implementations. The problem does not lie on the attribute number level. A short IP filtering attribute would be perfectly fine, whereas a longer one would not. Would you want to prohibit the gatewaying of any filtering attributes a priori, just because they *can* be longer than the RADIUS limit of 4096 minus some? Cheers, Emile. -- E-Advies - Emile van Bergen emile@e-advies.nl tel. +31 (0)78 6136282 http://www.e-advies.nl -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 22 Mar 2006 08:14:05 +0000 Date: Wed, 22 Mar 2006 09:13:22 +0100 From: Emile van Bergen To: Alan DeKok Cc: radiusext@ops.ietf.org Subject: Re: Location draft issues raised today Message-ID: <20060322081322.GA3625@note.evbergen.xs4all.nl> Mail-Followup-To: Alan DeKok , radiusext@ops.ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.9i Hi, On Tue, Mar 21, 2006 at 02:43:23PM -0500, Alan DeKok wrote: > There were concerns rasied in the meeting today about the encoding > of location data in RADIUS attributes. I'll expand on my comments here: > > - If the encoding of the location information is taken from a > normitive reference (as suggested in the WG meeting), then the packing > of that information should be outside of the scope of RADEXT. The > description of the complex encoding in the draft should be replaced by > a normitive reference to another document. > > That would resolve all of the concerns around complex attribute > encodings in RADIUS. I agree that it would support the packing as it is, but I think the overriding criterium is whether or not the server wants access to individual members in order to apply administrator defined policy. If so, an encoding using multiple attributes, however grouped (if needed at all; a request only contains at most one instance of location information if I understand correctly), would be desireable over packing, even if such a packing is standardized for another protocol. The repacking by the RADIUS client can be well defined and nonambiguous. I don't see any problem with that. Note that we can't foresee all future policies that servers or their administrators would wish to execute. It's better to err on the side of caution (splitting in multiple attributes where that's not really necessary) than on the other side, as that would require servers to be updated with GEOPRIV-specific parsing code as soon as they would want to support location-specific authorisations. In this case, if there is any reasonable use for individual member fields, they should use separate attributes, in my opinion. > - If, on the other hand, the encoding is specific to these attributes > and occurs nowhere else, then the packing is within the scope of > RADEXT, and the concerns raised should be addressed by the document > authors. It's in our scope anyway. It's not that "if there's any other encoding for this information, in any other protocol, we have nothing to say anymore". This is also what I seemed to hear from Bert as well as Bernard. It depends on whether there's any meaning to be attached to the elements *at our level*, that is, the RADIUS proxy or endpoint. Cheers, Emile. -- E-Advies - Emile van Bergen emile@e-advies.nl tel. +31 (0)78 6136282 http://www.e-advies.nl -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 21 Mar 2006 20:50:23 +0000 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: radiusext@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-radext-dynauth-client-mib-04.txt Message-Id: Date: Tue, 21 Mar 2006 15:50:02 -0500 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the RADIUS EXTensions Working Group of the IETF. Title : Dynamic Authorization Client MIB Author(s) : S. De Cnodder, et al. Filename : draft-ietf-radext-dynauth-client-mib-04.txt Pages : 28 Date : 2006-3-21 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes the Remote Authentication Dial In User Service (RADIUS) [RFC2865] Dynamic Authorization Client (DAC) functions that support the dynamic authorization extensions as defined in RFC 3576. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-radext-dynauth-client-mib-04.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-radext-dynauth-client-mib-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-radext-dynauth-client-mib-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-3-21143728.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-radext-dynauth-client-mib-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-radext-dynauth-client-mib-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-3-21143728.I-D@ietf.org> --OtherAccess-- --NextPart-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 21 Mar 2006 19:36:10 +0000 From: "Alan DeKok" To: radiusext@ops.ietf.org Subject: Location draft issues raised today Date: Tue, 21 Mar 2006 14:43:23 -0500 Message-Id: <20060321194324.096A416CC1@mail.nitros9.org> There were concerns rasied in the meeting today about the encoding of location data in RADIUS attributes. I'll expand on my comments here: - If the encoding of the location information is taken from a normitive reference (as suggested in the WG meeting), then the packing of that information should be outside of the scope of RADEXT. The description of the complex encoding in the draft should be replaced by a normitive reference to another document. That would resolve all of the concerns around complex attribute encodings in RADIUS. - If, on the other hand, the encoding is specific to these attributes and occurs nowhere else, then the packing is within the scope of RADEXT, and the concerns raised should be addressed by the document authors. Alan DeKok. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 21 Mar 2006 19:01:03 +0000 From: "Alan DeKok" To: radiusext@ops.ietf.org Subject: RADIUS to Diameter gateways & extended attributes Date: Tue, 21 Mar 2006 14:08:11 -0500 Message-Id: <20060321190811.9736716CC1@mail.nitros9.org> Some issues were raised during the WG meeting today. I'll try to address them here. The purpose behind using the Diameter format to carry extended RADIUS attributes is to simplify the work done by RADIUS to Diameter gateways. As a result, any issue of Diameter to RADIUS gatewaying and attribute/message size is largely out of scope. That is, it doesn't matter so much that Diameter can carry much more traffic per attribute/message than RADIUS can, because that is not the purpose behind the use of the Diameter attribute format. If that is true, we then have to ensure that Diameter to RADIUS gateways don't pass large Diameter attributes/messages to RADIUS. Since we already have Diameter to RADIUS gateways that perform this enforcement, it would appear that this worry is largely not a problem in practice. However... with the advent of many more RADIUS attributes being carried in Diameter, it would be good to enable Diameter to RADIUS gateways to tell which attributes *can* fit into RADIUS, and which cannot. One suggestion in the "extended attribute" subgroup was to allocate the Diameter-format RADIUS attributes from a subset of the Diameter space. The gateways could then trivially tell which attributes are RADIUS compatible. That suggestion may be problematic if a Diameter server adds additional RADIUS compatible attributes to a Diameter message that contains attributes previously taken from RADIUS. There is no way for a Diameter to RADIUS gateway to be sure if the attributes fit into a RADIUS packet. Another option would be to add a "RADIUS" bit to the Diameter attribute. Any attribute that came from a RADIUS to Diameter gateway would have that bit set, allowing later servers to handle them more appropriately. I think this addresses Glen's comments. It doesn't matter how large Diameter messages/attributes are if RADIUS servers never see that data. Since the Diameter format is used by the RADIUS servers only to *generate* RADIUS compatible traffic, and not to receive Diameter traffic, any compatibility issue is pushed to the Diameter side of the protocol implementations. Alan DeKok. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 21 Mar 2006 15:21:58 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: My Genart review issue on RADIUS Digest Date: Tue, 21 Mar 2006 17:21:28 +0200 Message-ID: <1AA39B75171A7144A73216AED1D7478D0186A096@esebe100.NOE.Nokia.com> Thread-Topic: My Genart review issue on RADIUS Digest Thread-Index: AcZM+x+o3iUPf8t7TCuMpoms8o/loQ== From: To: Just for the record, my issue has be resolved, so my issue can be cleared. John -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 21 Mar 2006 14:26:31 +0000 Message-ID: From: "Bernard Aboba" To: radiusext@ops.ietf.org Bcc: Subject: IETF 65 slides available Date: Tue, 21 Mar 2006 06:26:03 -0800 Mime-Version: 1.0 Content-Type: text/plain; format=flowed The slides from the IETF 65 RADEXT meeting are now available online here: http://www.drizzle.com/~aboba/IETF65/radext/ -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 21 Mar 2006 12:18:34 +0000 Message-ID: From: "Bernard Aboba" To: "'Congdon, Paul T \(ProCurve\)'" , "'Greg Weber \(gdweber\)'" Cc: Subject: RE: Proposed Resolution to Issue 180: Misuse of Data Types Date: Tue, 21 Mar 2006 04:16:47 -0800 Message-ID: <000301c64ce1$53118ed0$347160cc@ntdev.corp.microsoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Thread-Index: AcZJJaez5C50LytGSvGulkIoZn/6jgAvwwIgAKiwLCAACIlrYAACSKkgAAuY8CA= Tagged VLANs seems ok (and it fits in the diagrams). -----Original Message----- From: Congdon, Paul T (ProCurve) [mailto:paul.congdon@hp.com] Sent: Monday, March 20, 2006 10:45 PM To: Bernard Aboba; Greg Weber (gdweber) Cc: radiusext@ops.ietf.org Subject: RE: Proposed Resolution to Issue 180: Misuse of Data Types Yes, I remember the discussion about using ASCII representations of a flag. How about "Tagged VLANs" or "Tagged VLANs Flag" for a field name? To me, "VLAN Flag" is confusing. > -----Original Message----- > From: Bernard Aboba [mailto:Bernard_Aboba@hotmail.com] > Sent: Monday, March 20, 2006 10:08 PM > To: Congdon, Paul T (ProCurve); 'Greg Weber (gdweber)' > Cc: radiusext@ops.ietf.org > Subject: RE: Proposed Resolution to Issue 180: Misuse of Data Types > > Here are some thoughts: > > 1. The values of 0x31 and 0x32 translate to ASCII '1' and > '2'. This is useful for the Egress-VLAN-Name attribute, > since this allows the attribute (defined as type String) to > be entered easily. Changing the values to > 0x01 and 0x00 would it harder to input the attribute, so I > don't think this change is a good idea. > > 2. You are right that this variable is not really a Flag, and > others have stated it is not a Tag (at least in the RFC 2868 > sense). Given this, I'm somewhat concerned about calling it a > 'VLAN Tag Flag'. What do other people think? > > 3. Could we perhaps call it the "Tagging" field? > > > > > -----Original Message----- > From: owner-radiusext@ops.ietf.org > [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Congdon, > Paul T (ProCurve) > Sent: Monday, March 20, 2006 5:36 PM > To: Greg Weber (gdweber); Bernard Aboba > Cc: radiusext@ops.ietf.org > Subject: RE: Proposed Resolution to Issue 180: Misuse of Data Types > > The name "VLAN Flag" is miss leading. There is certainly a > VLAN present. The question is whether the VLAN is tagged or > not. I understand the confusion with Radius tags - though > people who understand VLANs and would be using this attribute > probably wouldn't have a problem. > > If you must change the field name - which I'm not really in > support of - I suggest calling it "VLAN Tag Flag" and going > with the 1 and 0 symantics of TRUE and FALSE. > > -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 21 Mar 2006 06:45:13 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Proposed Resolution to Issue 180: Misuse of Data Types Date: Mon, 20 Mar 2006 22:44:56 -0800 Message-ID: <85ECA15B7BB46944BFD4C73AEA55482404922EDC@cacexc07.americas.cpqcorp.net> Thread-Topic: Proposed Resolution to Issue 180: Misuse of Data Types Thread-Index: AcZJJaez5C50LytGSvGulkIoZn/6jgAvwwIgAKiwLCAACIlrYAACSKkg From: "Congdon, Paul T (ProCurve)" To: "Bernard Aboba" , "Greg Weber (gdweber)" Cc: Yes, I remember the discussion about using ASCII representations of a flag. How about "Tagged VLANs" or "Tagged VLANs Flag" for a field name? To me, "VLAN Flag" is confusing.=20 > -----Original Message----- > From: Bernard Aboba [mailto:Bernard_Aboba@hotmail.com]=20 > Sent: Monday, March 20, 2006 10:08 PM > To: Congdon, Paul T (ProCurve); 'Greg Weber (gdweber)' > Cc: radiusext@ops.ietf.org > Subject: RE: Proposed Resolution to Issue 180: Misuse of Data Types >=20 > Here are some thoughts: >=20 > 1. The values of 0x31 and 0x32 translate to ASCII '1' and=20 > '2'. This is useful for the Egress-VLAN-Name attribute,=20 > since this allows the attribute (defined as type String) to=20 > be entered easily. Changing the values to > 0x01 and 0x00 would it harder to input the attribute, so I=20 > don't think this change is a good idea. =20 >=20 > 2. You are right that this variable is not really a Flag, and=20 > others have stated it is not a Tag (at least in the RFC 2868=20 > sense). Given this, I'm somewhat concerned about calling it a=20 > 'VLAN Tag Flag'. What do other people think?=20 >=20 > 3. Could we perhaps call it the "Tagging" field?=20 >=20 >=20 >=20 >=20 > -----Original Message----- > From: owner-radiusext@ops.ietf.org=20 > [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Congdon,=20 > Paul T (ProCurve) > Sent: Monday, March 20, 2006 5:36 PM > To: Greg Weber (gdweber); Bernard Aboba > Cc: radiusext@ops.ietf.org > Subject: RE: Proposed Resolution to Issue 180: Misuse of Data Types >=20 > The name "VLAN Flag" is miss leading. There is certainly a=20 > VLAN present. The question is whether the VLAN is tagged or=20 > not. I understand the confusion with Radius tags - though=20 > people who understand VLANs and would be using this attribute=20 > probably wouldn't have a problem. >=20 > If you must change the field name - which I'm not really in=20 > support of - I suggest calling it "VLAN Tag Flag" and going=20 > with the 1 and 0 symantics of TRUE and FALSE. >=20 >=20 -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 21 Mar 2006 06:08:31 +0000 Message-ID: From: "Bernard Aboba" To: "'Congdon, Paul T \(ProCurve\)'" , "'Greg Weber \(gdweber\)'" Cc: Subject: RE: Proposed Resolution to Issue 180: Misuse of Data Types Date: Mon, 20 Mar 2006 22:08:05 -0800 Message-ID: <003701c64cad$d1990f00$347160cc@ntdev.corp.microsoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Thread-Index: AcZJJaez5C50LytGSvGulkIoZn/6jgAvwwIgAKiwLCAACIlrYA== Here are some thoughts: 1. The values of 0x31 and 0x32 translate to ASCII '1' and '2'. This is useful for the Egress-VLAN-Name attribute, since this allows the attribute (defined as type String) to be entered easily. Changing the values to 0x01 and 0x00 would it harder to input the attribute, so I don't think this change is a good idea. 2. You are right that this variable is not really a Flag, and others have stated it is not a Tag (at least in the RFC 2868 sense). Given this, I'm somewhat concerned about calling it a 'VLAN Tag Flag'. What do other people think? 3. Could we perhaps call it the "Tagging" field? -----Original Message----- From: owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Congdon, Paul T (ProCurve) Sent: Monday, March 20, 2006 5:36 PM To: Greg Weber (gdweber); Bernard Aboba Cc: radiusext@ops.ietf.org Subject: RE: Proposed Resolution to Issue 180: Misuse of Data Types The name "VLAN Flag" is miss leading. There is certainly a VLAN present. The question is whether the VLAN is tagged or not. I understand the confusion with Radius tags - though people who understand VLANs and would be using this attribute probably wouldn't have a problem. If you must change the field name - which I'm not really in support of - I suggest calling it "VLAN Tag Flag" and going with the 1 and 0 symantics of TRUE and FALSE. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 21 Mar 2006 05:59:01 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: MIB Counters discontinuity Date: Tue, 21 Mar 2006 11:28:24 +0530 Message-ID: <61D6551D82BC7149967B39B5C66879F8F587FB@xmb-blr-416.apac.cisco.com> Thread-Topic: MIB Counters discontinuity Thread-Index: AcZMNr+ZMTPeo6nBRriHSC8/MrynKAAHYh6gABX80MA= From: "Nagi Reddy Jonnala \(njonnala\)" To: "Nelson, David" , Sounds good and thanks to all of you. We'll address this issue in the next revision. -----Original Message----- From: owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Nelson, David Sent: Tuesday, March 21, 2006 1:08 AM To: radiusext@ops.ietf.org Subject: RE: MIB Counters discontinuity Bert Wijnen writes... > From your story, it seems to me that > you need your own Discontinuity Timer. I was discussing this issue with Dave Harrington, over lunch. Dave concurred with the suggestion that these MIBs contain their own discontinuity timestamp, rather than relying on the sysUpTime object or using sysORUpTime. It should be sufficient for each RADIUS client entity or server entity to maintain a single up time. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 21 Mar 2006 01:38:16 +0000 Mime-Version: 1.0 (Apple Message framework v623) To: radiusext@ops.ietf.org Message-Id: <93e7b5fa899000e25e37a1cf127182f0@cisco.com> Content-Type: multipart/alternative; boundary=Apple-Mail-1--758363358 From: John Schnizlein Subject: Fwd: [dhcwg] Fwd: RADEXT WG Last Call on "RADIUS Delegated IPv6 PrefixAttribute" Date: Mon, 20 Mar 2006 19:37:57 -0600 --Apple-Mail-1--758363358 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed Begin forwarded message: > From: "Bernie Volz \(volz\)" > Date: March 20, 2006 6:25:11 PM CST > To: "John Schnizlein \(jschnizl\)" > Subject: RE: [dhcwg] Fwd: RADEXT WG Last Call on "RADIUS Delegated > IPv6 PrefixAttribute" > > John: > > Feel free to forward this to the WG! > > I just read the draft and it looks fine to me; I support its > publication. > > There are a few minor nits though: > > ** 1. Why "another" in the second sentence of the introduction: > > --- > 1. Introduction > > The Delegated-IPv6-Prefix indicates an IPv6 prefix to be delegated > to > the user. For example, the prefix in a Delegated-IPv6-Prefix > attribute can be delegated to another node through DHCP Prefix > Delegation [2]. > --- > > Would not just "... can be delegated to a node through DHCP ..." be > sufficient? > > ---- > > ** 2. And further in the introduction: > > --- > The Delegated-IPv6-Prefix MAY be used in Access-Accept packets, and > can appear multiple times. It MAY be used in an Access-Request > packet as a hint by the NAS to the server that it would prefer these > prefix(es), but the server is not required to honor the hint. > --- > > The table in section 3 lists Accounting Request (0+). So, it MAY also > appear there. > > ---- > > ** 3. The use of bytes should be replaced by octets? This was a comment > I got on a recent round of documents from the IESG, so they'll raise it > and best to fix before it goes on to them? See section 3. > > --- > > Note that the prefix field is only required to be long enough to > hold > the prefix bits and can be shorter than 16 bytes. Any bits in the > prefix field that are not part of the prefix MUST be zero. > > --- > > ** 4. You might add "the": > > In this table 0 indicates that an attribute MUST NOT be present in > the packet and 0+ means that zero or more instances of this > attribute > MAY be present in the packet. > ^^^ > > Best regards, > > - Bernie > --Apple-Mail-1--758363358 Content-Transfer-Encoding: 7bit Content-Type: text/enriched; charset=US-ASCII Begin forwarded message: 0000,0000,0000From: "Bernie Volz \(volz\)" < 0000,0000,0000Date: March 20, 2006 6:25:11 PM CST 0000,0000,0000To: "John Schnizlein \(jschnizl\)" < 0000,0000,0000Subject: RE: [dhcwg] Fwd: RADEXT WG Last Call on "RADIUS Delegated IPv6 PrefixAttribute" John: Feel free to forward this to the WG! I just read the draft and it looks fine to me; I support its publication. There are a few minor nits though: ** 1. Why "another" in the second sentence of the introduction: --- 1. Introduction The Delegated-IPv6-Prefix indicates an IPv6 prefix to be delegated to the user. For example, the prefix in a Delegated-IPv6-Prefix attribute can be delegated to another node through DHCP Prefix Delegation [2]. --- Would not just "... can be delegated to a node through DHCP ..." be sufficient? ---- ** 2. And further in the introduction: --- The Delegated-IPv6-Prefix MAY be used in Access-Accept packets, and can appear multiple times. It MAY be used in an Access-Request packet as a hint by the NAS to the server that it would prefer these prefix(es), but the server is not required to honor the hint. --- The table in section 3 lists Accounting Request (0+). So, it MAY also appear there. ---- ** 3. The use of bytes should be replaced by octets? This was a comment I got on a recent round of documents from the IESG, so they'll raise it and best to fix before it goes on to them? See section 3. --- Note that the prefix field is only required to be long enough to hold the prefix bits and can be shorter than 16 bytes. Any bits in the prefix field that are not part of the prefix MUST be zero. --- ** 4. You might add "the": In this table 0 indicates that an attribute MUST NOT be present in the packet and 0+ means that zero or more instances of this attribute MAY be present in the packet. ^^^ Best regards, - Bernie --Apple-Mail-1--758363358-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 21 Mar 2006 01:36:47 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Proposed Resolution to Issue 180: Misuse of Data Types Date: Mon, 20 Mar 2006 17:36:17 -0800 Message-ID: <85ECA15B7BB46944BFD4C73AEA55482404922E42@cacexc07.americas.cpqcorp.net> Thread-Topic: Proposed Resolution to Issue 180: Misuse of Data Types Thread-Index: AcZJJaez5C50LytGSvGulkIoZn/6jgAvwwIgAKiwLCA= From: "Congdon, Paul T (ProCurve)" To: "Greg Weber (gdweber)" , "Bernard Aboba" Cc: The name "VLAN Flag" is miss leading. There is certainly a VLAN present. The question is whether the VLAN is tagged or not. I understand the confusion with Radius tags - though people who understand VLANs and would be using this attribute probably wouldn't have a problem. If you must change the field name - which I'm not really in support of - I suggest calling it "VLAN Tag Flag" and going with the 1 and 0 symantics of TRUE and FALSE. > -----Original Message----- > From: owner-radiusext@ops.ietf.org=20 > [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Greg Weber=20 > (gdweber) > Sent: Friday, March 17, 2006 9:09 AM > To: Bernard Aboba > Cc: radiusext@ops.ietf.org > Subject: RE: Proposed Resolution to Issue 180: Misuse of Data Types >=20 > =20 > Now the VLAN-01 strawman says: > The VLAN Flag field is one octet in length,=20 > and indicates whether the frames on the VLAN=20 > are tagged (0x31) or untagged (0x32).=20 >=20 > But it doesn't say *how* the flag field indicates tagged vs.=20 > untagged. With the attribute name being VLAN Flag, I would=20 > think that attribute's values would be 1 or 0. Do I indicate=20 > 'tagged' by setting the value of VLAN Flag to 1 or to 0x31? >=20 > Greg >=20 > > -----Original Message----- > > From: owner-radiusext@ops.ietf.org > > [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Bernard Aboba > > Sent: Thursday, March 16, 2006 1:15 PM > > To: radiusext@ops.ietf.org > > Subject: Proposed Resolution to Issue 180: Misuse of Data Types > >=20 > > The text of Issue 180 (and some of the subsequent discussion) is=20 > > enclosed below. > >=20 > > The proposed resolution is to change "VLAN Tag" to "VLAN Flag"=20 > > everywhere in the document. > >=20 > > In looking at the mailing list discussion, I did not detect=20 > consensus=20 > > for making other changes. > >=20 > > -------------------------------------------------------------- > > -------------------------------------- > > Issue 180: Misuse of Data Types > > Submitter name: Dave Nelson > > Submitter email address: dnelson@enterasys.com Date first=20 > submitted:=20 > > March 14, 2006 > > Reference: http://ops.ietf.org/lists/radiusext/2006/msg00280.html > > Document: VLAN/Priority -00 > > Comment type: 'T'echnical > > Priority: '1' Should fix > > Section: 2.1. Egress-VLANID > > Rationale/Explanation of issue: > >=20 > > I had previously raised this issue, and the resolution was we could=20 > > use a RADIUS data type of Integer, because only the VLANID (12-bit)=20 > > portion would be used. > > Thus, this object could be thought of as a range-limited integer.=20 > > Since I see that we still have the VLAN Tag fields, that resolution=20 > > falls apart. I claim that this data object is not an Integer. > >=20 > > Someone offered the suggestion that Integers are not simply the=20 > > mathematical definition, i.e. the positive and negative=20 > whole numbers=20 > > and zero, that we all learned in high school. With all due respect, > >=20 > > I think that's patently wrong. It is true that one can=20 > write programs=20 > > that treat 8-bit, 16-bit, 32-bit or 64-bit "integers" as=20 > packed data=20 > > structures using mask, bit-field, shift and rotate operations. > >=20 > > I still claim that those data structures are *not* integers simply=20 > > because they can be packed within the computer memory=20 > storage that is=20 > > also used by integers. > > Hopefully, there > > is more to data modeling than the storage length in bits. :-) > >=20 > > We are currently having a debate on the RADEXT WG list=20 > about the issue=20 > > of derived data types, and no consensus has yet been reached. > > However, until > > such a consensus is reached, it seems most appropriate to=20 > follow the=20 > > existing practice of defining derived data types as=20 > Strings, with the=20 > > bit-fields described in the text. I think that over-loading base=20 > > RADIUS data types with new meanings is inappropriate. > >=20 > > Given the relative timing of WGLC on this draft and the emerging=20 > > consensus on RADIUS Attribute Design Guidelines, I think=20 > this is the=20 > > best compromise. > >=20 > > Requested change: > >=20 > > OLD: > >=20 > > Integer > >=20 > > The Integer field is four octets in length. The format is described=20 > > below: > >=20 > > 0 1 2 3 > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | VLAN Tag | Pad | VLANID | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >=20 > > The VLAN Tag field is one octet in length, and indicates=20 > whether the=20 > > frames on the VLAN are tagged (0x31) or untagged (0x32).=20 > The Pad field=20 > > is 12-bits in length and MUST be 0 (zero). The VLANID is 12-bits in=20 > > length and contains the [IEEE-802.1Q] VLAN VID value. > >=20 > > NEW: > >=20 > > String > >=20 > > The String field is four octets in length. The format is described=20 > > below: > >=20 > > 0 1 2 3 > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | VLAN Tag | Pad | VLANID | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >=20 > > The VLAN Tag field is one octet in length, and indicates=20 > whether the=20 > > frames on the VLAN are tagged (0x31) or untagged (0x32).=20 > The Pad field=20 > > is 12-bits in length and MUST be 0 (zero). The VLANID is 12-bits in=20 > > length and contains the [IEEE-802.1Q] VLAN VID value. > >=20 > > Section: 2.3. Egress-VLAN-Name > > Rationale/Explanation of issue: > >=20 > > I'm rather uncomfortable with the usage of the VLAN Tag=20 > field, as it=20 > > seems to be at variance with the emerging WG consensus on=20 > complex or=20 > > structured data types. Once we standardize this usage,=20 > there will be=20 > > one more precedent in a RADIUS RFC to support ad-hoc data typing. > > If that's what RADEXT ultimately recommends, then this will=20 > be fine.=20 > > If the recommendation is to use a more formal method of aggregating=20 > > structured data, this will be one more anomaly. > >=20 > > VLAN Tag > >=20 > > The VLAN tag field is one octet in length, and indicates=20 > whether the=20 > > frames on the VLAN are tagged (0x31) or untagged (0x32). > >=20 > > Requested change: > >=20 > > I have no idea what (if any change) to request. Chalk this=20 > comment up=20 > > as my personal lament over the process that RADEXT has followed --=20 > > delaying consensus on attributes design to the point where we are=20 > > standardizing new attributes using complex data types prior=20 > to having=20 > > defined the design guidelines for complex data types. > >=20 > > Section 2.4 User-Priority-Table > > Rationale/Explanation of issue: > >=20 > > With all due deference to the well understood "array -=20 > string duality"=20 > > we find in programming languages such as C, I think that=20 > expressing a=20 > > attribute whose value is an array in the form of a RADIUS=20 > String type=20 > > is unfortunate, for the reasons expressed above. > >=20 > > Requested change: > >=20 > > (See above.) > >=20 > > The only way that I see to actually resolve my data typing / data=20 > > modeling concerns is to delay sending any RADEXT work item=20 > that uses=20 > > derived data types to the IESG until after we have sent the RADIUS=20 > > Design Guidelines and RADIUS Extended Attributes I-Ds to=20 > the IESG, and=20 > > that approach is not compatible with our milestones. > >=20 > > [Glen Zorn] > > With all due respect, I think that you are the one doing the > > overloading:=20 > > RFC 2568 says > >=20 > > integer 32 bit unsigned value, most significant octet first. > >=20 > > That's it. No range, no interpretation, nothing else. > >=20 > > [Emile Van Bergen] > > >I see nothing that indicates this data type is anything=20 > other than an=20 > > >integer, typically expressed in a C language declaration=20 > as "unsigned=20 > > >long". > >=20 > > You're completely correct. And in the case of the VLAN attribute, it > > *does* contain an unsigned integer value, one that's calculated as=20 > > follows: > >=20 > > value =3D vlanflag * 16777216 + vlanid > >=20 > > The reverse goes as follows: > >=20 > > vlanflag =3D value / 16777216 > > vlanid =3D value % 16777216 > >=20 > > (where > > * denotes unsigned integer multiplication, > > + denotes unsigned integer addition, > > / denotes unsigned integer division and % denotes taking=20 > the reminder=20 > > of an unsigned integer division, all to be carried out on unsigned=20 > > integers in the range 0 .. 2**32-1) > >=20 > > I'm not believing that people on this list would have to be=20 > explained=20 > > that shifting and masking bits are *not* magic operations=20 > that you can=20 > > only perform if you program in assembly (or its portable=20 > flavour, C),=20 > > but that those are normal mathematical operations on normal=20 > integers: > > multiply and take remainder (by powers of 2). > >=20 > > You can do that, I think, even in Java, SAP/r3, XSLT, SQL and=20 > > whatever. > > This whole issue has nothing whatsoever to do with C structures. > >=20 > >=20 > >=20 > > -- > > to unsubscribe send a message to=20 > radiusext-request@ops.ietf.org with=20 > > the word 'unsubscribe' in a single line as the message text body. > > archive: > >=20 >=20 > -- > to unsubscribe send a message to=20 > radiusext-request@ops.ietf.org with the word 'unsubscribe' in=20 > a single line as the message text body. > archive: >=20 -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Mon, 20 Mar 2006 20:36:01 +0000 Mime-Version: 1.0 (Apple Message framework v623) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <4e5d60d1478ab1c8ecf0320f19ccbcaf@cisco.com> Content-Transfer-Encoding: 7bit Cc: radiusext@ops.ietf.org From: John Schnizlein Subject: Re: RADEXT WG Last Call on "RADIUS Delegated IPv6 Prefix Attribute" Date: Mon, 20 Mar 2006 14:35:21 -0600 To: "Bernard Aboba" I have read the draft and support its advancement to RFC. John On Mar 3, 2006, at 2:12 PM, Bernard Aboba wrote: > This is an announcement of RADEXT WG last call on the "RADIUS > Delegated-IPv6 Prefix Attribute" > document, prior to sending this document on to the IESG for > consideration as a Proposed > Standard. > > The document is available for inspection here: > http://www.ietf.org/internet-drafts/draft-ietf-radext-delegated- > prefix-00.txt > > RADEXT WG last call will last until Monday March 27, 2006. Please > send your > comments to the RADEXT WG list (radiusext@ops.ietf.org) in the format > described > on the RADEXT Issues List: > http://www.drizzle.com/~aboba/RADEXT/ > > Since all RADEXT WG last calls require at least 5 reviewers in order > to advance > the document, please respond indicating that you have read the > document and > find it acceptable, even if you have no issues to file. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Mon, 20 Mar 2006 20:34:04 +0000 Mime-Version: 1.0 (Apple Message framework v623) To: radiusext@ops.ietf.org Message-Id: Content-Type: multipart/alternative; boundary=Apple-Mail-4--776610796 Cc: Mark Stapp Subject: Fwd: [dhcwg] Fwd: RADEXT WG Last Call on "RADIUS Delegated IPv6 Prefix Attribute" From: John Schnizlein Date: Mon, 20 Mar 2006 14:33:50 -0600 --Apple-Mail-4--776610796 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed forwarded on behalf of interested community on the DHC mailing list Begin forwarded message: > From: Mark Stapp > Date: March 20, 2006 2:27:28 PM CST > To: John Schnizlein > Subject: Re: [dhcwg] Fwd: RADEXT WG Last Call on "RADIUS Delegated > IPv6 Prefix Attribute" > > I have read the delegated prefix draft and have no objection. > > -- Mark Stapp --Apple-Mail-4--776610796 Content-Transfer-Encoding: 7bit Content-Type: text/enriched; charset=US-ASCII forwarded on behalf of interested community on the DHC mailing list Begin forwarded message: 0000,0000,0000From: Mark Stapp < 0000,0000,0000Date: March 20, 2006 2:27:28 PM CST 0000,0000,0000To: John Schnizlein < 0000,0000,0000Subject: Re: [dhcwg] Fwd: RADEXT WG Last Call on "RADIUS Delegated IPv6 Prefix Attribute" I have read the delegated prefix draft and have no objection. -- Mark Stapp --Apple-Mail-4--776610796-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Mon, 20 Mar 2006 19:58:42 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: Information for remote participants Date: Mon, 20 Mar 2006 14:58:29 -0500 Message-ID: <3CFB564E055A594B82C4FE89D2156560219165@MABOSEVS2.ets.enterasys.com> Thread-Topic: Information for remote participants Thread-Index: AcZMWKhIPlwB46cpR7+cNwpdKdECdg== From: "Nelson, David" To: The online meeting materials for RADEXT (and other WGs) are being posted at: https://datatracker.ietf.org/public/meeting_materials.cgi?meeting_num=3D6= 5 under the respective WG name. The streaming audio for IETF-65 sessions may be accessed at: http://videolab.uoregon.edu/events/ietf/ The Jabber Rooms for IETG Working Groups can be located at: http://www.ietf.org/meetings/text_conf.html The jabber server name is "rooms.jabber.ietf.org". The room name for RADEXT is "radext". It would be helpful if anyone who plans to remotely participate in the RADEXT session, starting Tuesday at 9:00 AM Central Standard Time, would reply to me directly so that I can attempt to ensure that we have a Jabber Scribe available to channel questions from remote participants.=20 -- Dave Nelson -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Mon, 20 Mar 2006 19:38:20 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: RE: MIB Counters discontinuity Date: Mon, 20 Mar 2006 14:37:34 -0500 Message-ID: <3CFB564E055A594B82C4FE89D2156560219164@MABOSEVS2.ets.enterasys.com> Thread-Topic: MIB Counters discontinuity Thread-Index: AcZMNr+ZMTPeo6nBRriHSC8/MrynKAAHYh6g From: "Nelson, David" To: Bert Wijnen writes... > From your story, it seems to me that > you need your own Discontinuity Timer. I was discussing this issue with Dave Harrington, over lunch. Dave concurred with the suggestion that these MIBs contain their own discontinuity timestamp, rather than relying on the sysUpTime object or using sysORUpTime. It should be sufficient for each RADIUS client entity or server entity to maintain a single up time. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Mon, 20 Mar 2006 15:55:12 +0000 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B155099880C7@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: stefaan.de_cnodder@alcatel.be, "Nagi Reddy Jonnala (njonnala)" Cc: j.schoenwaelder@iu-bremen.de, "Wijnen, Bert (Bert)" , radiusext@ops.ietf.org, "Dan Romascanu (E-mail)" Subject: RE: MIB Counters discontinuity (Was RE: radius dynauth client/ser ver mibs structure) Date: Mon, 20 Mar 2006 16:54:36 +0100 MIME-Version: 1.0 Content-Type: text/plain >From your story, it seems to me that you need your own Discontinuity Timer. Bert > -----Original Message----- > From: stefaan.de_cnodder@alcatel.be > [mailto:stefaan.de_cnodder@alcatel.be] > Sent: Monday, March 20, 2006 07:52 > To: Nagi Reddy Jonnala (njonnala) > Cc: j.schoenwaelder@iu-bremen.de; Wijnen, Bert (Bert); > radiusext@ops.ietf.org; Dan Romascanu (E-mail) > Subject: Re: MIB Counters discontinuity (Was RE: radius dynauth > client/server mibs structure) > > > >>> > >>>"This counter may experience discontinuity when the Dynamic > >>>Authorization Client (DAC) module is (re)started". > >> > >>Why only the DAC module? > > > > > > IMO, in theory, a DAC/DAS can be restarted regardless of the system > > restart(or sysUpTime). A similar statement is applicable to DAS > > Mib/module. > > > > Is it enough bu saying that there is a discontinuity at DAC or DAS > module restart or is there then also a need for a scalar that > contains > the value of sysUpTime at the time the discontinuity happened? For > implementations where the DAC or DAS cannot restart without that the > whole system restarts, this will always contain zero. This > looks better > to me but then the case where counters survive a restart > (e.g., if they > are put in persistent memory) is not possible anymore. I am > not really > interested in that case since these counters are not so > important that > they have to survive a restart. Introducing such an object would also > mean that when the management application restarts (sysUpTime > is zero), > then also the counters have to be reset even though the DAC or DAS > module might not have restarted (which is no problem for me). > > So, what is now the preference: > > 1) stating for each counter that it may experience a > discontinuity when > the DAC or DAS module (re)starts. > 2) introducing such a scalar > 3) use sysORUpTime instead > > Thanks, > Stefaan > > > > Thanks > > Nagi. > > > > > >>/js > >> > >>-- > >>Juergen Schoenwaelder International > University Bremen > >> P.O. Box 750 561, > >>28725 Bremen, Germany > > > > > -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Mon, 20 Mar 2006 15:21:03 +0000 Date: Mon, 20 Mar 2006 16:20:46 +0100 From: Emile van Bergen To: "Nelson, David" , radiusext@ops.ietf.org, Bernard Aboba Subject: Note: Slides are background material for Greg's talk, won't be presented at IETF65 Message-ID: <20060320152045.GA4688@note.evbergen.xs4all.nl> Mail-Followup-To: "Nelson, David" , radiusext@ops.ietf.org, Bernard Aboba Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.9i Sorry to bother you again, Please note that these slides are intended as background material for D.3.2 (Design Guidelines, by Greg Weber); I won't present them myself. Emile. On Mon, Mar 20, 2006 at 04:02:54PM +0100, Emile van Bergen wrote: > Please find my slides concerning the Extended Attribute format at > http://www.xs4all.nl/~evbergen/e-advies-nl/ietf/ietf65_radext_extattr_evb_1.pdf -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Mon, 20 Mar 2006 15:03:21 +0000 Date: Mon, 20 Mar 2006 16:02:54 +0100 From: Emile van Bergen To: "Nelson, David" Cc: radiusext@ops.ietf.org, Bernard Aboba Subject: Re: REMINDER: Submission of presentations (slides) for the RADEXT WG session at IETF-65 Message-ID: <20060320150254.GB4636@note.evbergen.xs4all.nl> Mail-Followup-To: "Nelson, David" , radiusext@ops.ietf.org, Bernard Aboba Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.9i Please find my slides concerning the Extended Attribute format at http://www.xs4all.nl/~evbergen/e-advies-nl/ietf/ietf65_radext_extattr_evb_1.pdf Kind regards, Emile. On Fri, Mar 17, 2006 at 05:55:36PM -0500, Nelson, David wrote: > REMINDER: > > > Please submit your RADEXT WG presentation materials to the chairs > ASAP. > > We would *really* like to have them all posted prior to the RADEXT > session > > on Tuesday morning of IETF week. > > -- > to unsubscribe send a message to radiusext-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: -- E-Advies - Emile van Bergen emile@e-advies.nl tel. +31 (0)78 6136282 http://www.e-advies.nl -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Mon, 20 Mar 2006 13:53:10 +0000 Message-ID: <441EB384.2090109@alcatel.be> Date: Mon, 20 Mar 2006 14:52:04 +0100 From: stefaan.de_cnodder@alcatel.be User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20040910 MIME-Version: 1.0 To: "Nagi Reddy Jonnala (njonnala)" Cc: j.schoenwaelder@iu-bremen.de, "Wijnen, Bert \(Bert\)" , radiusext@ops.ietf.org, "Dan Romascanu (E-mail)" Subject: Re: MIB Counters discontinuity (Was RE: radius dynauth client/server mibs structure) Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed >>> >>>"This counter may experience discontinuity when the Dynamic >>>Authorization Client (DAC) module is (re)started". >> >>Why only the DAC module? > > > IMO, in theory, a DAC/DAS can be restarted regardless of the system > restart(or sysUpTime). A similar statement is applicable to DAS > Mib/module. > Is it enough bu saying that there is a discontinuity at DAC or DAS module restart or is there then also a need for a scalar that contains the value of sysUpTime at the time the discontinuity happened? For implementations where the DAC or DAS cannot restart without that the whole system restarts, this will always contain zero. This looks better to me but then the case where counters survive a restart (e.g., if they are put in persistent memory) is not possible anymore. I am not really interested in that case since these counters are not so important that they have to survive a restart. Introducing such an object would also mean that when the management application restarts (sysUpTime is zero), then also the counters have to be reset even though the DAC or DAS module might not have restarted (which is no problem for me). So, what is now the preference: 1) stating for each counter that it may experience a discontinuity when the DAC or DAS module (re)starts. 2) introducing such a scalar 3) use sysORUpTime instead Thanks, Stefaan > Thanks > Nagi. > > >>/js >> >>-- >>Juergen Schoenwaelder International University Bremen >> P.O. Box 750 561, >>28725 Bremen, Germany > > -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Mon, 20 Mar 2006 13:14:27 +0000 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15509987F9C@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "Nagi Reddy Jonnala (njonnala)" , "Wijnen, Bert (Bert)" , stefaan.de_cnodder@alcatel.be Cc: radiusext@ops.ietf.org, "Dan Romascanu (E-mail)" Subject: RE: MIB Counters discontinuity (Was RE: radius dynauth client/ser ver mibs structure) Date: Mon, 20 Mar 2006 14:13:51 +0100 MIME-Version: 1.0 Content-Type: text/plain I think that would be OK, but where are the counters kept to survive a restart? Bert > -----Original Message----- > From: Nagi Reddy Jonnala (njonnala) [mailto:njonnala@cisco.com] > Sent: Sunday, March 19, 2006 22:34 > To: Wijnen, Bert (Bert); stefaan.de_cnodder@alcatel.be > Cc: radiusext@ops.ietf.org; Dan Romascanu (E-mail) > Subject: MIB Counters discontinuity (Was RE: radius dynauth > client/server mibs structure) > > > Bert, > > > Mmm... the "wraps from the max value to zero" is redundant, > > because that is the behaviour of every Counter32 and > > Counter64. That is already specified in RFC2578. > > W.r.t "is reset upon system (re)initialization", that is not > > exactly waht we wanted either. I do not know what you mean > > with "reset". > > It is not REQUIRED that counter reset to sero (if that is > > what you mean). > > They MAY do so, butnot required. > > I think what you want to write is: > > > > This counter will only experience a discuntinuity when the system > > (re)starts as indicated by the value of sysUpTime. > > > > Do you think mentioning "may" in the sentence is appropriate. > > "This counter may experience a discontinuity when the system > (re)starts > as indicated by the value of sysUpTime." > > > Thanks > Nagi. > -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Mon, 20 Mar 2006 10:02:39 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: MIB Counters discontinuity (Was RE: radius dynauth client/server mibs structure) Date: Mon, 20 Mar 2006 15:31:49 +0530 Message-ID: <61D6551D82BC7149967B39B5C66879F86FF186@xmb-blr-416.apac.cisco.com> Thread-Topic: MIB Counters discontinuity (Was RE: radius dynauth client/server mibs structure) Thread-Index: AcZL+27eYWX7qLDdSZubvpEt5JiMDAABh6fQ From: "Nagi Reddy Jonnala \(njonnala\)" To: Cc: "Wijnen, Bert \(Bert\)" , , , "Dan Romascanu \(E-mail\)" > > Juergen, Bert and all, > >=20 > > We have two options then. Please let us know which one=20 > works for you. > >=20 > > 1. As Juergen suggested "This counter uses sysUpTime as the=20 > > discontinuity indicator. Any discontinuity of this counter=20 > must cause a > > reset of sysUpTime." > >=20 > > 2. All we want to convey in the MIBs is that the counter might=20 > > experience discontinuity when the respective (DAC or DAS) module is=20 > > (re)started. Not sure if we need to draw any relation to=20 > sysUpTime or=20 > > some other object. Is implementing the sysUptime mandatory? >=20 > An SNMP agent without sysUptime (the default discontinuity=20 > indicator for all counters) is kind of broken. OK. >=20 > > If not, does the below work? > >=20 > > "This counter may experience discontinuity when the Dynamic=20 > > Authorization Client (DAC) module is (re)started". >=20 > Why only the DAC module? IMO, in theory, a DAC/DAS can be restarted regardless of the system restart(or sysUpTime). A similar statement is applicable to DAS Mib/module. Thanks Nagi. >=20 > /js >=20 > --=20 > Juergen Schoenwaelder International University Bremen > P.O. Box 750 561,=20 > 28725 Bremen, Germany >=20 -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Mon, 20 Mar 2006 08:51:06 +0000 Date: Mon, 20 Mar 2006 09:50:46 +0100 From: Juergen Schoenwaelder To: "Nagi Reddy Jonnala (njonnala)" Cc: "Wijnen, Bert (Bert)" , stefaan.de_cnodder@alcatel.be, radiusext@ops.ietf.org, "Dan Romascanu (E-mail)" Subject: Re: MIB Counters discontinuity (Was RE: radius dynauth client/server mibs structure) Message-ID: <20060320085046.GA18027@boskop.local> Reply-To: j.schoenwaelder@iu-bremen.de Mail-Followup-To: "Nagi Reddy Jonnala (njonnala)" , "Wijnen, Bert (Bert)" , stefaan.de_cnodder@alcatel.be, radiusext@ops.ietf.org, "Dan Romascanu (E-mail)" Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.10i On Mon, Mar 20, 2006 at 02:06:16PM +0530, Nagi Reddy Jonnala (njonnala) wrote: > Juergen, Bert and all, > > We have two options then. Please let us know which one works for you. > > 1. As Juergen suggested "This counter uses sysUpTime as the > discontinuity indicator. Any discontinuity of this counter must cause a > reset of sysUpTime." > > 2. All we want to convey in the MIBs is that the counter might > experience discontinuity when the respective (DAC or DAS) module is > (re)started. Not sure if we need to draw any relation to sysUpTime or > some other object. Is implementing the sysUptime mandatory? An SNMP agent without sysUptime (the default discontinuity indicator for all counters) is kind of broken. > If not, does the below work? > > "This counter may experience discontinuity when the Dynamic > Authorization Client (DAC) module is (re)started". Why only the DAC module? /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Mon, 20 Mar 2006 08:36:28 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: MIB Counters discontinuity (Was RE: radius dynauth client/server mibs structure) Date: Mon, 20 Mar 2006 14:06:16 +0530 Message-ID: <61D6551D82BC7149967B39B5C66879F86FF185@xmb-blr-416.apac.cisco.com> Thread-Topic: MIB Counters discontinuity (Was RE: radius dynauth client/server mibs structure) Thread-Index: AcZL8TqEaulbDGFPT7ChUKAGSu508wABcyJw From: "Nagi Reddy Jonnala \(njonnala\)" To: , "Wijnen, Bert \(Bert\)" Cc: , , "Dan Romascanu \(E-mail\)" Juergen, Bert and all, We have two options then. Please let us know which one works for you. 1. As Juergen suggested "This counter uses sysUpTime as the discontinuity indicator. Any discontinuity of this counter must cause a reset of sysUpTime." 2. All we want to convey in the MIBs is that the counter might experience discontinuity when the respective (DAC or DAS) module is (re)started. Not sure if we need to draw any relation to sysUpTime or some other object. Is implementing the sysUptime mandatory? If not, does the below work? "This counter may experience discontinuity when the Dynamic Authorization Client (DAC) module is (re)started". Thanks Nagi > -----Original Message----- > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@iu-bremen.de]=20 > Sent: Monday, March 20, 2006 1:08 PM > To: Nagi Reddy Jonnala (njonnala) > Cc: stefaan.de_cnodder@alcatel.be; Wijnen, Bert (Bert);=20 > radiusext@ops.ietf.org; Dan Romascanu (E-mail) > Subject: Re: radius dynauth client/server mibs structure >=20 > On Mon, Mar 20, 2006 at 10:26:32AM +0530, Nagi Reddy Jonnala=20 > (njonnala) wrote: > =20 > > I believe sysUpTime is typically used to record the system uptime. >=20 > No. >=20 > > However the above definition seems to underscore that it=20 > records the=20 > > network management portion of the system and not=20 > necessarily the whole=20 > > system. Agree? >=20 > Yes, I believe the definition in RFC 3418 to be correct. >=20 > > As I mentioned in the other thread, how about the below. > >=20 > > "This counter *may* experience a discontinuity when the system=20 > > (re)starts as indicated by the value of sysUpTime." >=20 > The system restart event is not really important (as it=20 > causes sysUpTime to be likely reset and managers will simply=20 > deal with it). The more interesting event is the restart of=20 > the subsystem that maintains the MIB counters, e.g., the=20 > restart of the RADIUS server itself. >=20 > /js >=20 > --=20 > Juergen Schoenwaelder International University Bremen > P.O. Box 750 561,=20 > 28725 Bremen, Germany >=20 -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Mon, 20 Mar 2006 07:38:41 +0000 Date: Mon, 20 Mar 2006 08:37:47 +0100 From: Juergen Schoenwaelder To: "Nagi Reddy Jonnala (njonnala)" Cc: stefaan.de_cnodder@alcatel.be, "Wijnen, Bert (Bert)" , radiusext@ops.ietf.org, "Dan Romascanu (E-mail)" Subject: Re: radius dynauth client/server mibs structure Message-ID: <20060320073747.GA12834@boskop.local> Reply-To: j.schoenwaelder@iu-bremen.de Mail-Followup-To: "Nagi Reddy Jonnala (njonnala)" , stefaan.de_cnodder@alcatel.be, "Wijnen, Bert (Bert)" , radiusext@ops.ietf.org, "Dan Romascanu (E-mail)" Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.10i On Mon, Mar 20, 2006 at 10:26:32AM +0530, Nagi Reddy Jonnala (njonnala) wrote: > I believe sysUpTime is typically used to record the system uptime. No. > However the above definition seems to underscore that it records the > network management portion of the system and not necessarily the whole > system. Agree? Yes, I believe the definition in RFC 3418 to be correct. > As I mentioned in the other thread, how about the below. > > "This counter *may* experience a discontinuity when the system > (re)starts as indicated by the value of sysUpTime." The system restart event is not really important (as it causes sysUpTime to be likely reset and managers will simply deal with it). The more interesting event is the restart of the subsystem that maintains the MIB counters, e.g., the restart of the RADIUS server itself. /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Mon, 20 Mar 2006 04:57:12 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: radius dynauth client/server mibs structure Date: Mon, 20 Mar 2006 10:26:32 +0530 Message-ID: <61D6551D82BC7149967B39B5C66879F86FF17F@xmb-blr-416.apac.cisco.com> Thread-Topic: radius dynauth client/server mibs structure Thread-Index: AcZLnxr55cZDbwukSKO3ZSUB5Ut1dQAOOMtg From: "Nagi Reddy Jonnala \(njonnala\)" To: , Cc: "Wijnen, Bert \(Bert\)" , , "Dan Romascanu \(E-mail\)" Juergen, Please see inline. =20 > Are you sure? I see two problems with the sentence above: >=20 > (a) sysUpTime does not record the system uptime; here is what RFC 3418 > tells us: >=20 > "The time (in hundredths of a second) since the > network management portion of the system was last > re-initialized." I believe sysUpTime is typically used to record the system uptime. However the above definition seems to underscore that it records the network management portion of the system and not necessarily the whole system. Agree? As I mentioned in the other thread, how about the below. "This counter *may* experience a discontinuity when the system (re)starts as indicated by the value of sysUpTime."=20 >=20 > (b) are you really sure counters will not have a discontinuity if a > RADIUS server is restarted? Counters which live in a Radius server > (e.g. an embedded AgentX client) most likely won't be=20 > persistent... It may not be the case (at least for the NASes) with the distribution model.=20 Thanks Nagi. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Mon, 20 Mar 2006 04:35:04 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: MIB Counters discontinuity (Was RE: radius dynauth client/server mibs structure) Date: Mon, 20 Mar 2006 10:03:57 +0530 Message-ID: <61D6551D82BC7149967B39B5C66879F86FF17E@xmb-blr-416.apac.cisco.com> Thread-Topic: MIB Counters discontinuity (Was RE: radius dynauth client/server mibs structure) Thread-Index: AcZLGEpqQqAtRtlVS9Wy+ae53baKugAvnFvA From: "Nagi Reddy Jonnala \(njonnala\)" To: "Wijnen, Bert \(Bert\)" , Cc: , "Dan Romascanu \(E-mail\)" Bert, > Mmm... the "wraps from the max value to zero" is redundant,=20 > because that is the behaviour of every Counter32 and=20 > Counter64. That is already specified in RFC2578. > W.r.t "is reset upon system (re)initialization", that is not=20 > exactly waht we wanted either. I do not know what you mean=20 > with "reset". > It is not REQUIRED that counter reset to sero (if that is=20 > what you mean). > They MAY do so, butnot required. > I think what you want to write is: >=20 > This counter will only experience a discuntinuity when the system > (re)starts as indicated by the value of sysUpTime. >=20 Do you think mentioning "may" in the sentence is appropriate. "This counter may experience a discontinuity when the system (re)starts as indicated by the value of sysUpTime."=20 Thanks Nagi. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Sun, 19 Mar 2006 21:49:49 +0000 Date: Sun, 19 Mar 2006 22:49:25 +0100 From: Juergen Schoenwaelder To: stefaan.de_cnodder@alcatel.be Cc: "Wijnen, Bert (Bert)" , radiusext@ops.ietf.org, "Dan Romascanu (E-mail)" Subject: Re: radius dynauth client/server mibs structure Message-ID: <20060319214925.GA8549@boskop.local> Reply-To: j.schoenwaelder@iu-bremen.de Mail-Followup-To: stefaan.de_cnodder@alcatel.be, "Wijnen, Bert (Bert)" , radiusext@ops.ietf.org, "Dan Romascanu (E-mail)" Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.10i On Sun, Mar 19, 2006 at 10:18:07PM +0100, stefaan.de_cnodder@alcatel.be wrote: > >I think what you want to write is: > > > > This counter will only experience a discuntinuity when the system > > (re)starts as indicated by the value of sysUpTime. > > Ok, I got the point. we will use this sentence and correct it for both docs. Are you sure? I see two problems with the sentence above: (a) sysUpTime does not record the system uptime; here is what RFC 3418 tells us: "The time (in hundredths of a second) since the network management portion of the system was last re-initialized." (b) are you really sure counters will not have a discontinuity if a RADIUS server is restarted? Counters which live in a Radius server (e.g. an embedded AgentX client) most likely won't be persistent... Perhaps you really want to state that the counters use sysUpTime as the discontinuity indicator and that any discontinuities the counters may experience causes a reset of sysUpTime (if you really want this behavior): This counter uses sysUpTime as the discontinuity indicator. Any discontinuity of this counter must cause a reset of sysUpTime. Another option could be to use the relevant sysORUpTime object as the discontinuity indicator but then this would require proper implementation of the sysORTable and stupid managers will rely on the default sysUpTime anyway (if they check for discontinuities at all). /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Sun, 19 Mar 2006 21:18:54 +0000 Message-ID: <441DCA8F.40203@alcatel.be> Date: Sun, 19 Mar 2006 22:18:07 +0100 From: stefaan.de_cnodder@alcatel.be User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20040910 MIME-Version: 1.0 To: "Wijnen, Bert (Bert)" Cc: radiusext@ops.ietf.org, "Dan Romascanu (E-mail)" Subject: Re: radius dynauth client/server mibs structure Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed Hi Bert, Thanks for these comments. We will limit the Address type to IPv4 and IPv6. see more below Wijnen, Bert (Bert) wrote: > I checked both new documents. > > You may want to check on page 7/8: > Copyright (C) The Internet Society (2006). Initial > version as published in RFC yyyy; > for full legal notices see the RFC its" > -- RFC Ed.: replace yyyy with actual RFC number & remove this note > > So I huess this sentence is incomplete: see the RFC its ??? > Probably should be: see the RFC itself. > yes something went worng here with the last update of the draft and a part of the sentence disappeared. > >>- add sentence "This counter wraps from the maximum value to >>zero and is >>reset upon system (re)initialization." for all counters of type >>Counter32 > > > Mmm... the "wraps from the max value to zero" is redundant, because > that is the behaviour of every Counter32 and Counter64. That is > already specified in RFC2578. > W.r.t "is reset upon system (re)initialization", that is not exactly > waht we wanted either. I do not know what you mean with "reset". > It is not REQUIRED that counter reset to sero (if that is what you mean). > They MAY do so, butnot required. > I think what you want to write is: > > This counter will only experience a discuntinuity when the system > (re)starts as indicated by the value of sysUpTime. > > Ok, I got the point. we will use this sentence and correct it for both docs. Currently version 04 is already submitted, so we will make it version 05. Thanks, Stefaan > >>- remove ref to IANA copyright. > > > thanks > > >>- some minor formatting (line breaks in the mib) >> > > > OK > > My comments to the other 4 mib docs (2618bis etc) also apply for > your use of InetAddress and InetAddressType. I know I did say (in my point 3) > last time that this was acceptable for Informational RFC. But now that I > reviewed the other MIB modules and now that I am asking for the below > updates tyo those, it would be best to do so too for these 2 > modules, in order to be consistent for all RADIUS related MIB modules. > So pls translate the following to your own objects and consider to > make similar changes: > > - radiusAuthServerInetAddress OBJECT-TYPE > SYNTAX InetAddress > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "The IP address of the RADIUS authentication > server referred to in this table entry, using > the version neutral IP address format." > ::= { radiusAuthServerExtEntry 3 } > > according to RFC4001, you MUST specify which object of SYNTAX > InetAddressType controls the format of this object. I t is clear > which one it is, b ut it would be good to add that. > > - radiusAuthClientServerInetPortNumber > According to RFC4001, you must specify what the value zero means > for this object. > > - for this one > radiusAuthClientExtMIBCompliance MODULE-COMPLIANCE > STATUS current > DESCRIPTION > "The compliance statement for authentication > clients implementing the RADIUS Authentication > Client IPv6 Extensions MIB. Implementation of > this module is for entities that support IPv6, > or support IPv4 and IPv6." > MODULE -- this module > MANDATORY-GROUPS { radiusAuthClientExtMIBGroup } > > ::= { radiusAuthClientMIBCompliances 2 } > > I think it would be better to do: > > radiusAuthClientExtMIBCompliance MODULE-COMPLIANCE > STATUS current > DESCRIPTION > "The compliance statement for authentication > clients implementing the RADIUS Authentication > Client IPv6 Extensions MIB. Implementation of > this module is for entities that support IPv6, > or support IPv4 and IPv6." > MODULE -- this module > MANDATORY-GROUPS { radiusAuthClientExtMIBGroup } > > OBJECT radiusAuthServerInetAddressType > SYNTAX InetAddressType { ipv4(1), ipv6(2) } > DESCRIPTION > "An implementation is only required to support IPv4 and > globally unique IPv6 addresses." > > OBJECT radiusAuthServerInetAddress > SYNTAX InetAddress (SIZE(4|16)) > DESCRIPTION > "An implementation is only required to support IPv4 and > globally unique IPv6 addresses." > > Bert > >>I tried a diff but that output is rather messy, so I sent you the >>complete drafts. >> >>Thanks, >>Stefaan >> > > > -- > to unsubscribe send a message to radiusext-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: > -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Sun, 19 Mar 2006 05:45:14 +0000 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B155098E2111@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: Bernard Aboba , radiusext@ops.ietf.org Cc: aaa-wg@merit.edu Subject: RE: Review of RADIUS Digest-07 Document Date: Sun, 19 Mar 2006 06:43:53 +0100 MIME-Version: 1.0 Content-Type: text/plain [when responding, it is probably best to only copy the radiusext WG list and not the AAA WG list.] Do the new rev is available, in fact has been since Mar 8th. Do we have consensus that this is now OK and that we can check if security ADs are also happy, and as a result we can then also finish the draft-ietf-aaa-diameter-sip-app-xx.txt document? It would be really great if we can finalize (i.e. get acceptable I-Ds posted) by Wed at the latest, so we can try and clear these 2 documents for approval. Pleas keep in mind my response to the updated version: > Wolfgang wrote: > my main focus for the -07 version was to address the 'discuss' > points from the IESG site. > In fact, since the document was (and basically still is) in IESG evaluation, I think the WG should not add new issues/concerns unless there is a FATAL FLAW that we discovered late. Bert (speaking as one of the ADs). Bert > -----Original Message----- > From: owner-aaa-wg@merit.edu > [mailto:owner-aaa-wg@merit.edu]On Behalf Of > Bernard Aboba > Sent: Tuesday, March 07, 2006 17:04 > To: aaa-wg@merit.edu > Subject: [AAA-WG]: Review of RADIUS Digest-07 Document > > > A new version of the RADIUS Digest document has been > submitted in response > to IETF last call and IESG DISCUSS comments. Until the > specification ends > up on the archive, it is available here: > http://www.drizzle.com/~aboba/RADEXT/draft-ietf-radext-digest- > auth-07.txt > > When it ends up on the archive, it will be available here: > http://www.ietf.org/internet-drafts/draft-ietf-radext-digest-a > uth-07.txt > > Please examine this new version of the document to see whether it > addresses the open issues, which were filed on the RADEXT WG > issues list: > http://www.drizzle.com/~aboba/RADEXT/ > > These include the following: > > Issue # Title Owner > > ---------- ------------------------- ---------------------- > 150 IANA Considerations John Loughney > 151 Another review Kurt Zeilenga > 152 Review Alexey Melnikov > 159 Negotiation Wolfgang Beck > 162 Nonce Replay Issue Wolfgang Beck > 173 Client Nonce Generation Sam Hartman > 174 Review Russ Housley > 175 Some NITs Bert Wijnen > > In particular, the following questions should have been addressed: > > * Handling of client/server nonce generation (comments from > Sam Hartman, > Glen Zorn and others) > * Extensibility for new algorithms (Russ Housley) > * Editorial comments (many) > > > -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Sun, 19 Mar 2006 05:45:06 +0000 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B155098E211B@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: radiusext@ops.ietf.org Cc: "Dan Romascanu (E-mail)" , "David Kessens (E-mail)" Subject: AD review of rfc2618bis-02 through rfc2621bis-02 Date: Sun, 19 Mar 2006 06:43:58 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Editor and WG, Dan had already done MIB doctor review and he is basically OK I believe). So I did a quick check in my role as AD. draft-ietf-radext-rfc2618bis-02.txt draft-ietf-radext-rfc2619bis-02.txt draft-ietf-radext-rfc2620bis-02.txt draft-ietf-radext-rfc2621bis-02.txt I did just do draft-ietf-radext-rfc2618bis-02.txt The others probably have similar minor issues. As far as I am concerned, we can do IETF Last Call (these go for standards track so we must do IETF LC) now. You can then consider below comments as the first set of IETF LC comments. And then address them right after IETF Last Call, or maybe you want to wait and see if there are any IESG comments that you could address at the same time. By that time, Dan will tell you how to proceed. Bert ---- comments somewhat MUST change comments (easy, and basically admin bureaucracy, but would be good to change): We do want a copyright statement in the DESCRIPTION clause of a module identity. So change OLD: DESCRIPTION "The MIB module for entities implementing the client side of the Remote Authentication Dial-In User Service (RADIUS) authentication protocol." NEW: DESCRIPTION "The MIB module for entities implementing the client side of the Remote Authentication Dial-In User Service (RADIUS) authentication protocol. Copyright (C) The Internet Society (2006). This version of this MIB module is part of RFC xxxx; see the RFC itself for full legal notices." -- RFC Ed.: replace xxxx with actual RFC number & remove this note - radiusAuthServerInetAddress OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS read-only STATUS current DESCRIPTION "The IP address of the RADIUS authentication server referred to in this table entry, using the version neutral IP address format." ::= { radiusAuthServerExtEntry 3 } according to RFC4001, you MUST specify which object of SYNTAX InetAddressType controls the format of this object. I t is clear which one it is, b ut it would be good to add that. - radiusAuthClientServerInetPortNumber According to RFC4001, you must specify what the value zero means for this object. - for this one radiusAuthClientExtMIBCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for authentication clients implementing the RADIUS Authentication Client IPv6 Extensions MIB. Implementation of this module is for entities that support IPv6, or support IPv4 and IPv6." MODULE -- this module MANDATORY-GROUPS { radiusAuthClientExtMIBGroup } ::= { radiusAuthClientMIBCompliances 2 } I think it would be better to do: radiusAuthClientExtMIBCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for authentication clients implementing the RADIUS Authentication Client IPv6 Extensions MIB. Implementation of this module is for entities that support IPv6, or support IPv4 and IPv6." MODULE -- this module MANDATORY-GROUPS { radiusAuthClientExtMIBGroup } OBJECT radiusAuthServerInetAddressType SYNTAX InetAddressType { ipv4(1), ipv6(2) } DESCRIPTION "An implementation is only required to support IPv4 and globally unique IPv6 addresses." OBJECT radiusAuthServerInetAddress SYNTAX InetAddress (SIZE(4|16)) DESCRIPTION "An implementation is only required to support IPv4 and globally unique IPv6 addresses." - real nits and admin stuff !! Contains embedded space: P004 L021: textual conventions defined in this memo [RFC 4001] that support all !! Missing citation for Normative reference: P020 L018: [RFC2574] Blumenthal, U. and B. Wijnen, "User-based Security Model !! Missing citation for Normative reference: P020 L022: [RFC2575] Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based !! Missing citation for Normative reference: P020 L049: [RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An !! Missing citation for Normative reference: P021 L006: [RFC3418] Presuhn, R., "Management Information Base (MIB) for the RFC2574 and RFC2575 should be replaced by RFC3414 and RFC3415 RFC3410 is better listed as an Informative reference. In general, pls re-check all citations/references. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Sun, 19 Mar 2006 05:44:58 +0000 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B155098E211C@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: stefaan.de_cnodder@alcatel.be Cc: radiusext@ops.ietf.org, "Dan Romascanu (E-mail)" Subject: RE: radius dynauth client/server mibs structure Date: Sun, 19 Mar 2006 06:43:59 +0100 MIME-Version: 1.0 Content-Type: text/plain I checked both new documents. You may want to check on page 7/8: Copyright (C) The Internet Society (2006). Initial version as published in RFC yyyy; for full legal notices see the RFC its" -- RFC Ed.: replace yyyy with actual RFC number & remove this note So I huess this sentence is incomplete: see the RFC its ??? Probably should be: see the RFC itself. More below. I propose to make the changes as suggested here and then submit to ID-repository. I believe it opens up again on Monday during IETF65. See further inline: > -----Original Message----- > From: stefaan.de_cnodder@alcatel.be > [mailto:stefaan.de_cnodder@alcatel.be] > Sent: Monday, March 13, 2006 22:05 > To: Nelson, David; Wijnen, Bert (Bert) > Cc: Nagi Reddy Jonnala (njonnala); j.schoenwaelder@iu-bremen.de; > radiusext@ops.ietf.org > Subject: Re: radius dynauth client/server mibs structure > > > > Hi Bert, Dave, > > The updated versions are attached. > > Changes are: > - change 2005 into 2006 in DESCRIPTION of MIB good, but see above > - group the scalars according the comment of Juergen Looks good to me now > - add sentence "This counter wraps from the maximum value to > zero and is > reset upon system (re)initialization." for all counters of type > Counter32 Mmm... the "wraps from the max value to zero" is redundant, because that is the behaviour of every Counter32 and Counter64. That is already specified in RFC2578. W.r.t "is reset upon system (re)initialization", that is not exactly waht we wanted either. I do not know what you mean with "reset". It is not REQUIRED that counter reset to sero (if that is what you mean). They MAY do so, butnot required. I think what you want to write is: This counter will only experience a discuntinuity when the system (re)starts as indicated by the value of sysUpTime. > - remove ref to IANA copyright. thanks > - some minor formatting (line breaks in the mib) > OK My comments to the other 4 mib docs (2618bis etc) also apply for your use of InetAddress and InetAddressType. I know I did say (in my point 3) last time that this was acceptable for Informational RFC. But now that I reviewed the other MIB modules and now that I am asking for the below updates tyo those, it would be best to do so too for these 2 modules, in order to be consistent for all RADIUS related MIB modules. So pls translate the following to your own objects and consider to make similar changes: - radiusAuthServerInetAddress OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS read-only STATUS current DESCRIPTION "The IP address of the RADIUS authentication server referred to in this table entry, using the version neutral IP address format." ::= { radiusAuthServerExtEntry 3 } according to RFC4001, you MUST specify which object of SYNTAX InetAddressType controls the format of this object. I t is clear which one it is, b ut it would be good to add that. - radiusAuthClientServerInetPortNumber According to RFC4001, you must specify what the value zero means for this object. - for this one radiusAuthClientExtMIBCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for authentication clients implementing the RADIUS Authentication Client IPv6 Extensions MIB. Implementation of this module is for entities that support IPv6, or support IPv4 and IPv6." MODULE -- this module MANDATORY-GROUPS { radiusAuthClientExtMIBGroup } ::= { radiusAuthClientMIBCompliances 2 } I think it would be better to do: radiusAuthClientExtMIBCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for authentication clients implementing the RADIUS Authentication Client IPv6 Extensions MIB. Implementation of this module is for entities that support IPv6, or support IPv4 and IPv6." MODULE -- this module MANDATORY-GROUPS { radiusAuthClientExtMIBGroup } OBJECT radiusAuthServerInetAddressType SYNTAX InetAddressType { ipv4(1), ipv6(2) } DESCRIPTION "An implementation is only required to support IPv4 and globally unique IPv6 addresses." OBJECT radiusAuthServerInetAddress SYNTAX InetAddress (SIZE(4|16)) DESCRIPTION "An implementation is only required to support IPv4 and globally unique IPv6 addresses." Bert > I tried a diff but that output is rather messy, so I sent you the > complete drafts. > > Thanks, > Stefaan > -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 17 Mar 2006 22:56:13 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: REMINDER: Submission of presentations (slides) for the RADEXT WG session at IETF-65 Date: Fri, 17 Mar 2006 17:55:36 -0500 Message-ID: <3CFB564E055A594B82C4FE89D215656021915C@MABOSEVS2.ets.enterasys.com> Thread-Topic: REMINDER: Submission of presentations (slides) for the RADEXT WG session at IETF-65 Thread-Index: AcZG0piM0KX+EfAZR82+k+XpnbGSvADQxjvw From: "Nelson, David" To: Cc: "Bernard Aboba" , "Nelson, David" REMINDER: =20 > Please submit your RADEXT WG presentation materials to the chairs ASAP. > We would *really* like to have them all posted prior to the RADEXT session > on Tuesday morning of IETF week. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 17 Mar 2006 17:10:00 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Proposed Resolution to Issue 180: Misuse of Data Types Date: Fri, 17 Mar 2006 12:09:10 -0500 Message-ID: <15B86BC7352F864BB53A47B540C089B6015B4777@xmb-rtp-20b.amer.cisco.com> Thread-Topic: Proposed Resolution to Issue 180: Misuse of Data Types Thread-Index: AcZJJaez5C50LytGSvGulkIoZn/6jgAvwwIg From: "Greg Weber \(gdweber\)" To: "Bernard Aboba" Cc: =20 Now the VLAN-01 strawman says: The VLAN Flag field is one octet in length,=20 and indicates whether the frames on the VLAN=20 are tagged (0x31) or untagged (0x32).=20 But it doesn't say *how* the flag field indicates=20 tagged vs. untagged. With the attribute name being VLAN Flag, I would think that attribute's values would be 1 or 0. Do I indicate 'tagged' by setting the value of VLAN Flag to 1 or to 0x31? Greg > -----Original Message----- > From: owner-radiusext@ops.ietf.org=20 > [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Bernard Aboba > Sent: Thursday, March 16, 2006 1:15 PM > To: radiusext@ops.ietf.org > Subject: Proposed Resolution to Issue 180: Misuse of Data Types >=20 > The text of Issue 180 (and some of the subsequent discussion)=20 > is enclosed=20 > below. >=20 > The proposed resolution is to change "VLAN Tag" to "VLAN=20 > Flag" everywhere in=20 > the document. >=20 > In looking at the mailing list discussion, I did not detect=20 > consensus for=20 > making other changes. >=20 > -------------------------------------------------------------- > -------------------------------------- > Issue 180: Misuse of Data Types > Submitter name: Dave Nelson > Submitter email address: dnelson@enterasys.com > Date first submitted: March 14, 2006 > Reference: http://ops.ietf.org/lists/radiusext/2006/msg00280.html > Document: VLAN/Priority -00 > Comment type: 'T'echnical > Priority: '1' Should fix > Section: 2.1. Egress-VLANID > Rationale/Explanation of issue: >=20 > I had previously raised this issue, and the resolution was we=20 > could use a=20 > RADIUS data > type of Integer, because only the VLANID (12-bit) portion=20 > would be used.=20 > Thus, this object could be thought of as a range-limited=20 > integer. Since I=20 > see that we still have the VLAN Tag fields, that resolution=20 > falls apart. I=20 > claim that this data object is not an Integer. >=20 > Someone offered the suggestion that Integers are not simply=20 > the mathematical=20 > definition, i.e. the positive and negative whole numbers and=20 > zero, that we=20 > all learned in high school. With all due respect, >=20 > I think that's patently wrong. It is true that one can write=20 > programs that=20 > treat 8-bit, 16-bit, > 32-bit or 64-bit "integers" as packed data structures using=20 > mask, bit-field,=20 > shift and rotate operations. >=20 > I still claim that those data structures are *not* integers=20 > simply because=20 > they can be packed within > the computer memory storage that is also used by integers.=20 > Hopefully, there=20 > is more to data modeling than the storage length in bits. :-) >=20 > We are currently having a debate on the RADEXT WG list about=20 > the issue of=20 > derived data types, and no consensus has yet been reached.=20 > However, until=20 > such a consensus is reached, it seems most appropriate to follow the=20 > existing practice of defining derived data types as Strings, with the=20 > bit-fields described in the text. I think that over-loading=20 > base RADIUS data=20 > types with new meanings is inappropriate. >=20 > Given the relative timing of WGLC on this draft and the=20 > emerging consensus=20 > on RADIUS Attribute Design Guidelines, I think this is the=20 > best compromise. >=20 > Requested change: >=20 > OLD: >=20 > Integer >=20 > The Integer field is four octets in length. The format is > described below: >=20 > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | VLAN Tag | Pad | VLANID | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >=20 > The VLAN Tag field is one octet in length, and indicates whether > the frames on the VLAN are tagged (0x31) or untagged (0x32). The > Pad field is 12-bits in length and MUST be 0 (zero). The VLANID is > 12-bits in length and contains the [IEEE-802.1Q] VLAN VID value. >=20 > NEW: >=20 > String >=20 > The String field is four octets in length. The format is > described below: >=20 > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | VLAN Tag | Pad | VLANID | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >=20 > The VLAN Tag field is one octet in length, and indicates whether > the frames on the VLAN are tagged (0x31) or untagged (0x32). The > Pad field is 12-bits in length and MUST be 0 (zero). The VLANID is > 12-bits in length and contains the [IEEE-802.1Q] VLAN VID value. >=20 > Section: 2.3. Egress-VLAN-Name > Rationale/Explanation of issue: >=20 > I'm rather uncomfortable with the usage of the VLAN Tag=20 > field, as it seems=20 > to be at variance > with the emerging WG consensus on complex or structured data=20 > types. Once we=20 > standardize > this usage, there will be one more precedent in a RADIUS RFC=20 > to support=20 > ad-hoc data typing. > If that's what RADEXT ultimately recommends, then this will=20 > be fine. If the=20 > recommendation > is to use a more formal method of aggregating structured=20 > data, this will be=20 > one more anomaly. >=20 > VLAN Tag >=20 > The VLAN tag field is one octet in length, and indicates whether > the frames on the VLAN are tagged (0x31) or untagged (0x32). >=20 > Requested change: >=20 > I have no idea what (if any change) to request. Chalk this=20 > comment up as my=20 > personal lament > over the process that RADEXT has followed -- delaying consensus on=20 > attributes design to the > point where we are standardizing new attributes using complex=20 > data types=20 > prior to having > defined the design guidelines for complex data types. >=20 > Section 2.4 User-Priority-Table > Rationale/Explanation of issue: >=20 > With all due deference to the well understood "array - string=20 > duality" we=20 > find in programming > languages such as C, I think that expressing a attribute=20 > whose value is an=20 > array in the form of > a RADIUS String type is unfortunate, for the reasons expressed above. >=20 > Requested change: >=20 > (See above.) >=20 > The only way that I see to actually resolve my data typing /=20 > data modeling=20 > concerns is to delay > sending any RADEXT work item that uses derived data types to=20 > the IESG until=20 > after we have sent > the RADIUS Design Guidelines and RADIUS Extended Attributes=20 > I-Ds to the=20 > IESG, and that approach > is not compatible with our milestones. >=20 > [Glen Zorn] > With all due respect, I think that you are the one doing the=20 > overloading:=20 > RFC 2568 says >=20 > integer 32 bit unsigned value, most significant octet first. >=20 > That's it. No range, no interpretation, nothing else. >=20 > [Emile Van Bergen] > >I see nothing that indicates this data type is anything other than an > >integer, typically expressed in a C language declaration as "unsigned > >long". >=20 > You're completely correct. And in the case of the VLAN attribute, it > *does* contain an unsigned integer value, one that's=20 > calculated as follows: >=20 > value =3D vlanflag * 16777216 + vlanid >=20 > The reverse goes as follows: >=20 > vlanflag =3D value / 16777216 > vlanid =3D value % 16777216 >=20 > (where > * denotes unsigned integer multiplication, > + denotes unsigned integer addition, > / denotes unsigned integer division and > % denotes taking the reminder of an unsigned integer division, > all to be carried out on unsigned integers in the range 0 .. 2**32-1) >=20 > I'm not believing that people on this list would have to be explained > that shifting and masking bits are *not* magic operations that you can > only perform if you program in assembly (or its portable flavour, C), > but that those are normal mathematical operations on normal integers: > multiply and take remainder (by powers of 2). >=20 > You can do that, I think, even in Java, SAP/r3, XSLT, SQL and=20 > whatever. > This whole issue has nothing whatsoever to do with C structures. >=20 >=20 >=20 > -- > to unsubscribe send a message to radiusext-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: >=20 -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 17 Mar 2006 02:59:32 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: New Technical Issues RE: WG last call in progress on VLAN/Priority Draft Date: Thu, 16 Mar 2006 22:01:14 -0500 Message-ID: Thread-Topic: New Technical Issues RE: WG last call in progress on VLAN/Priority Draft Thread-Index: AcZJOnCZyhp+R880T9yAN4yHDp+O+gADtNWg From: "Avi Lior" To: "Emile van Bergen" , "Glen Zorn \(gwz\)" Cc: "Barney Wolff" , "Alan DeKok" , Emile,=20 > This WGs very existence, how reluctantly it was started, is=20 > testament that people rather build upon RADIUS than look at=20 > DIAMETER for their solutions. I am sorry you don't get it!!!=20 It's not that we rather build upon RADIUS. We live in a commercial world that requires us to build upon RADIUS. We are not given a choice. We have paying customers who invested millions of dollars each in their RADIUS infrastructure and they don't want it to go away (yet). > I find it then entirely foolish to suggest that a blanket=20 > transport mechanism for DIAMETER inside RADIUS would solve=20 > all our issues.=20 Given the evidence I have seen, the Diameter encoding will work. Take away the 'M' and 'P' bits because I don't think those make sense much. Any shortcomings should be addressable -- unless of course the IETF decides to get in the way as they do with RADIUS. > I find it incomprehensible that the DIAMETER format would not=20 > need any evaluation against the alternatives on the merits,=20 > but that people can just wave their hands and say, there's=20 > already some diameter parsing code in many RADIUS server's=20 > that support TTLS in some form or other, so hey, 'tis the=20 > only sensible road ahead. If you want to transition from RADIUS to Diameter why not get the attributes aligned -- it will make the cut over a lot easier. =20 > Really, is that all we can muster these days? I havent seen any better approach so I guess -- yes. I am sorry that makes you sad. > Cheers, >=20 >=20 > Emile. >=20 > --=20 > E-Advies - Emile van Bergen emile@e-advies.nl =20 > tel. +31 (0)78 6136282 http://www.e-advies.nl =20 >=20 -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 16 Mar 2006 23:51:11 +0000 Date: Fri, 17 Mar 2006 00:51:07 +0100 From: Emile van Bergen To: Alan DeKok Cc: radiusext@ops.ietf.org Subject: Re: New Technical Issues RE: WG last call in progress on VLAN/Priority Draft Message-ID: <20060316235107.GF3623@note.evbergen.xs4all.nl> Mail-Followup-To: Alan DeKok , radiusext@ops.ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.9i Hi, On Thu, Mar 16, 2006 at 06:06:33PM -0500, Alan DeKok wrote: > Emile van Bergen wrote: > > I find it incomprehensible that the DIAMETER format would not need any > > evaluation against the alternatives on the merits, but that people can > > just wave their hands and say, there's already some diameter parsing > > code in many RADIUS server's that support TTLS in some form or other, so > > hey, 'tis the only sensible road ahead. > > s/only/proven working, implemented, deployed, and functional/ > > If there are other alternatives, they should be explored, of course. > But the diameter format, while wasteful of space in the RADIUS packet, > *is* a proven one. It's proven as a working AAA protocol. It's not yet proven as the successor to RADIUS. It's not proven as the best way to fix urgent RADIUS issues ad interim, as our charter sets out to do, before people move to DIAMETER. Cheers, Emile. -- E-Advies - Emile van Bergen emile@e-advies.nl tel. +31 (0)78 6136282 http://www.e-advies.nl -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 16 Mar 2006 23:48:37 +0000 Date: Fri, 17 Mar 2006 00:48:05 +0100 From: Emile van Bergen To: "Nelson, David" Cc: radiusext@ops.ietf.org Subject: Re: Attribute design thoughts (was RE: New Technical Issues RE: WG last call in progress on VLAN/Priority Draft) Message-ID: <20060316234804.GE3623@note.evbergen.xs4all.nl> Mail-Followup-To: "Nelson, David" , radiusext@ops.ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.9i Hi, On Wed, Mar 15, 2006 at 11:17:31AM -0500, Nelson, David wrote: > Emile van Bergen writes... > > > We're having a theoretical debate, and you're not answering the > > question. Let me try again. If RFC 2865 didn't have a time base type, > > how would you propose a session time to be conveyed? As an attribute > > consisting of subattributes allocated from a global IANA Type number > > space, however wide? > > OK, theoretically speaking then. > > If there were no RADIUS time data type, then I would search to see if > there were a standard one in common use, preferably one with a stable > reference, e.g. an RFC. I would almost certainly choose Unix Epoch time > (seconds since January 1, 1970) which conveniently fits in an Integer. > If I were worried about the 2024 (or whenever) wrap-around, I'd find > another standard representation, and use that (maybe an unsigned long > long, i.e. 64-bit integer). If I were *forced* to use the > representation you suggest, i.e. separate members of a structure for > each of the "units" of time, and there were no existing standard I could > reference, then I would look to the RADIUS Design Guidelines to see what > is recommended. Ok. So if I understand you correctly, you would suggest the current criteria? 1. does a widely accepted standard type for the information exist? If so, any packing used in that is OK. 2. if not, and you're not *forced* to use separate members either, then ... (you did not address that situation). 3. if you're *forced* to use separate members, you'd look at the Design Guidelines to see eg. how you would use the facilities provided by the Extended Attribute. > So, I haven't answered your question yet (but I will). My point up to > this juncture is that the WG should reach a consensus on design > guidelines, and then each individual attribute design decision should be > made with the benefit of those recommendations, providing a certain > level of consistency. This shouldn't be such an ad-hoc process, IMHO. > I suppose this is a controversial opinion, something like advocating > coding style standards. :-) While I have an opinion on this, I really > don't care so much as to what the WG decides, as long as it comes to a > consensus, and does so fairly quickly. Agreed, without sacrificing correctness to speed; RADIUS in particular shows that good formats tend to stay around for a long time, sometimes even long after aspects of the originally intended applications and corresponding use style have moved on. > I would prefer that the guidelines are substantive, and provide some > real guidance, rather than simply codifying the existing ad-hoc > practices. Agreed, however, if you want to get any kind of traction with implementors, it should not be prohibitively hard, nor require a complete redesign in a completely different paradigma, to migrate from those practices to the new recommendations. There is a reason DIAMETER hasn't received the attention people expected it to get. There is also a reason it was agreed that there would be a RADEXT WG. Its very existence is a testament that DIAMETER adoption isn't going as well as intended, that vendors so far prefer RADIUS (and I would venture to say, not just due to networking (in the economic sense) effects), and that there are some problems in RADIUS that people want fixed, and fixed in RADIUS' way, not by RADIUS starting to transport DIAMETER. [snip] > How would I suggest that the design guidelines be worded to recommend > encoding of structured data representations? My suggestion would be to > use the Extended RADIUS Attribute (however it is ultimately defined) and > use whatever grouping (data aggregation) method it supports to structure > the member elements into a logical structure. This could be via > sub-attributes, or via tagged attributes, or via grouped attributes (as > in Diameter). Well, I agree, but as said in our conference call, I don't think that the current design guidelines draft should remain leading after the Extended Attribute specification is done. I view that document as a survey of issues and a proposed set of requirements for the Extended Attribute format and an accompanying usage recommendations document, if any. The only section that comes up with guidelines is section 7, and that's rather brief in comparison with the rest. I would also suggest that some of those criteria depend on what the Extended Attribute format will be. I think that the the next step is to specify the Extended Attribute format, as one that should be flexible enough to be able to absorb existing RADIUS practice, as well as providing a common solution for the largest current problems: limited standard attribute number space and size and incompatible internal VSA formats. The most common cases of vendors not used the RADIUS attribute format inside their VSAs are those that use wider attribute number fields and multiple subattributes inside one VSA. So if we address that, then together with tagging and structures, we have most things covered, and encourages vendors to use the Extended-Attribute to encapsulate all their attributes in a common format (the Extended Attribute format), instead using the Vendor-Specific attribute to encapsulate one or more of their attributes in a vendor specific manner. Client vendors worried about server support needn't worry, because a server that does not support the Extended Attribute won't support their specific internal VSA structure either, unless they use RFC 2865's suggested format for values the Vendor-Specific attribute. with vendor specific code, allow That way, dictionary based implementations can gain access to more attributes, without either requiring vendor specific code or dictionaries that define lots of encoding parameters. The last step is to provide guidance on which features of the format to use in which cases, including what data types new attributes should use, to encourage sane practice and also to cater for a smooth migration to DIAMETER later. This would be a much expanded version of Section 7 of the current Design Guidelines. The reason to do it in two layers is that structure evolves at a much slower pace than style. We still use the same protocol structure and packet structure as 9 years ago, but usage style has *much* evolved. And the structure is so popular that we're still using it. So, following the charter, I think the extended attributes (and I hope we'll have one draft to consider for adoption as a WG item, not two), should use a format (inside a space created by concatenated RADIUS attributes), that: a. is able to absorb existing practice (eg. in terms of most of the Informational RFCs we have on RADIUS) without paradigm shifts or other nontrivial transformations (ie. no wholesale encapsulation of the DIAMETER protocol in a way as done for EAP) b. addresses at least 90% of the reasons vendors didn't use the standard RADIUS format inside their VSAs (larger Type field, longer attributes), removing the need for packet parsers to contain vendor specific code or the need for parsers to be supplied with much knowledge from the dictionary; c. encourages harmonization by creating large common attribute number spaces, governed by shared policies instead of the current situation where you either need standards action or rely on another vendor's private assignment policy. Also note that our charter specifically adds the SDO-specific attribute class to the IETF and Vendor specific classes of attributes; d. paves the way for a smooth migration to DIAMETER by allowing DIAMETER code points to be used and by strongly recommending the use of the DIAMETER data types for all basic scalar types. (In practice, that doesn't narrow things down much; *everything* at the level we're working at uses 2's complement big-endian values with sizes of either 1, 2, 4, 8 octets, or a variable length octet string that's either not interpreted at all or interpreted as UTF-8). > I think it's important to reiterate some thoughts expressed elsewhere in > this general discussion, however. One of those concepts is the issue of > whether or not a RADIUS Server or RADIUS Client needs to take an action > that depends on the value of one or more individual members of a data > structure. So far, much of this discussion has been from the view point > of RADIUS Servers, in terms of data dictionary implementations. We > should also consider this from the NAS developer's viewpoint. Agreed, but there the situation is often much easier, because NASes already have specific code to implement the actual services that are controlled by the RADIUS attributes that apply to them. Therefore, service specific value encodings seem much less of a problem for NAS vendors, and I think that's also the reason that we see so many today. > If a RADIUS entity (Server or Client) needs to take some action > dependent upon an element in a structure, it would be valuable and > desirable to have the individual elements easily addressable. > > Having sub-attribute IDs for these is one way, and in an Extended > RADIUS Attribute we can define this scheme without incurring any > backwards compatibility penalties. That was exactly the point in my suggested format. It allows all elements to be addressed 1. as a flat list of attributes, 2. as a flat list of tagged attributes, 3. as an ordered list of attribute sets (by splitting in sets based on tags), and 4. as an arbitrarily nested tree of attributes. Which addressing style depends on what the entity wants to do with the attribute and the attribute's semantics when it occurs at one particular level in the tree as opposed to another. > We could also write custom string parser code for each individual > attribute, which could work from fixed octet offsets, or could search > for specified delimiter values in variable length fields. I > personally find this kind of code more cumbersome, less flexible, less > re-usable, and more error prone. It's certainly good job security for > RADIUS developers. :-) I wholeheartedly agree with your point there. I personally even so thorougly hated that approach that I spent the effort of making the OpenRADIUS dictionary able to deal with almost all non-delimited formats, both fixed offsets and length field based, and the policy language to easily allow splitting on delimiters. However, after moving the format variation out of the code, the complexity is in the dictionary, so I'd still rather see a more harmonized approach to TLV formats. But for that to be successful, it needs to be flexible and not requiring the adoption of a different style, as DIAMETER does. > If no RADIUS entity needs to take action on the values of the structure > elements, e.g. it is passed to another entity (such as EAP), or it is > simply intended to be dumped verbatim into a RADIUS Accounting Server > log file, then it can perfectly well be densely packed into a string. > My only concern with this approach is that the author of a new attribute > *claims* that it can be treated as a string, because it's never parsed, > when in fact implementations of that application eventually *do* need to > have access to the individual data elements, and thus end up parsing > densely packed strings. Agreed. > Another way to look at this issue, purely for the sake of analysis, is > to see how the same data items would be encoded in ASN.1, using SMIv2, > for a MIB. Pretend that we're using SNMP to provision the NAS instead > of RADIUS. How would you write the MIB? You could easily see a > relationship between leaf OIDs and RADIUS attributes (or > sub-attributes). Now before anyone starts the flames, I realize that > RADIUS is not like SNMP. For one thing RADIUS doesn't have a formal > data model, like SNMP. I think the exercise is potentially instructive, > none the less. SNMP, including traps and writes (RFC 1067) predates RADIUS (RFC 2058) by 9 years (1988 vs. 1997). Using SNMP traps as RADIUS requests and SNMP writes as RADIUS responses, SNMP could have done the whole trick of dynamic service provisioning; nothing like RADIUS would theoretically be needed at all. I don't believe it was just an historic error or a case of not-invented-here on the part of Livingston that RADIUS was designed. If it was an error, that error surely has never seen any attempt of correction in the market place so far. Even when RADIUS was reaching some of its limits, people came up with DIAMETER, instead of encouraging people to use SNMP instead. If you want to spend time on another research on the reasons for that (hint: RADIUS is successful because it's so terribly *pragmatic*; we may need to limit that a bit, but not too much or we'll suffocate it), then that's fine, but if you suggest we embark on that I never want to hear one deadline or time based argument to end a technical discussion again. ;-) > If the eventual consensus of the WG is that individually addressable > elements of a structure are not our cup of tea for attribute encoding > guidelines, and that we really want to formalize the custom octet > packing method for attribute encoding, then I could live with that, if > it were algorithmic and predictable, from one attribute to another. One > way to make such a scheme predictable would be to mimic the way a > specified reference implementation of a C language complier, on a > specified reference CPU architecture, would encode a C structure > definition in physical memory, and simply clone that encoding method. Splitting of values at arbitrary octet boundaries can be defined with two parameters and two flags per subvalue, without looking at CPUs or compilers at all. a. You have the offset of each subvalue, either given in octets relative to the beginning or the end of the outer value; and b. you have the length of each subvalue, given in octets relative to the beginning or the end of the outer value. That's it. No reference to anything else is neccesary. If you have those values, then *why* those values were chosen (because data type X wants to be aligned at multiples of Y and has width Z) is irrelevant; you can still obtain or position the data. Also keep in mind that interpretation of the obtained octets as a certain data type happens at a higher level. Then, if multiple subvalues are to have variable lengths, the value effectively either contains a set of TLVs (possibly with implicit Ts) or a set of delimited values (less optimal in many cases, because the values cannot contain the delimiter, requiring an encoding layer on top to deal with (un)escaping). The parameters to walk any sane list of TLVs consist of: a. the offset of a big-endian length field, b. the size of that length field, c. the offset of the value itself, d. the size of the value relative to the value given by the length field, and e. the offset of the next TLV given as an adjustment and padding count relative to the value given by the length field. (all offsets and sizes in octets, all offsets relative to the start of the TLV). Those parameters allow you to walk RADIUS, DIAMETER, EAP, my Extended Attribute proposal and almost all RADIUS VSAs seen in the wild, without any specific code. > One could handle the on-the-wire endian-ness with a simple mechanism > such as the host-to-net and net-to-host macros (e.g. htonl, ntohl, etc). That's also a nonambiguous mathematical operation that is easily defined without reference to any (reference) implementation. Network order is Network order, that is, most significant octet first, and I don't see why anyone should use anything else on the Network. > Any way we go, I'd *much* rather reach consensus on design guidelines > and then be able to review proposed RADIUS extensions I-Ds against > those concrete best current practices, rather than make ad-hoc > evaluations of each new attribute against the personal opinions of the > day. Agreed. My most important issue is that I think that Section 7 of the design guidelines draft depends on the extended attribute format, not the other way around. The main substance of the draft provides guidance for the design of that format, but after the format is agreed upon, then the format should provide the framework for further style documents and design recommendations for attributes that use the new format. (Legenda, for people that have just tuned in and haven't gone away or fallen asleep yet: those are 'Extended [RADIUS] Attributes', which have a new attribute header format (which is under debate), of which one or more exist in a single virtual field in the RADIUS packet, created by the concatenation of all instances of the 'Extended-Attribute', a la EAP-Message -- at least that much we agree upon, I think). Cheers, Emile. -- E-Advies - Emile van Bergen emile@e-advies.nl tel. +31 (0)78 6136282 http://www.e-advies.nl -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 16 Mar 2006 22:58:58 +0000 From: "Alan DeKok" To: Emile van Bergen Subject: Re: New Technical Issues RE: WG last call in progress on VLAN/Priority Draft cc: radiusext@ops.ietf.org Date: Thu, 16 Mar 2006 18:06:33 -0500 Message-Id: <20060316230633.F29A616CC1@mail.nitros9.org> Emile van Bergen wrote: > I find it incomprehensible that the DIAMETER format would not need any > evaluation against the alternatives on the merits, but that people can > just wave their hands and say, there's already some diameter parsing > code in many RADIUS server's that support TTLS in some form or other, so > hey, 'tis the only sensible road ahead. s/only/proven working, implemented, deployed, and functional/ If there are other alternatives, they should be explored, of course. But the diameter format, while wasteful of space in the RADIUS packet, *is* a proven one. Alan DeKok. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 16 Mar 2006 22:32:24 +0000 From: "Alan DeKok" To: "Avi Lior" Subject: Re: New Technical Issues RE: WG last call in progress on VLAN/Priority Draft cc: radiusext@ops.ietf.org Date: Thu, 16 Mar 2006 17:40:06 -0500 Message-Id: <20060316224007.08B9016CC1@mail.nitros9.org> "Avi Lior" wrote: > I see so you PREFER that work that has complex attribute not be done in > RADEXT. That is not what I said, and not what I want. > You would be upset if you got the beef. Right? I'm starting to get upset that my point isn't getting across. Let's stop this. It's not productive. Alan DeKok. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 16 Mar 2006 22:28:16 +0000 Message-ID: From: "Bernard Aboba" To: radiusext@ops.ietf.org Bcc: Subject: RE: Proposed Resolution to Issue 167: Compatibility with RFC 2866 and RFC 3576 Date: Thu, 16 Mar 2006 14:28:11 -0800 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Note the text from the VLAN/Priority document on a similar subject: 1.3. Attribute Interpretation If a NAS conforming to this specification receives an Access-Accept packet containing an attribute defined in this document which it cannot apply, it MUST act as though it had received an Access-Reject. Similarly, [RFC3576] requires that a NAS receiving a CoA-Request containing an unsupported attribute reply with a CoA-NAK. It is recommended that an Error-Cause attribute with value set to "Unsupported Attribute" (401) be included in the packet. As noted in [RFC3576], authorization changes are atomic so that this situation does not result in session termination and the pre-existing configuration remains unchanged. As a result, no accounting packets should be generated. >From: "Bernard Aboba" >To: radiusext@ops.ietf.org >Subject: Proposed Resolution to Issue 167: Compatibility with RFC 2866 and >RFC 3576 >Date: Thu, 16 Mar 2006 14:12:04 -0800 > >The text of Issue 167 is enclosed below. The proposed resolution is as >follows: > >In Section 1.4, change: > > 1.4 Attribute Interpretation > > Unless otherwise noted in the individual description of an > attribute contained herein, a NAS that conforms to this > specification and receives an Access-Accept message that contains > an attribute from this document that it cannot apply MUST > interpret this though an Access-Reject had been sent and MUST > terminate the session. If accounting is enabled on the NAS, it > MUST generate an Accounting-Request(Stop) message upon session > termination. > > Similarly, if a NAS conforming to this specification and also > conforming to RFC 3576 [RFC3576] receives a CoA message that > contains an attribute from this document that it cannot apply, it > MUST NOT terminate the session and MUST generate a CoA-NAK packet > with ERROR-CAUSE(101) set to "Unsupported Attribute"(401). If > accounting is enabled on the NAS, it MUST NOT generate an > Accounting-Request(Stop) message in such instances. > >To: > > 1.4 Attribute Interpretation > > Unless otherwise noted in the individual description of an > attribute contained herein, a NAS that conforms to this > specification and receives an Access-Accept message that contains > an attribute from this document that it cannot apply MUST > interpret this though an Access-Reject had been sent and MUST > terminate the session. > > Similarly, if a NAS conforming to this specification and also > conforming to RFC 3576 [RFC3576] receives a CoA message that > contains an attribute from this document that it cannot apply, it > MUST NOT terminate the session and MUST generate a CoA-NAK packet. > >----------------------------------------------------------------------------------------------------- >Issue 167: Compatibility with RFC 2866 and RFC 3576 >Submitter names: Bernard Aboba >Submitter email address: aboba@internaut.com >Date first submitted: January 30, 2006 >Reference: >Document: IEEE 802-01 >Comment type: Technical >Priority: S >Section: 1.4 >Rationale/Explanation of issue: > >Section 1.4 states: > > 1.4 Attribute Interpretation > > Unless otherwise noted in the individual description of an > attribute contained herein, a NAS that conforms to this > specification and receives an Access-Accept message that contains > an attribute from this document that it cannot apply MUST > interpret this though an Access-Reject had been sent and MUST > terminate the session. If accounting is enabled on the NAS, it > MUST generate an Accounting-Request(Stop) message upon session > termination. > > Similarly, if a NAS conforming to this specification and also > conforming to RFC 3576 [RFC3576] receives a CoA message that > contains an attribute from this document that it cannot apply, it > MUST NOT terminate the session and MUST generate a CoA-NAK packet > with ERROR-CAUSE(101) set to "Unsupported Attribute"(401). If > accounting is enabled on the NAS, it MUST NOT generate an > Accounting-Request(Stop) message in such instances. >RFC 2866 does not specify the generation of Accounting Stop messages >resulting >from Access-Reject packets. This document is therefore requiring RADIUS >accounting clients to generate accounting records in circumstances where >they would not otherwise do so. This raises the question of why >this particular set of attributes would cause a special case modification >to RFC 2866. Here is what RFC 3576 has to say about receipt of attributes >in a CoA-Request: > > If one or more authorization changes specified in a CoA-Request > cannot be carried out, or if one or more attributes or attribute- > values is unsupported, a CoA-NAK MUST be sent. > >On inclusion of Error-Cause attributes: > > It is possible that the NAS cannot honor Disconnect-Request or > CoA-Request messages for some reason. The Error-Cause Attribute > provides more detail on the cause of the problem. It MAY be > included within Disconnect-ACK, Disconnect-NAK and CoA-NAK > messages. > >Since inclusion of an Error-Cause attribute is generally optional, the >second paragraph mandates behavior not required by RFC 3576. > > > >-- >to unsubscribe send a message to radiusext-request@ops.ietf.org with >the word 'unsubscribe' in a single line as the message text body. >archive: -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 16 Mar 2006 22:27:34 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: New Technical Issues RE: WG last call in progress on VLAN/Priority Draft Date: Thu, 16 Mar 2006 17:29:38 -0500 Message-ID: Thread-Topic: New Technical Issues RE: WG last call in progress on VLAN/Priority Draft Thread-Index: AcZJQAfy51Dk/OBIQ5aeEHznXm5uoQACEisQ From: "Avi Lior" To: "Alan DeKok" Cc: I see so you PREFER that work that has complex attribute not be done in RADEXT. If the waiter said: " Would you prefer the chicken or the beef" and you said to the waiter: " I prefer the chicken" You would be upset if you got the beef. Right? =20 > -----Original Message----- > From: aland@nitros9.org [mailto:aland@nitros9.org] On Behalf=20 > Of Alan DeKok > Sent: Thursday, March 16, 2006 4:29 PM > To: Avi Lior > Cc: radiusext@ops.ietf.org > Subject: Re: New Technical Issues RE: WG last call in=20 > progress on VLAN/Priority Draft >=20 > "Alan DeKok" wrote: > > And you also said this: right? > > > > > If the content of an attribute is a complex structure = as=3D20=20 > > > > > determined by the application, I would *prefer* that the=3D20 > > > structure=3D20 > > > > > is defined elsewhere, and the RADIUS docs simply reference it. > >=20 > > Defined elsewhere means to me its forbiden in RADIUS. >=20 > prefer !=3D forbid. >=20 > Please stop claiming I'm trying to forbid complex attributes. >=20 > Alan DeKok. >=20 -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 16 Mar 2006 22:23:47 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: Extended attribute formats (was RE: New Technical Issues RE: WG last call in progress on VLAN/Priority Draft) Date: Thu, 16 Mar 2006 17:23:29 -0500 Message-ID: <3CFB564E055A594B82C4FE89D215656021914A@MABOSEVS2.ets.enterasys.com> Thread-Topic: Extended attribute formats (was RE: New Technical Issues RE: WG last call in progress on VLAN/Priority Draft) Thread-Index: AcZJNZmtaqq8mwvOSQyq6dk0bhNg2AAAwhwwAAOf9gA= From: "Nelson, David" To: It would be helpful to change the subject line to accurately reflect the topic. Avi Lior writes... > Anyway most of the discussion today is a repeat of the discusssions we > had before (rehash).=20 Yes. We failed to reach consensus the previous time, so we are destined to continue the discussion until we reach one. There are WG milestones that are dependent upon reaching such a consensus. > Most of the people changed (it seem) except for David Nelson. That's not entirely true. I won't repeat my comments, but in https://psg.com/lists/radiusext/2006/msg00302.html I indicated some options, my preferences, but also that my ultimate desire that we reach a consensus on *something* concrete and useful in the way of design guidelines (and extended attribute format, if required). -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 16 Mar 2006 22:12:22 +0000 Message-ID: From: "Bernard Aboba" To: radiusext@ops.ietf.org Bcc: Subject: Proposed Resolution to Issue 167: Compatibility with RFC 2866 and RFC 3576 Date: Thu, 16 Mar 2006 14:12:04 -0800 Mime-Version: 1.0 Content-Type: text/plain; format=flowed The text of Issue 167 is enclosed below. The proposed resolution is as follows: In Section 1.4, change: 1.4 Attribute Interpretation Unless otherwise noted in the individual description of an attribute contained herein, a NAS that conforms to this specification and receives an Access-Accept message that contains an attribute from this document that it cannot apply MUST interpret this though an Access-Reject had been sent and MUST terminate the session. If accounting is enabled on the NAS, it MUST generate an Accounting-Request(Stop) message upon session termination. Similarly, if a NAS conforming to this specification and also conforming to RFC 3576 [RFC3576] receives a CoA message that contains an attribute from this document that it cannot apply, it MUST NOT terminate the session and MUST generate a CoA-NAK packet with ERROR-CAUSE(101) set to "Unsupported Attribute"(401). If accounting is enabled on the NAS, it MUST NOT generate an Accounting-Request(Stop) message in such instances. To: 1.4 Attribute Interpretation Unless otherwise noted in the individual description of an attribute contained herein, a NAS that conforms to this specification and receives an Access-Accept message that contains an attribute from this document that it cannot apply MUST interpret this though an Access-Reject had been sent and MUST terminate the session. Similarly, if a NAS conforming to this specification and also conforming to RFC 3576 [RFC3576] receives a CoA message that contains an attribute from this document that it cannot apply, it MUST NOT terminate the session and MUST generate a CoA-NAK packet. ----------------------------------------------------------------------------------------------------- Issue 167: Compatibility with RFC 2866 and RFC 3576 Submitter names: Bernard Aboba Submitter email address: aboba@internaut.com Date first submitted: January 30, 2006 Reference: Document: IEEE 802-01 Comment type: Technical Priority: S Section: 1.4 Rationale/Explanation of issue: Section 1.4 states: 1.4 Attribute Interpretation Unless otherwise noted in the individual description of an attribute contained herein, a NAS that conforms to this specification and receives an Access-Accept message that contains an attribute from this document that it cannot apply MUST interpret this though an Access-Reject had been sent and MUST terminate the session. If accounting is enabled on the NAS, it MUST generate an Accounting-Request(Stop) message upon session termination. Similarly, if a NAS conforming to this specification and also conforming to RFC 3576 [RFC3576] receives a CoA message that contains an attribute from this document that it cannot apply, it MUST NOT terminate the session and MUST generate a CoA-NAK packet with ERROR-CAUSE(101) set to "Unsupported Attribute"(401). If accounting is enabled on the NAS, it MUST NOT generate an Accounting-Request(Stop) message in such instances. RFC 2866 does not specify the generation of Accounting Stop messages resulting from Access-Reject packets. This document is therefore requiring RADIUS accounting clients to generate accounting records in circumstances where they would not otherwise do so. This raises the question of why this particular set of attributes would cause a special case modification to RFC 2866. Here is what RFC 3576 has to say about receipt of attributes in a CoA-Request: If one or more authorization changes specified in a CoA-Request cannot be carried out, or if one or more attributes or attribute- values is unsupported, a CoA-NAK MUST be sent. On inclusion of Error-Cause attributes: It is possible that the NAS cannot honor Disconnect-Request or CoA-Request messages for some reason. The Error-Cause Attribute provides more detail on the cause of the problem. It MAY be included within Disconnect-ACK, Disconnect-NAK and CoA-NAK messages. Since inclusion of an Error-Cause attribute is generally optional, the second paragraph mandates behavior not required by RFC 3576. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 16 Mar 2006 21:27:22 +0000 From: "Alan DeKok" To: "Glen Zorn \(gwz\)" Subject: Re: New Technical Issues RE: WG last call in progress on VLAN/Priority Draft cc: radiusext@ops.ietf.org Date: Thu, 16 Mar 2006 16:35:04 -0500 Message-Id: <20060316213504.0E7F616CC1@mail.nitros9.org> "Glen Zorn \(gwz\)" wrote: > Although the use of a Diameter header would allow for larger > attributes, the increase in overhead means that there is actually > less space available for attributes. Agreed. Do you have data on existing deployments where the 4k limit in RADIUS is insufficient? I can only recall running into it once in the past decade. The situation was where a vendor had a non-standard string encoding for attributes, and the customer wanted to send many of them. In that case, if the vendor had chosen to use a packed format, the 4k limit would have been sufficient. Alan DeKok. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 16 Mar 2006 21:21:30 +0000 From: "Alan DeKok" To: "Avi Lior" Subject: Re: New Technical Issues RE: WG last call in progress on VLAN/Priority Draft cc: radiusext@ops.ietf.org Date: Thu, 16 Mar 2006 16:29:00 -0500 Message-Id: <20060316212900.9680E16CC1@mail.nitros9.org> "Alan DeKok" wrote: > And you also said this: right? > > > > If the content of an attribute is a complex structure as=20 > > > > determined by the application, I would *prefer* that the=20 > > structure=20 > > > > is defined elsewhere, and the RADIUS docs simply reference it. > > Defined elsewhere means to me its forbiden in RADIUS. prefer != forbid. Please stop claiming I'm trying to forbid complex attributes. Alan DeKok. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 16 Mar 2006 21:05:54 +0000 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: New Technical Issues RE: WG last call in progress on VLAN/Priority Draft Date: Thu, 16 Mar 2006 13:05:39 -0800 Message-ID: <4C0FAAC489C8B74F96BEAD85EAEB262501B7BB61@xmb-sjc-215.amer.cisco.com> Thread-Topic: New Technical Issues RE: WG last call in progress on VLAN/Priority Draft Thread-Index: AcZJOrz76NU3QlNkSmuU7Gso9Fb6fgAAUgmg From: "Glen Zorn \(gwz\)" To: "Barney Wolff" Cc: Barney Wolff supposedly scribbled: ... > I would have thought that 4096 was quite generous, but I lack recent > operational experience. So I appeal to the group: What's the > largest RADIUS message that's been seen in the wild? Are we anywhere > close to being constrained by the 4096 limit, which we agree cannot > be changed?=20 I wouldn't bring it up were it not the case. In fact, at this very = moment I am tasked w/trying to figure out how to send messages larger = than the RADIUS limit (easy in Diameter, possibly impossible in RADIUS) = in something like a reasonable fashion. This is just the latest case: = IIRC, one of the major goals of the original RADIUS v2 (nee Diameter) = effort was to get rid of the 4096 limit. That was a _long_ time ago... =20 >=20 > I would also point out that we are not suggesting that all future > RADIUS attributes use the Diameter format. Only those that need more > than 253 bytes, use a Diameter data type (including Grouped), or have > type number greater than 255 would need to do so. =20 >=20 > Regards, > Barney Hope this helps, ~gwz Why is it that most of the world's problems can't be solved by simply listening to John Coltrane? -- Henry Gabriel -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 16 Mar 2006 20:46:48 +0000 Date: Thu, 16 Mar 2006 15:46:38 -0500 From: Barney Wolff To: "Glen Zorn (gwz)" Cc: radiusext@ops.ietf.org Subject: Re: New Technical Issues RE: WG last call in progress on VLAN/Priority Draft Message-ID: <20060316204638.GA36815@pit.databus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.11 On Thu, Mar 16, 2006 at 12:27:18PM -0800, Glen Zorn (gwz) wrote: > > I have given my reasoning several times, but I will repeat myself > again: the Diameter AVP structure was designed with the fact in > mind that Diameter messages are virtually unlimited in length. For > this reason, the header could be as big as desired, with little > concern for overhead. RADIUS messages, however, are strictly > constrained in length and I've not seen any realistic scheme for > expanding them in a backwards-compatible fashion. Attribute overhead > _is_ an issue in RADIUS; every octet taken for an AVP header is one > less available for actual data. Although the use of a Diameter > header would allow for larger attributes, the increase in overhead > means that there is actually less space available for attributes. I would have thought that 4096 was quite generous, but I lack recent operational experience. So I appeal to the group: What's the largest RADIUS message that's been seen in the wild? Are we anywhere close to being constrained by the 4096 limit, which we agree cannot be changed? I would also point out that we are not suggesting that all future RADIUS attributes use the Diameter format. Only those that need more than 253 bytes, use a Diameter data type (including Grouped), or have type number greater than 255 would need to do so. Regards, Barney -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 16 Mar 2006 20:40:52 +0000 Date: Thu, 16 Mar 2006 21:40:26 +0100 From: Emile van Bergen To: "Glen Zorn (gwz)" Cc: Barney Wolff , Alan DeKok , radiusext@ops.ietf.org, Avi Lior Subject: Re: New Technical Issues RE: WG last call in progress on VLAN/Priority Draft Message-ID: <20060316204025.GA3623@note.evbergen.xs4all.nl> Mail-Followup-To: "Glen Zorn (gwz)" , Barney Wolff , Alan DeKok , radiusext@ops.ietf.org, Avi Lior Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.9i Hi, On Thu, Mar 16, 2006 at 12:12:20PM -0800, Glen Zorn (gwz) wrote: > Barney Wolff <> supposedly scribbled: > > > On Thu, Mar 16, 2006 at 12:47:17PM -0500, Avi Lior wrote: > >> > >> Also I resent somewhat the push now is so much that it ignores what > >> we did a two years ago. Based on discussion it was Jari who proposed > >> encoding RADIUS attributes using Diameter syntax (I seem to recall > >> that one of you guys were taking credit for that). > > > > Just so we're clear, Alan did not "take" credit for it. I assigned > > credit to him because that's how I first heard the idea, and indeed a > > search of radext archives shows email from him suggesting it in Feb > > 2005. But of course, if you or Jari (or anyone) can point me to a > > prior discussion of the idea of using the Diameter attribute header > > format, I will be glad to correct the acknowledgment. > > Well, you can give me credit for being virtually the only person saying that this is a Very Bad Idea... Virtually, perhaps, but count me in as well. If DIAMETER would do all RADIUS is lacking, it would have known much stronger adoption. This WGs very existence, how reluctantly it was started, is testament that people rather build upon RADIUS than look at DIAMETER for their solutions. I find it then entirely foolish to suggest that a blanket transport mechanism for DIAMETER inside RADIUS would solve all our issues. I find it incomprehensible that the DIAMETER format would not need any evaluation against the alternatives on the merits, but that people can just wave their hands and say, there's already some diameter parsing code in many RADIUS server's that support TTLS in some form or other, so hey, 'tis the only sensible road ahead. Really, is that all we can muster these days? Cheers, Emile. -- E-Advies - Emile van Bergen emile@e-advies.nl tel. +31 (0)78 6136282 http://www.e-advies.nl -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 16 Mar 2006 20:40:44 +0000 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: Proposed Resolution to Issue 178: Allowing Hints in Request Messages Date: Thu, 16 Mar 2006 12:40:37 -0800 Message-ID: <4C0FAAC489C8B74F96BEAD85EAEB262501B7BB44@xmb-sjc-215.amer.cisco.com> Thread-Topic: Proposed Resolution to Issue 178: Allowing Hints in Request Messages Thread-Index: AcZJJGcDGT9hlLNTQkCdsTesCLmPWQAEapngAACNQQAAAF/BkA== From: "Glen Zorn \(gwz\)" To: "Sanchez, Mauricio" , "Bernard Aboba" Cc: Sanchez, Mauricio supposedly scribbled: > Glenn questioned.. ... > Only zero or one user-priority-table attribute is allowed. You must > be thinking about Egress-VLAN-Name attribute.=20 Yup. >=20 > The NAS may have the capability to allow a user session to be > associated with multiple VLANs. By sending multiple vlan attributes > up to the server (i.e. the "hints"), the server finds out what is a > possible set of VLANs the session may be assigned. =20 OK. >=20 > MS Hope this helps, ~gwz Why is it that most of the world's problems can't be solved by simply listening to John Coltrane? -- Henry Gabriel -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 16 Mar 2006 20:35:03 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Proposed Resolution to Issue 178: Allowing Hints in Request Messages Date: Thu, 16 Mar 2006 12:34:45 -0800 Message-ID: Thread-Topic: Proposed Resolution to Issue 178: Allowing Hints in Request Messages Thread-Index: AcZJJGcDGT9hlLNTQkCdsTesCLmPWQAEapngAACNQQA= From: "Sanchez, Mauricio" To: "Glen Zorn (gwz)" , "Bernard Aboba" Cc: Glenn questioned..=20 > -----Original Message----- > From: owner-radiusext@ops.ietf.org=20 > [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Glen Zorn (gwz) > Sent: Thursday, March 16, 2006 12:16 PM > To: Bernard Aboba > Cc: radiusext@ops.ietf.org > Subject: RE: Proposed Resolution to Issue 178: Allowing Hints=20 > in Request Messages >=20 > Bernard Aboba <> supposedly scribbled: >=20 > I'm fine with the hint thing, but I wonder why you would need=20 > to send, e.g., multiple Egress-VLANID or User-Priority-Table=20 > attributes as hints. Would not one of each suffice? Only zero or one user-priority-table attribute is allowed. You must be thinking about Egress-VLAN-Name attribute. =20 The NAS may have the capability to allow a user session to be associated with multiple VLANs. By sending multiple vlan attributes up to the server (i.e. the "hints"), the server finds out what is a possible set of VLANs the session may be assigned. =20 MS -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 16 Mar 2006 20:34:56 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: New Technical Issues RE: WG last call in progress on VLAN/Priority Draft Date: Thu, 16 Mar 2006 15:37:01 -0500 Message-ID: Thread-Topic: New Technical Issues RE: WG last call in progress on VLAN/Priority Draft Thread-Index: AcZJNZmtaqq8mwvOSQyq6dk0bhNg2AAAwhww From: "Avi Lior" To: "Barney Wolff" Cc: "Alan DeKok" , Take a look at: IETF 60 August 2004. Presentation: http://www3.ietf.org/proceedings/04aug/slides/radextt-6/sld8.htm But even before that we had that proposal from Jari. I remember the email distinctly. And here is that now forgotten email http://ops.ietf.org/lists/radiusext/2004/msg00441.html Anyway most of the discussion today is a repeat of the discusssions we had before (rehash). Most of the people changed (it seem) except for David Nelson.=20 > -----Original Message----- > From: Barney Wolff [mailto:barney@databus.com]=20 > Sent: Thursday, March 16, 2006 3:07 PM > To: Avi Lior > Cc: Alan DeKok; radiusext@ops.ietf.org > Subject: Re: New Technical Issues RE: WG last call in=20 > progress on VLAN/Priority Draft >=20 > On Thu, Mar 16, 2006 at 12:47:17PM -0500, Avi Lior wrote: > >=20 > > Also I resent somewhat the push now is so much that it=20 > ignores what we=20 > > did a two years ago. Based on discussion it was Jari who proposed=20 > > encoding RADIUS attributes using Diameter syntax (I seem to recall=20 > > that one of you guys were taking credit for that). >=20 > Just so we're clear, Alan did not "take" credit for it. I=20 > assigned credit to him because that's how I first heard the=20 > idea, and indeed a search of radext archives shows email from=20 > him suggesting it in Feb 2005. But of course, if you or Jari=20 > (or anyone) can point me to a prior discussion of the idea of=20 > using the Diameter attribute header format, I will be glad to=20 > correct the acknowledgment. >=20 > Regards, > Barney >=20 -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 16 Mar 2006 20:30:51 +0000 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: Proposed Resolution to Issue 180: Misuse of Data Types Date: Thu, 16 Mar 2006 12:30:46 -0800 Message-ID: <4C0FAAC489C8B74F96BEAD85EAEB262501B7BB38@xmb-sjc-215.amer.cisco.com> Thread-Topic: Proposed Resolution to Issue 180: Misuse of Data Types Thread-Index: AcZJJaiv9ztfBbXUREq0Mwr6NJkAPAABZKKgAAJoXCAAAOPGYA== From: "Glen Zorn \(gwz\)" To: "Sanchez, Mauricio" , "Bernard Aboba" Cc: Sanchez, Mauricio supposedly scribbled: ... > Can we agree, with whatever associated cringing, and accept the > current state of the VLAN draft data types as acceptable? They are > at best a continuation of the ad-hoc design legacy and at worst an > ugly wart that will stand out once clear design guidelines are > defined. I don't think anyone can pragmatically disagree that going > forward with the VLAN draft's data types will cause insurmountable > pain to implementers. It's only business as usual for RADIUS. =20 >=20 > My vote is to accept the draft as is on this matter. OK >=20 > Cheers, > MS ~gwz Why is it that most of the world's problems can't be solved by simply listening to John Coltrane? -- Henry Gabriel -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 16 Mar 2006 20:28:00 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Proposed Resolution to Issue 180: Misuse of Data Types Date: Thu, 16 Mar 2006 12:26:45 -0800 Message-ID: Thread-Topic: Proposed Resolution to Issue 180: Misuse of Data Types Thread-Index: AcZJJaiv9ztfBbXUREq0Mwr6NJkAPAABZKKgAAJoXCA= From: "Sanchez, Mauricio" To: "Glen Zorn (gwz)" , "Bernard Aboba" Cc: Bernard and Glen stated:=20 > Bernard Aboba <> supposedly scribbled: >=20 > > The text of Issue 180 (and some of the subsequent discussion) is=20 > > enclosed below. > >=20 > > The proposed resolution is to change "VLAN Tag" to "VLAN Flag" > > everywhere in the document.=20 >=20 > Sounds reasonable to me. I concur.=20 >=20 > >=20 > > In looking at the mailing list discussion, I did not detect=20 > consensus=20 > > for making other changes. >=20 > Although I don't think that the discussion is altogether=20 > complete, I would agree with your assessment of its progress thus far. We've got a chicken and egg problem here. Agreement on what to do with complex/compound/whatever-you-want-to-call-them RADIUS attributes is not going to get solved using the VLAN draft as the vehicle. It's something that Dave pointed out is best addressed in design guidelines draft. Yet, the design guideline draft and its associated discussion are only really going to happen after the VLAN draft milestone. =20 While I do agree that it would be admirable if we could come to a suitable general solution to the data problem, I don't think we're going to get to one quick enough. It does appear, however, that people do agree that the past design behavior for RADIUS attributes, while ad-hoc and non-optimal, has worked so far. =20 Can we agree, with whatever associated cringing, and accept the current state of the VLAN draft data types as acceptable? They are at best a continuation of the ad-hoc design legacy and at worst an ugly wart that will stand out once clear design guidelines are defined. I don't think anyone can pragmatically disagree that going forward with the VLAN draft's data types will cause insurmountable pain to implementers. It's only business as usual for RADIUS. My vote is to accept the draft as is on this matter. Cheers, MS -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 16 Mar 2006 20:27:52 +0000 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: New Technical Issues RE: WG last call in progress on VLAN/Priority Draft Date: Thu, 16 Mar 2006 12:27:18 -0800 Message-ID: <4C0FAAC489C8B74F96BEAD85EAEB262501B7BB31@xmb-sjc-215.amer.cisco.com> Thread-Topic: New Technical Issues RE: WG last call in progress on VLAN/Priority Draft Thread-Index: AcZJNp9IYa93fGTaS5e4YajUMKkcWQAADxnw From: "Glen Zorn \(gwz\)" To: "Barney Wolff" Cc: Barney Wolff supposedly scribbled: ... >> Well, you can give me credit for being virtually the only person >> saying that this is a Very Bad Idea...=20 >=20 > Credit would certainly be due if you would give your reasoning and it > was convincing.=20 I have given my reasoning several times, but I will repeat myself again: = the Diameter AVP structure was designed with the fact in mind that = Diameter messages are virtually unlimited in length. For this reason, = the header could be as big as desired, with little concern for overhead. = RADIUS messages, however, are strictly constrained in length and I've = not seen any realistic scheme for expanding them in a = backwards-compatible fashion. Attribute overhead _is_ an issue in = RADIUS; every octet taken for an AVP header is one less available for = actual data. Although the use of a Diameter header would allow for = larger attributes, the increase in overhead means that there is actually = less space available for attributes. ... Hope this helps, ~gwz Why is it that most of the world's problems can't be solved by simply listening to John Coltrane? -- Henry Gabriel -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 16 Mar 2006 20:17:21 +0000 Date: Thu, 16 Mar 2006 15:17:15 -0500 From: Barney Wolff To: "Glen Zorn (gwz)" Cc: radiusext@ops.ietf.org Subject: Re: New Technical Issues RE: WG last call in progress on VLAN/Priority Draft Message-ID: <20060316201715.GA20031@pit.databus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.11 On Thu, Mar 16, 2006 at 12:12:20PM -0800, Glen Zorn (gwz) wrote: > Barney Wolff <> supposedly scribbled: > > > On Thu, Mar 16, 2006 at 12:47:17PM -0500, Avi Lior wrote: > >> > >> Also I resent somewhat the push now is so much that it ignores what > >> we did a two years ago. Based on discussion it was Jari who proposed > >> encoding RADIUS attributes using Diameter syntax (I seem to recall > >> that one of you guys were taking credit for that). > > > > Just so we're clear, Alan did not "take" credit for it. I assigned > > credit to him because that's how I first heard the idea, and indeed a > > search of radext archives shows email from him suggesting it in Feb > > 2005. But of course, if you or Jari (or anyone) can point me to a > > prior discussion of the idea of using the Diameter attribute header > > format, I will be glad to correct the acknowledgment. > > Well, you can give me credit for being virtually the only person saying that this is a Very Bad Idea... Credit would certainly be due if you would give your reasoning and it was convincing. > Hope this helps, See above. Regards, Barney -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 16 Mar 2006 20:16:31 +0000 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: Proposed Resolution to Issue 178: Allowing Hints in Request Messages Date: Thu, 16 Mar 2006 12:15:47 -0800 Message-ID: <4C0FAAC489C8B74F96BEAD85EAEB262501B7BB26@xmb-sjc-215.amer.cisco.com> Thread-Topic: Proposed Resolution to Issue 178: Allowing Hints in Request Messages Thread-Index: AcZJJGcDGT9hlLNTQkCdsTesCLmPWQAEapng From: "Glen Zorn \(gwz\)" To: "Bernard Aboba" Cc: Bernard Aboba <> supposedly scribbled: I'm fine with the hint thing, but I wonder why you would need to send, = e.g., multiple Egress-VLANID or User-Priority-Table attributes as hints. = Would not one of each suffice? Hope this helps, ~gwz Why is it that most of the world's problems can't be solved by simply listening to John Coltrane? -- Henry Gabriel -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 16 Mar 2006 20:14:20 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: New Technical Issues RE: WG last call in progress on VLAN/Priority Draft Date: Thu, 16 Mar 2006 15:16:29 -0500 Message-ID: Thread-Topic: New Technical Issues RE: WG last call in progress on VLAN/Priority Draft Thread-Index: AcZJMrqI/byhIUPeSWGR5HbS3UCXpwAAzX1Q From: "Avi Lior" To: "Alan DeKok" Cc: Alan, You said this: > I'm not sure how you conclude that I'm trying to forbid=20 > complex attributes. =20 And you also said this: right? > > > If the content of an attribute is a complex structure as=20 > > > determined by the application, I would *prefer* that the=20 > structure=20 > > > is defined elsewhere, and the RADIUS docs simply reference it. Defined elsewhere means to me its forbiden in RADIUS. > -----Original Message----- > From: aland@nitros9.org [mailto:aland@nitros9.org] On Behalf=20 > Of Alan DeKok > Sent: Thursday, March 16, 2006 2:54 PM > To: Avi Lior > Cc: radiusext@ops.ietf.org > Subject: Re: New Technical Issues RE: WG last call in=20 > progress on VLAN/Priority Draft >=20 > "Avi Lior" wrote: > > > If the content of an attribute is a complex structure as=20 > > > determined by the application, I would *prefer* that the=20 > structure=20 > > > is defined elsewhere, and the RADIUS docs simply reference it. > >=20 > > I don't agree. Why should that be? >=20 > RFC 3576 > ... > 3.1. EAP-Message >=20 > Description >=20 > This attribute encapsulates EAP [RFC2284] ... >=20 > Instead of having a normitive reference, let's cut & paste=20 > big chunks of ASCII art from RFC 2284 here. >=20 > Oh, wait... >=20 > > Again, what you are saying if it doesn't fit into my=20 > dictionary then=20 > > I don't think its RADIUS. >=20 > I'm pretty clear that that's *not* what I'm saying. I've=20 > been trying to convince you of this, but for some reason I'm=20 > not succeeding. >=20 > I'm not sure how you conclude that I'm trying to forbid=20 > complex attributes. Perhaps I should stop protesting, and=20 > just let you believe what you want about my opinions. But=20 > *please* don't claim publicly I'm trying to forbid complex=20 > attributes. That is demonstratably not true. Just read my messages. >=20 > Alan DeKok. >=20 -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 16 Mar 2006 20:12:54 +0000 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: New Technical Issues RE: WG last call in progress on VLAN/Priority Draft Date: Thu, 16 Mar 2006 12:12:20 -0800 Message-ID: <4C0FAAC489C8B74F96BEAD85EAEB262501B7BB23@xmb-sjc-215.amer.cisco.com> Thread-Topic: New Technical Issues RE: WG last call in progress on VLAN/Priority Draft Thread-Index: AcZJNS8QmO9GxHfzQvmZIBwT931Q9gAAJneA From: "Glen Zorn \(gwz\)" To: "Barney Wolff" Cc: "Alan DeKok" , , "Avi Lior" Barney Wolff <> supposedly scribbled: > On Thu, Mar 16, 2006 at 12:47:17PM -0500, Avi Lior wrote: >>=20 >> Also I resent somewhat the push now is so much that it ignores what >> we did a two years ago. Based on discussion it was Jari who proposed >> encoding RADIUS attributes using Diameter syntax (I seem to recall >> that one of you guys were taking credit for that). >=20 > Just so we're clear, Alan did not "take" credit for it. I assigned > credit to him because that's how I first heard the idea, and indeed a > search of radext archives shows email from him suggesting it in Feb > 2005. But of course, if you or Jari (or anyone) can point me to a > prior discussion of the idea of using the Diameter attribute header > format, I will be glad to correct the acknowledgment. =20 Well, you can give me credit for being virtually the only person saying = that this is a Very Bad Idea... =20 >=20 > Regards, > Barney Hope this helps, ~gwz Why is it that most of the world's problems can't be solved by simply listening to John Coltrane? -- Henry Gabriel -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 16 Mar 2006 20:06:52 +0000 Date: Thu, 16 Mar 2006 15:06:33 -0500 From: Barney Wolff To: Avi Lior Cc: Alan DeKok , radiusext@ops.ietf.org Subject: Re: New Technical Issues RE: WG last call in progress on VLAN/Priority Draft Message-ID: <20060316200633.GA94220@pit.databus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.11 On Thu, Mar 16, 2006 at 12:47:17PM -0500, Avi Lior wrote: > > Also I resent somewhat the push now is so much that it ignores what we > did a two years ago. Based on discussion it was Jari who proposed > encoding RADIUS attributes using Diameter syntax (I seem to recall that > one of you guys were taking credit for that). Just so we're clear, Alan did not "take" credit for it. I assigned credit to him because that's how I first heard the idea, and indeed a search of radext archives shows email from him suggesting it in Feb 2005. But of course, if you or Jari (or anyone) can point me to a prior discussion of the idea of using the Diameter attribute header format, I will be glad to correct the acknowledgment. Regards, Barney -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 16 Mar 2006 19:57:28 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Proposed Resolution to Issue 178: Allowing Hints in Request Messages Date: Thu, 16 Mar 2006 11:57:06 -0800 Message-ID: Thread-Topic: Proposed Resolution to Issue 178: Allowing Hints in Request Messages Thread-Index: AcZJJIeTIVUyMLjlRI+/NCi3ZY+NxAADyVcw From: "Sanchez, Mauricio" To: "Bernard Aboba" Cc: This is satisfactory and issue can be closed once document is updated. MS=20 > -----Original Message----- > From: owner-radiusext@ops.ietf.org=20 > [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Bernard Aboba > Sent: Thursday, March 16, 2006 10:06 AM > To: radiusext@ops.ietf.org > Subject: Proposed Resolution to Issue 178: Allowing Hints in=20 > Request Messages >=20 > The text of Issue 178 is enclosed below. The proposed=20 > resolution is to accept the changes. >=20 > -------------------------------------------------------------- > ------------------------------------------------------------------ > Issue 178: Allowing Hints in Request Messages Submitter name:=20 > Mauricio Sanchez Submitter email address:=20 > mauricio.sanchez@hp.com Date first submitted: March 6, 2006 > Reference: http://ops.ietf.org/lists/radiusext/2006/msg00225.html > Document: draft-ietf-radext-vlan-00.txt > Comment type: T > Priority: 2 > Section: Table in section 3, individual attributes=20 > Rationale/Explanation of issue: > Draft-ietf-radext-vlan-00 does not allow the new attributes=20 > to be sent in ACCESS-REQUEST messages. If allowed,=20 > attributes in the REQUEST message could serve as 'hints' to=20 > the RADIUS server during the decision making process. > Requested change: Allow attributes to be sent ACCESS-REQUEST=20 > message Proposed changes to the document. >=20 > - Descriptions of individual attribute descriptions would be=20 > changed to allow attributes in access request, as follows: > Multiple attributes MAY be included in an=20 > Access-Request, Access-Accept or CoA-Request packet; this=20 > attribute MUST NOT be sent within an Access-Challenge,=20 > Access-Reject, Disconnect-Request, Disconnect-ACK,=20 > Disconnect-NAK, CoA-ACK, or CoA-NAK. >=20 > -Table in section 3 would be changed to: >=20 > Access- Access- Access- Access- CoA- > Request Accept Reject Challenge Req # Attribute > 0+ 0+ 0 0 0+ TBD Egress-VLANID > 0-1 0-1 0 0 0-1 TBD Ingress-Filters > 0+ 0+ 0 0 0+ TBD Egress-VLAN-Name > 0-1 0-1 0 0 0-1 TBD =20 > User-Priority-Table >=20 >=20 >=20 > -- > to unsubscribe send a message to=20 > radiusext-request@ops.ietf.org with the word 'unsubscribe' in=20 > a single line as the message text body. > archive: >=20 -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 16 Mar 2006 19:46:11 +0000 From: "Alan DeKok" To: "Avi Lior" Subject: Re: New Technical Issues RE: WG last call in progress on VLAN/Priority Draft cc: radiusext@ops.ietf.org Date: Thu, 16 Mar 2006 14:53:47 -0500 Message-Id: <20060316195347.6AAB616CC1@mail.nitros9.org> "Avi Lior" wrote: > > If the content of an attribute is a complex structure as > > determined by the application, I would *prefer* that the > > structure is defined elsewhere, and the RADIUS docs simply > > reference it. > > I don't agree. Why should that be? RFC 3576 ... 3.1. EAP-Message Description This attribute encapsulates EAP [RFC2284] ... Instead of having a normitive reference, let's cut & paste big chunks of ASCII art from RFC 2284 here. Oh, wait... > Again, what you are saying if it doesn't fit into my dictionary then I > don't think its RADIUS. I'm pretty clear that that's *not* what I'm saying. I've been trying to convince you of this, but for some reason I'm not succeeding. I'm not sure how you conclude that I'm trying to forbid complex attributes. Perhaps I should stop protesting, and just let you believe what you want about my opinions. But *please* don't claim publicly I'm trying to forbid complex attributes. That is demonstratably not true. Just read my messages. Alan DeKok. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 16 Mar 2006 19:22:12 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: New Technical Issues RE: WG last call in progress on VLAN/Priority Draft Date: Thu, 16 Mar 2006 14:24:19 -0500 Message-ID: Thread-Topic: New Technical Issues RE: WG last call in progress on VLAN/Priority Draft Thread-Index: AcZJKOs7C2d1NcpBT+6bqxM102wjMwABScQw From: "Avi Lior" To: "Alan DeKok" Cc: See inline....=20 > -----Original Message----- > From: aland@nitros9.org [mailto:aland@nitros9.org] On Behalf=20 > Of Alan DeKok > Sent: Thursday, March 16, 2006 1:43 PM > To: Avi Lior > Cc: radiusext@ops.ietf.org > Subject: Re: New Technical Issues RE: WG last call in=20 > progress on VLAN/Priority Draft >=20 > "Avi Lior" wrote: > > That is fine. But why should we balk when we are faced=20 > with a complex=20 > > attribute as required by a complex application. The=20 > argument that it=20 > > breaks the dictionary should NOT stop the work going forward. The=20 > > Dictionary should only parse it up to String. Let the application=20 > > decode the rest. >=20 > Agreed. >=20 > If the content of an attribute is a complex structure as=20 > determined by the application, I would *prefer* that the=20 > structure is defined elsewhere, and the RADIUS docs simply=20 > reference it. I don't agree. Why should that be? > The contention comes when more and more complex structures=20 > are shoe-horned into RADIUS attributes, where those=20 > structures have no definition outside of RADIUS. In those=20 > cases, the preference is to use existing RADIUS types where possible. Defining a RADIUS based RFC does not mean that your simple RADIUS server has to implement that attribute. It should though be able to transport it pass-through though. So it must be able to parse through that attribute. Again, what you are saying if it doesn't fit into my dictionary then I don't think its RADIUS. The attributes do fit in the Dictionary it just that you have to go beyong the strings at a different layer. So attributes like User-Name does not belong in RADIUS - by your logic. Neither does 3162, CHAP etc.... Which all use encoding that are not supported by RADIUS. I think this logic is seriously flawed. > Where not, use the Diameter attribute format, and leverage=20 > it's grouping mechanism to get complicated structural relationships. > Which will also not be RADIUS.... =20 > Alan DeKok. >=20 -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 16 Mar 2006 19:15:31 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Issue 168] split-out filter draft: IANA Date: Thu, 16 Mar 2006 11:15:10 -0800 Message-ID: Thread-Topic: [Issue 168] split-out filter draft: IANA Thread-Index: AcY/CVfTb17avNXBTL+4DqfWU5XJSwKJELBA From: "Sanchez, Mauricio" To: "Greg Weber (gdweber)" , Change requested will be made. Thanks for the in-depth review. Cheers, MS=20 > -----Original Message----- > From: owner-radiusext@ops.ietf.org=20 > [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Greg Weber=20 > (gdweber) > Sent: Friday, March 03, 2006 1:28 PM > To: radiusext@ops.ietf.org > Subject: [Issue 168] split-out filter draft: IANA >=20 >=20 > I see that draft-ietf-radext-filter-rules-00.txt fixes most=20 > of the editorial comments I made as part of issue 168. I=20 > guess we can close this issue if the authors will just agree=20 > to fix this (at some point): >=20 > - The IANA section says the draft is allocating six > attributes, but it's only allocating two. >=20 > Greg >=20 > -- > to unsubscribe send a message to=20 > radiusext-request@ops.ietf.org with the word 'unsubscribe' in=20 > a single line as the message text body. > archive: >=20 -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 16 Mar 2006 18:57:53 +0000 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: Proposed Resolution to Issue 180: Misuse of Data Types Date: Thu, 16 Mar 2006 10:57:32 -0800 Message-ID: <4C0FAAC489C8B74F96BEAD85EAEB262501B7BAA9@xmb-sjc-215.amer.cisco.com> Thread-Topic: Proposed Resolution to Issue 180: Misuse of Data Types Thread-Index: AcZJJaiv9ztfBbXUREq0Mwr6NJkAPAABZKKg From: "Glen Zorn \(gwz\)" To: "Bernard Aboba" Cc: Bernard Aboba <> supposedly scribbled: > The text of Issue 180 (and some of the subsequent discussion) is > enclosed below.=20 >=20 > The proposed resolution is to change "VLAN Tag" to "VLAN Flag" > everywhere in the document.=20 Sounds reasonable to me. >=20 > In looking at the mailing list discussion, I did not detect consensus > for making other changes.=20 Although I don't think that the discussion is altogether complete, I = would agree with your assessment of its progress thus far. >=20 > = -------------------------------------------------------------------------= --------------------------- > Issue 180: Misuse of Data Types > Submitter name: Dave Nelson > Submitter email address: dnelson@enterasys.com Date first submitted: > March 14, 2006=20 > Reference: http://ops.ietf.org/lists/radiusext/2006/msg00280.html > Document: VLAN/Priority -00 > Comment type: 'T'echnical > Priority: '1' Should fix > Section: 2.1. Egress-VLANID > Rationale/Explanation of issue: >=20 > I had previously raised this issue, and the resolution was we could > use a RADIUS data type of Integer, because only the VLANID (12-bit) > portion would be used. =20 > Thus, this object could be thought of as a range-limited integer. > Since I see that we still have the VLAN Tag fields, that resolution > falls apart. I claim that this data object is not an Integer. =20 >=20 > Someone offered the suggestion that Integers are not simply the > mathematical definition, i.e. the positive and negative whole > numbers and zero, that we all learned in high school. With all due > respect, =20 >=20 > I think that's patently wrong. It is true that one can write programs > that treat 8-bit, 16-bit, 32-bit or 64-bit "integers" as packed data > structures using mask, bit-field, shift and rotate operations. =20 >=20 > I still claim that those data structures are *not* integers simply > because they can be packed within the computer memory storage that is > also used by integers. Hopefully, there is more to data modeling=20 > than the storage length in bits. :-) =20 >=20 > We are currently having a debate on the RADEXT WG list about the > issue of derived data types, and no consensus has yet been reached. > However, until such a consensus is reached, it seems most appropriate > to follow the existing practice of defining derived data types as > Strings, with the bit-fields described in the text. I think that > over-loading base RADIUS data types with new meanings is > inappropriate. =20 >=20 > Given the relative timing of WGLC on this draft and the emerging > consensus on RADIUS Attribute Design Guidelines, I think this is the > best compromise. =20 >=20 > Requested change: >=20 > OLD: >=20 > Integer >=20 > The Integer field is four octets in length. The format is described > below:=20 >=20 > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> VLAN Tag | Pad | VLANID | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >=20 > The VLAN Tag field is one octet in length, and indicates whether the > frames on the VLAN are tagged (0x31) or untagged (0x32). The Pad > field is 12-bits in length and MUST be 0 (zero). The VLANID is > 12-bits in length and contains the [IEEE-802.1Q] VLAN VID value. =20 >=20 > NEW: >=20 > String >=20 > The String field is four octets in length. The format is described > below:=20 >=20 > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> VLAN Tag | Pad | VLANID | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >=20 > The VLAN Tag field is one octet in length, and indicates whether the > frames on the VLAN are tagged (0x31) or untagged (0x32). The Pad > field is 12-bits in length and MUST be 0 (zero). The VLANID is > 12-bits in length and contains the [IEEE-802.1Q] VLAN VID value. =20 >=20 > Section: 2.3. Egress-VLAN-Name > Rationale/Explanation of issue: >=20 > I'm rather uncomfortable with the usage of the VLAN Tag field, as it > seems to be at variance with the emerging WG consensus on complex or > structured data types. Once we standardize this usage, there will be > one more precedent in a RADIUS RFC to support ad-hoc data typing. =20 > If that's what RADEXT ultimately recommends, then this will be fine. > If the recommendation is to use a more formal method of aggregating > structured data, this will be one more anomaly. =20 >=20 > VLAN Tag >=20 > The VLAN tag field is one octet in length, and indicates whether the > frames on the VLAN are tagged (0x31) or untagged (0x32).=20 >=20 > Requested change: >=20 > I have no idea what (if any change) to request. Chalk this comment up > as my personal lament over the process that RADEXT has followed -- > delaying consensus on attributes design to the point where we are > standardizing new attributes using complex data types prior to having > defined the design guidelines for complex data types. =20 >=20 > Section 2.4 User-Priority-Table > Rationale/Explanation of issue: >=20 > With all due deference to the well understood "array - string > duality" we find in programming languages such as C, I think that > expressing a attribute whose value is an array in the form of a > RADIUS String type is unfortunate, for the reasons expressed above. =20 >=20 > Requested change: >=20 > (See above.) >=20 > The only way that I see to actually resolve my data typing / data > modeling concerns is to delay sending any RADEXT work item that uses > derived data types to the IESG until after we have sent the RADIUS > Design Guidelines and RADIUS Extended Attributes I-Ds to the IESG, > and that approach is not compatible with our milestones. =20 >=20 > [Glen Zorn] > With all due respect, I think that you are the one doing the > overloading:=20 > RFC 2568 says >=20 > integer 32 bit unsigned value, most significant octet first. >=20 > That's it. No range, no interpretation, nothing else. >=20 > [Emile Van Bergen] >> I see nothing that indicates this data type is anything other than an >> integer, typically expressed in a C language declaration as "unsigned >> long". >=20 > You're completely correct. And in the case of the VLAN attribute, it > *does* contain an unsigned integer value, one that's calculated as > follows:=20 >=20 > value =3D vlanflag * 16777216 + vlanid >=20 > The reverse goes as follows: >=20 > vlanflag =3D value / 16777216 > vlanid =3D value % 16777216 >=20 > (where > * denotes unsigned integer multiplication, > + denotes unsigned integer addition, > / denotes unsigned integer division and > % denotes taking the reminder of an unsigned integer division, all to > be carried out on unsigned integers in the range 0 .. 2**32-1)=20 >=20 > I'm not believing that people on this list would have to be explained > that shifting and masking bits are *not* magic operations that you > can only perform if you program in assembly (or its portable flavour, > C), but that those are normal mathematical operations on normal > integers: =20 > multiply and take remainder (by powers of 2). >=20 > You can do that, I think, even in Java, SAP/r3, XSLT, SQL and > whatever.=20 > This whole issue has nothing whatsoever to do with C structures. Hope this helps, ~gwz Why is it that most of the world's problems can't be solved by simply listening to John Coltrane? -- Henry Gabriel -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 16 Mar 2006 18:35:31 +0000 From: "Alan DeKok" To: "Avi Lior" Subject: Re: New Technical Issues RE: WG last call in progress on VLAN/Priority Draft cc: radiusext@ops.ietf.org Date: Thu, 16 Mar 2006 13:43:10 -0500 Message-Id: <20060316184310.AB50316CC1@mail.nitros9.org> "Avi Lior" wrote: > That is fine. But why should we balk when we are faced with a complex > attribute as required by a complex application. The argument that it > breaks the dictionary should NOT stop the work going forward. The > Dictionary should only parse it up to String. Let the application > decode the rest. Agreed. If the content of an attribute is a complex structure as determined by the application, I would *prefer* that the structure is defined elsewhere, and the RADIUS docs simply reference it. The contention comes when more and more complex structures are shoe-horned into RADIUS attributes, where those structures have no definition outside of RADIUS. In those cases, the preference is to use existing RADIUS types where possible. Where not, use the Diameter attribute format, and leverage it's grouping mechanism to get complicated structural relationships. Alan DeKok. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 16 Mar 2006 18:29:18 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: New Technical Issues RE: WG last call in progress on VLAN/Priority Draft Date: Thu, 16 Mar 2006 13:31:27 -0500 Message-ID: Thread-Topic: New Technical Issues RE: WG last call in progress on VLAN/Priority Draft Thread-Index: AcZJJBFsM7em8VdPReungqGoymPtaAAAFj3w From: "Avi Lior" To: "Alan DeKok" Cc: HI Alan, Please see inline....=20 > -----Original Message----- > From: aland@nitros9.org [mailto:aland@nitros9.org] On Behalf=20 > Of Alan DeKok > Sent: Thursday, March 16, 2006 1:09 PM > To: Avi Lior > Cc: radiusext@ops.ietf.org > Subject: Re: New Technical Issues RE: WG last call in=20 > progress on VLAN/Priority Draft >=20 > "Avi Lior" wrote: > ... >=20 > I think we're agreeing on most things, and just nit-picking=20 > on details. That being said, let's continue. I agree. > > But alan, you cant go on the assumption that you will only accept=20 > > non-binary "code" changes. >=20 > I'm not assuming that. I'm assuming that, again, for the=20 > 99% common case, dictionary updates are enough to enable the=20 > server to deal with new attributes. This has been true in my=20 > experience, in the last decade of working with RADIUS. That is the past.....today RADIUS and AAA for that matter is being asked to participate in more complex scenarios. So we have to let go of the past ---- let it go .... Let it go ;-) Examples of complicated AAA scenarios: EAP. RADIUS now has to have an EAP Authentication Server Prepaid or Credit control MIPv4 MIPv6 Redirection (complexity on client side) =20 > > Some attributes -- like the prepaid -- or mobile ip -- EAP=20 > --- require=20 > > complex algorithms to be executed. I doubt you can do them via=20 > > configuraiton files. >=20 > Which is why I never claimed you could. Please, don't=20 > think I'm unaware of algorithm changes that require updates=20 > to the server binary. I've mentioned that explicitely in=20 > previous messages. OK. I never claimed you are not aware. But since the Application has to parse the attribut anyway then on the transport layer why not just deal with it as a string? =20 > > Yes. I agree. But my parser in my product is very capable and can=20 > > handle more complex attribute structures then the other=20 > fellow. So I=20 > > can restate your statement as "complex things should be simle to do" >=20 > If your parser can handle algorithm updates, too, more power to you. > The problem the dictionaries solve is, again, the 99%=20 > common case where a more complex parser just isn't necessary. Yes in the old days ;-) for the simplest of applications. > > Semantics are handled by clever policy files which use the=20 > attribute=20 > > to compute some outcome. The policy files are NOT standard=20 > in RADIUS. >=20 > Agreed. But again, the dictionaries (to a large extent)=20 > simplify policy engines by removing the requirement that the=20 > policy engines understand RADIUS attributes. They don't. =20 > They just understand name to type mappings, and instances of=20 > named objects. Sure. But even in the Good Old Days of RADIUS attributes like User-name etc required complex parsing of the user-name usign Regular expressions. At least that was true in our deployements. And our deployements are never in the enterprise space. =20 > > The bottom line is this: > > We ought not make descision based on how complex or simple it is to=20 > > handle an attribute. That is nuts. >=20 > I'm not sure why. If an application can be supported by=20 > simply defining a new attribute, and requiring that the=20 > attribute be sent in a packet, then that application could be=20 > standardized with little discussion. That is fine. But why should we balk when we are faced with a complex attribute as required by a complex application. The argument that it breaks the dictionary should NOT stop the work going forward. The Dictionary should only parse it up to String. Let the application decode the rest. > If an application requires more complex changes to the=20 > protocol, then the decision to standardize it requires more=20 > discussion than the previous case. Dictionary is not Protocol!!! Application don't really change the protcol usually. Even complex ones. =20 > Complexity *does* influence decisions. Strongly. I don't agree that complexity should influnce decision. I think uncessary complexity should be reduced. But not to accept a RADIUs feature because its too complex is not correct. A RADIUS feature should be accepted if it's need is demonstrated regardless of its complexity. I agree that more complex application require more time to develop but at the application level and not neccesarily at the protocol level. And complex application does not necessarily mean a complex attribute. A simple attribute carrying an integer may be associated with a complex application. =20 > > My original motivation for having a standard for complex attributes=20 > > was because people were encoding attribute using name value=20 > pairs such=20 > > as: in a String address=3D"24 oberon",phone=3D" ". I wanted to=20 > stop that=20 > > because parsing these strings would slow every RADIUS server out=20 > > there, and it was wasting space. >=20 > Agreed completely. >=20 > > Also I resent somewhat the push now is so much that it=20 > ignores what we=20 > > did a two years ago. Based on discussion it was Jari who proposed=20 > > encoding RADIUS attributes using Diameter syntax (I seem to recall=20 > > that one of you guys were taking credit for that). >=20 > Sorry for any conflict... that wasn't the intent. >=20 > > I think any other coding scheme is nuts and we should just move on=20 > > with diameter encoding. Unless of course there is already working=20 > > code as in the case of Prepaid. >=20 > Agreed. Let's move forward on that basis. >=20 > Alan DeKok. >=20 -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 16 Mar 2006 18:28:43 +0000 Message-ID: From: "Bernard Aboba" To: radiusext@ops.ietf.org Bcc: Subject: Strawman VLAN -01 document Date: Thu, 16 Mar 2006 10:28:29 -0800 Mime-Version: 1.0 Content-Type: text/plain; format=flowed A version of the RADIUS VLAN/Priority document with all the proposed edits applied is available here: http://www.drizzle.com/~aboba/RADEXT/draft-ietf-radext-vlan-01.txt -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 16 Mar 2006 18:15:31 +0000 Message-ID: From: "Bernard Aboba" To: radiusext@ops.ietf.org Bcc: Subject: Proposed Resolution to Issue 180: Misuse of Data Types Date: Thu, 16 Mar 2006 10:15:17 -0800 Mime-Version: 1.0 Content-Type: text/plain; format=flowed The text of Issue 180 (and some of the subsequent discussion) is enclosed below. The proposed resolution is to change "VLAN Tag" to "VLAN Flag" everywhere in the document. In looking at the mailing list discussion, I did not detect consensus for making other changes. ---------------------------------------------------------------------------------------------------- Issue 180: Misuse of Data Types Submitter name: Dave Nelson Submitter email address: dnelson@enterasys.com Date first submitted: March 14, 2006 Reference: http://ops.ietf.org/lists/radiusext/2006/msg00280.html Document: VLAN/Priority -00 Comment type: 'T'echnical Priority: '1' Should fix Section: 2.1. Egress-VLANID Rationale/Explanation of issue: I had previously raised this issue, and the resolution was we could use a RADIUS data type of Integer, because only the VLANID (12-bit) portion would be used. Thus, this object could be thought of as a range-limited integer. Since I see that we still have the VLAN Tag fields, that resolution falls apart. I claim that this data object is not an Integer. Someone offered the suggestion that Integers are not simply the mathematical definition, i.e. the positive and negative whole numbers and zero, that we all learned in high school. With all due respect, I think that's patently wrong. It is true that one can write programs that treat 8-bit, 16-bit, 32-bit or 64-bit "integers" as packed data structures using mask, bit-field, shift and rotate operations. I still claim that those data structures are *not* integers simply because they can be packed within the computer memory storage that is also used by integers. Hopefully, there is more to data modeling than the storage length in bits. :-) We are currently having a debate on the RADEXT WG list about the issue of derived data types, and no consensus has yet been reached. However, until such a consensus is reached, it seems most appropriate to follow the existing practice of defining derived data types as Strings, with the bit-fields described in the text. I think that over-loading base RADIUS data types with new meanings is inappropriate. Given the relative timing of WGLC on this draft and the emerging consensus on RADIUS Attribute Design Guidelines, I think this is the best compromise. Requested change: OLD: Integer The Integer field is four octets in length. The format is described below: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | VLAN Tag | Pad | VLANID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The VLAN Tag field is one octet in length, and indicates whether the frames on the VLAN are tagged (0x31) or untagged (0x32). The Pad field is 12-bits in length and MUST be 0 (zero). The VLANID is 12-bits in length and contains the [IEEE-802.1Q] VLAN VID value. NEW: String The String field is four octets in length. The format is described below: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | VLAN Tag | Pad | VLANID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The VLAN Tag field is one octet in length, and indicates whether the frames on the VLAN are tagged (0x31) or untagged (0x32). The Pad field is 12-bits in length and MUST be 0 (zero). The VLANID is 12-bits in length and contains the [IEEE-802.1Q] VLAN VID value. Section: 2.3. Egress-VLAN-Name Rationale/Explanation of issue: I'm rather uncomfortable with the usage of the VLAN Tag field, as it seems to be at variance with the emerging WG consensus on complex or structured data types. Once we standardize this usage, there will be one more precedent in a RADIUS RFC to support ad-hoc data typing. If that's what RADEXT ultimately recommends, then this will be fine. If the recommendation is to use a more formal method of aggregating structured data, this will be one more anomaly. VLAN Tag The VLAN tag field is one octet in length, and indicates whether the frames on the VLAN are tagged (0x31) or untagged (0x32). Requested change: I have no idea what (if any change) to request. Chalk this comment up as my personal lament over the process that RADEXT has followed -- delaying consensus on attributes design to the point where we are standardizing new attributes using complex data types prior to having defined the design guidelines for complex data types. Section 2.4 User-Priority-Table Rationale/Explanation of issue: With all due deference to the well understood "array - string duality" we find in programming languages such as C, I think that expressing a attribute whose value is an array in the form of a RADIUS String type is unfortunate, for the reasons expressed above. Requested change: (See above.) The only way that I see to actually resolve my data typing / data modeling concerns is to delay sending any RADEXT work item that uses derived data types to the IESG until after we have sent the RADIUS Design Guidelines and RADIUS Extended Attributes I-Ds to the IESG, and that approach is not compatible with our milestones. [Glen Zorn] With all due respect, I think that you are the one doing the overloading: RFC 2568 says integer 32 bit unsigned value, most significant octet first. That's it. No range, no interpretation, nothing else. [Emile Van Bergen] >I see nothing that indicates this data type is anything other than an >integer, typically expressed in a C language declaration as "unsigned >long". You're completely correct. And in the case of the VLAN attribute, it *does* contain an unsigned integer value, one that's calculated as follows: value = vlanflag * 16777216 + vlanid The reverse goes as follows: vlanflag = value / 16777216 vlanid = value % 16777216 (where * denotes unsigned integer multiplication, + denotes unsigned integer addition, / denotes unsigned integer division and % denotes taking the reminder of an unsigned integer division, all to be carried out on unsigned integers in the range 0 .. 2**32-1) I'm not believing that people on this list would have to be explained that shifting and masking bits are *not* magic operations that you can only perform if you program in assembly (or its portable flavour, C), but that those are normal mathematical operations on normal integers: multiply and take remainder (by powers of 2). You can do that, I think, even in Java, SAP/r3, XSLT, SQL and whatever. This whole issue has nothing whatsoever to do with C structures. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 16 Mar 2006 18:10:48 +0000 Message-ID: From: "Bernard Aboba" To: radiusext@ops.ietf.org Bcc: Subject: Proposed resolution to Issue 181: Review Date: Thu, 16 Mar 2006 10:10:39 -0800 Mime-Version: 1.0 Content-Type: text/plain; format=flowed The text of Issue 181 is enclosed below. The proposed resolution is as follows: Add expansions of VLAN, RADIUS, NAS, etc. Substitute RFC 4363 for RFC 2674. Replace the terminology section with definitions taken from RFC 3748 and RFC 4005: Authenticator The end of the link initiating EAP authentication. The term authenticator is used in [RFC3748] and [IEEE-802.1X], and has the same meaning in this document. backend authentication server A backend authentication server is an entity that provides an authentication service to an authenticator. When used, this server typically executes EAP methods for the authenticator. This terminology is also used in [IEEE-802.1X]. Network Access Server (NAS) A device that provides an access service for a user to a network. Supplicant The end of the link that responds to the authenticator in [IEEE-802.1X]. Rewrite the security considerations section as follows: "This specification describes the use of RADIUS for purposes of authentication, authorization and accounting in networks supporting [IEEE 802.1X]. Threats and security issues for this application are described in [RFC3579] and [RFC3580]; security issues encountered in roaming are described in [RFC2607]. This document specifies new attributes that can be included in existing RADIUS packets, which are protected as described in [RFC3579] and [RFC3576]. See those documents for a more detailed description. The security mechanisms described in [RFC3579] and [RFC3576] are focused on preventing an attacker from spoofing packets or modifying packets in transit. They do not prevent an authorized RADIUS server or proxy from inserting attributes with malicious intent. VLAN attributes sent by a RADIUS server or proxy may enable access to unauthorized VLANs. These vulnerabilities can be limited by performing authorization checks at the NAS. For example, a NAS can be configured to accept only certain VLANIDs from a given RADIUS server/proxy. Similarly, an attacker gaining control of a RADIUS server or proxy can modify the user priority table, causing either degradation of quality of service (by downgrading user priority of packets arriving at a port), or denial of service (by raising the level of priority of traffic at multiple ports of a device, oversubscribing the switch or link capabilities)." --------------------------------------------------------------------------------------- Issue 181: Review Submitter name: Dan Romascanu Submitter email address: dromasca@avaya.com Date first submitted: March 16, 2006 Reference: http://ops.ietf.org/lists/radiusext/2006/msg00311.html Document: VLAN/Priority -00 Comment type: 'T'echnical Priority: S Section: Various Rationale/Explanation of issue: I believe that the document is in pretty good shape, I still have a few comments which I believe are worth being considered. Content: 1. [RFC2674] is now obsoleted by [RFC4363]. I suggest to modify this reference. 2. The supplicant definition in 1.1 says: A supplicant is an entity that is being authenticated by an authenticator. The supplicant may be connected to the authenticator at one end of a point-to-point LAN segment or 802.11 wireless link. It is not clear why 'point-to-point' is mentioned here seemingly as opposed to wireless. I believe that the point that is being made is about connecting to a point-to-point or shared LAN segment. I suggest to replace this by: A supplicant is an entity that is being authenticated by an authenticator. The supplicant may be connected to the authenticator at one end of a point-to-point or shared LAN segment 3. I believe that there is at least one other example of security attack by insertion of attributes with a malicious content that is worth being mentioned. This is the case when the user priority table is modified causing either degradation of quality of service by downgrading user priority of packets arriving at a port, or denial of service by oversubscribing the switch or link capabilities by raising the level of priority of traffic at multiple ports of a device. Editorial: 1. It is recommended that abstract sections expand acronyms with the exception of the obvious (IP, TCP, etc...). I would say that VLAN and RADIUS are not in the obvious category. 2. NAS shows up first in section 1.3 and is not expanded. 3. The first phrase in Section 5 seems broken, I read it as the document being vulnerable, which is not the intent, I believe. [David Nelson] That is a good point. I think that further clarification would be desirable, however. My recollection of IEEE 802.1X is that it applies to ports, which may be point-to-point LAN links, or virtual ports on shared media defined by a protected association. So perhaps we could extend the suggested text, as follows: A supplicant is an entity that is being authenticated by an authenticator. The supplicant may be connected to the authenticator at one end of a point-to-point LAN link or via a protected association over a shared LAN segment. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 16 Mar 2006 18:07:38 +0000 Message-ID: From: "Bernard Aboba" To: radiusext@ops.ietf.org Bcc: Subject: Proposed Resolution to Issue 179: Editorial issue Date: Thu, 16 Mar 2006 10:07:32 -0800 Mime-Version: 1.0 Content-Type: text/plain; format=flowed The text of issue 179 is enclosed below. The proposed resolution is to accept the change. ----------------------------------------------------------------------------------------- Issue 179: Editorial Issue Submitter name: Dave Nelson Submitter email address: dnelson@enterasys.com Date first submitted: March 14, 2006 Reference: http://ops.ietf.org/lists/radiusext/2006/msg00279.html Document: VLAN/Priority -00 Comment type: 'E'ditorial Priority: '1' Should fix Section: 1.3 Attribute Interpretation Rationale/Explanation of issue: missing quote Requested change: s/value set to Unsupported Attribute" (401)/value set to "Unsupported Attribute" (401)/ -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 16 Mar 2006 18:06:39 +0000 Message-ID: From: "Bernard Aboba" To: radiusext@ops.ietf.org Bcc: Subject: Proposed Resolution to Issue 178: Allowing Hints in Request Messages Date: Thu, 16 Mar 2006 10:06:29 -0800 Mime-Version: 1.0 Content-Type: text/plain; format=flowed The text of Issue 178 is enclosed below. The proposed resolution is to accept the changes. -------------------------------------------------------------------------------------------------------------------------------- Issue 178: Allowing Hints in Request Messages Submitter name: Mauricio Sanchez Submitter email address: mauricio.sanchez@hp.com Date first submitted: March 6, 2006 Reference: http://ops.ietf.org/lists/radiusext/2006/msg00225.html Document: draft-ietf-radext-vlan-00.txt Comment type: T Priority: 2 Section: Table in section 3, individual attributes Rationale/Explanation of issue: Draft-ietf-radext-vlan-00 does not allow the new attributes to be sent in ACCESS-REQUEST messages. If allowed, attributes in the REQUEST message could serve as 'hints' to the RADIUS server during the decision making process. Requested change: Allow attributes to be sent ACCESS-REQUEST message Proposed changes to the document. - Descriptions of individual attribute descriptions would be changed to allow attributes in access request, as follows: Multiple attributes MAY be included in an Access-Request, Access-Accept or CoA-Request packet; this attribute MUST NOT be sent within an Access-Challenge, Access-Reject, Disconnect-Request, Disconnect-ACK, Disconnect-NAK, CoA-ACK, or CoA-NAK. -Table in section 3 would be changed to: Access- Access- Access- Access- CoA- Request Accept Reject Challenge Req # Attribute 0+ 0+ 0 0 0+ TBD Egress-VLANID 0-1 0-1 0 0 0-1 TBD Ingress-Filters 0+ 0+ 0 0 0+ TBD Egress-VLAN-Name 0-1 0-1 0 0 0-1 TBD User-Priority-Table -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 16 Mar 2006 18:01:03 +0000 From: "Alan DeKok" To: "Avi Lior" Subject: Re: New Technical Issues RE: WG last call in progress on VLAN/Priority Draft cc: radiusext@ops.ietf.org Date: Thu, 16 Mar 2006 13:08:36 -0500 Message-Id: <20060316180836.040BF16CC1@mail.nitros9.org> "Avi Lior" wrote: ... I think we're agreeing on most things, and just nit-picking on details. That being said, let's continue. > But alan, you cant go on the assumption that you will only accept > non-binary "code" changes. I'm not assuming that. I'm assuming that, again, for the 99% common case, dictionary updates are enough to enable the server to deal with new attributes. This has been true in my experience, in the last decade of working with RADIUS. > Some attributes -- like the prepaid -- or mobile ip -- EAP --- require > complex algorithms to be executed. I doubt you can do them via > configuraiton files. Which is why I never claimed you could. Please, don't think I'm unaware of algorithm changes that require updates to the server binary. I've mentioned that explicitely in previous messages. > Yes. I agree. But my parser in my product is very capable and can handle > more complex attribute structures then the other fellow. So I can > restate your statement as "complex things should be simle to do" If your parser can handle algorithm updates, too, more power to you. The problem the dictionaries solve is, again, the 99% common case where a more complex parser just isn't necessary. > Semantics are handled by clever policy files which use the attribute to > compute some outcome. The policy files are NOT standard in RADIUS. Agreed. But again, the dictionaries (to a large extent) simplify policy engines by removing the requirement that the policy engines understand RADIUS attributes. They don't. They just understand name to type mappings, and instances of named objects. > The bottom line is this: > We ought not make descision based on how complex or simple it is to > handle an attribute. That is nuts. I'm not sure why. If an application can be supported by simply defining a new attribute, and requiring that the attribute be sent in a packet, then that application could be standardized with little discussion. If an application requires more complex changes to the protocol, then the decision to standardize it requires more discussion than the previous case. Complexity *does* influence decisions. Strongly. > My original motivation for having a standard for complex attributes > was because people were encoding attribute using name value pairs > such as: in a String address="24 oberon",phone=" ". I wanted to > stop that because parsing these strings would slow every RADIUS > server out there, and it was wasting space. Agreed completely. > Also I resent somewhat the push now is so much that it ignores what we > did a two years ago. Based on discussion it was Jari who proposed > encoding RADIUS attributes using Diameter syntax (I seem to recall that > one of you guys were taking credit for that). Sorry for any conflict... that wasn't the intent. > I think any other coding scheme is nuts and we should just move on with > diameter encoding. Unless of course there is already working code as > in the case of Prepaid. Agreed. Let's move forward on that basis. Alan DeKok. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 16 Mar 2006 17:45:24 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: New Technical Issues RE: WG last call in progress on VLAN/Priority Draft Date: Thu, 16 Mar 2006 12:47:17 -0500 Message-ID: Thread-Topic: New Technical Issues RE: WG last call in progress on VLAN/Priority Draft Thread-Index: AcZIxyxypGUSp/7XTzu8RJZvgqLcNwAVqjVw From: "Avi Lior" To: "Alan DeKok" Cc: Alan, See inline.=20 > -----Original Message----- > From: aland@nitros9.org [mailto:aland@nitros9.org] On Behalf=20 > Of Alan DeKok > Sent: Thursday, March 16, 2006 2:04 AM > To: Avi Lior > Cc: radiusext@ops.ietf.org > Subject: Re: New Technical Issues RE: WG last call in=20 > progress on VLAN/Priority Draft >=20 > "Avi Lior" wrote: > > I know about policy files and GUIs and XmL and auto code etc... >=20 > Yes, I didn't mean to presume otherwise. My point was that=20 > we should separate binary code changes from configuration file "code" > changes. Binary code changes may be complicated and=20 > expensive to deploy. Configuration file changes can often be=20 > done by end users who know little about the protocol or=20 > implementation. But alan, you cant go on the assumption that you will only accept non-binary "code" changes. Some attributes -- like the prepaid -- or mobile ip -- EAP --- require complex algorithms to be executed. I doubt you can do them via configuraiton files. Lets get real here. What we are talking about is adding a new Application to the AAA. > > So whether I end up dealing with the attribute by pressing=20 > a few gui=20 > > buttons to add another If rule, or I have to insert a new=20 > EAP method=20 > > or Cryptography procedure do deal with the new attribute=20 > --- its all=20 > > code change. >=20 > That statement really masks the fact that some code changes=20 > are pretty trivial to do. Adding new policies based on=20 > recently updated dictionary entries is usually pretty=20 > trivial. Adding support for a new authentication algorithm=20 > is usually non-trivial. Exactly. =20 > Dictionaries allow a much more common set of use-cases for "code" > changes to be done trivially. They follow the maxim of=20 > "simple things should be simple to do". Yes. I agree. But my parser in my product is very capable and can handle more complex attribute structures then the other fellow. So I can restate your statement as "complex things should be simle to do" =20 > > In a very simple world yes you can live within the limits of your=20 > > dictionaries but in more complex scenarios, you have to roll some=20 > > good old fashion C compiler. >=20 > Agreed. That's why I said the dictionaries catch the 99%=20 > common case, not 100% of the situations. Lets be accurate here. The dicitionary is about encoding and decoding and very little about smeantics. Semantics are handled by clever policy files which use the attribute to compute some outcome. The policy files are NOT standard in RADIUS. Policy files are exectued by Policy Engines (which are NOT covered by RADIUS). Policy engines come in many flavours. Some are simple and some are complex. For example, some may provide very simple parsing capability and some support REGEX capabilities. Some can execute script code found in the policy file some can't. Therefore "How far you can go with your policy file -- depends on how much you were willing to invest in your policy engine". Where the policy engine stops is where you have to start adding code to you RADIUS server. In some cases adding code is expesive and in some cases very simple. It depends on how much you invested in you RADIUS design. The bottom line is this: We ought not make descision based on how complex or simple it is to handle an attribute. That is nuts. Rather we have to realize that RADIUS needs to support new Applications with new attributes. An entity that needs to use those attributes will have to parse them. Proxies that don't need to interact with them, should be able to skip the attribute in the RADIUS packet. This is done by having the attributes hide within RADIUS "STRINGS". Since the Application typically has to parse the attribute, it is not necessary for the RADIUS dictionary driven code to be able to parse it. RADIUS dictionaries don't need to parse the EAP-message. We are all comfortable with that. Why are we worried about that now???? It would be nice though to have a standard way to encode complex attributes. But given that typically these complex attributes require code beyond even the most complex policy engine then it is not necessary to do so. My original motivation for having a standard for complex attributes was because people were encoding attribute using name value pairs such as: in a String address=3D"24 oberon",phone=3D" ". I wanted to stop = that because parsing these strings would slow every RADIUS server out there, and it was wasting space. Also I resent somewhat the push now is so much that it ignores what we did a two years ago. Based on discussion it was Jari who proposed encoding RADIUS attributes using Diameter syntax (I seem to recall that one of you guys were taking credit for that). I think any other coding scheme is nuts and we should just move on with diameter encoding. Unless of course there is already working code as in the case of Prepaid. =20 > Alan DeKok. >=20 >=20 -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 16 Mar 2006 16:43:11 +0000 Message-ID: From: "Bernard Aboba" To: radiusext@ops.ietf.org Bcc: Subject: RE: PLEASE READ: RADEXT WG last call in progress on VLAN/Priority Draft Date: Thu, 16 Mar 2006 08:42:51 -0800 Mime-Version: 1.0 Content-Type: text/plain; format=flowed I have read the document, and am OK with it (other than the issues that have already been filed). -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 16 Mar 2006 15:52:07 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: RE: PLEASE READ: RADEXT WG last call in progress on VLAN/Priority Draft Date: Thu, 16 Mar 2006 10:51:36 -0500 Message-ID: <3CFB564E055A594B82C4FE89D2156560219142@MABOSEVS2.ets.enterasys.com> Thread-Topic: PLEASE READ: RADEXT WG last call in progress on VLAN/Priority Draft Thread-Index: AcZHfGXMHFOy8WwvSBuY1xHy0QOrGwBY6ptwAAwpcLA= From: "Nelson, David" To: Dan Romascanu writes... =20 > It is not clear why 'point-to-point' is mentioned here seemingly as > opposed to wireless. I believe that the point that is being made is > about connecting to a point-to-point or shared LAN segment. I suggest to > replace this by: >=20 > A supplicant is an entity that is being authenticated by an > authenticator. The supplicant may be connected to the > authenticator at one end of a point-to-point or shared LAN > segment That is a good point. I think that further clarification would be desirable, however. My recollection of IEEE 802.1X is that it applies to ports, which may be point-to-point LAN links, or virtual ports on shared media defined by a protected association. So perhaps we could extend the suggested text, as follows: A supplicant is an entity that is being authenticated by an authenticator. The supplicant may be connected to the authenticator at one end of a point-to-point LAN link or via a protected association over a shared LAN segment. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 16 Mar 2006 11:59:29 +0000 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: PLEASE READ: RADEXT WG last call in progress on VLAN/Priority Draft Date: Thu, 16 Mar 2006 13:58:59 +0200 Message-ID: Thread-Topic: PLEASE READ: RADEXT WG last call in progress on VLAN/Priority Draft Thread-Index: AcZHfGXMHFOy8WwvSBuY1xHy0QOrGwBY6ptw From: "Romascanu, Dan \(Dan\)" To: "Bernard Aboba" , I believe that the document is in pretty good shape, I still have a few comments which I believe are worth being considered.=20 Content: 1. [RFC2674] is now obsoleted by [RFC4363]. I suggest to modify this reference.=20 2. The supplicant definition in 1.1 says:=20 A supplicant is an entity that is being authenticated by an authenticator. The supplicant may be connected to the authenticator at one end of a point-to-point LAN segment or 802.11 wireless link. It is not clear why 'point-to-point' is mentioned here seemingly as opposed to wireless. I believe that the point that is being made is about connecting to a point-to-point or shared LAN segment. I suggest to replace this by: A supplicant is an entity that is being authenticated by an authenticator. The supplicant may be connected to the authenticator at one end of a point-to-point or shared LAN=20 segment 3. I believe that there is at least one other example of security attack by insertion of attributes with a malicious content that is worth being mentioned. This is the case when the user priority table is modified causing either degradation of quality of service by downgrading user priority of packets arriving at a port, or denial of service by oversubscribing the switch or link capabilities by raising the level of priority of traffic at multiple ports of a device.=20 Editorial: 1. It is recommended that abstract sections expand acronyms with the exception of the obvious (IP, TCP, etc...). I would say that VLAN and RADIUS are not in the obvious category. 2. NAS shows up first in section 1.3 and is not expanded.=20 3. The first phrase in Section 5 seems broken, I read it as the document being vulnerable, which is not the intent, I believe.=20 Regards, Dan =20 =20 > -----Original Message----- > From: owner-radiusext@ops.ietf.org=20 > [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Bernard Aboba > Sent: Tuesday, March 14, 2006 5:30 PM > To: radiusext@ops.ietf.org > Subject: PLEASE READ: RADEXT WG last call in progress on=20 > VLAN/Priority Draft >=20 > There is a RADEXT WG last call in progress on the VLAN and=20 > Priority Attributes document, prior to sending it on to the=20 > IESG for consideration as a Proposed Standard. >=20 > The document is available here: > http://www.ietf.org/internet-drafts/draft-ietf-radext-vlan-00.txt >=20 > RADEXT WG last call will last until Friday, March 17, 2006.=20 > Please send your comments to the RADEXT WG mailing list=20 > (radext@ops.ietf.org) in the format described on the RADEXT=20 > Issues list: > http://www.drizzle.com/~aboba/RADEXT/ >=20 > NOTE: 5 reviews are required for the document to advance as a=20 > Proposed Standard. If you have read the document, please=20 > post your opinion to the list, even if you have no issues to file: >=20 > So far, only two reviews have been received: > http://ops.ietf.org/lists/radiusext/2006/msg00169.html > http://ops.ietf.org/lists/radiusext/2006/msg00225.html >=20 >=20 >=20 > -- > to unsubscribe send a message to=20 > radiusext-request@ops.ietf.org with the word 'unsubscribe' in=20 > a single line as the message text body. > archive: >=20 -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 16 Mar 2006 07:02:10 +0000 From: "Alan DeKok" To: Barney Wolff Subject: Re: New Technical Issues RE: WG last call in progress on VLAN/Priority Draft cc: radiusext@ops.ietf.org Date: Thu, 16 Mar 2006 02:09:40 -0500 Message-Id: <20060316070940.59D7716CC1@mail.nitros9.org> Barney Wolff wrote: > Why in the name of Turing do we agree to do this for managing our > RADIUS entities but cannot or will not for the protocol itself? That's been the "holy grail" of many people for many years. Unfortunately, the skills required involve a large subset of each of coding, protocol design, algorithm analysis, language theory, etc. So far, it's been easier for protocol authors to hack something together than to try to design such a system. And the math people who might be able to do it don't feel the pain, so they're not interested. Many code projects still use hand-written parsers (no, I don't mean gcc), because for simple grammars, lexx & yacc are slower and more complex than a few lines of simple string manipulation in C. The last company I worked at had something close to what you describe. Unfortunately, using it required that the customers spend time learning how to use it, which turned out to be too high a hurdle for many people, even if it did end up solving the problem better than their existing tools. Alan DeKok. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 16 Mar 2006 06:56:27 +0000 From: "Alan DeKok" To: "Avi Lior" Subject: Re: New Technical Issues RE: WG last call in progress on VLAN/Priority Draft cc: radiusext@ops.ietf.org Date: Thu, 16 Mar 2006 02:03:52 -0500 Message-Id: <20060316070352.4F1C216CC1@mail.nitros9.org> "Avi Lior" wrote: > I know about policy files and GUIs and XmL and auto code etc... Yes, I didn't mean to presume otherwise. My point was that we should separate binary code changes from configuration file "code" changes. Binary code changes may be complicated and expensive to deploy. Configuration file changes can often be done by end users who know little about the protocol or implementation. > So whether I end up dealing with the attribute by pressing a few gui > buttons to add another If rule, or I have to insert a new EAP method or > Cryptography procedure do deal with the new attribute --- its all code > change. That statement really masks the fact that some code changes are pretty trivial to do. Adding new policies based on recently updated dictionary entries is usually pretty trivial. Adding support for a new authentication algorithm is usually non-trivial. Dictionaries allow a much more common set of use-cases for "code" changes to be done trivially. They follow the maxim of "simple things should be simple to do". > In a very simple world yes you can live within the limits of your > dictionaries but in more complex scenarios, you have to roll some good > old fashion C compiler. Agreed. That's why I said the dictionaries catch the 99% common case, not 100% of the situations. Alan DeKok. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 16 Mar 2006 02:21:17 +0000 Date: Wed, 15 Mar 2006 21:21:02 -0500 From: Barney Wolff To: Avi Lior Cc: Bernard Aboba , radiusext@ops.ietf.org Subject: Re: New Technical Issues RE: WG last call in progress on VLAN/Priority Draft Message-ID: <20060316022102.GA10560@pit.databus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.11 On Wed, Mar 15, 2006 at 06:31:07PM -0500, Avi Lior wrote: > > So whether or not the attribute is compound or not, if the server needs > to "interact" with that attribute then it needs to have new code added. > This applies to any server or client that needs to "interact" with that > attribute. > > So the notion of dictionary driven code and using existing radius types > really speaks only about not adding any code to the RADIUS packet > encoder/decoder. RADIUS entities do more than just "interact" with attributes. They also display them to humans, transfer them to other applications, store them, validate them, and so on. For many of these "peripheral" purposes, something like a dictionary is helpful. Of course, a sufficiently fancy dictionary can cope with packed data. But why should it have to? What is gained - a few bytes in a UDP packet? I am unable to imagine a scenario where the bandwidth sent or received by a RADIUS entity is a significant issue, even for very high volume applications. In my ideal world, there would be an abstract data language akin to ASN.1 (or ABNF) in which the set of attributes for some feature could be represented, and there would be automated means to generate code to handle encoding and decoding. The abstract data type definition would be included in the RFC defining the feature. Why in the name of Turing do we agree to do this for managing our RADIUS entities but cannot or will not for the protocol itself? That goes double for Diameter. Barney -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 16 Mar 2006 02:12:41 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: New Technical Issues RE: WG last call in progress on VLAN/Priority Draft Date: Wed, 15 Mar 2006 21:14:29 -0500 Message-ID: Thread-Topic: New Technical Issues RE: WG last call in progress on VLAN/Priority Draft Thread-Index: AcZIijAY0X4D+hxcQQiqQQdAc8VBdAAFGbsA From: "Avi Lior" To: "Alan DeKok" Cc: Alan I know about policy files and GUIs and XmL and auto code etc... All of those are code changes. Its just different code. Some code change is simpler then others. So whether I end up dealing with the attribute by pressing a few gui buttons to add another If rule, or I have to insert a new EAP method or Cryptography procedure do deal with the new attribute --- its all code change. =20 Lets be real about it and not loose sight that when a server is required to deal with a new attribute new code has to be inserted. > Dictionaries also allow the creation of complex policy=20 > languages, by separating the language syntax from the data=20 > and types the language operates on. In a very simple world yes you can live within the limits of your dictionaries but in more complex scenarios, you have to roll some good old fashion C compiler. =20 > -----Original Message----- > From: aland@nitros9.org [mailto:aland@nitros9.org] On Behalf=20 > Of Alan DeKok > Sent: Wednesday, March 15, 2006 6:47 PM > To: Avi Lior > Cc: radiusext@ops.ietf.org > Subject: Re: New Technical Issues RE: WG last call in=20 > progress on VLAN/Priority Draft >=20 > "Avi Lior" wrote: > > So whether or not the attribute is compound or not, if the server=20 > > needs to "interact" with that attribute then it needs to=20 > have new code added. > > This applies to any server or client that needs to "interact" with=20 > > that attribute. >=20 > For clients, yes. For servers, though, many have complex=20 > policy configuration files. So the policy has to be updated=20 > to deal with a new attribute, but the server code does not=20 > need to change. >=20 > In many cases, the policy is GUI driven, and is "if you see=20 > FOO with value BAR in the request, respond with FOOD with value BARD". >=20 > > So the notion of dictionary driven code and using existing radius=20 > > types really speaks only about not adding any code to the RADIUS=20 > > packet encoder/decoder. >=20 > Dictionaries also allow the creation of complex policy=20 > languages, by separating the language syntax from the data=20 > and types the language operates on. >=20 > Alan DeKok. >=20 -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 15 Mar 2006 23:39:43 +0000 From: "Alan DeKok" To: "Avi Lior" Subject: Re: New Technical Issues RE: WG last call in progress on VLAN/Priority Draft cc: radiusext@ops.ietf.org Date: Wed, 15 Mar 2006 18:47:17 -0500 Message-Id: <20060315234717.5629C16CC1@mail.nitros9.org> "Avi Lior" wrote: > So whether or not the attribute is compound or not, if the server needs > to "interact" with that attribute then it needs to have new code added. > This applies to any server or client that needs to "interact" with that > attribute. For clients, yes. For servers, though, many have complex policy configuration files. So the policy has to be updated to deal with a new attribute, but the server code does not need to change. In many cases, the policy is GUI driven, and is "if you see FOO with value BAR in the request, respond with FOOD with value BARD". > So the notion of dictionary driven code and using existing radius types > really speaks only about not adding any code to the RADIUS packet > encoder/decoder. Dictionaries also allow the creation of complex policy languages, by separating the language syntax from the data and types the language operates on. Alan DeKok. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 15 Mar 2006 23:29:19 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: New Technical Issues RE: WG last call in progress on VLAN/Priority Draft Date: Wed, 15 Mar 2006 18:31:07 -0500 Message-ID: Thread-Topic: New Technical Issues RE: WG last call in progress on VLAN/Priority Draft Thread-Index: AcZH343xDhzHqRBCSbmLgV9w0v+74gAp87Dg From: "Avi Lior" To: "Bernard Aboba" , Bernard, I agree with what you wrote and I want to add something: > As far as I can tell, while compound attributes have a rich=20 > history within RADIUS, being described in RFCs 2865, 2868,=20 > 2869, and 3162, at no point have any compound attributes been=20 > introduced which require individual addressing of=20 > sub-elements. So as far as I can see, it is not use of=20 > "compound attributes" but rather "individually addressable=20 > sub-elements" that represents the critical distinction here. But also, even if we added an attribute of known type say "FOO" type integer, the Server would not have to add any code to parse this attribute, but it probably will need to have code to handle this attribute, unless of course all the server did was record the attribute and did not intepret it. So whether or not the attribute is compound or not, if the server needs to "interact" with that attribute then it needs to have new code added. This applies to any server or client that needs to "interact" with that attribute. So the notion of dictionary driven code and using existing radius types really speaks only about not adding any code to the RADIUS packet encoder/decoder.=20 > -----Original Message----- > From: owner-radiusext@ops.ietf.org=20 > [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Bernard Aboba > Sent: Tuesday, March 14, 2006 10:17 PM > To: radiusext@ops.ietf.org > Subject: RE: New Technical Issues RE: WG last call in=20 > progress on VLAN/Priority Draft >=20 > Glen Zorn said: >=20 > "There are problems with such things, as this conversation=20 > illustrates. One is that one person's "meaningful type" is=20 > another's "meaningless distinction", leading to (possibly=20 > endless) discussions akin to those medieval ones involving=20 > angels and pins ;-); another is the addition of yet another=20 > constituency to the debate over protocol extension. How long=20 > would it be before we hear from some server vendor that some=20 > perfectly reasonable & extremely useful RADIUS extension=20 > cannot be adopted because "my parser won't handle that data type"?" >=20 > Maybe it would be useful to go back to the original=20 > justification for the RADIUS dictionary. RADIUS does not=20 > support explicit data typing as in ASN.1, for example. As=20 > far as I can tell, the purpose of including any typing at all=20 > in RADIUS is to enable support for new attributes by addition=20 > of dictionary entries, without changing code. This is not=20 > just an academic=20 > point about "data models" -- this has real impact on customers. >=20 > As Emile has noted, some implementations have added support=20 > for more elaborate structures, allowing compound attributes=20 > of type "STRING" to be entered more easily (e.g. the tagged=20 > attributes of RFC 2868). >=20 > However, this is but a detail -- using the basic RADIUS data=20 > types, it is possible for the administrator to add support=20 > for virtually any new attribute sent by the server to the=20 > client, by adding a dictionary entry. =20 > No new code required. So if we are talking about attributes=20 > only sent in Access-Challenges or Access-Accepts, I don't=20 > think see how compound attributes affect the ability of=20 > administrators to add support for new attributes without code changes. >=20 > The issue is really about attributes sent from the client to=20 > the server. As Emile noted, if the attribute sub-elements=20 > don't need to be addressed individually, such as if they are=20 > always handled as an opaque blob, then the attribute can be=20 > treated as type "STRING" by the server, and existing=20 > implementations will work just fine, so there is no issue. >=20 > The problem occurs if the sub-elements need to be referred to=20 > individually. =20 > Can existing implementations handle this, or will new code=20 > be required? My guess is that in most cases, new code *will*=20 > be required. If so, these kind of attributes represent a=20 > departure from the principles underlying the creation of the=20 > RADIUS dictionary, and will force users to upgrade their=20 > servers. So this is really the situation in which compound=20 > attributes impose a real cost. >=20 > As far as I can tell, while compound attributes have a rich=20 > history within RADIUS, being described in RFCs 2865, 2868,=20 > 2869, and 3162, at no point have any compound attributes been=20 > introduced which require individual addressing of=20 > sub-elements. So as far as I can see, it is not use of=20 > "compound attributes" but rather "individually addressable=20 > sub-elements" that represents the critical distinction here. >=20 >=20 >=20 > -- > to unsubscribe send a message to=20 > radiusext-request@ops.ietf.org with the word 'unsubscribe' in=20 > a single line as the message text body. > archive: >=20 -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 15 Mar 2006 18:31:50 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: RE: Attribute design thoughts (was RE: New Technical Issues RE: WG last call in progress on VLAN/Priority Draft) Date: Wed, 15 Mar 2006 12:56:55 -0500 Message-ID: <3CFB564E055A594B82C4FE89D215656021913C@MABOSEVS2.ets.enterasys.com> Thread-Topic: Attribute design thoughts (was RE: New Technical Issues RE: WG last call in progress on VLAN/Priority Draft) Thread-Index: AcZIPk/uZ3EXz7RMSS2eOwb6PRxETwABdIaQAAMILlAAAghOoA== From: "Nelson, David" To: Dan Romascanu writes... =20 > The WG has already a number of RADIUS extensions documents in a more > advance phase than the Design Guidelines. Yes. Although the Design Guidelines was originally one of the first milestones in the WG charter, so this was not supposed to happen. > Is the proposal to hold those waiting for the reference to review > against, ... We plan to stick to our current milestones. If rough consensus is achieved on the Design Guidelines, that should serve as the basis for review for some of the later deliverables. There is not plan to hold up documents scheduled to be forwarded to the IESG prior to such a consensus being formed on Design Guidelines. Such documents are being reviewed against past practice, and on an ad-hoc basis as to the current thoughts of WG members on attribute design. > ...or would these be treated as part of the already approved and try to > make the guidelines backwards compatible with them? I suppose that factors into the consensus opinion. It would seem unfortunate to publish Proposed Standards RFCs that do not comport well with the Design Guidelines BCP. The timing is unfortunate, but we are doing our best to manage to the current milestones. > Moreover, does the WG considers this within the scope of the Design > Guidelines document, or do we need more clarification or even an extension=20 > of the charter? I think it is understood to be within the scope of the Design Guidelines document, as per the current charter. If there is confusion as to the purpose and scope of that document, comment from others within the WG would be welcomed. -- Dave -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 15 Mar 2006 17:01:00 +0000 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Attribute design thoughts (was RE: New Technical Issues RE: WG last call in progress on VLAN/Priority Draft) Date: Wed, 15 Mar 2006 19:00:46 +0200 Message-ID: Thread-Topic: Attribute design thoughts (was RE: New Technical Issues RE: WG last call in progress on VLAN/Priority Draft) Thread-Index: AcZIPk/uZ3EXz7RMSS2eOwb6PRxETwABdIaQAAMILlA= From: "Romascanu, Dan \(Dan\)" To: "Nelson, David" , > -----Original Message----- > From: owner-radiusext@ops.ietf.org=20 > [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Nelson, David > Sent: Wednesday, March 15, 2006 6:18 PM > To: radiusext@ops.ietf.org > Subject: Attribute design thoughts (was RE: New Technical=20 > Issues RE: WG last call in progress on VLAN/Priority Draft) >=20 > Emile van Bergen writes... >=20 > > It was half serious. What I'm after is to find out at which=20 > point you=20 > > would start to agree that certain things are better only taken > together. >=20 > OK. I was reacting to your phrasing "all kinds of bad, bad=20 > magic". That doesn't move us forward, either. >=20 > > We're having a theoretical debate, and you're not answering the=20 > > question. Let me try again. If RFC 2865 didn't have a time=20 > base type,=20 > > how would you propose a session time to be conveyed? As an=20 > attribute=20 > > consisting of subattributes allocated from a global IANA=20 > Type number=20 > > space, however wide? >=20 > OK, theoretically speaking then. >=20 > If there were no RADIUS time data type, then I would search=20 > to see if there were a standard one in common use, preferably=20 > one with a stable reference, e.g. an RFC. I would almost=20 > certainly choose Unix Epoch time (seconds since January 1,=20 > 1970) which conveniently fits in an Integer. > If I were worried about the 2024 (or whenever) wrap-around,=20 > I'd find another standard representation, and use that (maybe=20 > an unsigned long long, i.e. 64-bit integer). If I were=20 > *forced* to use the representation you suggest, i.e. separate=20 > members of a structure for each of the "units" of time, and=20 > there were no existing standard I could reference, then I=20 > would look to the RADIUS Design Guidelines to see what is recommended. >=20 > So, I haven't answered your question yet (but I will). My=20 > point up to this juncture is that the WG should reach a=20 > consensus on design guidelines, and then each individual=20 > attribute design decision should be made with the benefit of=20 > those recommendations, providing a certain level of=20 > consistency. This shouldn't be such an ad-hoc process, IMHO. > I suppose this is a controversial opinion, something like=20 > advocating coding style standards. :-) While I have an=20 > opinion on this, I really don't care so much as to what the=20 > WG decides, as long as it comes to a consensus, and does so=20 > fairly quickly. I would prefer that the guidelines are=20 > substantive, and provide some real guidance, rather than=20 > simply codifying the existing ad-hoc practices. >=20 > OK, so we're in an imperfect world, and the WG has not yet=20 > come to consensus on design guidelines, so I'm left to my own=20 > devices. How would I propose to encode the structure that=20 > you've presented as a hypothetical? Toss a coin? The=20 > problem is that in the absence of guidelines, it's a matter=20 > of personal style. >=20 > How would I suggest that the design guidelines be worded to=20 > recommend encoding of structured data representations? My=20 > suggestion would be to use the Extended RADIUS Attribute=20 > (however it is ultimately defined) and use whatever grouping=20 > (data aggregation) method it supports to structure the member=20 > elements into a logical structure. This could be via=20 > sub-attributes, or via tagged attributes, or via grouped=20 > attributes (as in Diameter). >=20 > I think it's important to reiterate some thoughts expressed=20 > elsewhere in this general discussion, however. One of those=20 > concepts is the issue of whether or not a RADIUS Server or=20 > RADIUS Client needs to take an action that depends on the=20 > value of one or more individual members of a data structure. =20 > So far, much of this discussion has been from the view point=20 > of RADIUS Servers, in terms of data dictionary=20 > implementations. We should also consider this from the NAS=20 > developer's viewpoint. >=20 > If a RADIUS entity (Server or Client) needs to take some=20 > action dependent upon an element in a structure, it would be=20 > valuable and desirable to have the individual elements easily=20 > addressable. Having sub-attribute IDs for these is one way,=20 > and in an Extended RADIUS Attribute we can define this scheme=20 > without incurring any backwards compatibility penalties. We=20 > could also write custom string parser code for each=20 > individual attribute, which could work from fixed octet=20 > offsets, or could search for specified delimiter values in=20 > variable length fields. I personally find this kind of code=20 > more cumbersome, less flexible, less re-usable, and more=20 > error prone. It's certainly good job security for RADIUS=20 > developers. :-) >=20 > If no RADIUS entity needs to take action on the values of the=20 > structure elements, e.g. it is passed to another entity (such=20 > as EAP), or it is simply intended to be dumped verbatim into=20 > a RADIUS Accounting Server log file, then it can perfectly=20 > well be densely packed into a string. > My only concern with this approach is that the author of a=20 > new attribute > *claims* that it can be treated as a string, because it's=20 > never parsed, when in fact implementations of that=20 > application eventually *do* need to have access to the=20 > individual data elements, and thus end up parsing densely=20 > packed strings. >=20 > Another way to look at this issue, purely for the sake of=20 > analysis, is to see how the same data items would be encoded=20 > in ASN.1, using SMIv2, for a MIB. Pretend that we're using=20 > SNMP to provision the NAS instead of RADIUS. How would you=20 > write the MIB? You could easily see a relationship between=20 > leaf OIDs and RADIUS attributes (or sub-attributes). Now=20 > before anyone starts the flames, I realize that RADIUS is not=20 > like SNMP. For one thing RADIUS doesn't have a formal data=20 > model, like SNMP. I think the exercise is potentially=20 > instructive, none the less. >=20 > If the eventual consensus of the WG is that individually=20 > addressable elements of a structure are not our cup of tea=20 > for attribute encoding guidelines, and that we really want to=20 > formalize the custom octet packing method for attribute=20 > encoding, then I could live with that, if it were algorithmic=20 > and predictable, from one attribute to another. One way to=20 > make such a scheme predictable would be to mimic the way a=20 > specified reference implementation of a C language complier,=20 > on a specified reference CPU architecture, would encode a C=20 > structure definition in physical memory, and simply clone=20 > that encoding method. > One could handle the on-the-wire endian-ness with a simple=20 > mechanism such as the host-to-net and net-to-host macros=20 > (e.g. htonl, ntohl, etc). >=20 > Any way we go, I'd *much* rather reach consensus on design=20 > guidelines and then be able to review proposed RADIUS=20 > extensions I-Ds against those concrete best current=20 > practices, rather than make ad-hoc evaluations of each new=20 > attribute against the personal opinions of the day. >=20 The WG has already a number of RADIUS extensions documents in a more advance phase than the Design Guidelines. Is the proposal to hold those waiting for the reference to review against, or would these be treated as part of the already approved and try to make the guidelines backwards compatible with them? Moreover, does the WG considers thisa within the scope of the Design Guidelines document, or do we need more clarification or even an extension of the charter? =20 Dan =20 -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 15 Mar 2006 16:17:45 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: Attribute design thoughts (was RE: New Technical Issues RE: WG last call in progress on VLAN/Priority Draft) Date: Wed, 15 Mar 2006 11:17:31 -0500 Message-ID: <3CFB564E055A594B82C4FE89D2156560219137@MABOSEVS2.ets.enterasys.com> Thread-Topic: Attribute design thoughts (was RE: New Technical Issues RE: WG last call in progress on VLAN/Priority Draft) Thread-Index: AcZIPk/uZ3EXz7RMSS2eOwb6PRxETwABdIaQ From: "Nelson, David" To: Emile van Bergen writes... > It was half serious. What I'm after is to find out at which point you > would start to agree that certain things are better only taken together. OK. I was reacting to your phrasing "all kinds of bad, bad magic". That doesn't move us forward, either. > We're having a theoretical debate, and you're not answering the > question. Let me try again. If RFC 2865 didn't have a time base type, > how would you propose a session time to be conveyed? As an attribute > consisting of subattributes allocated from a global IANA Type number > space, however wide? OK, theoretically speaking then. If there were no RADIUS time data type, then I would search to see if there were a standard one in common use, preferably one with a stable reference, e.g. an RFC. I would almost certainly choose Unix Epoch time (seconds since January 1, 1970) which conveniently fits in an Integer. If I were worried about the 2024 (or whenever) wrap-around, I'd find another standard representation, and use that (maybe an unsigned long long, i.e. 64-bit integer). If I were *forced* to use the representation you suggest, i.e. separate members of a structure for each of the "units" of time, and there were no existing standard I could reference, then I would look to the RADIUS Design Guidelines to see what is recommended. So, I haven't answered your question yet (but I will). My point up to this juncture is that the WG should reach a consensus on design guidelines, and then each individual attribute design decision should be made with the benefit of those recommendations, providing a certain level of consistency. This shouldn't be such an ad-hoc process, IMHO. I suppose this is a controversial opinion, something like advocating coding style standards. :-) While I have an opinion on this, I really don't care so much as to what the WG decides, as long as it comes to a consensus, and does so fairly quickly. I would prefer that the guidelines are substantive, and provide some real guidance, rather than simply codifying the existing ad-hoc practices. OK, so we're in an imperfect world, and the WG has not yet come to consensus on design guidelines, so I'm left to my own devices. How would I propose to encode the structure that you've presented as a hypothetical? Toss a coin? The problem is that in the absence of guidelines, it's a matter of personal style. How would I suggest that the design guidelines be worded to recommend encoding of structured data representations? My suggestion would be to use the Extended RADIUS Attribute (however it is ultimately defined) and use whatever grouping (data aggregation) method it supports to structure the member elements into a logical structure. This could be via sub-attributes, or via tagged attributes, or via grouped attributes (as in Diameter). I think it's important to reiterate some thoughts expressed elsewhere in this general discussion, however. One of those concepts is the issue of whether or not a RADIUS Server or RADIUS Client needs to take an action that depends on the value of one or more individual members of a data structure. So far, much of this discussion has been from the view point of RADIUS Servers, in terms of data dictionary implementations. We should also consider this from the NAS developer's viewpoint. If a RADIUS entity (Server or Client) needs to take some action dependent upon an element in a structure, it would be valuable and desirable to have the individual elements easily addressable. Having sub-attribute IDs for these is one way, and in an Extended RADIUS Attribute we can define this scheme without incurring any backwards compatibility penalties. We could also write custom string parser code for each individual attribute, which could work from fixed octet offsets, or could search for specified delimiter values in variable length fields. I personally find this kind of code more cumbersome, less flexible, less re-usable, and more error prone. It's certainly good job security for RADIUS developers. :-) If no RADIUS entity needs to take action on the values of the structure elements, e.g. it is passed to another entity (such as EAP), or it is simply intended to be dumped verbatim into a RADIUS Accounting Server log file, then it can perfectly well be densely packed into a string. My only concern with this approach is that the author of a new attribute *claims* that it can be treated as a string, because it's never parsed, when in fact implementations of that application eventually *do* need to have access to the individual data elements, and thus end up parsing densely packed strings. Another way to look at this issue, purely for the sake of analysis, is to see how the same data items would be encoded in ASN.1, using SMIv2, for a MIB. Pretend that we're using SNMP to provision the NAS instead of RADIUS. How would you write the MIB? You could easily see a relationship between leaf OIDs and RADIUS attributes (or sub-attributes). Now before anyone starts the flames, I realize that RADIUS is not like SNMP. For one thing RADIUS doesn't have a formal data model, like SNMP. I think the exercise is potentially instructive, none the less. If the eventual consensus of the WG is that individually addressable elements of a structure are not our cup of tea for attribute encoding guidelines, and that we really want to formalize the custom octet packing method for attribute encoding, then I could live with that, if it were algorithmic and predictable, from one attribute to another. One way to make such a scheme predictable would be to mimic the way a specified reference implementation of a C language complier, on a specified reference CPU architecture, would encode a C structure definition in physical memory, and simply clone that encoding method. One could handle the on-the-wire endian-ness with a simple mechanism such as the host-to-net and net-to-host macros (e.g. htonl, ntohl, etc). Any way we go, I'd *much* rather reach consensus on design guidelines and then be able to review proposed RADIUS extensions I-Ds against those concrete best current practices, rather than make ad-hoc evaluations of each new attribute against the personal opinions of the day. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 15 Mar 2006 14:49:38 +0000 Message-ID: From: "Bernard Aboba" To: radiusext@ops.ietf.org Bcc: Subject: Re: IETF last call comments on RADIUS Digest AWUthentcation Date: Wed, 15 Mar 2006 06:49:32 -0800 Mime-Version: 1.0 Content-Type: text/plain; format=flowed ---------- Forwarded message ---------- Date: Wed, 15 Mar 2006 14:31:45 +0000 From: Alexey Melnikov To: "Beck01, Wolfgang" Cc: aboba@internaut.com, bwijnen@lucent.com, david.kessens@nokia.com, dnelson@enterasys.com, john.loughney@nokia.com, dromasca@avay.com, miguel.an.garcia@nokia.com Subject: Re: AW: IETF last call comments on RADIUS Digest Authentication docum ent Beck01, Wolfgang wrote: >Alexey, > >my main focus for the -07 version was to address the 'discuss' >points from the IESG site. > > That is fine. I was under impression that all issues raised were addressed in -07. > > 1). [Major]: Everywhere in section 4: all references to "without quotes" > > [..] > > [Wolfgang] > > > Blindly removing the surrounding quotes is exactly > > what was meant. quoted-string is used to allow characters > > that would break the HTTP syntax. This is not relevant for RADIUS, as we > > have TLV. (Un-)Escaping the actual value would not save very much space > > (I'd guess that escapes are rare) but complicate the implementation. > > > [Alexey] > > I think you are missing the point. Unescaping is not an optional HTTP > > feature. An HTTP Digest username can contain "\" or <"> characters. They > > must be escaped as per HTTP quoted string syntax. For example if you > > have a username 'domain\user' it will be represented in HTTP Digest as > > "domain\\user". If a naive implementation just strips the quotes it will > > end up with 2 slashes and not 1, which will lead to digest verification > > failure. > > > Why do you think the RADIUS client should deal with escapes? >It does not look into the values. That's the RADIUS server's >task. > > I guess you can do that. In which case you still have to say that Digest servers MUST unescape values before processing them, as this is not obvious (I certainly wouldn't have implemented this way). > > This comment applies to at least to Digest-Username (section 4.13), > > Digest-Realm (section 4.2), Digest-Nonce (section 4.3) and Digest-Cnonce > > (section 4.11). > > > 2). [Medium]: It would be nice to see examples of both scenario 1 and >2 > > in the > > document. I think it will clean up a lot of confusion. > > > [..] > > > > [Alexey] > > The message flow is fine, but there are so many optional RADIUS options > > that a regular reader will be easily lost. An additional example can > > also help verify that your description is actually correct. I had to > > reread section 3.1 multiple times to understand how it relates to the > > two scenarios. > > > > I've split up the larger text blocks into sections to make it easier >to follow. > > I've seen this change and it improved the readability, thank you. But I still want another example ;-). > > 3). [Minor] > > > 3.2.5. Obtaining Nonces > > > > > The RADIUS server can send Digest-Qop, Digest-Algorithm, Digest- > > > Realm, Digest-Domain and Digest-Opaque attributes in the Access- > > > Challenge carrying the nonce. If these attributes are > present, the > > > client MUST use them. > > > The Digest-Realm attribute is required as per section 3.2. The use of > > "can" is confusing in this case, as all other attributes are optional. > > > I can't find the quoted section in -07. The closest match is: >"The RADIUS server can send Digest-Qop, Digest- >Algorithm, Digest-Domain and Digest-Opaque attributes in the Access- >Challenge carrying the nonce. If these attributes are present, the >client MUST use them." > Ok. The original issue seemed to be addressed. > > 4). [Medium] > > > > 3.2. RADIUS Server Behavior > > [...] > > > A RADIUS server MUST check if the RADIUS client is authorized to > > > serve users of the realm mentioned in the Digest-Realm > attribute. >If > > > the RADIUS client is not authorized, the RADIUS server > MUST send an > > > Access-Reject. The RADIUS server SHOULD log the event so as to > > > notify the operator, and MAY take additional action such > as sending > > > an Access-Reject in response to all future requests from > this >client, > > > until this behavior is reset by management action. > > > If the server follow the last MAY, this can be used by DOS attacks, so >I > > think this should be pointed out. > > > [Wolfgang] > > > In this paragraph or in the Security Considerations section? > > > [Alexey] > > In this section. > > > Not following the MAY might result in cracked passwords... > > There is a tradeoff, IMHO, the document should explain both problems with following and not following MAY. This would be much better than just explaining one side. > > 5). [Medium] > > > 4.4. Digest-Response-Auth attribute > > > > > Description > > > This attribute enables the RADIUS server to prove > possession of > > > the password. If the previously received > Digest-Qop attribute > > > was 'auth-int' (without quotes), the RADIUS server > MUST send a > > > Digest-HA1 attribute instead of a Digest-Response-Auth > > > attribute. > > > This MUST is confusing, as other sections say that both > > Digest-Response-Auth and Digest-HA1 are optional. > > > [Wolfgang] This is a conditional MUST. Digest-HA1 is mandatory, if > > Digest-Qop was > > auth-int. > > > [Alexey] > > The following text from section 3.1 (in -06, 3.2.3 in -07) suggests that > > Digest-HA1 is truly > > optional: > > o If the Access-Accept packet contains neither a Digest-Response- > > Auth nor a Digest-HA1 attribute, the RADIUS client will not create > > an Authentication-Info header for its HTTP-style response. > > > < > If the previously received Digest-Qop attribute > > was 'auth-int' (without surrounding quotes), the > RADIUS server > > MUST NOT send a Digest-Response-Auth attribute and SHOULD send > > a Digest-HA1 attribute instead (see section 4.19). > > > We have discussed that before. How do you express 'A MUST be sent if >conditions C holds, and MAY be sent if condition C doesn't hold.'? > > The best I can see is to use conditional "if C, then MAY ..., else MUST ...". I suggested specific text above, do you think it is wrong? >Is A mandatory? Is A optional? > > > > 6). [Medium] > > > > 4.8. Digest-Qop attribute > > > > > Description > > > This attribute holds the Quality of Protection > parameter that > > > influences the HTTP Digest calculation. This > attribute MUST > > > only be used in Access-Request and > Access-Challenge packets. A > > > RADIUS client SHOULD insert one of the Digest-Qop > attributes it > > > has received in a previous Access-Challenge packet. > > > I was under impression that the HTTP[-like] client is the one choosing > > Qop from the list of Qops specified by the RADIUS server. > > > The last sentence "A RADIUS client SHOULD insert one of the Digest-Qop > > attributes it has received in a previous Access-Challenge packet." > > implies that the RADIUS client (== HTTP server) is the one picking the > > Qop. I think the last sentence should be reworded to say something like > > this: > > > "A RADIUS client sends the Qop value received from the HTTP client in > > the Digest-Qop attribute." > > > See the 'Text' paragraph of the section. > > I will get back to you on this one. > > 7). [Medium] > > > > RADIUS > > > servers SHOULD insert at least one Digest-Qop > attribute in an > > > Access-Challenge packet. Digest-Qop is optional > in order to > > > preserve backward compatibility with a minimal > implementation > > > of [RFC2069]. > > > Type > > > [IANA: use 109 if possible] for Digest-Qop > > > Length > > > > =3 > > > Text > > > In Access-Requests, the RADIUS client takes the > value of the > > > qop directive (qop-value as described in > [RFC2617]) without the > > > quotes from the HTTP-style request it wants to > authenticate. > > > In Access-Challenge packets, the RADIUS server > puts a desired > > > qop-value into this attribute. If the RADIUS > server supports > > > more than one "quality of protection" value, it > puts each qop- > > > value into a separate Digest-Qop attribute. > > > As per my comment above - if multiple Qop values were specified by the > > RADIUS server, the RADIUS client needs to put them into a single "qop" > > directive containing comma separated list of Qop values. > > > [Wolfgang] This is one possibility. I've chosen a different one: > > > "If the RADIUS server supports more than one "quality of protection" > > value, it puts each qop-value into a separate Digest-Qop attribute." Do > > you object to splitting up the qop directive into various TLVs? > > > [Alexey] > > I think this will break existing HTTP Digest and/or DIGEST-MD5 (which is > > backward compatible with HTTP Digest) implementations. The problem is > > that the behavior you propose was never explicitly allowed or disallowed > > in the HTTP Digest document. > > > <in > > a single HTTP Digest qop directive, or add a note explaining possible > > interoperability issue if this is not done.>> > > > A RADIUS attribute consisting of a list of items would be a structured >attribute. >The use of structured attributes is >>highly<< controversial in the WG. >I dont see a problem with existing implementations. The server has to parse >the RADIUS message anyway. If you have a RfC 2617 lib, just concat the >attributes >to form a comma-separated list. > > I am not saying that doing one way or another is *difficult*. I am just pointing out that there are existing implementations which can't cope with "qop=foo,qop=bar". They will either treat it is an error, or ignore all but the last value. > > 8). [Minor] > > > > 4.13. Digest-Username attribute > > > > > Description > > > This attribute holds the user name used in the HTTP digest > > > calculation. The RADIUS server MUST use this > attribute only > > > for the purposes of calculating the digest. In order to > > > determine the appropriate user credentials, the > RADIUS server > > > MUST use the User-Name (1) attribute, and MUST NOT use the > > > Digest-Username attribute. This attribute MUST > only be used in > > > Access-Request packets. > > > I am still not convinced that the Digest-Username is ever different >from > > the User-Name attribute. I would like to see an example when they would > > be different. > > [Wolfgang] > > > What if your current policy was to assign HTTP user names containing >'@' > > signs? A RADIUS infrastructure would interpret those User-Names as NAIs > > which may lead to undesired effects. > > > [Alexey] > > I think giving this example in the document would explain why they may > > be different. > > > There are two attributes with nearly identical meaning. The document doesn't explain why both ot them are needed. An example you've mentioned will explain why both are needed. > > You also need to add some text explaining how User-Name can be derived > > from the Digest-Username. > > > Implementers of the original draft-sterman didn't seem to have that >problem. > > Sorry, this doesn't prove anything. Regards, Alexey -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 15 Mar 2006 14:49:10 +0000 Message-ID: From: "Bernard Aboba" To: radiusext@ops.ietf.org Bcc: Subject: Re: IETF last call comments on RADIUS Digest Authentication document Date: Wed, 15 Mar 2006 06:48:49 -0800 Mime-Version: 1.0 Content-Type: text/plain; format=flowed ---------- Forwarded message ---------- Date: Wed, 15 Mar 2006 15:02:28 +0100 From: "Beck01, Wolfgang" To: alexey.melnikov@isode.com, aboba@internaut.com Cc: bwijnen@lucent.com, david.kessens@nokia.com, dnelson@enterasys.com, john.loughney@nokia.com, dromasca@avay.com, miguel.an.garcia@nokia.com Subject: AW: IETF last call comments on RADIUS Digest Authentication document Alexey, my main focus for the -07 version was to address the 'discuss' points from the IESG site. >1). [Major]: Everywhere in section 4: all references to "without quotes" >[..] >[Wolfgang] > >Blindly removing the surrounding quotes is exactly >what was meant. quoted-string is used to allow characters >that would break the HTTP syntax. This is not relevant for RADIUS, as we >have TLV. (Un-)Escaping the actual value would not save very much space >(I'd guess that escapes are rare) but complicate the implementation. > >[Alexey] >I think you are missing the point. Unescaping is not an optional HTTP >feature. An HTTP Digest username can contain "\" or <"> characters. They >must be escaped as per HTTP quoted string syntax. For example if you have a >username 'domain\user' it will be represented in HTTP Digest as >"domain\\user". If a naive implementation just strips the quotes it will >end up with 2 slashes and not 1, which will lead to digest verification >failure. Why do you think the RADIUS client should deal with escapes? It does not look into the values. That's the RADIUS server's task. >This comment applies to at least to Digest-Username (section 4.13), >Digest-Realm (section 4.2), Digest-Nonce (section 4.3) and Digest-Cnonce >(section 4.11). > >2). [Medium]: It would be nice to see examples of both scenario 1 and 2 in >the >document. I think it will clean up a lot of confusion. > [..] >[Alexey] >The message flow is fine, but there are so many optional RADIUS options >that a regular reader will be easily lost. An additional example can also >help verify that your description is actually correct. I had to reread >section 3.1 multiple times to understand how it relates to the two >scenarios. > I've split up the larger text blocks into sections to make it easier to follow. >3). [Minor] > >3.2.5. Obtaining Nonces > > > > The RADIUS server can send Digest-Qop, Digest-Algorithm, Digest- > > Realm, Digest-Domain and Digest-Opaque attributes in the Access- > > Challenge carrying the nonce. If these attributes are present, the > > client MUST use them. > >The Digest-Realm attribute is required as per section 3.2. The use of "can" >is confusing in this case, as all other attributes are optional. I can't find the quoted section in -07. The closest match is: "The RADIUS server can send Digest-Qop, Digest- Algorithm, Digest-Domain and Digest-Opaque attributes in the Access- Challenge carrying the nonce. If these attributes are present, the client MUST use them." >4). [Medium] > > >3.2. RADIUS Server Behavior >[...] > > A RADIUS server MUST check if the RADIUS client is authorized to > > serve users of the realm mentioned in the Digest-Realm attribute. If > > the RADIUS client is not authorized, the RADIUS server MUST send an > > Access-Reject. The RADIUS server SHOULD log the event so as to > > notify the operator, and MAY take additional action such as sending > > an Access-Reject in response to all future requests from this client, > > until this behavior is reset by management action. > >If the server follow the last MAY, this can be used by DOS attacks, so I >think this should be pointed out. > >[Wolfgang] > >In this paragraph or in the Security Considerations section? > >[Alexey] >In this section. > Not following the MAY might result in cracked passwords... >5). [Medium] > >4.4. Digest-Response-Auth attribute > > > > Description > > This attribute enables the RADIUS server to prove possession of > > the password. If the previously received Digest-Qop attribute > > was 'auth-int' (without quotes), the RADIUS server MUST send a > > Digest-HA1 attribute instead of a Digest-Response-Auth > > attribute. > >This MUST is confusing, as other sections say that both >Digest-Response-Auth and Digest-HA1 are optional. > >[Wolfgang] This is a conditional MUST. Digest-HA1 is mandatory, if >Digest-Qop was >auth-int. > >[Alexey] >The following text from section 3.1 (in -06, 3.2.3 in -07) suggests that >Digest-HA1 is truly >optional: > o If the Access-Accept packet contains neither a Digest-Response- > Auth nor a Digest-HA1 attribute, the RADIUS client will not create > an Authentication-Info header for its HTTP-style response. > >< If the previously received Digest-Qop attribute > was 'auth-int' (without surrounding quotes), the RADIUS server > MUST NOT send a Digest-Response-Auth attribute and SHOULD send > a Digest-HA1 attribute instead (see section 4.19). > We have discussed that before. How do you express 'A MUST be sent if conditions C holds, and MAY be sent if condition C doesn't hold.'? Is A mandatory? Is A optional? > >6). [Medium] > > >4.8. Digest-Qop attribute > > > > Description > > This attribute holds the Quality of Protection parameter that > > influences the HTTP Digest calculation. This attribute MUST > > only be used in Access-Request and Access-Challenge packets. A > > RADIUS client SHOULD insert one of the Digest-Qop attributes it > > has received in a previous Access-Challenge packet. > >I was under impression that the HTTP[-like] client is the one choosing Qop >from the list of Qops specified by the RADIUS server. > >The last sentence "A RADIUS client SHOULD insert one of the Digest-Qop >attributes it has received in a previous Access-Challenge packet." implies >that the RADIUS client (== HTTP server) is the one picking the Qop. I think >the last sentence should be reworded to say something like this: > >"A RADIUS client sends the Qop value received from the HTTP client in the >Digest-Qop attribute." See the 'Text' paragraph of the section. > >7). [Medium] > > >RADIUS > > servers SHOULD insert at least one Digest-Qop attribute in an > > Access-Challenge packet. Digest-Qop is optional in order to > > preserve backward compatibility with a minimal implementation > > of [RFC2069]. > > Type > > [IANA: use 109 if possible] for Digest-Qop > > Length > > >=3 > > Text > > In Access-Requests, the RADIUS client takes the value of the > > qop directive (qop-value as described in [RFC2617]) without the > > quotes from the HTTP-style request it wants to authenticate. > > In Access-Challenge packets, the RADIUS server puts a desired > > qop-value into this attribute. If the RADIUS server supports > > more than one "quality of protection" value, it puts each qop- > > value into a separate Digest-Qop attribute. > >As per my comment above - if multiple Qop values were specified by the >RADIUS server, the RADIUS client needs to put them into a single "qop" >directive containing comma separated list of Qop values. > >[Wolfgang] This is one possibility. I've chosen a different one: > >"If the RADIUS server supports more than one "quality of protection" value, >it puts each qop-value into a separate Digest-Qop attribute." Do you object >to splitting up the qop directive into various TLVs? > >[Alexey] >I think this will break existing HTTP Digest and/or DIGEST-MD5 (which is >backward compatible with HTTP Digest) implementations. The problem is that >the behavior you propose was never explicitly allowed or disallowed in the >HTTP Digest document. > > <a single HTTP Digest qop directive, or add a note explaining possible >interoperability issue if this is not done.>> A RADIUS attribute consisting of a list of items would be a structured attribute. The use of structured attributes is >>highly<< controversial in the WG. I dont see a problem with existing implementations. The server has to parse the RADIUS message anyway. If you have a RfC 2617 lib, just concat the attributes to form a comma-separated list. > >8). [Minor] > > >4.13. Digest-Username attribute > > > > Description > > This attribute holds the user name used in the HTTP digest > > calculation. The RADIUS server MUST use this attribute only > > for the purposes of calculating the digest. In order to > > determine the appropriate user credentials, the RADIUS server > > MUST use the User-Name (1) attribute, and MUST NOT use the > > Digest-Username attribute. This attribute MUST only be used in > > Access-Request packets. > >I am still not convinced that the Digest-Username is ever different from >the User-Name attribute. I would like to see an example when they would be >different. >[Wolfgang] > >What if your current policy was to assign HTTP user names containing '@' >signs? A RADIUS infrastructure would interpret those User-Names as NAIs >which may lead to undesired effects. > >[Alexey] >I think giving this example in the document would explain why they may be >different. > >You also need to add some text explaining how User-Name can be derived from >the Digest-Username. Implementers of the original draft-sterman didn't seem to have that problem. Thanks for your efforts, Wolfgang -- T-Systems Next Generation IP Services and Systems +49 6151 937 2863 Am Kavalleriesand 3 64295 Darmstadt Germany -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 15 Mar 2006 14:40:10 +0000 Date: Wed, 15 Mar 2006 15:39:40 +0100 From: Emile van Bergen To: "Nelson, David" Cc: radiusext@ops.ietf.org Subject: Re: New Technical Issues RE: WG last call in progress on VLAN/Priority Draft Message-ID: <20060315143939.GC5751@note.evbergen.xs4all.nl> Mail-Followup-To: "Nelson, David" , radiusext@ops.ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.9i Hi, On Tue, Mar 14, 2006 at 05:33:48PM -0500, Nelson, David wrote: > Emile van Bergen writes... > > > Eg. the number of hours, minutes and seconds that a session lasted are > > so closely related that we decided to do all kinds of bad, bad magic > > to those 3 values and pack them together into one attribute: > > Acct-Session-Time. > > I think perhaps you are making a jest at my expense. That's fine; I > have a thick skin. It was half serious. What I'm after is to find out at which point you would start to agree that certain things are better only taken together. My small joke at your expense attempted to gauge how far we need to go before reaching common ground, but you sadly, you rejected my attempt. > > If all packing is bad, I suppose you also consider /that/ attribute a > > candidate for a complex data type as well? No? > > No. > > > Why not? > > Because RFC 2865 defines a time as a base data type: We're having a theoretical debate, and you're not answering the question. Let me try again. If RFC 2865 didn't have a time base type, how would you propose a session time to be conveyed? As an attribute consisting of subattributes allocated from a global IANA Type number space, however wide? No? Why not? Cheers, Emile. -- E-Advies - Emile van Bergen emile@e-advies.nl tel. +31 (0)78 6136282 http://www.e-advies.nl -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 15 Mar 2006 06:07:35 +0000 From: "Alan DeKok" To: "Bernard Aboba" Subject: Re: New Technical Issues RE: WG last call in progress on VLAN/Priority Draft cc: radiusext@ops.ietf.org Date: Wed, 15 Mar 2006 01:14:47 -0500 Message-Id: <20060315061447.05A7716CC1@mail.nitros9.org> "Bernard Aboba" wrote: > As far as I can tell, the purpose of including any typing at all in > RADIUS is to enable support for new attributes by addition of > dictionary entries, without changing code. This is not just an > academic point about "data models" -- this has real impact on > customers. Yes. The other side of this requirement is that new functionality that requires *interpretation* of the attribute content may require new types in the dictionary. This hasn't historically been a problem for implementors. That is, the dictionaries exist to solve the 99% common problem, where vendors need to send a string/integer/ipaddr in RADIUS to their box. Server vendors then can update dictionaries without changing server code. In this model, the VLAN format fits just fine. It's an ASCII string with magic format. That's no different than other magically formatted text strings like in RFC 2865: 5.22. Framed-Route ... That is followed by a space, a gateway address in dotted quad form, a space, and one or more metrics separated by spaces. For example, "192.168.1.0/24 192.168.1.1 1 2 -1 3 400". ... There may be others, but that's the first one that springs to mind. Multi-field text strings are well within common RADIUS practices. > The issue is really about attributes sent from the client to the server. As > Emile noted, if the attribute sub-elements don't need to be addressed > individually, such as if they are always handled as an opaque blob, then the > attribute can be treated as type "STRING" by the server, and existing > implementations will work just fine, so there is no issue. I concur. > As far as I can tell, while compound attributes have a rich history within > RADIUS, being described in RFCs 2865, 2868, 2869, and 3162, at no point have > any compound attributes been introduced which require individual addressing > of sub-elements. So as far as I can see, it is not use of "compound > attributes" but rather "individually addressable sub-elements" that > represents the critical distinction here. That's a good summary. For this draft, the semantics of the attribute would not change if the document was updated to make it an attribute of type "text" containing no embedded fields. The description text could then add that the format had special requirements: the VLAN name should be prefixed with an ASCII "1" or "2". If we go down that route, I would *then* say that there should be a space between the two fields, just to address human issues. Administrators can readily interpret multi-field text strings, if the fields are separated by spaces. As the document exists today, there are human interpretation issues, as was earlier pointed out. Still, I'm OK with it as it is. I had no objections during the whol review process, so it would be a little inopportune to comment now. Alan DeKok. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 15 Mar 2006 03:17:19 +0000 Message-ID: From: "Bernard Aboba" To: radiusext@ops.ietf.org Bcc: Subject: RE: New Technical Issues RE: WG last call in progress on VLAN/Priority Draft Date: Tue, 14 Mar 2006 19:17:07 -0800 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Glen Zorn said: "There are problems with such things, as this conversation illustrates. One is that one person's "meaningful type" is another's "meaningless distinction", leading to (possibly endless) discussions akin to those medieval ones involving angels and pins ;-); another is the addition of yet another constituency to the debate over protocol extension. How long would it be before we hear from some server vendor that some perfectly reasonable & extremely useful RADIUS extension cannot be adopted because "my parser won't handle that data type"?" Maybe it would be useful to go back to the original justification for the RADIUS dictionary. RADIUS does not support explicit data typing as in ASN.1, for example. As far as I can tell, the purpose of including any typing at all in RADIUS is to enable support for new attributes by addition of dictionary entries, without changing code. This is not just an academic point about "data models" -- this has real impact on customers. As Emile has noted, some implementations have added support for more elaborate structures, allowing compound attributes of type "STRING" to be entered more easily (e.g. the tagged attributes of RFC 2868). However, this is but a detail -- using the basic RADIUS data types, it is possible for the administrator to add support for virtually any new attribute sent by the server to the client, by adding a dictionary entry. No new code required. So if we are talking about attributes only sent in Access-Challenges or Access-Accepts, I don't think see how compound attributes affect the ability of administrators to add support for new attributes without code changes. The issue is really about attributes sent from the client to the server. As Emile noted, if the attribute sub-elements don't need to be addressed individually, such as if they are always handled as an opaque blob, then the attribute can be treated as type "STRING" by the server, and existing implementations will work just fine, so there is no issue. The problem occurs if the sub-elements need to be referred to individually. Can existing implementations handle this, or will new code be required? My guess is that in most cases, new code *will* be required. If so, these kind of attributes represent a departure from the principles underlying the creation of the RADIUS dictionary, and will force users to upgrade their servers. So this is really the situation in which compound attributes impose a real cost. As far as I can tell, while compound attributes have a rich history within RADIUS, being described in RFCs 2865, 2868, 2869, and 3162, at no point have any compound attributes been introduced which require individual addressing of sub-elements. So as far as I can see, it is not use of "compound attributes" but rather "individually addressable sub-elements" that represents the critical distinction here. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 15 Mar 2006 02:48:45 +0000 Message-ID: From: "Bernard Aboba" To: radiusext@ops.ietf.org Bcc: Subject: IETF last call comments on RADIUS Digest Authentication document not addressed Date: Tue, 14 Mar 2006 18:48:11 -0800 Mime-Version: 1.0 Content-Type: text/plain; format=flowed >---------- Forwarded message ---------- >Date: Wed, 15 Mar 2006 02:26:43 +0000 >From: Alexey Melnikov To: Bernard Aboba Cc: bwijnen@lucent.com, david.kessens@nokia.com, dnelson@enterasys.com, john.loughney@nokia.com, dromasca@avay.com, beckw@t-systems.com, miguel.an.garcia@nokia.com Subject: Re: IETF last call comments on RADIUS Digest Authentication document I've just checked the updated document and about half of the issues I've I've reduced my original comments to the following list (Note, even though some of the comments are minor, I would like to at least hear back some argument from authors on why they would not be addressed. My new comments are enclosed in <<>>): 1). [Major]: Everywhere in section 4: all references to "without quotes" has to be replaced with "unquoted" or similar. "Without quotes" can be interpreted as just blindly removing the surrounding quote characters, however many attribute values are allowed to contain quoted (escaped) "\" and <">, so just removing the quotes will not produce proper result. >[Wolfgang] > >Blindly removing the surrounding quotes is exactly >what was meant. quoted-string is used to allow characters >that would break the HTTP syntax. This is not relevant for RADIUS, >as we have TLV. (Un-)Escaping the actual value would not save very >much space (I'd guess that escapes are rare) but complicate the >implementation. [Alexey] I think you are missing the point. Unescaping is not an optional HTTP feature. An HTTP Digest username can contain "\" or <"> characters. They must be escaped as per HTTP quoted string syntax. For example if you have a username 'domain\user' it will be represented in HTTP Digest as "domain\\user". If a naive implementation just strips the quotes it will end up with 2 slashes and not 1, which will lead to digest verification failure. This comment applies to at least to Digest-Username (section 4.13), Digest-Realm (section 4.2), Digest-Nonce (section 4.3) and Digest-Cnonce (section 4.11). 2). [Medium]: It would be nice to see examples of both scenario 1 and 2 in the document. I think it will clean up a lot of confusion. >[Wolfgang] > >What's wrong with message flow given in 1.3.1 figure 2? > [Alexey] The message flow is fine, but there are so many optional RADIUS options that a regular reader will be easily lost. An additional example can also help verify that your description is actually correct. I had to reread section 3.1 multiple times to understand how it relates to the two scenarios. 3). [Minor] >3.2.5. Obtaining Nonces > >The RADIUS server can send Digest-Qop, Digest-Algorithm, Digest- >Realm, Digest-Domain and Digest-Opaque attributes in the Access- >Challenge carrying the nonce. If these attributes are present, the >client MUST use them. The Digest-Realm attribute is required as per section 3.2. The use of "can" is confusing in this case, as all other attributes are optional. 4). [Medium] >3.2. RADIUS Server Behavior >[...] >A RADIUS server MUST check if the RADIUS client is authorized to >serve users of the realm mentioned in the Digest-Realm attribute. If >the RADIUS client is not authorized, the RADIUS server MUST send an >Access-Reject. The RADIUS server SHOULD log the event so as to >notify the operator, and MAY take additional action such as sending >an Access-Reject in response to all future requests from this client, >until this behavior is reset by management action. If the server follow the last MAY, this can be used by DOS attacks, so I think this should be pointed out. >[Wolfgang] > >In this paragraph or in the Security Considerations section? [Alexey] In this section. 5). [Medium] >4.4. Digest-Response-Auth attribute > >Description >This attribute enables the RADIUS server to prove possession of >the password. If the previously received Digest-Qop attribute >was 'auth-int' (without quotes), the RADIUS server MUST send a >Digest-HA1 attribute instead of a Digest-Response-Auth >attribute. This MUST is confusing, as other sections say that both Digest-Response-Auth and Digest-HA1 are optional. >[Wolfgang] This is a conditional MUST. Digest-HA1 is mandatory, if >Digest-Qop >was auth-int. [Alexey] The following text from section 3.1 (in -06, 3.2.3 in -07) suggests that Digest-HA1 is truly optional: o If the Access-Accept packet contains neither a Digest-Response- Auth nor a Digest-HA1 attribute, the RADIUS client will not create an Authentication-Info header for its HTTP-style response. <4.8. Digest-Qop attribute > >Description >This attribute holds the Quality of Protection parameter that >influences the HTTP Digest calculation. This attribute MUST >only be used in Access-Request and Access-Challenge packets. A >RADIUS client SHOULD insert one of the Digest-Qop attributes it >has received in a previous Access-Challenge packet. I was under impression that the HTTP[-like] client is the one choosing Qop from the list of Qops specified by the RADIUS server. The last sentence "A RADIUS client SHOULD insert one of the Digest-Qop attributes it has received in a previous Access-Challenge packet." implies that the RADIUS client (== HTTP server) is the one picking the Qop. I think the last sentence should be reworded to say something like this: "A RADIUS client sends the Qop value received from the HTTP client in the Digest-Qop attribute." 7). [Medium] >RADIUS >servers SHOULD insert at least one Digest-Qop attribute in an >Access-Challenge packet. Digest-Qop is optional in order to >preserve backward compatibility with a minimal implementation >of [RFC2069]. >Type > [IANA: use 109 if possible] for Digest-Qop >Length > > =3 >Text >In Access-Requests, the RADIUS client takes the value of the >qop directive (qop-value as described in [RFC2617]) without the >quotes from the HTTP-style request it wants to authenticate. >In Access-Challenge packets, the RADIUS server puts a desired >qop-value into this attribute. If the RADIUS server supports >more than one "quality of protection" value, it puts each qop- >value into a separate Digest-Qop attribute. As per my comment above - if multiple Qop values were specified by the RADIUS server, the RADIUS client needs to put them into a single "qop" directive containing comma separated list of Qop values. >[Wolfgang] This is one possibility. I've chosen a different one: > >"If the RADIUS server supports more than one "quality of protection" value, >it >puts each qop-value into a separate Digest-Qop attribute." >Do you object to splitting up the qop directive into various TLVs? > [Alexey] I think this will break existing HTTP Digest and/or DIGEST-MD5 (which is backward compatible with HTTP Digest) implementations. The problem is that the behavior you propose was never explicitly allowed or disallowed in the HTTP Digest document. <> 8). [Minor] > >4.13. Digest-Username attribute > >Description >This attribute holds the user name used in the HTTP digest >calculation. The RADIUS server MUST use this attribute only >for the purposes of calculating the digest. In order to >determine the appropriate user credentials, the RADIUS server >MUST use the User-Name (1) attribute, and MUST NOT use the >Digest-Username attribute. This attribute MUST only be used in >Access-Request packets. I am still not convinced that the Digest-Username is ever different from the User-Name attribute. I would like to see an example when they would be different. >[Wolfgang] > >What if your current policy was to assign HTTP user names containing '@' >signs? A RADIUS infrastructure would interpret those User-Names as NAIs >which may lead to undesired effects. > [Alexey] I think giving this example in the document would explain why they may be different. You also need to add some text explaining how User-Name can be derived from the Digest-Username. === Regards, Alexey -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 14 Mar 2006 23:47:09 +0000 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: Discussion of the RADIUS data model (was RE: New Technical Issues RE: WG last call in progress on VLAN/Priority Draft) Date: Tue, 14 Mar 2006 15:46:09 -0800 Message-ID: <4C0FAAC489C8B74F96BEAD85EAEB262501B0B051@xmb-sjc-215.amer.cisco.com> Thread-Topic: Discussion of the RADIUS data model (was RE: New Technical Issues RE: WG last call in progress on VLAN/Priority Draft) Thread-Index: AcZHh1+mNIg4d2j8QVS/PDrC7mlc0QACNsnQAADFOPAAASz2oAAA2/PwAATP3vAAAkQ0wAABFObw From: "Glen Zorn \(gwz\)" To: "Nelson, David" Cc: Nelson, David <> supposedly scribbled: ... >=20 > I agree that the right balance is important. My feeling is that we > need more formality in the RADIUS data model that we have now (which > is pretty minimal) to enhance interoperability going forwards, and > allow server vendors who wish to design data dictionary driven > implementations to do so. Exactly how much more is the topic we > should be debating. =20 >=20 > I've noticed, BTW, that no one on the list has taken up Greg Weber's > invitation to directly comment upon his latest RADIUS Design > Guidelines draft. We seem to be having some of that discussion, in a > meta-discussion sense, in this thread though. I suppose that simply > validates the observation that WG's don't really engage in discussing > any document until WGLC. :-) =20 I suggest that WGs do their best work in a non-linear fashion and = further, that documents are in fact the tangible expression of that = work, rather than ends in and of themselves. =20 Hope this helps, ~gwz Why is it that most of the world's problems can't be solved by simply listening to John Coltrane? -- Henry Gabriel -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 14 Mar 2006 22:54:13 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: Discussion of the RADIUS data model (was RE: New Technical Issues RE: WG last call in progress on VLAN/Priority Draft) Date: Tue, 14 Mar 2006 17:53:55 -0500 Message-ID: <3CFB564E055A594B82C4FE89D2156560219135@MABOSEVS2.ets.enterasys.com> Thread-Topic: Discussion of the RADIUS data model (was RE: New Technical Issues RE: WG last call in progress on VLAN/Priority Draft) Thread-Index: AcZHh1+mNIg4d2j8QVS/PDrC7mlc0QACNsnQAADFOPAAASz2oAAA2/PwAATP3v AAAkQ0wA== From: "Nelson, David" To: Glen Zorn writes... > I think it depends upon one's interpretation (which is what this > conversation is about). BTW, the definition of the "Address" data=20 > type in RFC 2865 is identical (with the exception that addresses=20 > can be signed) to that of "Integer"; what does that mean?=20 Good question. I don't think I've ever seen the address data type used. The notion of a signed address confuses me. :-) > More to=20 > the point, it doesn't matter to me whether the attribute data field > in question is defined as a string or an integer, since it is=20 > neither (or both, depending upon your POV). Well, I suppose it does matter when the encoding on the wire may differ, or one implementer's interpretation (POV) differs from another's, resulting in poor interoperability. > > I'm sure that there are lots of such programs, as C has no=20 > > strong data typing. >=20 > As you imply below, neither does RADIUS... I think RFCs 2865/66 have strong, but very limited (and limiting), data typing. Once you get beyond those base documents, yes, I think there is no consistent data model. > > The substance of this discussion, I think, is whether > > or not the RADIUS protocol should have meaningful data model,=20 > >and meaningful data types, >=20 > There are problems with such things, as this conversation=20 > illustrates. One is that one person's "meaningful type" is=20 > another's "meaningless distinction", leading to (possibly endless) > discussions akin to those medieval ones involving angels and pins ;-); > another is the addition of yet another constituency to the debate > over protocol extension. How long would it be before we hear from=20 > some server vendor that some perfectly reasonable & extremely useful > RADIUS extension cannot be adopted because "my parser won't handle=20 > that data type"? I agree that the right balance is important. My feeling is that we need more formality in the RADIUS data model that we have now (which is pretty minimal) to enhance interoperability going forwards, and allow server vendors who wish to design data dictionary driven implementations to do so. Exactly how much more is the topic we should be debating. I've noticed, BTW, that no one on the list has taken up Greg Weber's invitation to directly comment upon his latest RADIUS Design Guidelines draft. We seem to be having some of that discussion, in a meta-discussion sense, in this thread though. I suppose that simply validates the observation that WG's don't really engage in discussing any document until WGLC. :-) -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 14 Mar 2006 22:33:58 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: RE: New Technical Issues RE: WG last call in progress on VLAN/Priority Draft Date: Tue, 14 Mar 2006 17:33:48 -0500 Message-ID: <3CFB564E055A594B82C4FE89D2156560219134@MABOSEVS2.ets.enterasys.com> Thread-Topic: New Technical Issues RE: WG last call in progress on VLAN/Priority Draft Thread-Index: AcZHspfjSjUUPRChRoaJf0h88hWYswAA9dnw From: "Nelson, David" To: Emile van Bergen writes... > Eg. the number of hours, minutes and seconds that a session lasted are > so closely related that we decided to do all kinds of bad, bad magic to > those 3 values and pack them together into one attribute: > Acct-Session-Time. I think perhaps you are making a jest at my expense. That's fine; I have a thick skin. > If all packing is bad, I suppose you also consider /that/ attribute a > candidate for a complex data type as well? No?=20 No. > Why not? Because RFC 2865 defines a time as a base data type: time 32 bit unsigned value, most significant octet first -- seconds since 00:00:00 UTC, January 1, 1970. The standard Attributes do not use this data type but it is presented here for possible use in future attributes. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 14 Mar 2006 21:59:44 +0000 Date: Tue, 14 Mar 2006 22:59:35 +0100 From: Emile van Bergen To: "Nelson, David" Cc: radiusext@ops.ietf.org Subject: Re: New Technical Issues RE: WG last call in progress on VLAN/Priority Draft Message-ID: <20060314215934.GB3623@note.evbergen.xs4all.nl> Mail-Followup-To: "Nelson, David" , radiusext@ops.ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.9i Hi, On Tue, Mar 14, 2006 at 04:47:50PM -0500, Nelson, David wrote: > Emile van Bergen writes... > > > And in the case of the VLAN attribute, it > > *does* contain an unsigned integer value, one that's calculated as > > follows: > > > > value = vlanflag * 16777216 + vlanid > > > > The reverse goes as follows: > > > > vlanflag = value / 16777216 > > vlanid = value % 16777216 > > > > (where > > * denotes unsigned integer multiplication, > > + denotes unsigned integer addition, > > / denotes unsigned integer division and > > % denotes taking the reminder of an unsigned integer division, > > all to be carried out on unsigned integers in the range 0 .. 2**32-1) > > Well, that would be one method of defining the VLANID attribute that > would clearly an integer data type. *roffle* Surprise! It's the same definition as the one in the draft. Calloo, callay, and joy abounds. Cheers, Emile. > > I'm not believing that people on this list would have to be explained > > that shifting and masking bits are *not* magic operations that you can > > only perform if you program in assembly (or its portable flavour, C), > > but that those are normal mathematical operations on normal integers: > > multiply and take remainder (by powers of 2). > > No. My point was that packing multiple, separate fields into an opaque > data container is representing a complex data type, whether you perform > the packing using bit or octet offsets in a string type or arithmetic > manipulations on an integer type. Packing is packing. :-) Agreed about that last sentence. But to come to your point: some things are so closely associated that closely packing them together is *good*. Eg. the number of hours, minutes and seconds that a session lasted are so closely related that we decided to do all kinds of bad, bad magic to those 3 values and pack them together into one attribute: Acct-Session-Time. If all packing is bad, I suppose you also consider /that/ attribute a candidate for a complex data type as well? No? Why not? Cheers, Emile. -- E-Advies - Emile van Bergen emile@e-advies.nl tel. +31 (0)78 6136282 http://www.e-advies.nl -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 14 Mar 2006 21:50:30 +0000 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: New Technical Issues RE: WG last call in progress on VLAN/Priority Draft Date: Tue, 14 Mar 2006 13:50:23 -0800 Message-ID: <4C0FAAC489C8B74F96BEAD85EAEB262501B0AFB2@xmb-sjc-215.amer.cisco.com> Thread-Topic: New Technical Issues RE: WG last call in progress on VLAN/Priority Draft Thread-Index: AcZHh1+mNIg4d2j8QVS/PDrC7mlc0QACNsnQAADFOPAAASz2oAAA2/PwAATP3vA= From: "Glen Zorn \(gwz\)" To: "Nelson, David" Cc: Nelson, David <> supposedly scribbled: ... >>> (2) The range is defined as 0 .. 2**32-1. >>=20 >> But that's not what it _says_; what it _says_ is "32 bit unsigned >> value".=20 >=20 > Is that not what it means? I had always thought so. I think it depends upon one's interpretation (which is what this = conversation is about). BTW, the definition of the "Address" data type = in RFC 2865 is identical (with the exception that addresses can be = signed) to that of "Integer"; what does that mean? More to the point, = it doesn't matter to me whether the attribute data field in question is = defined as a string or an integer, since it is neither (or both, = depending upon your POV). =20 >=20 >> Now, everybody who has never written a C program that treated an >> unsigned long as a string of bits (rather than a whole number) raise >> their hands ... >=20 > I'm sure that there are lots of such programs, as C has no strong > data typing. =20 As you imply below, neither does RADIUS... > The substance of this discussion, I think, is whether > or not the RADIUS protocol should have meaningful model, and > meaningful data types,=20 There are problems with such things, as this conversation illustrates. = One is that one person's "meaningful type" is another's "meaningless = distinction", leading to (possibly endless) discussions akin to those = medieval ones involving angels and pins ;-); another is the addition of = yet another constituency to the debate over protocol extension. How = long would it be before we hear from some server vendor that some = perfectly reasonable & extremely useful RADIUS extension cannot be = adopted because "my parser won't handle that data type"? Hope this helps, ~gwz Why is it that most of the world's problems can't be solved by simply listening to John Coltrane? -- Henry Gabriel -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 14 Mar 2006 21:48:02 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: RE: New Technical Issues RE: WG last call in progress on VLAN/Priority Draft Date: Tue, 14 Mar 2006 16:47:50 -0500 Message-ID: <3CFB564E055A594B82C4FE89D2156560219133@MABOSEVS2.ets.enterasys.com> Thread-Topic: New Technical Issues RE: WG last call in progress on VLAN/Priority Draft Thread-Index: AcZHr7sez77FjM/xQAi/xugXrbyLpAAAHFUQ From: "Nelson, David" To: Emile van Bergen writes... > And in the case of the VLAN attribute, it > *does* contain an unsigned integer value, one that's calculated as > follows: >=20 > value =3D vlanflag * 16777216 + vlanid >=20 > The reverse goes as follows: >=20 > vlanflag =3D value / 16777216 > vlanid =3D value % 16777216 >=20 > (where > * denotes unsigned integer multiplication, > + denotes unsigned integer addition, > / denotes unsigned integer division and > % denotes taking the reminder of an unsigned integer division, > all to be carried out on unsigned integers in the range 0 .. 2**32-1) Well, that would be one method of defining the VLANID attribute that would clearly an integer data type. > I'm not believing that people on this list would have to be explained > that shifting and masking bits are *not* magic operations that you can > only perform if you program in assembly (or its portable flavour, C), > but that those are normal mathematical operations on normal integers: > multiply and take remainder (by powers of 2). No. My point was that packing multiple, separate fields into an opaque data container is representing a complex data type, whether you perform the packing using bit or octet offsets in a string type or arithmetic manipulations on an integer type. Packing is packing. :-) -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 14 Mar 2006 21:39:37 +0000 Date: Tue, 14 Mar 2006 22:39:02 +0100 From: Emile van Bergen To: "Nelson, David" Cc: radiusext@ops.ietf.org Subject: Re: New Technical Issues RE: WG last call in progress on VLAN/Priority Draft Message-ID: <20060314213902.GA3623@note.evbergen.xs4all.nl> Mail-Followup-To: "Nelson, David" , radiusext@ops.ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.9i Hi, On Tue, Mar 14, 2006 at 01:27:48PM -0500, Nelson, David wrote: > [GwZ] > > > RFC 2568 says > > > > integer 32 bit unsigned value, most significant octet first. > > > > That's it. No range, no interpretation, nothing else. > > I beg to differ. The way I interpret this RADIUS data type is as > follows: > > (1) Its an integer. > (2) The range is defined as 0 .. 2**32-1. > (3) Its unsigned. > (4) Its big-endian. > > I see nothing that indicates this data type is anything other than an > integer, typically expressed in a C language declaration as "unsigned > long". You're completely correct. And in the case of the VLAN attribute, it *does* contain an unsigned integer value, one that's calculated as follows: value = vlanflag * 16777216 + vlanid The reverse goes as follows: vlanflag = value / 16777216 vlanid = value % 16777216 (where * denotes unsigned integer multiplication, + denotes unsigned integer addition, / denotes unsigned integer division and % denotes taking the reminder of an unsigned integer division, all to be carried out on unsigned integers in the range 0 .. 2**32-1) I'm not believing that people on this list would have to be explained that shifting and masking bits are *not* magic operations that you can only perform if you program in assembly (or its portable flavour, C), but that those are normal mathematical operations on normal integers: multiply and take remainder (by powers of 2). You can do that, I think, even in Java, SAP/r3, XSLT, SQL and whatever. This whole issue has nothing whatsoever to do with C structures. Cheers, Emile. -- E-Advies - Emile van Bergen emile@e-advies.nl tel. +31 (0)78 6136282 http://www.e-advies.nl -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 14 Mar 2006 19:39:55 +0000 Date: Tue, 14 Mar 2006 14:39:36 -0500 From: Barney Wolff To: Alan DeKok Cc: Barney Wolff , radiusext@ops.ietf.org Subject: Re: New Technical Issues RE: WG last call in progress on VLAN/Priority Draft Message-ID: <20060314193936.GA63873@pit.databus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.11 On Tue, Mar 14, 2006 at 02:42:42PM -0500, Alan DeKok wrote: > Barney Wolff wrote: > > It seems to me that what's wrong with the attribute is not so much > > whether it should be called integer or string, but that it is a > > misuse (or clever hack) of the tag field to have semantic value. > > But it's not a RADIUS tag field. It's meaning has no correlation > with the tag fields of RADIUS tagged attributes, because those tags > have values 1..0x1f. Instead, it's using a VLAN tag. Oops. Sorry, I misremembered the set of valid tag values. So my comments are largely nonsensical. Barney -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 14 Mar 2006 19:35:07 +0000 From: "Alan DeKok" To: Barney Wolff Subject: Re: New Technical Issues RE: WG last call in progress on VLAN/Priority Draft cc: radiusext@ops.ietf.org Date: Tue, 14 Mar 2006 14:42:42 -0500 Message-Id: <20060314194242.7FF2516CC1@mail.nitros9.org> Barney Wolff wrote: > It seems to me that what's wrong with the attribute is not so much > whether it should be called integer or string, but that it is a > misuse (or clever hack) of the tag field to have semantic value. But it's not a RADIUS tag field. It's meaning has no correlation with the tag fields of RADIUS tagged attributes, because those tags have values 1..0x1f. Instead, it's using a VLAN tag. > That's clear from the allowed values of the first octet, 0x31 or > 0x32. So far as I'm aware, tags have only been used for grouping > and ordering of attribute sets. Here, what is manifestly > a tag field is being used to communicate a 1-bit flag value. Perhaps calling it "VLAN flag" rather than "VLAN tag" would minimize confusion. > I don't even believe that the clever hack will work well, because it > will allow undefined values (0x32 etc) to escape detection I'm not sure what you mean by that. > and it will make the human-readable form of the attribute look > misleading. That is certainly true. That's the price to be paid for not having a machine-readable data model. Alan DeKok. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 14 Mar 2006 19:22:08 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: RE: New Technical Issues RE: WG last call in progress on VLAN/Priority Draft Date: Tue, 14 Mar 2006 14:21:59 -0500 Message-ID: <3CFB564E055A594B82C4FE89D215656021912D@MABOSEVS2.ets.enterasys.com> Thread-Topic: New Technical Issues RE: WG last call in progress on VLAN/Priority Draft Thread-Index: AcZHh1+mNIg4d2j8QVS/PDrC7mlc0QACNsnQAADFOPAAASz2oAAA2/Pw From: "Nelson, David" To: Glen Zorn writes... > That they are not is patently false. Too many layers of negation for me to parse this, but I suspect it doesn't matter. > > (1) Its an integer. >=20 > Impossible. OK. Your point is taken. It's a computer representation of an integer in 32 bits. > > (2) The range is defined as 0 .. 2**32-1. >=20 > But that's not what it _says_; what it _says_ is "32 bit unsigned value". Is that not what it means? I had always thought so. > Now, everybody who has never written a C program that treated an > unsigned long as a string of bits (rather than a whole number) raise > their hands ... I'm sure that there are lots of such programs, as C has no strong data typing. The substance of this discussion, I think, is whether or not the RADIUS protocol should have meaningful model, and meaningful data types, not whether or not the C programming language enforces these properties. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 14 Mar 2006 19:13:50 +0000 Date: Tue, 14 Mar 2006 14:13:47 -0500 From: Barney Wolff Cc: radiusext@ops.ietf.org Subject: Re: New Technical Issues RE: WG last call in progress on VLAN/Priority Draft Message-ID: <20060314191347.GA11759@pit.databus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.11 It seems to me that what's wrong with the attribute is not so much whether it should be called integer or string, but that it is a misuse (or clever hack) of the tag field to have semantic value. That's clear from the allowed values of the first octet, 0x31 or 0x32. So far as I'm aware, tags have only been used for grouping and ordering of attribute sets. Here, what is manifestly a tag field is being used to communicate a 1-bit flag value. I don't even believe that the clever hack will work well, because it will allow undefined values (0x32 etc) to escape detection and it will make the human-readable form of the attribute look misleading. Barney -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 14 Mar 2006 19:10:06 +0000 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: New Technical Issues RE: WG last call in progress on VLAN/Priority Draft Date: Tue, 14 Mar 2006 11:09:49 -0800 Message-ID: <4C0FAAC489C8B74F96BEAD85EAEB262501B0AEC9@xmb-sjc-215.amer.cisco.com> Thread-Topic: New Technical Issues RE: WG last call in progress on VLAN/Priority Draft Thread-Index: AcZHh1+mNIg4d2j8QVS/PDrC7mlc0QACNsnQAADFOPAAASz2oA== From: "Glen Zorn \(gwz\)" To: "Nelson, David" Cc: Nelson, David <> supposedly scribbled: > Glen Zorn writes.... >=20 >> For this to be wrong, there must be a non-infinite representation of >> any integer. However, no such representation exists; the proof is >> left as a (trivial) exercise for the reader. >=20 > The fact that computer representations of integers cannot take on > infinite, does not invalidate the point I was attempting to make.=20 You said "Someone offered the suggestion that Integers are not simply = the mathematical definition, i.e. the positive and negative whole = numbers and zero, that we all learned in high school. With all due = respect, I think that's patently wrong." That they are not is patently = false. =20 > BTW, there has been work on indefinite precision arithmetic, which > permits extensible range integers, but not infinite ones. That is irrelevant, I think. =20 >=20 >> Indeed, there is as much as you want; the questions are, how useful >> is it to go down that road & (if it is at all useful), how far do we >> want to go?=20 >=20 > That, indeed, is the crux of the debate. >=20 >> With all due respect, I think that you are the one doing the >> overloading: RFC 2568 says=20 >>=20 >> integer 32 bit unsigned value, most significant octet first. >>=20 >> That's it. No range, no interpretation, nothing else. >=20 > I beg to differ. The way I interpret this RADIUS data type is as > follows: >=20 > (1) Its an integer. Impossible. > (2) The range is defined as 0 .. 2**32-1. But that's not what it _says_; what it _says_ is "32 bit unsigned = value". > (3) Its unsigned. > (4) Its big-endian. >=20 > I see nothing that indicates this data type is anything other than an > integer, typically expressed in a C language declaration as "unsigned > long".=20 OK, let's just accept this latter statement as valid. Now, everybody = who has never written a=20 C program that treated an unsigned long as a string of bits (rather than = a whole number) raise their hands (& send a note justifying your = presence on this list ;-). Hope this helps, ~gwz Why is it that most of the world's problems can't be solved by simply listening to John Coltrane? -- Henry Gabriel -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 14 Mar 2006 18:28:00 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: RE: New Technical Issues RE: WG last call in progress on VLAN/Priority Draft Date: Tue, 14 Mar 2006 13:27:48 -0500 Message-ID: <3CFB564E055A594B82C4FE89D2156560219129@MABOSEVS2.ets.enterasys.com> Thread-Topic: New Technical Issues RE: WG last call in progress on VLAN/Priority Draft Thread-Index: AcZHh1+mNIg4d2j8QVS/PDrC7mlc0QACNsnQAADFOPA= From: "Nelson, David" To: Glen Zorn writes.... > For this to be wrong, there must be a non-infinite representation of any > integer. However, no such representation exists; the proof is left as a > (trivial) exercise for the reader. The fact that computer representations of integers cannot take on infinite, does not invalidate the point I was attempting to make. BTW, there has been work on indefinite precision arithmetic, which permits extensible range integers, but not infinite ones. > Indeed, there is as much as you want; the questions are, how useful is it > to go down that road & (if it is at all useful), how far do we want to go? That, indeed, is the crux of the debate. > With all due respect, I think that you are the one doing the overloading: > RFC 2568 says >=20 > integer 32 bit unsigned value, most significant octet first. >=20 > That's it. No range, no interpretation, nothing else. I beg to differ. The way I interpret this RADIUS data type is as follows: (1) Its an integer. (2) The range is defined as 0 .. 2**32-1. (3) Its unsigned. (4) Its big-endian. I see nothing that indicates this data type is anything other than an integer, typically expressed in a C language declaration as "unsigned long". -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 14 Mar 2006 18:03:31 +0000 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: New Technical Issues RE: WG last call in progress on VLAN/Priority Draft Date: Tue, 14 Mar 2006 10:03:20 -0800 Message-ID: <4C0FAAC489C8B74F96BEAD85EAEB262501B0AE40@xmb-sjc-215.amer.cisco.com> Thread-Topic: New Technical Issues RE: WG last call in progress on VLAN/Priority Draft Thread-Index: AcZHh1+mNIg4d2j8QVS/PDrC7mlc0QACNsnQ From: "Glen Zorn \(gwz\)" To: "Nelson, David" Cc: Nelson, David <> supposedly scribbled: > Submitter name: Dave Nelson > Submitter email address: dnelson@enterasys.com Date first submitted: > March 14, 2006=20 > Reference: > Document: VLAN/Priority -00 > Comment type: 'T'echnical > Priority: '1' Should fix >=20 > Section: 2.1. Egress-VLANID > Rationale/Explanation of issue: >=20 > Misuse of data types. I had previously raised this issue, and the > resolution was we could use a RADIUS data type of Integer, because > only the VLANID (12-bit) portion would be used. Thus, this object > could be thought of as a range-limited integer. Since I see that we > still have the VLAN Tag fields, that resolution falls apart. I claim > that this data object is not an Integer. =20 >=20 > Someone offered the suggestion that Integers are not simply the > mathematical definition, i.e. the positive and negative whole numbers > and zero, that we all learned in high school. With all due respect, > I think that's patently wrong. =20 For this to be wrong, there must be a non-infinite representation of any = integer. However, no such representation exists; the proof is left as a = (trivial) exercise for the reader. > It is true that one can write > programs that treat 8-bit, 16-bit, 32-bit or 64-bit "integers" as > packed data structures using mask, bit-field, shift and rotate > operations. I still claim that those data structures are *not* > integers simply because they can be packed within the computer memory > storage that is also used by integers. Hopefully, there is more to > data modeling than the storage length in bits. :-) =20 Indeed, there is as much as you want; the questions are, how useful is = it to go down that road & (if it is at all useful), how far do we want = to go? =20 >=20 > We are currently having a debate on the RADEXT WG list about the > issue of derived data types, and no consensus has yet been reached.=20 > However, until such a consensus is reached, it seems most appropriate > to follow the existing practice of defining derived data types as > Strings, with the bit-fields described in the text. I think that > over-loading base RADIUS data types with new meanings is > inappropriate. =20 With all due respect, I think that you are the one doing the = overloading: RFC 2568 says=20 integer 32 bit unsigned value, most significant octet first. That's it. No range, no interpretation, nothing else. > Given the relative timing of WGLC on this draft and > the emerging consensus on RADIUS Attribute Design Guidelines, I think > this is the best compromise.=20 I think that the best compromise is to strictly interpret RFC 2568. =20 >=20 > Requested change: >=20 > OLD: >=20 > Integer >=20 > The Integer field is four octets in length. The format is > described below: >=20 > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > =20 > =20 > =20 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |=20 > VLAN Tag | Pad | VLANID | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =20 >=20 > The VLAN Tag field is one octet in length, and indicates whether > the frames on the VLAN are tagged (0x31) or untagged (0x32).=20 > The Pad field is 12-bits in length and MUST be 0 (zero). The > VLANID is 12-bits in length and contains the [IEEE-802.1Q] VLAN > VID value.=20 >=20 >=20 > NEW: >=20 > String >=20 > The String field is four octets in length. The format is > described below: >=20 > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > =20 > =20 > =20 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |=20 > VLAN Tag | Pad | VLANID | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =20 >=20 > The VLAN Tag field is one octet in length, and indicates whether > the frames on the VLAN are tagged (0x31) or untagged (0x32).=20 > The Pad field is 12-bits in length and MUST be 0 (zero). The > VLANID is 12-bits in length and contains the [IEEE-802.1Q] VLAN > VID value.=20 >=20 >=20 > Section: 2.3. Egress-VLAN-Name > Rationale/Explanation of issue: >=20 > I'm rather uncomfortable with the usage of the VLAN Tag field, as it > seems to be at variance with the emerging WG consensus on complex or > structured data types. Once we standardize this usage, there will be > one more precedent in a RADIUS RFC to support ad-hoc data typing. If > that's what RADEXT ultimately recommends, then this will be fine. If > the recommendation is to use a more formal method of aggregating > structured data, this will be one more anomaly. =20 >=20 > VLAN Tag >=20 > The VLAN tag field is one octet in length, and indicates whether > the frames on the VLAN are tagged (0x31) or untagged (0x32). >=20 > Requested change: >=20 > I have no idea what (if any change) to request. Chalk this comment > up as my personal lament over the process that RADEXT has followed -- > delaying consensus on attributes design to the point where we are > standardizing new attributes using complex data types prior to having > defined the design guidelines for complex data types. =20 >=20 >=20 > Section 2.4 User-Priority-Table > Rationale/Explanation of issue: >=20 > With all due deference to the well understood "array - string > duality" we find in programming languages such as C, I think that > expressing a attribute whose value is an array in the form of a > RADIUS String type is unfortunate, for the reasons expressed above. =20 >=20 > Requested change: >=20 > (See above.) >=20 > The only way that I see to actually resolve my data typing / data > modeling concerns is to delay sending any RADEXT work item that uses > derived data types to the IESG until after we have sent the RADIUS > Design Guidelines and RADIUS Extended Attributes I-Ds to the IESG, > and that approach is not compatible with our milestones. =20 >=20 > Regards, >=20 > Dave >=20 > David B. Nelson > Enterasys Networks, Inc. > 50 Minuteman Road > Andover, MA 01810-1008 > Phone: (978) 684-1330 > E-mail: dnelson@enterasys.com Hope this helps, ~gwz Why is it that most of the world's problems can't be solved by simply listening to John Coltrane? -- Henry Gabriel -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 14 Mar 2006 17:43:34 +0000 From: "Alan DeKok" To: "Bernard Aboba" Subject: Re: PLEASE READ: RADEXT WG last call in progress on VLAN/Priority Draft cc: radiusext@ops.ietf.org Date: Tue, 14 Mar 2006 12:50:27 -0500 Message-Id: <20060314175027.DAD6216CC1@mail.nitros9.org> "Bernard Aboba" wrote: > NOTE: 5 reviews are required for the document to advance as a Proposed > Standard. If you have read the document, please post your opinion to the > list, even if you have no issues to file: I'm OK with it. I have no additional issues. Alan DeKok. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 14 Mar 2006 16:50:24 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Subject: New Technical Issues RE: WG last call in progress on VLAN/Priority Draft Date: Tue, 14 Mar 2006 11:50:18 -0500 Message-ID: <3CFB564E055A594B82C4FE89D2156560219127@MABOSEVS2.ets.enterasys.com> Thread-Topic: New Technical Issues RE: WG last call in progress on VLAN/Priority Draft Thread-Index: AcZHh1+mNIg4d2j8QVS/PDrC7mlc0Q== From: "Nelson, David" To: Submitter name: Dave Nelson Submitter email address: dnelson@enterasys.com Date first submitted: March 14, 2006 Reference: Document: VLAN/Priority -00 Comment type: 'T'echnical Priority: '1' Should fix Section: 2.1. Egress-VLANID Rationale/Explanation of issue: Misuse of data types. I had previously raised this issue, and the = resolution was we could use a RADIUS data type of Integer, because only = the VLANID (12-bit) portion would be used. Thus, this object could be = thought of as a range-limited integer. Since I see that we still have = the VLAN Tag fields, that resolution falls apart. I claim that this data = object is not an Integer. Someone offered the suggestion that Integers are not simply the = mathematical definition, i.e. the positive and negative whole numbers = and zero, that we all learned in high school. With all due respect, I = think that's patently wrong. It is true that one can write programs = that treat 8-bit, 16-bit, 32-bit or 64-bit "integers" as packed data = structures using mask, bit-field, shift and rotate operations. I still = claim that those data structures are *not* integers simply because they = can be packed within the computer memory storage that is also used by = integers. Hopefully, there is more to data modeling than the storage = length in bits. :-) We are currently having a debate on the RADEXT WG list about the issue = of derived data types, and no consensus has yet been reached. However, = until such a consensus is reached, it seems most appropriate to follow = the existing practice of defining derived data types as Strings, with = the bit-fields described in the text. I think that over-loading base = RADIUS data types with new meanings is inappropriate. Given the = relative timing of WGLC on this draft and the emerging consensus on = RADIUS Attribute Design Guidelines, I think this is the best compromise. Requested change: OLD: Integer The Integer field is four octets in length. The format is described below: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | VLAN Tag | Pad | VLANID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The VLAN Tag field is one octet in length, and indicates whether the frames on the VLAN are tagged (0x31) or untagged (0x32). The Pad field is 12-bits in length and MUST be 0 (zero). The VLANID is 12-bits in length and contains the [IEEE-802.1Q] VLAN VID value. NEW: String The String field is four octets in length. The format is described below: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | VLAN Tag | Pad | VLANID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The VLAN Tag field is one octet in length, and indicates whether the frames on the VLAN are tagged (0x31) or untagged (0x32). The Pad field is 12-bits in length and MUST be 0 (zero). The VLANID is 12-bits in length and contains the [IEEE-802.1Q] VLAN VID value. Section: 2.3. Egress-VLAN-Name Rationale/Explanation of issue: I'm rather uncomfortable with the usage of the VLAN Tag field, as it = seems to be at variance with the emerging WG consensus on complex or = structured data types. Once we standardize this usage, there will be = one more precedent in a RADIUS RFC to support ad-hoc data typing. If = that's what RADEXT ultimately recommends, then this will be fine. If = the recommendation is to use a more formal method of aggregating = structured data, this will be one more anomaly. VLAN Tag The VLAN tag field is one octet in length, and indicates whether the frames on the VLAN are tagged (0x31) or untagged (0x32). Requested change: I have no idea what (if any change) to request. Chalk this comment up = as my personal lament over the process that RADEXT has followed -- = delaying consensus on attributes design to the point where we are = standardizing new attributes using complex data types prior to having = defined the design guidelines for complex data types.=20 Section 2.4 User-Priority-Table Rationale/Explanation of issue: With all due deference to the well understood "array - string duality" = we find in programming languages such as C, I think that expressing a = attribute whose value is an array in the form of a RADIUS String type is = unfortunate, for the reasons expressed above. Requested change: (See above.) The only way that I see to actually resolve my data typing / data = modeling concerns is to delay sending any RADEXT work item that uses = derived data types to the IESG until after we have sent the RADIUS = Design Guidelines and RADIUS Extended Attributes I-Ds to the IESG, and = that approach is not compatible with our milestones. Regards, =A0 Dave =A0 David B. Nelson Enterasys Networks, Inc. 50 Minuteman Road Andover, MA 01810-1008 Phone: (978) 684-1330=A0=20 E-mail: dnelson@enterasys.com =A0 -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 14 Mar 2006 16:44:41 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: New Editorial Issues RE: WG last call in progress on VLAN/Priority Draft Date: Tue, 14 Mar 2006 11:44:14 -0500 Message-ID: <3CFB564E055A594B82C4FE89D2156560219126@MABOSEVS2.ets.enterasys.com> Thread-Topic: New Editorial Issues RE: WG last call in progress on VLAN/Priority Draft Thread-Index: AcZHfGSiHdTtlJc8TU6RP+y/UmuzVQAAILVw From: "Nelson, David" To: Submitter name: Dave Nelson Submitter email address: dnelson@enterasys.com Date first submitted: March 14, 2006 Reference: Document: VLAN/Priority -00 Comment type: 'E'ditorial Priority: '1' Should fix Section: 1.3 Attribute Interpretation Rationale/Explanation of issue: missing quote Requested change: s/value set to Unsupported Attribute" (401)/value set to "Unsupported Attribute" (401)/ -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 14 Mar 2006 15:36:11 +0000 Message-ID: From: "Bernard Aboba" To: radiusext@ops.ietf.org Bcc: Subject: PLEASE READ: WG last call in progress on RADIUS Delegated IPv6 Prefix Attribute Date: Tue, 14 Mar 2006 07:35:57 -0800 Mime-Version: 1.0 Content-Type: text/plain; format=flowed There is a RADEXT WG last call in progress on the RADIUS Delegated IPv6 Prefix Attribute document, prior to sending it on to the IESG for consideration as a Proposed Standard. The document is available here: http://www.ietf.org/internet-drafts/draft-ietf-radext-delegated-prefix-00.txt RADEXT WG last call will last until Monday March 27, 2006. Please send your comments to the RADEXT WG list (radiusext@ops.ietf.org) in the format described on the RADEXT Issues List: http://www.drizzle.com/~aboba/RADEXT/ NOTE: 5 reviews are required for the document to advance as a Proposed Standard. If you have read the document, please post your opinion to the list, even if you have no issues to file. For example, if you support publication of this document, please send a message to the list to this effect. Currently, insufficient reviews have been posted to allow this document to advance. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 14 Mar 2006 15:31:03 +0000 Message-ID: From: "Bernard Aboba" To: radiusext@ops.ietf.org Bcc: Subject: PLEASE READ: RADEXT WG last call in progress on VLAN/Priority Draft Date: Tue, 14 Mar 2006 07:30:21 -0800 Mime-Version: 1.0 Content-Type: text/plain; format=flowed There is a RADEXT WG last call in progress on the VLAN and Priority Attributes document, prior to sending it on to the IESG for consideration as a Proposed Standard. The document is available here: http://www.ietf.org/internet-drafts/draft-ietf-radext-vlan-00.txt RADEXT WG last call will last until Friday, March 17, 2006. Please send your comments to the RADEXT WG mailing list (radext@ops.ietf.org) in the format described on the RADEXT Issues list: http://www.drizzle.com/~aboba/RADEXT/ NOTE: 5 reviews are required for the document to advance as a Proposed Standard. If you have read the document, please post your opinion to the list, even if you have no issues to file: So far, only two reviews have been received: http://ops.ietf.org/lists/radiusext/2006/msg00169.html http://ops.ietf.org/lists/radiusext/2006/msg00225.html -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 14 Mar 2006 08:27:51 +0000 Message-ID: <44167E50.9000006@alcatel.be> Date: Tue, 14 Mar 2006 09:26:56 +0100 From: stefaan.de_cnodder@alcatel.be User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20040910 MIME-Version: 1.0 To: "Nelson, David" Cc: "Nagi Reddy Jonnala (njonnala)" , j.schoenwaelder@iu-bremen.de, radiusext@ops.ietf.org, "Wijnen, Bert \(Bert\)" Subject: Re: radius dynauth client/server mibs structure Content-Type: multipart/mixed; boundary="------------040706070208020204040408" This is a multi-part message in MIME format. --------------040706070208020204040408 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed And here is the correct client MIB. Sorry for the duplicate server MIB. Thanks, Stefaan Nelson, David wrote: > Stefaan, > > It appears that the two revised draft version files you sent today were > both the server MIB. > > -- Dave > --------------040706070208020204040408 Content-Transfer-Encoding: 7bit Content-Type: text/plain; name="draft-ietf-radext-dynauth-client-mib-04.txt" Content-Disposition: inline; filename="draft-ietf-radext-dynauth-client-mib-04.txt" Network Working Group S. De Cnodder Internet-Draft Alcatel Expires: September 15, 2006 N. Jonnala M. Chiba Cisco Systems, Inc. March 14, 2006 Dynamic Authorization Client MIB draft-ietf-radext-dynauth-client-mib-04.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on September 15, 2006. Copyright Notice Copyright (C) The Internet Society (2006). Abstract This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes the Remote Authentication Dial In User Service (RADIUS) [RFC2865] Dynamic Authorization Client (DAC) functions that support the dynamic authorization extensions as defined in RFC 3576. De Cnodder, et al. Expires September 15, 2006 [Page 1] Internet-Draft Dynamic Authorization Client MIB March 2006 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Requirements notation . . . . . . . . . . . . . . . . . . 3 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 2. The Internet-Standard Management Framework . . . . . . . . . . 4 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. RADIUS Dynamic Authorization Client MIB Definitions . . . . . 6 5. Security Considerations . . . . . . . . . . . . . . . . . . . 21 6. IANA considerations . . . . . . . . . . . . . . . . . . . . . 23 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 24 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25 8.1. Normative References . . . . . . . . . . . . . . . . . . . 25 8.2. Informative References . . . . . . . . . . . . . . . . . . 25 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27 Intellectual Property and Copyright Statements . . . . . . . . . . 28 De Cnodder, et al. Expires September 15, 2006 [Page 2] Internet-Draft Dynamic Authorization Client MIB March 2006 1. Introduction This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. It is becoming increasingly important to support Dynamic Authorization extensions on the network access server (NAS) devices to handle the Disconnect and Change-of-Authorization (CoA) messages as described in [RFC3576]. As a result, the effective management of RADIUS Dynamic Authorization entities is of considerable importance. This RADIUS Dynamic Authorization Client MIB complements the managed objects used for managing RADIUS authentication and accounting servers as described in [RFC2619bis] and [RFC2621bis], respectively. -- RFC Ed.: references [DYNSERV], [RFC2619bis], [RFC2621bis] should -- be replaced by references to the corresponding RFC. 1.1. Requirements notation The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 1.2. Terminology Dynamic Authorization Server (DAS) The component that resides on the NAS which processes the Disconnect and Change-of-Authorization (CoA) Request packets [RFC3576] sent by the Dynamic Authorization Client. Dynamic Authorization Client (DAC) The component which sends Disconnect and CoA-Request packets to the Dynamic Authorization Server. While often residing on the RADIUS server, it is also possible for this component to be located on a separate host, such as a Rating Engine. Dynamic Authorization Server Port The UDP port on which the Dynamic Authorization Server listens for the Disconnect and CoA requests sent by the Dynamic Authorization Client. De Cnodder, et al. Expires September 15, 2006 [Page 3] Internet-Draft Dynamic Authorization Client MIB March 2006 2. The Internet-Standard Management Framework For a detailed overview of the documents that describe the current Internet-Standard Management Framework, please refer to section 7 of [RFC3410]. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. MIB objects are generally accessed through the Simple Network Management Protocol (SNMP). Objects in the MIB are defined using the mechanisms defined in the Structure of Management Information (SMI). This memo specifies a MIB module that is compliant to the SMIv2, which is described in STD 58, RFC2578 [RFC2578], STD 58, RFC2579 [RFC2579] and STD 58, RFC2580 [RFC2580]. De Cnodder, et al. Expires September 15, 2006 [Page 4] Internet-Draft Dynamic Authorization Client MIB March 2006 3. Overview "Dynamic Authorization Extensions to RADIUS" [RFC3576] defines the operation of Disconnect-Request, Disconnect-ACK, Disconnect-NAK, CoA- Request, CoA-ACK and CoA-NAK packets. [DYNSERV] defines the Dynamic Authorization Server MIB and the relationship with other MIB modules. This MIB module for the Dynamic Authorization Client contains the following: 1. Two scalar objects, and 2. One Dynamic Authorization Server table. This table contains one row for each DAS that the DAC shares a secret with. De Cnodder, et al. Expires September 15, 2006 [Page 5] Internet-Draft Dynamic Authorization Client MIB March 2006 4. RADIUS Dynamic Authorization Client MIB Definitions RADIUS-DYNAUTH-CLIENT-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, Counter32, Gauge32, Integer32, mib-2, TimeTicks FROM SNMPv2-SMI -- [RFC2578] SnmpAdminString FROM SNMP-FRAMEWORK-MIB -- [RFC3411] InetAddressType, InetAddress, InetPortNumber FROM INET-ADDRESS-MIB -- [RFC4001] MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF; -- [RFC2580] radiusDynAuthClientMIB MODULE-IDENTITY LAST-UPDATED "200603100000Z" -- 10 March 2006 ORGANIZATION "IETF RADEXT Working Group" CONTACT-INFO " Stefaan De Cnodder Alcatel Francis Wellesplein 1 B-2018 Antwerp Belgium Phone: +32 3 240 85 15 EMail: stefaan.de_cnodder@alcatel.be Nagi Reddy Jonnala Cisco Systems, Inc. Divyasree Chambers, B Wing, O'Shaugnessy Road, Bangalore-560027, India. Phone: +91 98456 99445 EMail: njonnala@cisco.com Murtaza Chiba Cisco Systems, Inc. 170 West Tasman Dr. San Jose CA, 95134 Phone: +1 408 525 7198 EMail: mchiba@cisco.com " DESCRIPTION "The MIB module for entities implementing the client side of the Dynamic Authorization Extensions to Remote Authentication Dial In User Service (RADIUS) protocol. De Cnodder, et al. Expires September 15, 2006 [Page 6] Internet-Draft Dynamic Authorization Client MIB March 2006 Copyright (C) The Internet Society (2006). Initial version as published in RFC yyyy; for full legal notices see the RFC itself." -- RFC Ed.: replace yyyy with actual RFC number & remove this note REVISION "200603100000Z" -- 10 March 2006 DESCRIPTION "Initial version as published in RFC yyyy" -- RFC Ed.: replace yyyy with actual RFC number & remove this note ::= { mib-2 xxx } -- The value xxx to be assigned by IANA. radiusDynAuthClientMIBObjects OBJECT IDENTIFIER ::= { radiusDynAuthClientMIB 1 } radiusDynAuthClientScalars OBJECT IDENTIFIER ::= { radiusDynAuthClientMIBObjects 1 } radiusDynAuthClientDisconInvalidServerAddresses OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of Disconnect-Ack and Disconnect-NAK packets received from unknown addresses. This counter wraps from the maximum value to zero and is reset upon system (re)initialization." ::= { radiusDynAuthClientScalars 1 } radiusDynAuthClientCoAInvalidServerAddresses OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of CoA-Ack and CoA-NAK packets received from unknown addresses. This counter wraps from the maximum value to zero and is reset upon system (re)initialization." ::= { radiusDynAuthClientScalars 2 } radiusDynAuthServerTable OBJECT-TYPE SYNTAX SEQUENCE OF RadiusDynAuthServerEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The (conceptual) table listing the RADIUS Dynamic Authorization Servers with which the client shares a secret." ::= { radiusDynAuthClientMIBObjects 2 } De Cnodder, et al. Expires September 15, 2006 [Page 7] Internet-Draft Dynamic Authorization Client MIB March 2006 radiusDynAuthServerEntry OBJECT-TYPE SYNTAX RadiusDynAuthServerEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry (conceptual row) representing one Dynamic Authorization Server with which the client shares a secret." INDEX { radiusDynAuthServerIndex } ::= { radiusDynAuthServerTable 1 } RadiusDynAuthServerEntry ::= SEQUENCE { radiusDynAuthServerIndex Integer32, radiusDynAuthServerAddressType InetAddressType, radiusDynAuthServerAddress InetAddress, radiusDynAuthServerClientPortNumber InetPortNumber, radiusDynAuthServerID SnmpAdminString, radiusDynAuthClientRoundTripTime TimeTicks, radiusDynAuthClientDisconRequests Counter32, radiusDynAuthClientDisconAuthOnlyRequests Counter32, radiusDynAuthClientDisconRetransmissions Counter32, radiusDynAuthClientDisconAcks Counter32, radiusDynAuthClientDisconNaks Counter32, radiusDynAuthClientDisconNakAuthOnlyRequest Counter32, radiusDynAuthClientDisconNakSessNoContext Counter32, radiusDynAuthClientMalformedDisconResponses Counter32, radiusDynAuthClientDisconBadAuthenticators Counter32, radiusDynAuthClientDisconPendingRequests Gauge32, radiusDynAuthClientDisconTimeouts Counter32, radiusDynAuthClientDisconPacketsDropped Counter32, radiusDynAuthClientCoARequests Counter32, radiusDynAuthClientCoAAuthOnlyRequest Counter32, radiusDynAuthClientCoARetransmissions Counter32, radiusDynAuthClientCoAAcks Counter32, radiusDynAuthClientCoANaks Counter32, radiusDynAuthClientCoANakAuthOnlyRequest Counter32, radiusDynAuthClientCoANakSessNoContext Counter32, radiusDynAuthClientMalformedCoAResponses Counter32, radiusDynAuthClientCoABadAuthenticators Counter32, radiusDynAuthClientCoAPendingRequests Gauge32, radiusDynAuthClientCoATimeouts Counter32, radiusDynAuthClientCoAPacketsDropped Counter32, radiusDynAuthClientUnknownTypes Counter32 } radiusDynAuthServerIndex OBJECT-TYPE SYNTAX Integer32 (1..2147483647) De Cnodder, et al. Expires September 15, 2006 [Page 8] Internet-Draft Dynamic Authorization Client MIB March 2006 MAX-ACCESS not-accessible STATUS current DESCRIPTION "A number uniquely identifying each RADIUS Dynamic Authorization Server with which this Dynamic Authorization Client communicates. This number is allocated by the agent implementing this MIB module, and is unique in this context." ::= { radiusDynAuthServerEntry 1 } radiusDynAuthServerAddressType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS read-only STATUS current DESCRIPTION "The type of IP address of the RADIUS Dynamic Authorization Server referred to in this table entry." ::= { radiusDynAuthServerEntry 2 } radiusDynAuthServerAddress OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS read-only STATUS current DESCRIPTION "The IP address value of the RADIUS Dynamic Authorization Server referred to in this table entry using the version neutral IP address format." ::= { radiusDynAuthServerEntry 3 } radiusDynAuthServerClientPortNumber OBJECT-TYPE SYNTAX InetPortNumber MAX-ACCESS read-only STATUS current DESCRIPTION "The UDP destination port that the RADIUS Dynamic Authorization Client is using to send requests to this server." ::= { radiusDynAuthServerEntry 4 } radiusDynAuthServerID OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-only STATUS current DESCRIPTION "The NAS-Identifier of the RADIUS Dynamic Authorization Server referred to in this table entry. This is not necessarily the same as sysName in MIB II." De Cnodder, et al. Expires September 15, 2006 [Page 9] Internet-Draft Dynamic Authorization Client MIB March 2006 REFERENCE "RFC 2865, Section 5.32, NAS-Identifier." ::= { radiusDynAuthServerEntry 5 } radiusDynAuthClientRoundTripTime OBJECT-TYPE SYNTAX TimeTicks UNITS "hundredths of a second" MAX-ACCESS read-only STATUS current DESCRIPTION "The time interval (in hundredths of a second) between the most recent Disconnect or CoA request and the reception of the corresponding Disconnect or CoA reply. A value of zero is returned in case no reply has been received yet from this server." ::= { radiusDynAuthServerEntry 6 } radiusDynAuthClientDisconRequests OBJECT-TYPE SYNTAX Counter32 UNITS "requests" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of RADIUS Disconnect-Requests sent to this Dynamic Authorization Server. This also includes the RADIUS Disconnect-Requests that have a Service-Type attribute with value 'Authorize Only'. This counter wraps from the maximum value to zero and is reset upon system (re)initialization." REFERENCE "RFC 3576, Section 2.1, Disconnect Messages (DM)." ::= { radiusDynAuthServerEntry 7 } radiusDynAuthClientDisconAuthOnlyRequests OBJECT-TYPE SYNTAX Counter32 UNITS "requests" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of RADIUS Disconnect-Requests that include a Service-Type attribute with value 'Authorize Only' sent to this Dynamic Authorization Server. This counter wraps from the maximum value to zero and is reset upon system (re)initialization." REFERENCE "RFC 3576, Section 2.1, Disconnect Messages (DM)." ::= { radiusDynAuthServerEntry 8 } De Cnodder, et al. Expires September 15, 2006 [Page 10] Internet-Draft Dynamic Authorization Client MIB March 2006 radiusDynAuthClientDisconRetransmissions OBJECT-TYPE SYNTAX Counter32 UNITS "retransmissions" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of RADIUS Disconnect-request packets retransmitted to this RADIUS Dynamic Authorization Server. This counter wraps from the maximum value to zero and is reset upon system (re)initialization." REFERENCE "RFC 3576, Section 2.1, Disconnect Messages (DM)." ::= { radiusDynAuthServerEntry 9 } radiusDynAuthClientDisconAcks OBJECT-TYPE SYNTAX Counter32 UNITS "replies" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of RADIUS Disconnect-ACK packets received from this Dynamic Authorization Server. This counter wraps from the maximum value to zero and is reset upon system (re)initialization." REFERENCE "RFC 3576, Section 2.1, Disconnect Messages (DM)." ::= { radiusDynAuthServerEntry 10 } radiusDynAuthClientDisconNaks OBJECT-TYPE SYNTAX Counter32 UNITS "replies" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of RADIUS Disconnect-NAK packets received from this Dynamic Authorization Server. This includes the RADIUS Disconnect-NAK packets received with a Service-Type attribute with value 'Authorize Only' and the RADIUS Disconnect-NAK packets received no session context was found. This counter wraps from the maximum value to zero and is reset upon system (re)initialization." REFERENCE "RFC 3576, Section 2.1, Disconnect Messages (DM)." ::= { radiusDynAuthServerEntry 11 } radiusDynAuthClientDisconNakAuthOnlyRequest OBJECT-TYPE SYNTAX Counter32 De Cnodder, et al. Expires September 15, 2006 [Page 11] Internet-Draft Dynamic Authorization Client MIB March 2006 UNITS "replies" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of RADIUS Disconnect-NAK packets that include a Service-Type attribute with value 'Authorize Only' received from this Dynamic Authorization Server. This counter wraps from the maximum value to zero and is reset upon system (re)initialization." REFERENCE "RFC 3576, Section 2.1, Disconnect Messages (DM)." ::= { radiusDynAuthServerEntry 12 } radiusDynAuthClientDisconNakSessNoContext OBJECT-TYPE SYNTAX Counter32 UNITS "replies" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of RADIUS Disconnect-NAK packets received from this Dynamic Authorization Server because no session context was found, i.e. it includes an Error-Cause attribute with value 503 ('Session Context Not Found'). This counter wraps from the maximum value to zero and is reset upon system (re)initialization." REFERENCE "RFC 3576, Section 2.1, Disconnect Messages (DM)." ::= { radiusDynAuthServerEntry 13 } radiusDynAuthClientMalformedDisconResponses OBJECT-TYPE SYNTAX Counter32 UNITS "replies" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of malformed RADIUS Disconnect-Ack and Disconnect-NAK packets received from this Dynamic Authorization Server. Bad authenticators and unknown types are not included as malformed Disconnect-Ack and Disconnect-NAK packets. This counter wraps from the maximum value to zero and is reset upon system (re)initialization." REFERENCE "RFC 3576, Section 2.1, Disconnect Messages (DM), and Section 2.3, Packet Format." ::= { radiusDynAuthServerEntry 14 } De Cnodder, et al. Expires September 15, 2006 [Page 12] Internet-Draft Dynamic Authorization Client MIB March 2006 radiusDynAuthClientDisconBadAuthenticators OBJECT-TYPE SYNTAX Counter32 UNITS "replies" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of RADIUS Disconnect-Ack and Disconnect-NAK packets which contained invalid Authenticator field received from this Dynamic Authorization Server. This counter wraps from the maximum value to zero and is reset upon system (re)initialization." REFERENCE "RFC 3576, Section 2.1, Disconnect Messages (DM), and Section 2.3, Packet Format." ::= { radiusDynAuthServerEntry 15 } radiusDynAuthClientDisconPendingRequests OBJECT-TYPE SYNTAX Gauge32 UNITS "requests" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of RADIUS Disconnect-request packets destined for this server that have not yet timed out or received a response. This variable is incremented when an Disconnect-Request is sent and decremented due to receipt of an Disconnect-Ack, Disconnect-NAK or a timeout or a retransmission." REFERENCE "RFC 3576, Section 2.1, Disconnect Messages (DM)." ::= { radiusDynAuthServerEntry 16 } radiusDynAuthClientDisconTimeouts OBJECT-TYPE SYNTAX Counter32 UNITS "timeouts" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of Disconnect request timeouts to this server. After a timeout the client may retry to the same server or give up. A retry to the same server is counted as a retransmit as well as a timeout. A send to a different server is counted as a Disconnect-Request as well as a timeout. This counter wraps from the maximum value to zero and is reset upon system (re)initialization." REFERENCE "RFC 3576, Section 2.1, Disconnect Messages (DM)." De Cnodder, et al. Expires September 15, 2006 [Page 13] Internet-Draft Dynamic Authorization Client MIB March 2006 ::= { radiusDynAuthServerEntry 17 } radiusDynAuthClientDisconPacketsDropped OBJECT-TYPE SYNTAX Counter32 UNITS "replies" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of incoming Disconnect-Ack and Disconnect-NAK packets from this Dynamic Authorization Server silently discarded by the client application for some reason other than malformed, bad authenticators or unknown types. This counter wraps from the maximum value to zero and is reset upon system (re)initialization." REFERENCE "RFC 3576, Section 2.1, Disconnect Messages (DM), and Section 2.3, Packet Format." ::= { radiusDynAuthServerEntry 18 } radiusDynAuthClientCoARequests OBJECT-TYPE SYNTAX Counter32 UNITS "requests" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of RADIUS CoA-Requests sent to this Dynamic Authorization Server. This also includes the CoA requests that have a Service-Type attribute with value 'Authorize Only'. This counter wraps from the maximum value to zero and is reset upon system (re)initialization." REFERENCE "RFC 3576, Section 2.2, Change-of-Authorization Messages (CoA)." ::= { radiusDynAuthServerEntry 19 } radiusDynAuthClientCoAAuthOnlyRequest OBJECT-TYPE SYNTAX Counter32 UNITS "requests" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of RADIUS CoA-requests that include a Service-Type attribute with value 'Authorize Only' sent to this Dynamic Authorization Client. This counter wraps from the maximum value to zero and is reset upon system (re)initialization." De Cnodder, et al. Expires September 15, 2006 [Page 14] Internet-Draft Dynamic Authorization Client MIB March 2006 REFERENCE "RFC 3576, Section 2.2, Change-of-Authorization Messages (CoA)." ::= { radiusDynAuthServerEntry 20 } radiusDynAuthClientCoARetransmissions OBJECT-TYPE SYNTAX Counter32 UNITS "retransmissions" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of RADIUS CoA-request packets retransmitted to this RADIUS Dynamic Authorization Server. This counter wraps from the maximum value to zero and is reset upon system (re)initialization." REFERENCE "RFC 3576, Section 2.2, Change-of-Authorization Messages (CoA)." ::= { radiusDynAuthServerEntry 21 } radiusDynAuthClientCoAAcks OBJECT-TYPE SYNTAX Counter32 UNITS "replies" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of RADIUS CoA-ACK packets received from this Dynamic Authorization Server. This counter wraps from the maximum value to zero and is reset upon system (re)initialization." REFERENCE "RFC 3576, Section 2.2, Change-of-Authorization Messages (CoA)." ::= { radiusDynAuthServerEntry 22 } radiusDynAuthClientCoANaks OBJECT-TYPE SYNTAX Counter32 UNITS "replies" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of RADIUS CoA-NAK packets received from this Dynamic Authorization Server. This includes the RADIUS CoA-NAK packets received with a Service-Type attribute with value 'Authorize Only' and the RADIUS CoA-NAK packets received because no session context was found. This counter wraps from the maximum value to zero and is reset upon system (re)initialization." De Cnodder, et al. Expires September 15, 2006 [Page 15] Internet-Draft Dynamic Authorization Client MIB March 2006 REFERENCE "RFC 3576, Section 2.2, Change-of-Authorization Messages (CoA)." ::= { radiusDynAuthServerEntry 23 } radiusDynAuthClientCoANakAuthOnlyRequest OBJECT-TYPE SYNTAX Counter32 UNITS "replies" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of RADIUS CoA-NAK packets that include a Service-Type attribute with value 'Authorize Only' received from this Dynamic Authorization Server. This counter wraps from the maximum value to zero and is reset upon system (re)initialization." REFERENCE "RFC 3576, Section 2.2, Change-of-Authorization Messages (CoA)." ::= { radiusDynAuthServerEntry 24 } radiusDynAuthClientCoANakSessNoContext OBJECT-TYPE SYNTAX Counter32 UNITS "replies" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of RADIUS CoA-NAK packets received from this Dynamic Authorization Server because no session context was found, i.e. it includes an Error-Cause attribute with value 503 ('Session Context Not Found'). This counter wraps from the maximum value to zero and is reset upon system (re)initialization." REFERENCE "RFC 3576, Section 2.2, Change-of-Authorization Messages (CoA)." ::= { radiusDynAuthServerEntry 25 } radiusDynAuthClientMalformedCoAResponses OBJECT-TYPE SYNTAX Counter32 UNITS "replies" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of malformed RADIUS CoA-Ack and CoA-NAK packets received from this Dynamic Authorization Server. Bad authenticators and unknown types are not included as malformed CoA-Ack and CoA-NAK packets. De Cnodder, et al. Expires September 15, 2006 [Page 16] Internet-Draft Dynamic Authorization Client MIB March 2006 This counter wraps from the maximum value to zero and is reset upon system (re)initialization." REFERENCE "RFC 3576, Section 2.2, Change-of-Authorization Messages (CoA), and Section 2.3, Packet Format." ::= { radiusDynAuthServerEntry 26 } radiusDynAuthClientCoABadAuthenticators OBJECT-TYPE SYNTAX Counter32 UNITS "replies" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of RADIUS CoA-Ack and CoA-NAK packets which contained invalid Authenticator field received from this Dynamic Authorization Server. This counter wraps from the maximum value to zero and is reset upon system (re)initialization." REFERENCE "RFC 3576, Section 2.2, Change-of-Authorization Messages (CoA), and Section 2.3, Packet Format." ::= { radiusDynAuthServerEntry 27 } radiusDynAuthClientCoAPendingRequests OBJECT-TYPE SYNTAX Gauge32 UNITS "requests" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of RADIUS CoA-request packets destined for this server that have not yet timed out or received a response. This variable is incremented when an CoA-Request is sent and decremented due to receipt of a CoA-Ack, CoA-NAK or a timeout or a retransmission. This counter wraps from the maximum value to zero and is reset upon system (re)initialization." REFERENCE "RFC 3576, Section 2.2, Change-of-Authorization Messages (CoA)." ::= { radiusDynAuthServerEntry 28 } radiusDynAuthClientCoATimeouts OBJECT-TYPE SYNTAX Counter32 UNITS "timeouts" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of CoA request timeouts to this server. De Cnodder, et al. Expires September 15, 2006 [Page 17] Internet-Draft Dynamic Authorization Client MIB March 2006 After a timeout the client may retry to the same server or give up. A retry to the same server is counted as a retransmit as well as a timeout. A send to a different server is counted as a CoA-Request as well as a timeout. This counter wraps from the maximum value to zero and is reset upon system (re)initialization." REFERENCE "RFC 3576, Section 2.2, Change-of-Authorization Messages (CoA)." ::= { radiusDynAuthServerEntry 29 } radiusDynAuthClientCoAPacketsDropped OBJECT-TYPE SYNTAX Counter32 UNITS "replies" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of incoming CoA-Ack and CoA-NAK from this Dynamic Authorization Server silently discarded by the client application for some reason other than malformed, bad authenticators or unknown types. This counter wraps from the maximum value to zero and is reset upon system (re)initialization." REFERENCE "RFC 3576, Section 2.2, Change-of-Authorization Messages (CoA), and Section 2.3, Packet Format." ::= { radiusDynAuthServerEntry 30 } radiusDynAuthClientUnknownTypes OBJECT-TYPE SYNTAX Counter32 UNITS "replies" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of incoming packets of unknown types which were received on the Dynamic Authorization port. This counter wraps from the maximum value to zero and is reset upon system (re)initialization." REFERENCE "RFC 3576, Section 2.3, Packet Format." ::= { radiusDynAuthServerEntry 31 } -- conformance information radiusDynAuthClientMIBConformance OBJECT IDENTIFIER ::= { radiusDynAuthClientMIB 2 } radiusDynAuthClientMIBCompliances OBJECT IDENTIFIER ::= { radiusDynAuthClientMIBConformance 1 } De Cnodder, et al. Expires September 15, 2006 [Page 18] Internet-Draft Dynamic Authorization Client MIB March 2006 radiusDynAuthClientMIBGroups OBJECT IDENTIFIER ::= { radiusDynAuthClientMIBConformance 2 } -- compliance statements radiusDynAuthClientMIBCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for entities implementing the RADIUS Dynamic Authorization Client." MODULE -- this module MANDATORY-GROUPS { radiusDynAuthClientMIBGroup } GROUP radiusDynAuthClientAuthOnlyGroup DESCRIPTION "Only required for Dynamic Authorization Clients that are supporting Service-Type attributes with value 'Authorize-Only'." GROUP radiusDynAuthClientNoSessGroup DESCRIPTION "This group is not required in case the Dynamic Authorization Server can not easily determine whether a session exists or not (e.g., in case of a RADIUS proxy)." ::= { radiusDynAuthClientMIBCompliances 1 } -- units of conformance radiusDynAuthClientMIBGroup OBJECT-GROUP OBJECTS { radiusDynAuthClientDisconInvalidServerAddresses, radiusDynAuthClientCoAInvalidServerAddresses, radiusDynAuthServerAddressType, radiusDynAuthServerAddress, radiusDynAuthServerClientPortNumber, radiusDynAuthServerID, radiusDynAuthClientRoundTripTime, radiusDynAuthClientDisconRequests, radiusDynAuthClientDisconRetransmissions, radiusDynAuthClientDisconAcks, radiusDynAuthClientDisconNaks, radiusDynAuthClientMalformedDisconResponses, radiusDynAuthClientDisconBadAuthenticators, radiusDynAuthClientDisconPendingRequests, radiusDynAuthClientDisconTimeouts, radiusDynAuthClientDisconPacketsDropped, De Cnodder, et al. Expires September 15, 2006 [Page 19] Internet-Draft Dynamic Authorization Client MIB March 2006 radiusDynAuthClientCoARequests, radiusDynAuthClientCoARetransmissions, radiusDynAuthClientCoAAcks, radiusDynAuthClientCoANaks, radiusDynAuthClientMalformedCoAResponses, radiusDynAuthClientCoABadAuthenticators, radiusDynAuthClientCoAPendingRequests, radiusDynAuthClientCoATimeouts, radiusDynAuthClientCoAPacketsDropped, radiusDynAuthClientUnknownTypes } STATUS current DESCRIPTION "The collection of objects providing management of a RADIUS Dynamic Authorization Client." ::= { radiusDynAuthClientMIBGroups 1 } radiusDynAuthClientAuthOnlyGroup OBJECT-GROUP OBJECTS { radiusDynAuthClientDisconAuthOnlyRequests, radiusDynAuthClientDisconNakAuthOnlyRequest, radiusDynAuthClientCoAAuthOnlyRequest, radiusDynAuthClientCoANakAuthOnlyRequest } STATUS current DESCRIPTION "The collection of objects supporting the RADIUS messages including Service-Type attribute with value 'Authorize Only'." ::= { radiusDynAuthClientMIBGroups 2 } radiusDynAuthClientNoSessGroup OBJECT-GROUP OBJECTS { radiusDynAuthClientDisconNakSessNoContext, radiusDynAuthClientCoANakSessNoContext } STATUS current DESCRIPTION "The collection of objects supporting the RADIUS messages that are referring to non existing sessions." ::= { radiusDynAuthClientMIBGroups 3 } END De Cnodder, et al. Expires September 15, 2006 [Page 20] Internet-Draft Dynamic Authorization Client MIB March 2006 5. Security Considerations There are no management objects defined in this MIB module that have a MAX-ACCESS clause of read-write and/or read-create. So, if this MIB module is implemented correctly, then there is no risk that an intruder can alter or create any management objects of this MIB module via direct SNMP SET operations Some of the readable objects in this MIB module (i.e., objects with a MAX-ACCESS other than not-accessible) may be considered sensitive or vulnerable in some network environments. It is thus important to control even GET and/or NOTIFY access to these objects and possibly to even encrypt the values of these objects when sending them over the network via SNMP. These are the tables and objects and their sensitivity/vulnerability: radiusDynAuthServerAddress and radiusDynAuthServerAddressType These can be used to determine the address of the DAS with which the DAC is communicating. This information could be useful in mounting an attack on the DAS. radiusDynAuthServerID This can be used to determine the Identifier of the DAS. This information could be useful in impersonating the DAS. radiusDynAuthServerClientPortNumber This can be used to determine the destination port number to which the DAC is sending. This information could be useful in mounting an attack on the DAS. SNMP versions prior to SNMPv3 did not include adequate security. Even if the network itself is secure (for example by using IPsec), even then, there is no control as to who on the secure network is allowed to access and GET/SET (read/change/create/delete) the objects in this MIB module. It is RECOMMENDED that implementers consider the security features as provided by the SNMPv3 framework (see [RFC3410], section 8), including full support for the SNMPv3 cryptographic mechanisms (for authentication and privacy). Further, deployment of SNMP versions prior to SNMPv3 is NOT RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to enable cryptographic security. It is then a customer/operator responsibility to ensure that the SNMP entity giving access to an De Cnodder, et al. Expires September 15, 2006 [Page 21] Internet-Draft Dynamic Authorization Client MIB March 2006 instance of this MIB module is properly configured to give access to the objects only to those principals (users) that have legitimate rights to indeed GET or SET (change/create/delete) them. De Cnodder, et al. Expires September 15, 2006 [Page 22] Internet-Draft Dynamic Authorization Client MIB March 2006 6. IANA considerations IANA is requested to assign an OID under mib-2. De Cnodder, et al. Expires September 15, 2006 [Page 23] Internet-Draft Dynamic Authorization Client MIB March 2006 7. Acknowledgements The authors would also like to acknowledge the following people for their comments on this document: Bernard Aboba, Alan DeKok, David Nelson, Anjaneyulu Pata, Dan Romascanu, Juergen Schoenwaelder, Greg Weber, Bert Wijnen, and Glen Zorn. De Cnodder, et al. Expires September 15, 2006 [Page 24] Internet-Draft Dynamic Authorization Client MIB March 2006 8. References 8.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997. [RFC2578] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M., and S. Waldbusser, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. [RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M., and S. Waldbusser, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999. [RFC2580] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M., and S. Waldbusser, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999. [RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, December 2002. [RFC3576] Chiba, M., Dommety, G., Eklund, M., Mitton, D., and B. Aboba, "Dynamic Authorization Extensions to Remote Authentication Dial In User Service (RADIUS)", RFC 3576, July 2003. [RFC4001] Daniele, M. and et al., "Textual Conventions for Internet Network Addresses", RFC 4001, February 2005. 8.2. Informative References [DYNSERV] De Cnodder, S., Jonnala, N., and M. Chiba, "RADIUS Dynamic Authorization Server MIB", draft-ietf-radext-dynauth-server-mib-03.txt, work in progress, December 2005. [RFC2619bis] Nelson, D., "RADIUS Auth Server MIB (IPv6)", draft-ietf-radext-rfc2619bis-01.txt work in progress, October 2005. [RFC2621bis] Nelson, D., "RADIUS Acct Server MIB (IPv6)", draft-ietf-radext-rfc2621bis-01.txt work in progress, De Cnodder, et al. Expires September 15, 2006 [Page 25] Internet-Draft Dynamic Authorization Client MIB March 2006 October 2005. [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000. [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction and Applicability Statements for Internet- Standard Management Framework", RFC 3410, December 2002. De Cnodder, et al. Expires September 15, 2006 [Page 26] Internet-Draft Dynamic Authorization Client MIB March 2006 Authors' Addresses Stefaan De Cnodder Alcatel Francis Wellesplein 1 B-2018 Antwerp Belgium Phone: +32 3 240 85 15 Email: stefaan.de_cnodder@alcatel.be Nagi Reddy Jonnala Cisco Systems, Inc. Divyasree Chambers, B Wing, O'Shaugnessy Road Bangalore-560027, India Phone: +91 98456 99445 Email: njonnala@cisco.com Murtaza Chiba Cisco Systems, Inc. 170 West Tasman Dr. San Jose CA, 95134 Phone: +1 408 525 7198 Email: mchiba@cisco.com De Cnodder, et al. Expires September 15, 2006 [Page 27] Internet-Draft Dynamic Authorization Client MIB March 2006 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. De Cnodder, et al. Expires September 15, 2006 [Page 28] --------------040706070208020204040408-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Mon, 13 Mar 2006 22:10:13 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: RE: radius dynauth client/server mibs structure Date: Mon, 13 Mar 2006 17:09:48 -0500 Message-ID: <3CFB564E055A594B82C4FE89D2156560219125@MABOSEVS2.ets.enterasys.com> Thread-Topic: radius dynauth client/server mibs structure Thread-Index: AcZG4eDp3u2AoYloQGKTfS5+9ujeyAACLxXA From: "Nelson, David" To: Cc: "Nagi Reddy Jonnala \(njonnala\)" , , , "Wijnen, Bert \(Bert\)" Stefaan, It appears that the two revised draft version files you sent today were both the server MIB. -- Dave -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Mon, 13 Mar 2006 21:06:05 +0000 Message-ID: <4415DE91.8080909@alcatel.be> Date: Mon, 13 Mar 2006 22:05:21 +0100 From: stefaan.de_cnodder@alcatel.be User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20040910 MIME-Version: 1.0 To: "Nelson, David" , "Wijnen, Bert \(Bert\)" Cc: "Nagi Reddy Jonnala (njonnala)" , j.schoenwaelder@iu-bremen.de, radiusext@ops.ietf.org Subject: Re: radius dynauth client/server mibs structure Content-Type: multipart/mixed; boundary="------------060703020402050606000906" This is a multi-part message in MIME format. --------------060703020402050606000906 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed Hi Bert, Dave, The updated versions are attached. Changes are: - change 2005 into 2006 in DESCRIPTION of MIB - group the scalars according the comment of Juergen - add sentence "This counter wraps from the maximum value to zero and is reset upon system (re)initialization." for all counters of type Counter32 - remove ref to IANA copyright. - some minor formatting (line breaks in the mib) I tried a diff but that output is rather messy, so I sent you the complete drafts. Thanks, Stefaan Nelson, David wrote: > Bert writes... > > >>I am happy to chekc a pre-release rev 04 as well. > > >>>Stefaan DeCnodder writes... >>> >>>Since the suggestion has sufficient support it is best to >>>do so. Is it Ok to sent a version -04 of both docs after the >>>IETF containing all updates? > > > I think Bert would like to get this document revision submitted ASAP. > The IETF I-D Tracker tool has these documents in the "Revised I-D > Required" state. > > Bert will be stepping down as O&M Area Director after IETF-65, so if > these documents are still awaiting IESG approval after next week, then > they will need to be handed off to another AD for shepherding. > > -- Dave > > > -- > to unsubscribe send a message to radiusext-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: --------------060703020402050606000906 Content-Transfer-Encoding: 7bit Content-Type: text/plain; name="draft-ietf-radext-dynauth-client-mib-04.txt" Content-Disposition: inline; filename="draft-ietf-radext-dynauth-client-mib-04.txt" Network Working Group S. De Cnodder Internet-Draft Alcatel Expires: September 14, 2006 N. Jonnala M. Chiba Cisco Systems, Inc. March 13, 2006 Dynamic Authorization Server MIB draft-ietf-radext-dynauth-server-mib-04.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on September 14, 2006. Copyright Notice Copyright (C) The Internet Society (2006). Abstract This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes the Remote Authentication Dial In User Service (RADIUS) [RFC2865] Dynamic Authorization Server (DAS) functions that support the dynamic authorization extensions as defined in RFC 3576. De Cnodder, et al. Expires September 14, 2006 [Page 1] Internet-Draft Dynamic Authorization Server MIB March 2006 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Requirements notation . . . . . . . . . . . . . . . . . . 3 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 2. The Internet-Standard Management Framework . . . . . . . . . . 4 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. RADIUS Dynamic Authorization Server MIB Definitions . . . . . 7 5. Security Considerations . . . . . . . . . . . . . . . . . . . 21 6. IANA considerations . . . . . . . . . . . . . . . . . . . . . 22 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 23 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24 8.1. Normative References . . . . . . . . . . . . . . . . . . . 24 8.2. Informative References . . . . . . . . . . . . . . . . . . 24 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26 Intellectual Property and Copyright Statements . . . . . . . . . . 27 De Cnodder, et al. Expires September 14, 2006 [Page 2] Internet-Draft Dynamic Authorization Server MIB March 2006 1. Introduction This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. It is becoming increasingly important to support Dynamic Authorization extensions on the network access server (NAS) devices to handle the Disconnect and Change-of-Authorization (CoA) messages as described in [RFC3576]. As a result, the effective management of RADIUS Dynamic Authorization entities is of considerable importance. This RADIUS Dynamic Authorization Server (DAS) MIB complements the managed objects used for managing RADIUS authentication and accounting clients as described in [RFC2618bis] and [RFC2620bis], respectively. -- RFC Ed.: references [DYNSERV], [RFC2618bis], [RFC2619bis], -- [RFC2620bis], and [RFC2621bis] should be replaced by -- references to the corresponding RFC. 1.1. Requirements notation The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 1.2. Terminology Dynamic Authorization Server (DAS) The component that resides on the NAS which processes the Disconnect and Change-of-Authorization (CoA) Request packets [RFC3576] sent by the Dynamic Authorization Client. Dynamic Authorization Client (DAC) The component which sends Disconnect and CoA-Request packets to the Dynamic Authorization Server. While often residing on the RADIUS server, it is also possible for this component to be located on a separate host, such as a Rating Engine. Dynamic Authorization Server Port The UDP port on which the Dynamic Authorization Server listens for the Disconnect and CoA requests sent by the Dynamic Authorization Client. De Cnodder, et al. Expires September 14, 2006 [Page 3] Internet-Draft Dynamic Authorization Server MIB March 2006 2. The Internet-Standard Management Framework For a detailed overview of the documents that describe the current Internet-Standard Management Framework, please refer to section 7 of [RFC3410]. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. MIB objects are generally accessed through the Simple Network Management Protocol (SNMP). Objects in the MIB are defined using the mechanisms defined in the Structure of Management Information (SMI). This memo specifies a MIB module that is compliant to the SMIv2, which is described in STD 58, RFC2578 [RFC2578], STD 58, RFC2579 [RFC2579] and STD 58, RFC2580 [RFC2580]. De Cnodder, et al. Expires September 14, 2006 [Page 4] Internet-Draft Dynamic Authorization Server MIB March 2006 3. Overview "Dynamic Authorization Extensions to RADIUS" [RFC3576] defines the operation of Disconnect-Request, Disconnect-ACK, Disconnect-NAK, CoA- Request, CoA-ACK and CoA-NAK packets. Typically NAS devices implement the DAS function, and thus would be expected to implement the RADIUS Dynamic Authorization Server MIB, while DACs implement the client function, and thus would be expected to implement the RADIUS Dynamic Authorization Client MIB. However, it is possible for a RADIUS Dynamic Authorization entity to perform both client and server functions. For example, a RADIUS proxy may act as a DAS to one or more DACs, while simultaneously acting as a DAC to one or more DASs. In such situations, it is expected that RADIUS entities combining client and server functionality will support both the client and server MIBs. This memo describes the MIB for Dynamic Authorization Servers and relates to the following documents as follows: [RFC2618bis] describes the MIB for a RADIUS Auth Client MIB. [RFC2619bis] describes the MIB for a RADIUS Auth Server MIB. [RFC2620bis] describes the MIB for a RADIUS Acct Client MIB. [RFC2621bis] describes the MIB for a RADIUS Acct Server MIB. [DYNCLNT] describes the MIB for a RADIUS Dynamic Authorization Client. A NAS typically implements the MIBs for a RADIUS Authentication Client, a RADIUS accounting client, and a RADIUS Dynamic Authorization Server. However, any one MIB can be implemented without implementing any of the other MIBs, i.e. the MIBs have no dependencies on each other. A typical case would be for a device to implement the MIBs RADIUS authentication server, RADIUS accounting server and RADIUS Dynamic Authorization Client. A RADIUS proxy might implement any, all or a subset of the MIBs listed above and the MIB as defined in this document. De Cnodder, et al. Expires September 14, 2006 [Page 5] Internet-Draft Dynamic Authorization Server MIB March 2006 +---------------+ +---------------+ User 1----| | Disconnect-Request | | | Dynamic | CoA-Request | Dynamic | User 2----| Authorization |<---------------------| Authorization | | Server |--------------------->| Client | User 3----| (DAS) | Disconnect-Ack | (DAC) | | | Disconnect-NAK | | +---------------+ CoA-Ack/CoA-NAK +---------------+ Figure 1: Mapping of clients and servers. This MIB module for the Dynamic Authorization Server contains the following: 1. Three scalar objects, and 2. One Dynamic Authorization Client Table. This table contains one row for each DAC with which the DAS shares a secret. De Cnodder, et al. Expires September 14, 2006 [Page 6] Internet-Draft Dynamic Authorization Server MIB March 2006 4. RADIUS Dynamic Authorization Server MIB Definitions RADIUS-DYNAUTH-SERVER-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, Counter32, Integer32, mib-2 FROM SNMPv2-SMI -- [RFC2578] SnmpAdminString FROM SNMP-FRAMEWORK-MIB -- [RFC3411] InetAddressType, InetAddress FROM INET-ADDRESS-MIB -- [RFC4001] MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF; -- [RFC2580] radiusDynAuthServerMIB MODULE-IDENTITY LAST-UPDATED "200603100000Z" -- 10 March 2006 ORGANIZATION "IETF RADEXT Working Group" CONTACT-INFO " Stefaan De Cnodder Alcatel Francis Wellesplein 1 B-2018 Antwerp Belgium Phone: +32 3 240 85 15 EMail: stefaan.de_cnodder@alcatel.be Nagi Reddy Jonnala Cisco Systems, Inc. Divyasree Chambers, B Wing, O'Shaugnessy Road, Bangalore-560027, India. Phone: +91 98456 99445 EMail: njonnala@cisco.com Murtaza Chiba Cisco Systems, Inc. 170 West Tasman Dr. San Jose CA, 95134 Phone: +1 408 525 7198 EMail: mchiba@cisco.com " DESCRIPTION "The MIB module for entities implementing the server side of the Dynamic Authorization Extensions to Remote Authentication Dial In User Service (RADIUS) protocol. Copyright (C) The Internet Society (2006). Initial De Cnodder, et al. Expires September 14, 2006 [Page 7] Internet-Draft Dynamic Authorization Server MIB March 2006 version as published in RFC yyyy; for full legal notices see the RFC its" -- RFC Ed.: replace yyyy with actual RFC number & remove this note REVISION "200603100000Z" -- 10 March 2006 DESCRIPTION "Initial version as published in RFC yyyy." -- RFC Ed.: replace yyyy with actual RFC number & remove this note ::= { mib-2 xxx } -- The value xxx to be assigned by IANA. radiusDynAuthServerMIBObjects OBJECT IDENTIFIER ::= { radiusDynAuthServerMIB 1 } radiusDynAuthServerScalars OBJECT IDENTIFIER ::= { radiusDynAuthServerMIBObjects 1 } radiusDynAuthServerDisconInvalidClientAddresses OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of Disconnect-Request packets received from unknown addresses. This counter wraps from the maximum value to zero and is reset upon system (re)initialization." ::= { radiusDynAuthServerScalars 1 } radiusDynAuthServerCoAInvalidClientAddresses OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of CoA-Request packets received from unknown addresses. This counter wraps from the maximum value to zero and is reset upon system (re)initialization." ::= { radiusDynAuthServerScalars 2 } radiusDynAuthServerIdentifier OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-only STATUS current DESCRIPTION "The NAS-Identifier of the RADIUS Dynamic Authorization Server. This is not necessarily the same as sysName in MIB II." REFERENCE "RFC 2865, Section 5.32, NAS-Identifier." ::= { radiusDynAuthServerScalars 3 } De Cnodder, et al. Expires September 14, 2006 [Page 8] Internet-Draft Dynamic Authorization Server MIB March 2006 radiusDynAuthClientTable OBJECT-TYPE SYNTAX SEQUENCE OF RadiusDynAuthClientEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The (conceptual) table listing the RADIUS Dynamic Authorization Clients with which the server shares a secret." ::= { radiusDynAuthServerMIBObjects 2 } radiusDynAuthClientEntry OBJECT-TYPE SYNTAX RadiusDynAuthClientEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry (conceptual row) representing one Dynamic Authorization Client with which the server shares a secret." INDEX { radiusDynAuthClientIndex } ::= { radiusDynAuthClientTable 1 } RadiusDynAuthClientEntry ::= SEQUENCE { radiusDynAuthClientIndex Integer32, radiusDynAuthClientAddressType InetAddressType, radiusDynAuthClientAddress InetAddress, radiusDynAuthServDisconRequests Counter32, radiusDynAuthServDisconAuthOnlyRequests Counter32, radiusDynAuthServDupDisconRequests Counter32, radiusDynAuthServDisconAcks Counter32, radiusDynAuthServDisconNaks Counter32, radiusDynAuthServDisconNakAuthOnlyRequests Counter32, radiusDynAuthServDisconNakSessNoContext Counter32, radiusDynAuthServDisconUserSessRemoved Counter32, radiusDynAuthServMalformedDisconRequests Counter32, radiusDynAuthServDisconBadAuthenticators Counter32, radiusDynAuthServDisconPacketsDropped Counter32, radiusDynAuthServCoARequests Counter32, radiusDynAuthServCoAAuthOnlyRequests Counter32, radiusDynAuthServDupCoARequests Counter32, radiusDynAuthServCoAAcks Counter32, radiusDynAuthServCoANaks Counter32, radiusDynAuthServCoANakAuthOnlyRequests Counter32, radiusDynAuthServCoANakSessNoContext Counter32, radiusDynAuthServCoAUserSessChanged Counter32, radiusDynAuthServMalformedCoARequests Counter32, radiusDynAuthServCoABadAuthenticators Counter32, radiusDynAuthServCoAPacketsDropped Counter32, radiusDynAuthServUnknownTypes Counter32 De Cnodder, et al. Expires September 14, 2006 [Page 9] Internet-Draft Dynamic Authorization Server MIB March 2006 } radiusDynAuthClientIndex OBJECT-TYPE SYNTAX Integer32 (1..2147483647) MAX-ACCESS not-accessible STATUS current DESCRIPTION "A number uniquely identifying each RADIUS Dynamic Authorization Client with which this Dynamic Authorization Server communicates. This number is allocated by the agent implementing this MIB module, and is unique in this context." ::= { radiusDynAuthClientEntry 1 } radiusDynAuthClientAddressType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS read-only STATUS current DESCRIPTION "The type of IP address of the RADIUS Dynamic Authorization Client referred to in this table entry." ::= { radiusDynAuthClientEntry 2 } radiusDynAuthClientAddress OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS read-only STATUS current DESCRIPTION "The IP address value of the RADIUS Dynamic Authorization Client referred to in this table entry, using the version neutral IP address format." ::= { radiusDynAuthClientEntry 3 } radiusDynAuthServDisconRequests OBJECT-TYPE SYNTAX Counter32 UNITS "requests" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of RADIUS Disconnect-Requests received from this Dynamic Authorization Client. This also includes the RADIUS Disconnect-Requests that have a Service-Type attribute with value 'Authorize Only'. This counter wraps from the maximum value to zero and is reset upon system (re)initialization." REFERENCE "RFC 3576, Section 2.1, Disconnect Messages (DM)." De Cnodder, et al. Expires September 14, 2006 [Page 10] Internet-Draft Dynamic Authorization Server MIB March 2006 ::= { radiusDynAuthClientEntry 4 } radiusDynAuthServDisconAuthOnlyRequests OBJECT-TYPE SYNTAX Counter32 UNITS "requests" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of RADIUS Disconnect-Requests that include a Service-Type attribute with value 'Authorize Only' received from this Dynamic Authorization Client. This counter wraps from the maximum value to zero and is reset upon system (re)initialization." REFERENCE "RFC 3576, Section 2.1, Disconnect Messages (DM)." ::= { radiusDynAuthClientEntry 5 } radiusDynAuthServDupDisconRequests OBJECT-TYPE SYNTAX Counter32 UNITS "requests" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of duplicate RADIUS Disconnect-Request packets received from this Dynamic Authorization Client. This counter wraps from the maximum value to zero and is reset upon system (re)initialization." REFERENCE "RFC 3576, Section 2.1, Disconnect Messages (DM)." ::= { radiusDynAuthClientEntry 6 } radiusDynAuthServDisconAcks OBJECT-TYPE SYNTAX Counter32 UNITS "replies" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of RADIUS Disconnect-ACK packets sent to this Dynamic Authorization Client. This counter wraps from the maximum value to zero and is reset upon system (re)initialization." REFERENCE "RFC 3576, Section 2.1, Disconnect Messages (DM)." ::= { radiusDynAuthClientEntry 7 } radiusDynAuthServDisconNaks OBJECT-TYPE SYNTAX Counter32 UNITS "replies" De Cnodder, et al. Expires September 14, 2006 [Page 11] Internet-Draft Dynamic Authorization Server MIB March 2006 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of RADIUS Disconnect-NAK packets sent to this Dynamic Authorization Client. This includes the RADIUS Disconnect-NAK packets sent with a Service-Type attribute with value 'Authorize Only' and the RADIUS Disconnect-NAK packets sent because no session context was found. This counter wraps from the maximum value to zero and is reset upon system (re)initialization." REFERENCE "RFC 3576, Section 2.1, Disconnect Messages (DM)." ::= { radiusDynAuthClientEntry 8 } radiusDynAuthServDisconNakAuthOnlyRequests OBJECT-TYPE SYNTAX Counter32 UNITS "replies" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of RADIUS Disconnect-NAK packets that include a Service-Type attribute with value 'Authorize Only' sent to this Dynamic Authorization Client. This counter wraps from the maximum value to zero and is reset upon system (re)initialization." REFERENCE "RFC 3576, Section 2.1, Disconnect Messages (DM)." ::= { radiusDynAuthClientEntry 9 } radiusDynAuthServDisconNakSessNoContext OBJECT-TYPE SYNTAX Counter32 UNITS "replies" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of RADIUS Disconnect-NAK packets sent to this Dynamic Authorization Client because no session context was found. This counter wraps from the maximum value to zero and is reset upon system (re)initialization." REFERENCE "RFC 3576, Section 2.1, Disconnect Messages (DM)." ::= { radiusDynAuthClientEntry 10 } radiusDynAuthServDisconUserSessRemoved OBJECT-TYPE SYNTAX Counter32 UNITS "sessions" De Cnodder, et al. Expires September 14, 2006 [Page 12] Internet-Draft Dynamic Authorization Server MIB March 2006 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of user sessions removed for the Disconnect-Requests received from this Dynamic Authorization Client. Depending on site specific policies, a single Disconnect request can remove multiple user sessions. In the case that this Dynamic Authorization Server has no knowledge of the number of user sessions that are affected by a single request, for each such Disconnect-Request, it will count as a single affected user session only. This counter wraps from the maximum value to zero and is reset upon system (re)initialization." REFERENCE "RFC 3576, Section 2.1, Disconnect Messages (DM)." ::= { radiusDynAuthClientEntry 11 } radiusDynAuthServMalformedDisconRequests OBJECT-TYPE SYNTAX Counter32 UNITS "requests" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of malformed RADIUS Disconnect-Request packets received from this Dynamic Authorization Client. Bad authenticators and unknown types are not included as malformed Disconnect-Requests. This counter wraps from the maximum value to zero and is reset upon system (re)initialization." REFERENCE "RFC 3576, Section 2.1, Disconnect Messages (DM), and Section 2.3, Packet Format." ::= { radiusDynAuthClientEntry 12 } radiusDynAuthServDisconBadAuthenticators OBJECT-TYPE SYNTAX Counter32 UNITS "requests" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of RADIUS Disconnect-Request packets which contained invalid Authenticator field received from this Dynamic Authorization Client. This counter wraps from the maximum value to zero and is reset upon system (re)initialization." REFERENCE De Cnodder, et al. Expires September 14, 2006 [Page 13] Internet-Draft Dynamic Authorization Server MIB March 2006 "RFC 3576, Section 2.1, Disconnect Messages (DM), and Section 2.3, Packet Format." ::= { radiusDynAuthClientEntry 13 } radiusDynAuthServDisconPacketsDropped OBJECT-TYPE SYNTAX Counter32 UNITS "requests" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of incoming Disconnect-Requests from this Dynamic Authorization Client silently discarded by the server application for some reason other than malformed, bad authenticators or unknown types. This counter wraps from the maximum value to zero and is reset upon system (re)initialization." REFERENCE "RFC 3576, Section 2.1, Disconnect Messages (DM), and Section 2.3, Packet Format." ::= { radiusDynAuthClientEntry 14 } radiusDynAuthServCoARequests OBJECT-TYPE SYNTAX Counter32 UNITS "requests" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of RADIUS CoA-requests received from this Dynamic Authorization Client. This also includes the CoA requests that have a Service-Type attribute with value 'Authorize Only'. This counter wraps from the maximum value to zero and is reset upon system (re)initialization." REFERENCE "RFC 3576, Section 2.2, Change-of-Authorization Messages (CoA)." ::= { radiusDynAuthClientEntry 15 } radiusDynAuthServCoAAuthOnlyRequests OBJECT-TYPE SYNTAX Counter32 UNITS "requests" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of RADIUS CoA-requests that include a Service-Type attribute with value 'Authorize Only' received from this Dynamic Authorization Client. This counter wraps from the maximum value to zero and is De Cnodder, et al. Expires September 14, 2006 [Page 14] Internet-Draft Dynamic Authorization Server MIB March 2006 reset upon system (re)initialization." REFERENCE "RFC 3576, Section 2.2, Change-of-Authorization Messages (CoA)." ::= { radiusDynAuthClientEntry 16 } radiusDynAuthServDupCoARequests OBJECT-TYPE SYNTAX Counter32 UNITS "requests" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of duplicate RADIUS CoA-Request packets received from this Dynamic Authorization Client. This counter wraps from the maximum value to zero and is reset upon system (re)initialization." REFERENCE "RFC 3576, Section 2.2, Change-of-Authorization Messages (CoA)." ::= { radiusDynAuthClientEntry 17 } radiusDynAuthServCoAAcks OBJECT-TYPE SYNTAX Counter32 UNITS "replies" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of RADIUS CoA-ACK packets sent to this Dynamic Authorization Client. This counter wraps from the maximum value to zero and is reset upon system (re)initialization." REFERENCE "RFC 3576, Section 2.2, Change-of-Authorization Messages (CoA)." ::= { radiusDynAuthClientEntry 18 } radiusDynAuthServCoANaks OBJECT-TYPE SYNTAX Counter32 UNITS "replies" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of RADIUS CoA-NAK packets sent to this Dynamic Authorization Client. This includes the RADIUS CoA-NAK packets sent with a Service-Type attribute with value 'Authorize Only' and the RADIUS CoA-NAK packets sent because no session context was De Cnodder, et al. Expires September 14, 2006 [Page 15] Internet-Draft Dynamic Authorization Server MIB March 2006 found. This counter wraps from the maximum value to zero and is reset upon system (re)initialization." REFERENCE "RFC 3576, Section 2.2, Change-of-Authorization Messages (CoA)." ::= { radiusDynAuthClientEntry 19 } radiusDynAuthServCoANakAuthOnlyRequests OBJECT-TYPE SYNTAX Counter32 UNITS "replies" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of RADIUS CoA-NAK packets that include a Service-Type attribute with value 'Authorize Only' sent to this Dynamic Authorization Client. This counter wraps from the maximum value to zero and is reset upon system (re)initialization." REFERENCE "RFC 3576, Section 2.2, Change-of-Authorization Messages (CoA)." ::= { radiusDynAuthClientEntry 20 } radiusDynAuthServCoANakSessNoContext OBJECT-TYPE SYNTAX Counter32 UNITS "replies" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of RADIUS CoA-NAK packets sent to this Dynamic Authorization Client because no session context was found. This counter wraps from the maximum value to zero and is reset upon system (re)initialization." REFERENCE "RFC 3576, Section 2.2, Change-of-Authorization Messages (CoA)." ::= { radiusDynAuthClientEntry 21 } radiusDynAuthServCoAUserSessChanged OBJECT-TYPE SYNTAX Counter32 UNITS "sessions" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of user sessions authorization changed for the CoA-Requests received from this Dynamic Authorization Client. Depending on site specific policies, a single CoA request can change De Cnodder, et al. Expires September 14, 2006 [Page 16] Internet-Draft Dynamic Authorization Server MIB March 2006 multiple user sessions' authorization. In the case this Dynamic Authorization Server has no knowledge of the number of user sessions that are affected by a single request, for each such CoA-Request, it will count as a single affected user session only. This counter wraps from the maximum value to zero and is reset upon system (re)initialization." REFERENCE "RFC 3576, Section 2.2, Change-of-Authorization Messages (CoA)." ::= { radiusDynAuthClientEntry 22 } radiusDynAuthServMalformedCoARequests OBJECT-TYPE SYNTAX Counter32 UNITS "requests" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of malformed RADIUS CoA-Request packets received from this Dynamic Authorization Client. Bad authenticators and unknown types are not included as malformed CoA-Requests. This counter wraps from the maximum value to zero and is reset upon system (re)initialization." REFERENCE "RFC 3576, Section 2.2, Change-of-Authorization Messages (CoA), and Section 2.3, Packet Format." ::= { radiusDynAuthClientEntry 23 } radiusDynAuthServCoABadAuthenticators OBJECT-TYPE SYNTAX Counter32 UNITS "requests" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of RADIUS CoA-Request packets which contained invalid Authenticator field received from this Dynamic Authorization Client. This counter wraps from the maximum value to zero and is reset upon system (re)initialization." REFERENCE "RFC 3576, Section 2.2, Change-of-Authorization Messages (CoA), and Section 2.3, Packet Format." ::= { radiusDynAuthClientEntry 24 } radiusDynAuthServCoAPacketsDropped OBJECT-TYPE SYNTAX Counter32 UNITS "requests" De Cnodder, et al. Expires September 14, 2006 [Page 17] Internet-Draft Dynamic Authorization Server MIB March 2006 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of incoming CoA packets from this Dynamic Authorization Client silently discarded by the server application for some reason other than malformed, bad authenticators or unknown types. This counter wraps from the maximum value to zero and is reset upon system (re)initialization." REFERENCE "RFC 3576, Section 2.2, Change-of-Authorization Messages (CoA), and Section 2.3, Packet Format." ::= { radiusDynAuthClientEntry 25 } radiusDynAuthServUnknownTypes OBJECT-TYPE SYNTAX Counter32 UNITS "requests" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of incoming packets of unknown types which were received on the Dynamic Authorization port. This counter wraps from the maximum value to zero and is reset upon system (re)initialization." REFERENCE "RFC 3576, Section 2.3, Packet Format." ::= { radiusDynAuthClientEntry 26 } -- conformance information radiusDynAuthServerMIBConformance OBJECT IDENTIFIER ::= { radiusDynAuthServerMIB 2 } radiusDynAuthServerMIBCompliances OBJECT IDENTIFIER ::= { radiusDynAuthServerMIBConformance 1 } radiusDynAuthServerMIBGroups OBJECT IDENTIFIER ::= { radiusDynAuthServerMIBConformance 2 } -- compliance statements radiusAuthServerMIBCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for entities implementing the RADIUS Dynamic Authorization Server." MODULE -- this module MANDATORY-GROUPS { radiusDynAuthServerMIBGroup } GROUP radiusDynAuthServerAuthOnlyGroup De Cnodder, et al. Expires September 14, 2006 [Page 18] Internet-Draft Dynamic Authorization Server MIB March 2006 DESCRIPTION "Only required for Dynamic Authorization Clients that are supporting Service-Type attributes with value 'Authorize-Only'." GROUP radiusDynAuthServerNoSessGroup DESCRIPTION "This group is not required in case the Dynamic Authorization Server can not easily determine whether a session exists or not (e.g., in case of a RADIUS proxy)." ::= { radiusDynAuthServerMIBCompliances 1 } -- units of conformance radiusDynAuthServerMIBGroup OBJECT-GROUP OBJECTS { radiusDynAuthServerDisconInvalidClientAddresses, radiusDynAuthServerCoAInvalidClientAddresses, radiusDynAuthServerIdentifier, radiusDynAuthClientAddressType, radiusDynAuthClientAddress, radiusDynAuthServDisconRequests, radiusDynAuthServDupDisconRequests, radiusDynAuthServDisconAcks, radiusDynAuthServDisconNaks, radiusDynAuthServDisconUserSessRemoved, radiusDynAuthServMalformedDisconRequests, radiusDynAuthServDisconBadAuthenticators, radiusDynAuthServDisconPacketsDropped, radiusDynAuthServCoARequests, radiusDynAuthServDupCoARequests, radiusDynAuthServCoAAcks, radiusDynAuthServCoANaks, radiusDynAuthServCoAUserSessChanged, radiusDynAuthServMalformedCoARequests, radiusDynAuthServCoABadAuthenticators, radiusDynAuthServCoAPacketsDropped, radiusDynAuthServUnknownTypes } STATUS current DESCRIPTION "The collection of objects providing management of a RADIUS Dynamic Authorization Server." ::= { radiusDynAuthServerMIBGroups 1 } radiusDynAuthServerAuthOnlyGroup OBJECT-GROUP De Cnodder, et al. Expires September 14, 2006 [Page 19] Internet-Draft Dynamic Authorization Server MIB March 2006 OBJECTS { radiusDynAuthServDisconAuthOnlyRequests, radiusDynAuthServDisconNakAuthOnlyRequests, radiusDynAuthServCoAAuthOnlyRequests, radiusDynAuthServCoANakAuthOnlyRequests } STATUS current DESCRIPTION "The collection of objects supporting the RADIUS messages including Service-Type attribute with value 'Authorize Only'." ::= { radiusDynAuthServerMIBGroups 2 } radiusDynAuthServerNoSessGroup OBJECT-GROUP OBJECTS { radiusDynAuthServDisconNakSessNoContext, radiusDynAuthServCoANakSessNoContext } STATUS current DESCRIPTION "The collection of objects supporting the RADIUS messages that are referring to non existing sessions." ::= { radiusDynAuthServerMIBGroups 3 } END De Cnodder, et al. Expires September 14, 2006 [Page 20] Internet-Draft Dynamic Authorization Server MIB March 2006 5. Security Considerations There are no management objects defined in this MIB module that have a MAX-ACCESS clause of read-write and/or read-create. So, if this MIB module is implemented correctly, then there is no risk that an intruder can alter or create any management objects of this MIB module via direct SNMP SET operations Some of the readable objects in this MIB module (i.e., objects with a MAX-ACCESS other than not-accessible) may be considered sensitive or vulnerable in some network environments. It is thus important to control even GET and/or NOTIFY access to these objects and possibly to even encrypt the values of these objects when sending them over the network via SNMP. These are the tables and objects and their sensitivity/vulnerability: radiusDynAuthClientAddress and radiusDynAuthClientAddressType These can be used to determine the address of the DAC with which the DAS is communicating. This information could be useful in mounting an attack on the DAC. radiusDynAuthServerIdentifier This can be used to determine the Identifier of the DAS. This information could be useful in impersonating the DAS. SNMP versions prior to SNMPv3 did not include adequate security. Even if the network itself is secure (for example by using IPsec), even then, there is no control as to who on the secure network is allowed to access and GET/SET (read/change/create/delete) the objects in this MIB module. It is RECOMMENDED that implementers consider the security features as provided by the SNMPv3 framework (see [RFC3410], section 8), including full support for the SNMPv3 cryptographic mechanisms (for authentication and privacy). Further, deployment of SNMP versions prior to SNMPv3 is NOT RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to enable cryptographic security. It is then a customer/operator responsibility to ensure that the SNMP entity giving access to an instance of this MIB module is properly configured to give access to the objects only to those principals (users) that have legitimate rights to indeed GET or SET (change/create/delete) them. De Cnodder, et al. Expires September 14, 2006 [Page 21] Internet-Draft Dynamic Authorization Server MIB March 2006 6. IANA considerations IANA is requested to assign an OID xxx under mib-2. De Cnodder, et al. Expires September 14, 2006 [Page 22] Internet-Draft Dynamic Authorization Server MIB March 2006 7. Acknowledgements The authors would also like to acknowledge the following people for their comments on this document: Bernard Aboba, Alan DeKok, David Nelson, Anjaneyulu Pata, Dan Romascanu, Juergen Schoenwaelder, Greg Weber, Bert Wijnen, and Glen Zorn. De Cnodder, et al. Expires September 14, 2006 [Page 23] Internet-Draft Dynamic Authorization Server MIB March 2006 8. References 8.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997. [RFC2578] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M., and S. Waldbusser, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. [RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M., and S. Waldbusser, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999. [RFC2580] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M., and S. Waldbusser, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999. [RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, December 2002. [RFC3576] Chiba, M., Dommety, G., Eklund, M., Mitton, D., and B. Aboba, "Dynamic Authorization Extensions to Remote Authentication Dial In User Service (RADIUS)", RFC 3576, July 2003. [RFC4001] Daniele, M. and et al., "Textual Conventions for Internet Network Addresses", RFC 4001, February 2005. 8.2. Informative References [DYNCLNT] De Cnodder, S., Jonnala, N., and M. Chiba, "RADIUS Dynamic Authorization Client MIB", draft-ietf-radext-dynauth-client-mib-03.txt, work in progress, December 2005. [RFC2618bis] Nelson, D., "RADIUS Auth Client MIB (IPv6)", draft-ietf-radext-rfc2618bis-01.txt work in progress, October 2005. [RFC2619bis] Nelson, D., "RADIUS Auth Server MIB (IPv6)", draft-ietf-radext-rfc2619bis-01.txt work in progress, De Cnodder, et al. Expires September 14, 2006 [Page 24] Internet-Draft Dynamic Authorization Server MIB March 2006 October 2005. [RFC2620bis] Nelson, D., "RADIUS Acct Client MIB (IPv6)", draft-ietf-radext-rfc2620bis-01.txt work in progress, October 2005. [RFC2621bis] Nelson, D., "RADIUS Acct Server MIB (IPv6)", draft-ietf-radext-rfc2621bis-01.txt work in progress, October 2005. [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000. [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction and Applicability Statements for Internet- Standard Management Framework", RFC 3410, December 2002. De Cnodder, et al. Expires September 14, 2006 [Page 25] Internet-Draft Dynamic Authorization Server MIB March 2006 Authors' Addresses Stefaan De Cnodder Alcatel Francis Wellesplein 1 B-2018 Antwerp Belgium Phone: +32 3 240 85 15 Email: stefaan.de_cnodder@alcatel.be Nagi Reddy Jonnala Cisco Systems, Inc. Divyasree Chambers, B Wing, O'Shaugnessy Road Bangalore-560027, India Phone: +91 98456 99445 Email: njonnala@cisco.com Murtaza Chiba Cisco Systems, Inc. 170 West Tasman Dr. San Jose CA, 95134 Phone: +1 408 525 7198 Email: mchiba@cisco.com De Cnodder, et al. Expires September 14, 2006 [Page 26] Internet-Draft Dynamic Authorization Server MIB March 2006 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. De Cnodder, et al. Expires September 14, 2006 [Page 27] --------------060703020402050606000906 Content-Transfer-Encoding: 7bit Content-Type: text/plain; name="draft-ietf-radext-dynauth-server-mib-04.txt" Content-Disposition: inline; filename="draft-ietf-radext-dynauth-server-mib-04.txt" Network Working Group S. De Cnodder Internet-Draft Alcatel Expires: September 14, 2006 N. Jonnala M. Chiba Cisco Systems, Inc. March 13, 2006 Dynamic Authorization Server MIB draft-ietf-radext-dynauth-server-mib-04.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on September 14, 2006. Copyright Notice Copyright (C) The Internet Society (2006). Abstract This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes the Remote Authentication Dial In User Service (RADIUS) [RFC2865] Dynamic Authorization Server (DAS) functions that support the dynamic authorization extensions as defined in RFC 3576. De Cnodder, et al. Expires September 14, 2006 [Page 1] Internet-Draft Dynamic Authorization Server MIB March 2006 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Requirements notation . . . . . . . . . . . . . . . . . . 3 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 2. The Internet-Standard Management Framework . . . . . . . . . . 4 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. RADIUS Dynamic Authorization Server MIB Definitions . . . . . 7 5. Security Considerations . . . . . . . . . . . . . . . . . . . 21 6. IANA considerations . . . . . . . . . . . . . . . . . . . . . 22 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 23 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24 8.1. Normative References . . . . . . . . . . . . . . . . . . . 24 8.2. Informative References . . . . . . . . . . . . . . . . . . 24 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26 Intellectual Property and Copyright Statements . . . . . . . . . . 27 De Cnodder, et al. Expires September 14, 2006 [Page 2] Internet-Draft Dynamic Authorization Server MIB March 2006 1. Introduction This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. It is becoming increasingly important to support Dynamic Authorization extensions on the network access server (NAS) devices to handle the Disconnect and Change-of-Authorization (CoA) messages as described in [RFC3576]. As a result, the effective management of RADIUS Dynamic Authorization entities is of considerable importance. This RADIUS Dynamic Authorization Server (DAS) MIB complements the managed objects used for managing RADIUS authentication and accounting clients as described in [RFC2618bis] and [RFC2620bis], respectively. -- RFC Ed.: references [DYNSERV], [RFC2618bis], [RFC2619bis], -- [RFC2620bis], and [RFC2621bis] should be replaced by -- references to the corresponding RFC. 1.1. Requirements notation The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 1.2. Terminology Dynamic Authorization Server (DAS) The component that resides on the NAS which processes the Disconnect and Change-of-Authorization (CoA) Request packets [RFC3576] sent by the Dynamic Authorization Client. Dynamic Authorization Client (DAC) The component which sends Disconnect and CoA-Request packets to the Dynamic Authorization Server. While often residing on the RADIUS server, it is also possible for this component to be located on a separate host, such as a Rating Engine. Dynamic Authorization Server Port The UDP port on which the Dynamic Authorization Server listens for the Disconnect and CoA requests sent by the Dynamic Authorization Client. De Cnodder, et al. Expires September 14, 2006 [Page 3] Internet-Draft Dynamic Authorization Server MIB March 2006 2. The Internet-Standard Management Framework For a detailed overview of the documents that describe the current Internet-Standard Management Framework, please refer to section 7 of [RFC3410]. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. MIB objects are generally accessed through the Simple Network Management Protocol (SNMP). Objects in the MIB are defined using the mechanisms defined in the Structure of Management Information (SMI). This memo specifies a MIB module that is compliant to the SMIv2, which is described in STD 58, RFC2578 [RFC2578], STD 58, RFC2579 [RFC2579] and STD 58, RFC2580 [RFC2580]. De Cnodder, et al. Expires September 14, 2006 [Page 4] Internet-Draft Dynamic Authorization Server MIB March 2006 3. Overview "Dynamic Authorization Extensions to RADIUS" [RFC3576] defines the operation of Disconnect-Request, Disconnect-ACK, Disconnect-NAK, CoA- Request, CoA-ACK and CoA-NAK packets. Typically NAS devices implement the DAS function, and thus would be expected to implement the RADIUS Dynamic Authorization Server MIB, while DACs implement the client function, and thus would be expected to implement the RADIUS Dynamic Authorization Client MIB. However, it is possible for a RADIUS Dynamic Authorization entity to perform both client and server functions. For example, a RADIUS proxy may act as a DAS to one or more DACs, while simultaneously acting as a DAC to one or more DASs. In such situations, it is expected that RADIUS entities combining client and server functionality will support both the client and server MIBs. This memo describes the MIB for Dynamic Authorization Servers and relates to the following documents as follows: [RFC2618bis] describes the MIB for a RADIUS Auth Client MIB. [RFC2619bis] describes the MIB for a RADIUS Auth Server MIB. [RFC2620bis] describes the MIB for a RADIUS Acct Client MIB. [RFC2621bis] describes the MIB for a RADIUS Acct Server MIB. [DYNCLNT] describes the MIB for a RADIUS Dynamic Authorization Client. A NAS typically implements the MIBs for a RADIUS Authentication Client, a RADIUS accounting client, and a RADIUS Dynamic Authorization Server. However, any one MIB can be implemented without implementing any of the other MIBs, i.e. the MIBs have no dependencies on each other. A typical case would be for a device to implement the MIBs RADIUS authentication server, RADIUS accounting server and RADIUS Dynamic Authorization Client. A RADIUS proxy might implement any, all or a subset of the MIBs listed above and the MIB as defined in this document. De Cnodder, et al. Expires September 14, 2006 [Page 5] Internet-Draft Dynamic Authorization Server MIB March 2006 +---------------+ +---------------+ User 1----| | Disconnect-Request | | | Dynamic | CoA-Request | Dynamic | User 2----| Authorization |<---------------------| Authorization | | Server |--------------------->| Client | User 3----| (DAS) | Disconnect-Ack | (DAC) | | | Disconnect-NAK | | +---------------+ CoA-Ack/CoA-NAK +---------------+ Figure 1: Mapping of clients and servers. This MIB module for the Dynamic Authorization Server contains the following: 1. Three scalar objects, and 2. One Dynamic Authorization Client Table. This table contains one row for each DAC with which the DAS shares a secret. De Cnodder, et al. Expires September 14, 2006 [Page 6] Internet-Draft Dynamic Authorization Server MIB March 2006 4. RADIUS Dynamic Authorization Server MIB Definitions RADIUS-DYNAUTH-SERVER-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, Counter32, Integer32, mib-2 FROM SNMPv2-SMI -- [RFC2578] SnmpAdminString FROM SNMP-FRAMEWORK-MIB -- [RFC3411] InetAddressType, InetAddress FROM INET-ADDRESS-MIB -- [RFC4001] MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF; -- [RFC2580] radiusDynAuthServerMIB MODULE-IDENTITY LAST-UPDATED "200603100000Z" -- 10 March 2006 ORGANIZATION "IETF RADEXT Working Group" CONTACT-INFO " Stefaan De Cnodder Alcatel Francis Wellesplein 1 B-2018 Antwerp Belgium Phone: +32 3 240 85 15 EMail: stefaan.de_cnodder@alcatel.be Nagi Reddy Jonnala Cisco Systems, Inc. Divyasree Chambers, B Wing, O'Shaugnessy Road, Bangalore-560027, India. Phone: +91 98456 99445 EMail: njonnala@cisco.com Murtaza Chiba Cisco Systems, Inc. 170 West Tasman Dr. San Jose CA, 95134 Phone: +1 408 525 7198 EMail: mchiba@cisco.com " DESCRIPTION "The MIB module for entities implementing the server side of the Dynamic Authorization Extensions to Remote Authentication Dial In User Service (RADIUS) protocol. Copyright (C) The Internet Society (2006). Initial De Cnodder, et al. Expires September 14, 2006 [Page 7] Internet-Draft Dynamic Authorization Server MIB March 2006 version as published in RFC yyyy; for full legal notices see the RFC its" -- RFC Ed.: replace yyyy with actual RFC number & remove this note REVISION "200603100000Z" -- 10 March 2006 DESCRIPTION "Initial version as published in RFC yyyy." -- RFC Ed.: replace yyyy with actual RFC number & remove this note ::= { mib-2 xxx } -- The value xxx to be assigned by IANA. radiusDynAuthServerMIBObjects OBJECT IDENTIFIER ::= { radiusDynAuthServerMIB 1 } radiusDynAuthServerScalars OBJECT IDENTIFIER ::= { radiusDynAuthServerMIBObjects 1 } radiusDynAuthServerDisconInvalidClientAddresses OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of Disconnect-Request packets received from unknown addresses. This counter wraps from the maximum value to zero and is reset upon system (re)initialization." ::= { radiusDynAuthServerScalars 1 } radiusDynAuthServerCoAInvalidClientAddresses OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of CoA-Request packets received from unknown addresses. This counter wraps from the maximum value to zero and is reset upon system (re)initialization." ::= { radiusDynAuthServerScalars 2 } radiusDynAuthServerIdentifier OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-only STATUS current DESCRIPTION "The NAS-Identifier of the RADIUS Dynamic Authorization Server. This is not necessarily the same as sysName in MIB II." REFERENCE "RFC 2865, Section 5.32, NAS-Identifier." ::= { radiusDynAuthServerScalars 3 } De Cnodder, et al. Expires September 14, 2006 [Page 8] Internet-Draft Dynamic Authorization Server MIB March 2006 radiusDynAuthClientTable OBJECT-TYPE SYNTAX SEQUENCE OF RadiusDynAuthClientEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The (conceptual) table listing the RADIUS Dynamic Authorization Clients with which the server shares a secret." ::= { radiusDynAuthServerMIBObjects 2 } radiusDynAuthClientEntry OBJECT-TYPE SYNTAX RadiusDynAuthClientEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry (conceptual row) representing one Dynamic Authorization Client with which the server shares a secret." INDEX { radiusDynAuthClientIndex } ::= { radiusDynAuthClientTable 1 } RadiusDynAuthClientEntry ::= SEQUENCE { radiusDynAuthClientIndex Integer32, radiusDynAuthClientAddressType InetAddressType, radiusDynAuthClientAddress InetAddress, radiusDynAuthServDisconRequests Counter32, radiusDynAuthServDisconAuthOnlyRequests Counter32, radiusDynAuthServDupDisconRequests Counter32, radiusDynAuthServDisconAcks Counter32, radiusDynAuthServDisconNaks Counter32, radiusDynAuthServDisconNakAuthOnlyRequests Counter32, radiusDynAuthServDisconNakSessNoContext Counter32, radiusDynAuthServDisconUserSessRemoved Counter32, radiusDynAuthServMalformedDisconRequests Counter32, radiusDynAuthServDisconBadAuthenticators Counter32, radiusDynAuthServDisconPacketsDropped Counter32, radiusDynAuthServCoARequests Counter32, radiusDynAuthServCoAAuthOnlyRequests Counter32, radiusDynAuthServDupCoARequests Counter32, radiusDynAuthServCoAAcks Counter32, radiusDynAuthServCoANaks Counter32, radiusDynAuthServCoANakAuthOnlyRequests Counter32, radiusDynAuthServCoANakSessNoContext Counter32, radiusDynAuthServCoAUserSessChanged Counter32, radiusDynAuthServMalformedCoARequests Counter32, radiusDynAuthServCoABadAuthenticators Counter32, radiusDynAuthServCoAPacketsDropped Counter32, radiusDynAuthServUnknownTypes Counter32 De Cnodder, et al. Expires September 14, 2006 [Page 9] Internet-Draft Dynamic Authorization Server MIB March 2006 } radiusDynAuthClientIndex OBJECT-TYPE SYNTAX Integer32 (1..2147483647) MAX-ACCESS not-accessible STATUS current DESCRIPTION "A number uniquely identifying each RADIUS Dynamic Authorization Client with which this Dynamic Authorization Server communicates. This number is allocated by the agent implementing this MIB module, and is unique in this context." ::= { radiusDynAuthClientEntry 1 } radiusDynAuthClientAddressType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS read-only STATUS current DESCRIPTION "The type of IP address of the RADIUS Dynamic Authorization Client referred to in this table entry." ::= { radiusDynAuthClientEntry 2 } radiusDynAuthClientAddress OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS read-only STATUS current DESCRIPTION "The IP address value of the RADIUS Dynamic Authorization Client referred to in this table entry, using the version neutral IP address format." ::= { radiusDynAuthClientEntry 3 } radiusDynAuthServDisconRequests OBJECT-TYPE SYNTAX Counter32 UNITS "requests" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of RADIUS Disconnect-Requests received from this Dynamic Authorization Client. This also includes the RADIUS Disconnect-Requests that have a Service-Type attribute with value 'Authorize Only'. This counter wraps from the maximum value to zero and is reset upon system (re)initialization." REFERENCE "RFC 3576, Section 2.1, Disconnect Messages (DM)." De Cnodder, et al. Expires September 14, 2006 [Page 10] Internet-Draft Dynamic Authorization Server MIB March 2006 ::= { radiusDynAuthClientEntry 4 } radiusDynAuthServDisconAuthOnlyRequests OBJECT-TYPE SYNTAX Counter32 UNITS "requests" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of RADIUS Disconnect-Requests that include a Service-Type attribute with value 'Authorize Only' received from this Dynamic Authorization Client. This counter wraps from the maximum value to zero and is reset upon system (re)initialization." REFERENCE "RFC 3576, Section 2.1, Disconnect Messages (DM)." ::= { radiusDynAuthClientEntry 5 } radiusDynAuthServDupDisconRequests OBJECT-TYPE SYNTAX Counter32 UNITS "requests" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of duplicate RADIUS Disconnect-Request packets received from this Dynamic Authorization Client. This counter wraps from the maximum value to zero and is reset upon system (re)initialization." REFERENCE "RFC 3576, Section 2.1, Disconnect Messages (DM)." ::= { radiusDynAuthClientEntry 6 } radiusDynAuthServDisconAcks OBJECT-TYPE SYNTAX Counter32 UNITS "replies" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of RADIUS Disconnect-ACK packets sent to this Dynamic Authorization Client. This counter wraps from the maximum value to zero and is reset upon system (re)initialization." REFERENCE "RFC 3576, Section 2.1, Disconnect Messages (DM)." ::= { radiusDynAuthClientEntry 7 } radiusDynAuthServDisconNaks OBJECT-TYPE SYNTAX Counter32 UNITS "replies" De Cnodder, et al. Expires September 14, 2006 [Page 11] Internet-Draft Dynamic Authorization Server MIB March 2006 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of RADIUS Disconnect-NAK packets sent to this Dynamic Authorization Client. This includes the RADIUS Disconnect-NAK packets sent with a Service-Type attribute with value 'Authorize Only' and the RADIUS Disconnect-NAK packets sent because no session context was found. This counter wraps from the maximum value to zero and is reset upon system (re)initialization." REFERENCE "RFC 3576, Section 2.1, Disconnect Messages (DM)." ::= { radiusDynAuthClientEntry 8 } radiusDynAuthServDisconNakAuthOnlyRequests OBJECT-TYPE SYNTAX Counter32 UNITS "replies" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of RADIUS Disconnect-NAK packets that include a Service-Type attribute with value 'Authorize Only' sent to this Dynamic Authorization Client. This counter wraps from the maximum value to zero and is reset upon system (re)initialization." REFERENCE "RFC 3576, Section 2.1, Disconnect Messages (DM)." ::= { radiusDynAuthClientEntry 9 } radiusDynAuthServDisconNakSessNoContext OBJECT-TYPE SYNTAX Counter32 UNITS "replies" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of RADIUS Disconnect-NAK packets sent to this Dynamic Authorization Client because no session context was found. This counter wraps from the maximum value to zero and is reset upon system (re)initialization." REFERENCE "RFC 3576, Section 2.1, Disconnect Messages (DM)." ::= { radiusDynAuthClientEntry 10 } radiusDynAuthServDisconUserSessRemoved OBJECT-TYPE SYNTAX Counter32 UNITS "sessions" De Cnodder, et al. Expires September 14, 2006 [Page 12] Internet-Draft Dynamic Authorization Server MIB March 2006 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of user sessions removed for the Disconnect-Requests received from this Dynamic Authorization Client. Depending on site specific policies, a single Disconnect request can remove multiple user sessions. In the case that this Dynamic Authorization Server has no knowledge of the number of user sessions that are affected by a single request, for each such Disconnect-Request, it will count as a single affected user session only. This counter wraps from the maximum value to zero and is reset upon system (re)initialization." REFERENCE "RFC 3576, Section 2.1, Disconnect Messages (DM)." ::= { radiusDynAuthClientEntry 11 } radiusDynAuthServMalformedDisconRequests OBJECT-TYPE SYNTAX Counter32 UNITS "requests" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of malformed RADIUS Disconnect-Request packets received from this Dynamic Authorization Client. Bad authenticators and unknown types are not included as malformed Disconnect-Requests. This counter wraps from the maximum value to zero and is reset upon system (re)initialization." REFERENCE "RFC 3576, Section 2.1, Disconnect Messages (DM), and Section 2.3, Packet Format." ::= { radiusDynAuthClientEntry 12 } radiusDynAuthServDisconBadAuthenticators OBJECT-TYPE SYNTAX Counter32 UNITS "requests" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of RADIUS Disconnect-Request packets which contained invalid Authenticator field received from this Dynamic Authorization Client. This counter wraps from the maximum value to zero and is reset upon system (re)initialization." REFERENCE De Cnodder, et al. Expires September 14, 2006 [Page 13] Internet-Draft Dynamic Authorization Server MIB March 2006 "RFC 3576, Section 2.1, Disconnect Messages (DM), and Section 2.3, Packet Format." ::= { radiusDynAuthClientEntry 13 } radiusDynAuthServDisconPacketsDropped OBJECT-TYPE SYNTAX Counter32 UNITS "requests" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of incoming Disconnect-Requests from this Dynamic Authorization Client silently discarded by the server application for some reason other than malformed, bad authenticators or unknown types. This counter wraps from the maximum value to zero and is reset upon system (re)initialization." REFERENCE "RFC 3576, Section 2.1, Disconnect Messages (DM), and Section 2.3, Packet Format." ::= { radiusDynAuthClientEntry 14 } radiusDynAuthServCoARequests OBJECT-TYPE SYNTAX Counter32 UNITS "requests" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of RADIUS CoA-requests received from this Dynamic Authorization Client. This also includes the CoA requests that have a Service-Type attribute with value 'Authorize Only'. This counter wraps from the maximum value to zero and is reset upon system (re)initialization." REFERENCE "RFC 3576, Section 2.2, Change-of-Authorization Messages (CoA)." ::= { radiusDynAuthClientEntry 15 } radiusDynAuthServCoAAuthOnlyRequests OBJECT-TYPE SYNTAX Counter32 UNITS "requests" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of RADIUS CoA-requests that include a Service-Type attribute with value 'Authorize Only' received from this Dynamic Authorization Client. This counter wraps from the maximum value to zero and is De Cnodder, et al. Expires September 14, 2006 [Page 14] Internet-Draft Dynamic Authorization Server MIB March 2006 reset upon system (re)initialization." REFERENCE "RFC 3576, Section 2.2, Change-of-Authorization Messages (CoA)." ::= { radiusDynAuthClientEntry 16 } radiusDynAuthServDupCoARequests OBJECT-TYPE SYNTAX Counter32 UNITS "requests" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of duplicate RADIUS CoA-Request packets received from this Dynamic Authorization Client. This counter wraps from the maximum value to zero and is reset upon system (re)initialization." REFERENCE "RFC 3576, Section 2.2, Change-of-Authorization Messages (CoA)." ::= { radiusDynAuthClientEntry 17 } radiusDynAuthServCoAAcks OBJECT-TYPE SYNTAX Counter32 UNITS "replies" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of RADIUS CoA-ACK packets sent to this Dynamic Authorization Client. This counter wraps from the maximum value to zero and is reset upon system (re)initialization." REFERENCE "RFC 3576, Section 2.2, Change-of-Authorization Messages (CoA)." ::= { radiusDynAuthClientEntry 18 } radiusDynAuthServCoANaks OBJECT-TYPE SYNTAX Counter32 UNITS "replies" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of RADIUS CoA-NAK packets sent to this Dynamic Authorization Client. This includes the RADIUS CoA-NAK packets sent with a Service-Type attribute with value 'Authorize Only' and the RADIUS CoA-NAK packets sent because no session context was De Cnodder, et al. Expires September 14, 2006 [Page 15] Internet-Draft Dynamic Authorization Server MIB March 2006 found. This counter wraps from the maximum value to zero and is reset upon system (re)initialization." REFERENCE "RFC 3576, Section 2.2, Change-of-Authorization Messages (CoA)." ::= { radiusDynAuthClientEntry 19 } radiusDynAuthServCoANakAuthOnlyRequests OBJECT-TYPE SYNTAX Counter32 UNITS "replies" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of RADIUS CoA-NAK packets that include a Service-Type attribute with value 'Authorize Only' sent to this Dynamic Authorization Client. This counter wraps from the maximum value to zero and is reset upon system (re)initialization." REFERENCE "RFC 3576, Section 2.2, Change-of-Authorization Messages (CoA)." ::= { radiusDynAuthClientEntry 20 } radiusDynAuthServCoANakSessNoContext OBJECT-TYPE SYNTAX Counter32 UNITS "replies" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of RADIUS CoA-NAK packets sent to this Dynamic Authorization Client because no session context was found. This counter wraps from the maximum value to zero and is reset upon system (re)initialization." REFERENCE "RFC 3576, Section 2.2, Change-of-Authorization Messages (CoA)." ::= { radiusDynAuthClientEntry 21 } radiusDynAuthServCoAUserSessChanged OBJECT-TYPE SYNTAX Counter32 UNITS "sessions" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of user sessions authorization changed for the CoA-Requests received from this Dynamic Authorization Client. Depending on site specific policies, a single CoA request can change De Cnodder, et al. Expires September 14, 2006 [Page 16] Internet-Draft Dynamic Authorization Server MIB March 2006 multiple user sessions' authorization. In the case this Dynamic Authorization Server has no knowledge of the number of user sessions that are affected by a single request, for each such CoA-Request, it will count as a single affected user session only. This counter wraps from the maximum value to zero and is reset upon system (re)initialization." REFERENCE "RFC 3576, Section 2.2, Change-of-Authorization Messages (CoA)." ::= { radiusDynAuthClientEntry 22 } radiusDynAuthServMalformedCoARequests OBJECT-TYPE SYNTAX Counter32 UNITS "requests" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of malformed RADIUS CoA-Request packets received from this Dynamic Authorization Client. Bad authenticators and unknown types are not included as malformed CoA-Requests. This counter wraps from the maximum value to zero and is reset upon system (re)initialization." REFERENCE "RFC 3576, Section 2.2, Change-of-Authorization Messages (CoA), and Section 2.3, Packet Format." ::= { radiusDynAuthClientEntry 23 } radiusDynAuthServCoABadAuthenticators OBJECT-TYPE SYNTAX Counter32 UNITS "requests" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of RADIUS CoA-Request packets which contained invalid Authenticator field received from this Dynamic Authorization Client. This counter wraps from the maximum value to zero and is reset upon system (re)initialization." REFERENCE "RFC 3576, Section 2.2, Change-of-Authorization Messages (CoA), and Section 2.3, Packet Format." ::= { radiusDynAuthClientEntry 24 } radiusDynAuthServCoAPacketsDropped OBJECT-TYPE SYNTAX Counter32 UNITS "requests" De Cnodder, et al. Expires September 14, 2006 [Page 17] Internet-Draft Dynamic Authorization Server MIB March 2006 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of incoming CoA packets from this Dynamic Authorization Client silently discarded by the server application for some reason other than malformed, bad authenticators or unknown types. This counter wraps from the maximum value to zero and is reset upon system (re)initialization." REFERENCE "RFC 3576, Section 2.2, Change-of-Authorization Messages (CoA), and Section 2.3, Packet Format." ::= { radiusDynAuthClientEntry 25 } radiusDynAuthServUnknownTypes OBJECT-TYPE SYNTAX Counter32 UNITS "requests" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of incoming packets of unknown types which were received on the Dynamic Authorization port. This counter wraps from the maximum value to zero and is reset upon system (re)initialization." REFERENCE "RFC 3576, Section 2.3, Packet Format." ::= { radiusDynAuthClientEntry 26 } -- conformance information radiusDynAuthServerMIBConformance OBJECT IDENTIFIER ::= { radiusDynAuthServerMIB 2 } radiusDynAuthServerMIBCompliances OBJECT IDENTIFIER ::= { radiusDynAuthServerMIBConformance 1 } radiusDynAuthServerMIBGroups OBJECT IDENTIFIER ::= { radiusDynAuthServerMIBConformance 2 } -- compliance statements radiusAuthServerMIBCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for entities implementing the RADIUS Dynamic Authorization Server." MODULE -- this module MANDATORY-GROUPS { radiusDynAuthServerMIBGroup } GROUP radiusDynAuthServerAuthOnlyGroup De Cnodder, et al. Expires September 14, 2006 [Page 18] Internet-Draft Dynamic Authorization Server MIB March 2006 DESCRIPTION "Only required for Dynamic Authorization Clients that are supporting Service-Type attributes with value 'Authorize-Only'." GROUP radiusDynAuthServerNoSessGroup DESCRIPTION "This group is not required in case the Dynamic Authorization Server can not easily determine whether a session exists or not (e.g., in case of a RADIUS proxy)." ::= { radiusDynAuthServerMIBCompliances 1 } -- units of conformance radiusDynAuthServerMIBGroup OBJECT-GROUP OBJECTS { radiusDynAuthServerDisconInvalidClientAddresses, radiusDynAuthServerCoAInvalidClientAddresses, radiusDynAuthServerIdentifier, radiusDynAuthClientAddressType, radiusDynAuthClientAddress, radiusDynAuthServDisconRequests, radiusDynAuthServDupDisconRequests, radiusDynAuthServDisconAcks, radiusDynAuthServDisconNaks, radiusDynAuthServDisconUserSessRemoved, radiusDynAuthServMalformedDisconRequests, radiusDynAuthServDisconBadAuthenticators, radiusDynAuthServDisconPacketsDropped, radiusDynAuthServCoARequests, radiusDynAuthServDupCoARequests, radiusDynAuthServCoAAcks, radiusDynAuthServCoANaks, radiusDynAuthServCoAUserSessChanged, radiusDynAuthServMalformedCoARequests, radiusDynAuthServCoABadAuthenticators, radiusDynAuthServCoAPacketsDropped, radiusDynAuthServUnknownTypes } STATUS current DESCRIPTION "The collection of objects providing management of a RADIUS Dynamic Authorization Server." ::= { radiusDynAuthServerMIBGroups 1 } radiusDynAuthServerAuthOnlyGroup OBJECT-GROUP De Cnodder, et al. Expires September 14, 2006 [Page 19] Internet-Draft Dynamic Authorization Server MIB March 2006 OBJECTS { radiusDynAuthServDisconAuthOnlyRequests, radiusDynAuthServDisconNakAuthOnlyRequests, radiusDynAuthServCoAAuthOnlyRequests, radiusDynAuthServCoANakAuthOnlyRequests } STATUS current DESCRIPTION "The collection of objects supporting the RADIUS messages including Service-Type attribute with value 'Authorize Only'." ::= { radiusDynAuthServerMIBGroups 2 } radiusDynAuthServerNoSessGroup OBJECT-GROUP OBJECTS { radiusDynAuthServDisconNakSessNoContext, radiusDynAuthServCoANakSessNoContext } STATUS current DESCRIPTION "The collection of objects supporting the RADIUS messages that are referring to non existing sessions." ::= { radiusDynAuthServerMIBGroups 3 } END De Cnodder, et al. Expires September 14, 2006 [Page 20] Internet-Draft Dynamic Authorization Server MIB March 2006 5. Security Considerations There are no management objects defined in this MIB module that have a MAX-ACCESS clause of read-write and/or read-create. So, if this MIB module is implemented correctly, then there is no risk that an intruder can alter or create any management objects of this MIB module via direct SNMP SET operations Some of the readable objects in this MIB module (i.e., objects with a MAX-ACCESS other than not-accessible) may be considered sensitive or vulnerable in some network environments. It is thus important to control even GET and/or NOTIFY access to these objects and possibly to even encrypt the values of these objects when sending them over the network via SNMP. These are the tables and objects and their sensitivity/vulnerability: radiusDynAuthClientAddress and radiusDynAuthClientAddressType These can be used to determine the address of the DAC with which the DAS is communicating. This information could be useful in mounting an attack on the DAC. radiusDynAuthServerIdentifier This can be used to determine the Identifier of the DAS. This information could be useful in impersonating the DAS. SNMP versions prior to SNMPv3 did not include adequate security. Even if the network itself is secure (for example by using IPsec), even then, there is no control as to who on the secure network is allowed to access and GET/SET (read/change/create/delete) the objects in this MIB module. It is RECOMMENDED that implementers consider the security features as provided by the SNMPv3 framework (see [RFC3410], section 8), including full support for the SNMPv3 cryptographic mechanisms (for authentication and privacy). Further, deployment of SNMP versions prior to SNMPv3 is NOT RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to enable cryptographic security. It is then a customer/operator responsibility to ensure that the SNMP entity giving access to an instance of this MIB module is properly configured to give access to the objects only to those principals (users) that have legitimate rights to indeed GET or SET (change/create/delete) them. De Cnodder, et al. Expires September 14, 2006 [Page 21] Internet-Draft Dynamic Authorization Server MIB March 2006 6. IANA considerations IANA is requested to assign an OID xxx under mib-2. De Cnodder, et al. Expires September 14, 2006 [Page 22] Internet-Draft Dynamic Authorization Server MIB March 2006 7. Acknowledgements The authors would also like to acknowledge the following people for their comments on this document: Bernard Aboba, Alan DeKok, David Nelson, Anjaneyulu Pata, Dan Romascanu, Greg Weber, Bert Wijnen, and Glen Zorn. De Cnodder, et al. Expires September 14, 2006 [Page 23] Internet-Draft Dynamic Authorization Server MIB March 2006 8. References 8.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997. [RFC2578] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M., and S. Waldbusser, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. [RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M., and S. Waldbusser, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999. [RFC2580] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M., and S. Waldbusser, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999. [RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, December 2002. [RFC3576] Chiba, M., Dommety, G., Eklund, M., Mitton, D., and B. Aboba, "Dynamic Authorization Extensions to Remote Authentication Dial In User Service (RADIUS)", RFC 3576, July 2003. [RFC4001] Daniele, M. and et al., "Textual Conventions for Internet Network Addresses", RFC 4001, February 2005. 8.2. Informative References [DYNCLNT] De Cnodder, S., Jonnala, N., and M. Chiba, "RADIUS Dynamic Authorization Client MIB", draft-ietf-radext-dynauth-client-mib-03.txt, work in progress, December 2005. [RFC2618bis] Nelson, D., "RADIUS Auth Client MIB (IPv6)", draft-ietf-radext-rfc2618bis-01.txt work in progress, October 2005. [RFC2619bis] Nelson, D., "RADIUS Auth Server MIB (IPv6)", draft-ietf-radext-rfc2619bis-01.txt work in progress, De Cnodder, et al. Expires September 14, 2006 [Page 24] Internet-Draft Dynamic Authorization Server MIB March 2006 October 2005. [RFC2620bis] Nelson, D., "RADIUS Acct Client MIB (IPv6)", draft-ietf-radext-rfc2620bis-01.txt work in progress, October 2005. [RFC2621bis] Nelson, D., "RADIUS Acct Server MIB (IPv6)", draft-ietf-radext-rfc2621bis-01.txt work in progress, October 2005. [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000. [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction and Applicability Statements for Internet- Standard Management Framework", RFC 3410, December 2002. De Cnodder, et al. Expires September 14, 2006 [Page 25] Internet-Draft Dynamic Authorization Server MIB March 2006 Authors' Addresses Stefaan De Cnodder Alcatel Francis Wellesplein 1 B-2018 Antwerp Belgium Phone: +32 3 240 85 15 Email: stefaan.de_cnodder@alcatel.be Nagi Reddy Jonnala Cisco Systems, Inc. Divyasree Chambers, B Wing, O'Shaugnessy Road Bangalore-560027, India Phone: +91 98456 99445 Email: njonnala@cisco.com Murtaza Chiba Cisco Systems, Inc. 170 West Tasman Dr. San Jose CA, 95134 Phone: +1 408 525 7198 Email: mchiba@cisco.com De Cnodder, et al. Expires September 14, 2006 [Page 26] Internet-Draft Dynamic Authorization Server MIB March 2006 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. De Cnodder, et al. Expires September 14, 2006 [Page 27] --------------060703020402050606000906-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Mon, 13 Mar 2006 20:36:48 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: RE: radius dynauth client/server mibs structure Date: Mon, 13 Mar 2006 15:36:28 -0500 Message-ID: <3CFB564E055A594B82C4FE89D2156560219121@MABOSEVS2.ets.enterasys.com> Thread-Topic: radius dynauth client/server mibs structure Thread-Index: AcZCMpZmuHs3sISyTsu4WNmWYHVrXgEqmZTQ From: "Nelson, David" To: "Wijnen, Bert \(Bert\)" , Cc: "Nagi Reddy Jonnala \(njonnala\)" , , Bert writes... > I am happy to chekc a pre-release rev 04 as well. > > Stefaan DeCnodder writes... > > > > Since the suggestion has sufficient support it is best to > > do so. Is it Ok to sent a version -04 of both docs after the=20 > > IETF containing all updates? I think Bert would like to get this document revision submitted ASAP. The IETF I-D Tracker tool has these documents in the "Revised I-D Required" state. Bert will be stepping down as O&M Area Director after IETF-65, so if these documents are still awaiting IESG approval after next week, then they will need to be handed off to another AD for shepherding. -- Dave -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Mon, 13 Mar 2006 19:16:53 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Submission of presentations (slides) for the RADEXT WG session at IETF-65 Date: Mon, 13 Mar 2006 14:16:14 -0500 Message-ID: <3CFB564E055A594B82C4FE89D215656021911D@MABOSEVS2.ets.enterasys.com> Thread-Topic: Submission of presentations (slides) for the RADEXT WG session at IETF-65 Thread-Index: AcZG0piM0KX+EfAZR82+k+XpnbGSvA== From: "Nelson, David" To: Cc: "Bernard Aboba" , "Nelson, David" The chairs (of all WGs) have been requested to post WG session = presentation materials on the web (at = https://datatracker.ietf.org/public/meeting_materials.cgi?meeting_num=3D6= 5 ) in advance of the meeting. This is especially important to assist = remote participants (via streaming audio and jabber). The chairs now = have a nice web-based tool to publish WG materials, agendas, etc., = without assistance from the Secretariat. Please submit your RADEXT WG presentation materials to the chairs ASAP. = We would *really* like to have them all posted prior to the RADEXT = session on Tuesday morning of IETF week. Regards, =A0 Dave & Bernard -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Sat, 11 Mar 2006 01:34:15 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: RADEXT WG Last Call on "RADIUS Delegated IPv6 Prefix Attribute" Date: Fri, 10 Mar 2006 20:33:46 -0500 Message-ID: <15B86BC7352F864BB53A47B540C089B6014CA1A0@xmb-rtp-20b.amer.cisco.com> Thread-Topic: RADEXT WG Last Call on "RADIUS Delegated IPv6 Prefix Attribute" Thread-Index: AcZDZlCmSMxZIKaDQSeNXsXJWXhxNABQ5QKw From: "Greg Weber \(gdweber\)" To: "Emile van Bergen" Cc: =20 > -----Original Message----- > From: owner-radiusext@ops.ietf.org=20 > [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Emile van Bergen > Sent: Thursday, March 09, 2006 5:43 AM > To: Nelson, David > Cc: radiusext@ops.ietf.org > Subject: Re: RADEXT WG Last Call on "RADIUS Delegated IPv6=20 > Prefix Attribute" >=20 > The current Extended Attribute draft uses the DIAMETER=20 > format, and the only facility it has toward structured=20 > data is the 'Grouped' data type, which is a *blank*=20 > container for *top level* attributes only. Hi Emile, I just wanted to make sure we are in sync on this bit above. In RFC 3588, I see: 4.4. Grouped AVP Values The Diameter protocol allows AVP values of type 'Grouped.' This implies that the Data field is actually a sequence of AVPs. It is possible to include an AVP with a Grouped type within a Grouped type, that is, to nest them. [...] Doesn't this ability to nest Grouped AVPs effectively provide a c-struct like facility that enables arbitrary complexity? =20 I wasn't sure if by *top level*, you meant non-recursive grouping, or if you meant all layers are defined in the same attribute type space (I think the latter is probably a good thing). Greg -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 10 Mar 2006 18:40:51 +0000 From: "Alan DeKok" To: "Nelson, David" Subject: Re: Dealing with compound attributes (was RE: RADEXT WG Last Call on "RADIUS Delegated IPv6 Prefix Attribute") cc: radiusext@ops.ietf.org Date: Fri, 10 Mar 2006 13:47:39 -0500 Message-Id: <20060310184739.9D02516CC1@mail.nitros9.org> "Nelson, David" wrote: > It would seem to me that if the RADIUS protocol engine > doesn't "care" about the member elements, it does not need to know their > boundaries. Hence we are back to the opaque blob. If it *does* need to > know the boundaries, then I claim that it "cares" about the data > elements. Agreed. > Now, I suppose we could attempt to define "levels of caring". For > example, in the RADIUS/GEOPRIV draft, there are attributes that contain > a number of data elements, that when reassembled form a GEOPRIV data > structure. Is it necessary for the RADIUS protocol engine to know their > boundaries? If not, then the boundaries may not need to be described in the RADIUS document. A simple normitive reference to the geopriv document containing the structure definition would be fine. (It would be nice for the geopriv authors to respond to comments about their document). > I personally object to the notion of RADIUS as a packager and shipper > for arbitrary applications, i.e. RADIUS as transport mechanism. I > realize that it has been, and continues to be, used in this fashion, > usually for applications at least vaguely related to AAA. As more protocols need AAA features, the boundaries between protocols start to blur. This is unfortunate, but it's happening. > I think the argument that RADIUS cares "enough" about the individual > data elements to warrant defining them in explicit sub-fields of a > RADIUS attribute, but not so much as to require any regularization of > their on-the-wire encoding, is problematic. Agreed. The practice should be discouraged. Normitive references to other standards that describe the sub-fields would be the preferred approach. > The only scenario that I see that justifies this middle-ground > "level of caring" is the RADIUS as transport case, i.e. the UPS > Store model. And I think those situations are few and far between. Alan DeKok. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 10 Mar 2006 15:27:10 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: WG Process Issues (was RE: RADEXT WG Last Call on "RADIUS Delegated IPv6 Prefix Attribute") Date: Fri, 10 Mar 2006 10:26:56 -0500 Message-ID: <3CFB564E055A594B82C4FE89D2156560219111@MABOSEVS2.ets.enterasys.com> Thread-Topic: WG Process Issues (was RE: RADEXT WG Last Call on "RADIUS Delegated IPv6 Prefix Attribute") Thread-Index: AcZDrTR2Q9STH7qbTnqiWM6sLEPFvwAACXGgAAB/wCAAAPse8AARGi1wABdxuS A= From: "Nelson, David" To: Glen Zorn writes... > This is clearly not the way this WG works, though (just one=20 > example: the 802 draft which emerged horribly broken from the > design team & was funneled directly into last call). Whether the draft was "horribly" broken is a value judgment. You have accurately observed one item of process that, in RADEXT at least, is different from the traditional IETF of years past. Working Group Last Call (WGLC) is used more aggressively these days, and is not always the "last" opportunity for the WG to comment. Sometimes WGLC is in reality Working Group First Call. The fact of the matter is that the chairs have noticed that it is often difficult to get a broad cross section of the WG to actively comment on drafts until they are in WGLC. I suspect that other WGs have seen this, as well. > I consider the position of WG chair to be a service position, with the > major responsibility that (fraught with danger!) of gauging WG consensus. This is still a major responsibility. It is not the only one however. Among the additional responsibilities, the chairs are held accountable by the ADs for adherence to WG milestones and charters, and for the overall quality level of documents that the WG sends to the IESG. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 10 Mar 2006 15:10:18 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: Dealing with compound attributes (was RE: RADEXT WG Last Call on "RADIUS Delegated IPv6 Prefix Attribute") Date: Fri, 10 Mar 2006 10:10:04 -0500 Message-ID: <3CFB564E055A594B82C4FE89D2156560219110@MABOSEVS2.ets.enterasys.com> Thread-Topic: Dealing with compound attributes (was RE: RADEXT WG Last Call on "RADIUS Delegated IPv6 Prefix Attribute") Thread-Index: AcZEFRKDCNhp0GBEQAuqi+4nS8xaYAAO014A From: "Nelson, David" To: Bernard Aboba writes... I've changed the topic (again) because I think we've wandered past discussion of a particular draft in WGLC, and are effectively discussing the RADIUS Design Guidelines draft. > >As long as the compound format made sense for the actual entity > >generating or processing the attribute's contents and as long as the > >individual member values were not needed in any RADIUS policy nor > >generated dynamically by the RADIUS server proper, there's never been a > >strong problem with such compound attributes, and I don't think there > >necessarily should be any such problem now. >=20 > I think this is a very reasonable distinction. If there is no need to > distinguish the member values, compound attributes are ok. However, if > there is such a need, compounding is problematic, requiring code to be > written that would not otherwise be necessary. Reducing the need for > continual code updates was the original purpose of the Dictionary, after > all. The classic case of a compound attribute where RADIUS does not need to parse (separate or distinguish) or take action upon (create or react to) the member values is EAP-Message. This attribute is an opaque blob to RADIUS, so the case is simple, and degenerate. No arguments there. The distinction that is being proposed here is when a RADIUS RFC (one defining RADIUS protocol elements, such as attributes) specifies a compound attribute (e.g. one containing a structure) for which the RADIUS protocol engine does not "care" about the individual member elements, the attribute may be formatted as conveniently packed bit-fields and octet fields. We presume some of these fields may be further defined in the textual descriptions as integers, bit-vectors, Booleans, strings, arrays, etc. I find it hard to quantify the "care" vs. "don't care" status of the data elements. It would seem to me that if the RADIUS protocol engine doesn't "care" about the member elements, it does not need to know their boundaries. Hence we are back to the opaque blob. If it *does* need to know the boundaries, then I claim that it "cares" about the data elements. Now, I suppose we could attempt to define "levels of caring". For example, in the RADIUS/GEOPRIV draft, there are attributes that contain a number of data elements, that when reassembled form a GEOPRIV data structure. Is it necessary for the RADIUS protocol engine to know their boundaries? Well, one reason for knowing the boundaries is that the RADIUS protocol engine might be expected to perform the data packing, from a set of discrete data elements. I would liken this to the "UPS Store" analogy. The customer brings a collection of loose household objects to the UPS Store to be packed and shipped. The UPS Store employees don't really "care" much about the objects. They only care about the properties that affect packing into cardboard cartons. This might include size, shape, weight, whether or not the object is fragile, and whether or not the material is hazardous or otherwise subject to special shipping regulations. I personally object to the notion of RADIUS as a packager and shipper for arbitrary applications, i.e. RADIUS as transport mechanism. I realize that it has been, and continues to be, used in this fashion, usually for applications at least vaguely related to AAA. I think another way to look at RADIUS attribute data element fields is that if the RADIUS protocol engine needs to know they exist, then they should fall under the attribute design guidelines. Conversely if the RADIUS protocol engine does not need to know that individual date elements exist, then treat the complex data structure in the same fashion that RADIUS treats EAP messages, as an opaque blob. I think the argument that RADIUS cares "enough" about the individual data elements to warrant defining them in explicit sub-fields of a RADIUS attribute, but not so much as to require any regularization of their on-the-wire encoding, is problematic. The only scenario that I see that justifies this middle-ground "level of caring" is the RADIUS as transport case, i.e. the UPS Store model. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 10 Mar 2006 15:10:10 +0000 Date: Fri, 10 Mar 2006 16:09:35 +0100 From: Emile van Bergen To: "Nelson, David" Cc: radiusext@ops.ietf.org Subject: Re: Formats for structured attributes Message-ID: <20060310150935.GA4850@note.evbergen.xs4all.nl> Mail-Followup-To: "Nelson, David" , radiusext@ops.ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.9i Hi, On Thu, Mar 09, 2006 at 12:06:09PM -0500, Nelson, David wrote: > Emile van Bergen writes... > > > Where there are two bits of information for one attribute, pre-RADEXT > > RADIUS has always taken the approach of simply putting them together > > into C struct-like subfields. That can hardly come as a surprise, and > > indeed, without a grouping mechanism, it's the most efficient and > > sensible approach. > > > > As long as the compound format made sense for the actual entity > > generating or processing the attribute's contents and as long as the > > individual member values were not needed in any RADIUS policy nor > > generated dynamically by the RADIUS server proper, there's never been a > > strong problem with such compound attributes, and I don't think there > > necessarily should be any such problem now. > > I think it would be very valuable to allow the expression of compound > data elements in attribute formats that permit an extended form of data > dictionary driven RADIUS server to add new instances of these attributes > into the data dictionary. What I advocate is a mechanism that > regularizes the on-the-wire encoding of the equivalent of C-language > structures in RADIUS attributes, such that new attributes can be added > to a data dictionary, and the sub-elements of the structure can be > described in that fashion. An implementation of such a mechanism can be seen in OpenRADIUS; you can there specify in the dictionary that an attribute contains a 'subspace', and specify how that space is to be parsed: either as a list of fields at fixed offsets or as a set of TLVs in whatever format. Each parsed item can then be addressed individually in administrator defined policies. > > Case in point: MS-CHAP2-Response (RFC 2548); this attribute only > > makes sense as a whole and only to the actual MSCHAPv2 authenticator > endpoint; > > the values of the individual subfields are neither dynamically > generated > > at the RADIUS level nor interpreted by the server as part of > > executing any local policy. > > If you implement the MS-CHAP authenticator as a "plug-in" module to > the RADIUS server, this makes some sense. Whether or not you make that module an external plug in, it still holds that the fewer cross dependencies, the better. If a dictionary driven RADIUS attribute layer is independent from the policy engine and both are independent from the authenticators, then everyting can evolve independently, without having to redesign everything when one becomes obsolete. Currently, this is very well possible with RADIUS, even with most of the baroque attributes that have sprung into existence over the years. In the case of MS-CHAP, neither the packet decoder nor the policy engine needs to know the internal structure of the CHAP Response attribute. And the MS-CHAP authenticator only to know the value of that attribute, together with a cleartext or RC4 password; it does not need any knowledge about the packet or the server policy. Another example is Ascend-Data-Filter; you can translate the textual format into the binary format using an external tool, and simply put the binary value in your user profile. The translation does not need to happen separately for each request, and therefore no specific knowledge about the attribute's internal syntax is needed by the packet encoder or the policy engine. A counterexample is Message-Authenticator: for verification, you need to access both the RADIUS packet as a whole and the attribute itself, and for generation it's worse: the attribute needs to be updated in situ after the whole packet has been encoded. Thus, even the lowest layer of a RADIUS implementation needed changes when this attribute was introduced. This was therefore a very problematic attribute, but of course it was still the most reasonable solution for improving signatures for requests and responses. The only alternative would be an extra fixed header, which would create an incompatible protocol. > > The current Extended Attribute draft uses the DIAMETER format, and the > > only facility it has toward structured data is the 'Grouped' data > > type, which is a *blank* container for *top level* attributes only. > > Then maybe we need to discuss a more general notion of a regularized, > and extensible data model for RADIUS that easily encompasses structured > data. My suggestion for the format of the attributes inside the Extended Attribute space as described in http://www.e-advies.nl/ietf/draft-evbergen-radext-extended-attribute-01.txt proposes nested attributes to create structured data, and creates a model with the following properties: * All A/V pairs, including all subattrbutes, are still primarily made available as a flat list of TLVs, as in normal RADIUS, but with an additional Tag field as in RFC 2868. Relative ordering of instances of the same attribute is preserved. * Grouping pairs by their tags, you can create an ordered list of sets of A/V pairs, and uniquely address a set of pairs containing tag Y, or the n'th tagged set. This mechanism is already deployed in any NAS that supports RFC 2868. Thus, in a policy engine, pairs can be addressed uniquely as the n'th instance of attribute X with tag Y. Eg. (last)Tunnel-Media-Type:1 == IPv4 * Because any pair can refer to a tagged set of attributes as its subordinates, using a dedicated Child-Tag field, you can create a nested structure of attributes. Any attribute of any type can at the same time convey a value as well as a set of subattributes. Whether the attribute has a value, a set of subattributes, both, or none is *not* dependent on a-priori information about the attribute (eg. from the dictionary), but is made clear in the header: if the Length spans only the header, the attribute has no value, and if the Child-Tag field is zero, the attribute does not refer to any tagged set as its children. * In addition to the Type field, each attribute contains a 32-bit STD/Vendor field that defines the number space for the Type field. It allows 2^24 vendors, 2^24 SDOs, 2^24 IETF standards to each govern 2^32 attributes. One particular value of the STD/Vendor field specifies that the attribute's Type number is to be interpreted relative to the parent attribute that refers to the tagged set as its child set. In other words, it allows each attribute to define subattributes without cluttering the global attribute number space. Because the 'locally numbered' subattributes exist in a distinct number space, no clashes occur, even if you look at all pairs as a flat list. While it is impossible to distinguish among *local* attributes of any type without looking at the nested structure created by the Tags and Child-Tags, it's still possible to distinguish all *local* attributes of a certain Type from all *global* attributes of that Type, because the former use a specific value in the STD/Vendor field. * So, as long as you record each attribute's tag, child-tag, and preserve the relative ordering of all attributes of the same type, parsing a packet into a flat list does not cause you to loose any information at all. Thus, the packet decoder/encoder neither requires any knowledge about the nested data structure, nor does anything that addresses the structured data require knowledge that is only available in the encoder/decoder. The structure exists entirely on a level above the parsed list of Std/Vendor, Type, Tag, Child-Tag, Value tuples. Thus, in addition to the tagged flat list perspective, my proposal for structured data in RADIUS allows a policy engine to refer to subattribute X in the unique tagged set that is referred to as a child set by attribute Y. An example: When a policy engine would parse a test for Framed-Tunnel::Media-Type == IPv4, you'd first search for the STD/Vendor/Type tuple of a Framed-Tunnel attribute in your dictionary. You would then look up the Type number for a Media-Type attribute that is defined as a subattribute of Framed-Tunnel; if one is found, the STD/Vendor/Type tuple is known, because all parent dependent attributes use the same value for the STD/Vendor field. If none is found, you would search for the Media-Type attribute in the main dictionary to obtain the global STD/Vendor/Type tuple, if Media-Type is a regular top level attribute. Finally, you'd search for the constant value for 'IPv4' in the list of named constants associated with that Media-Type (sub)attribute. Then, you'd apply this test in your policy engine as follows: Search for the first (or last) instance of the attribute on the request list with the known 64-bit STD/Vendor/Type tuple belonging to Framed-Tunnel, ignore the value, if any, and obtain the Child-Tag. Next, search for the first (or last) instance of the attribute on the request list with the known STD/Vendor/Type tuple belonging to Media-Type and the tag found in the previous step. You would then take the value of this instance of the attribute and compare it to the known value for IPv4 for this attribute. == In short: in my proposal, all attributes can contain structured data, member attributes don't need to be allocated a global Type number, structuring can be done to any depth, and structure is preserved when transporting a flat list of pairs. Traversing the attribute space is simple and efficient; attributes are aligned at 4-octet boundaries, just as with DIAMETER. By contrast, searching for an instance of an attribute in a packet can be done using a single unconditional 64-bit compare; each attribute starts with the 32-bit STD/Vendor field, followed by the 32-bit Type field. The DIAMETER attribute Type space is fully incorporated, but non-DIAMETER attributes can be defined as well, and room is created for other SDOs to assign their own attribute Type spaces. The only metadata about the value given by the attribute header is the value's length in octets; without a priori knowledge of the attribute (dictionary), the value's data type is unknown. Of course, that does not prevent policy engines from comparing or retrieving such values; after all, in addition to their native type, every value is also of the known and well supported type 'string of octets'. Of course, you may argue that this format is a bit too flexible and provides too many ways to shoot yourself in the foot, but I think that in cases like this, it's better to have strong style and strong data type recommendations together with an expressive format, than a format in which you cannot express bad thoughts at all. Structure evolves much slower than style, after all. Cheers, Emile. -- E-Advies - Emile van Bergen emile@e-advies.nl tel. +31 (0)78 6136282 http://www.e-advies.nl -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 10 Mar 2006 09:44:31 +0000 Date: Fri, 10 Mar 2006 10:44:06 +0100 From: Emile van Bergen To: "Nelson, David" Cc: radiusext@ops.ietf.org Subject: Re: RADEXT WG Last Call on "RADIUS Delegated IPv6 Prefix Attribute" Message-ID: <20060310094406.GA3631@note.evbergen.xs4all.nl> Mail-Followup-To: "Nelson, David" , radiusext@ops.ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.9i Hi, On Thu, Mar 09, 2006 at 12:11:25PM -0500, Nelson, David wrote: > Emile van Bergen writes... > > > Before disregarding C structures as proper solutions, I think that > each > > alternative solution should be carefully applied to the problem to see > > how it plays out. This process is only just beginning in the WG, and > > deprecating all existing practice *now* seems rather premature. > > Are you suggesting that the RADEXT WG work items of RADIUS Attribute > Design Guidelines and RADIUS Extended Attributes should be applied > *only* to RADIUS related I-Ds that are submitted *after* RADEXT > completes its work on all the other extensions on its charter? IMHO, it > would be cynical, to say the least, that we establish design guidelines > and new attribute formats for others but exempt ourselves from paying > heed to them. Do as I say, not as I do. :-( Quite the contrary. *After* the Extended Attribute design is completed, and tested against existing real world situations, and approved by rough consensus, I would encourage that authors of *existing* I-Ds and even standards documents revisit their material in the light of the new recommendations. However, as it is, the solution in the Delegated-IPv6-Prefix attribute draft is more mature than the Extended Attribute design work. That's not something to be overly worried about. A new attribute that follows a template set out in an existing standard (RFC3162) will surely be done in less time than a new, future proof design for structured data in RADIUS. Also, because it follows an existing standard (RFC3162), it can easily be deployed *now* by any implementation that offers dictionary driven support for the IPv6 attributes defined in RFC3162. Finally, if you already have an Framed-IPv6-Prefix attribute that needs review, adding a Delegated-IPv6-Prefix attribute with the exacy same data type does not do any harm. You're not suggesting that we have a Framed-IPv6-Prefix attribute with one data type, and a Delegated-IPv6-Prefix that uses an entirely different structure, do you? Therefore, to make the Delegated-IPv6-Prefix wait for the new Extended Attribute design would be entirely unreasonable. Indeed, to do so would only make sense if you *do* hold the cynical view that only documents submitted *after* the Extended Attribute and Design Guidelines work is completed, need to pay any consideration to it. I think it's more reasonable to expect that shortly after the Extended Attribute work completes, people will provide review documents showing in painstaking detail how existing solutions that leave something to be desired, can be reimplemented using the new framework. Those suggestions can then be adopted by the authors that want to update their work. Cheers, Emile. -- E-Advies - Emile van Bergen emile@e-advies.nl tel. +31 (0)78 6136282 http://www.e-advies.nl -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 10 Mar 2006 07:34:56 +0000 Message-ID: From: "Bernard Aboba" To: openradius-radextwg@e-advies.nl, dnelson@enterasys.com Cc: radiusext@ops.ietf.org Bcc: Subject: Re: RADEXT WG Last Call on "RADIUS Delegated IPv6 Prefix Attribute" Date: Thu, 09 Mar 2006 23:34:20 -0800 Mime-Version: 1.0 Content-Type: text/plain; format=flowed >As long as the compound format made sense for the actual entity >generating or processing the attribute's contents and as long as the >individual member values were not needed in any RADIUS policy nor >generated dynamically by the RADIUS server proper, there's never been a >strong problem with such compound attributes, and I don't think there >necessarily should be any such problem now. I think this is a very reasonable distinction. If there is no need to distinguish the member values, compound attributes are ok. However, if there is such a need, compounding is problematic, requiring code to be written that would not otherwise be necessary. Reducing the need for continual code updates was the original purpose of the Dictionary, after all. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 10 Mar 2006 04:23:34 +0000 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: RADEXT WG Last Call on "RADIUS Delegated IPv6 Prefix Attribute" Date: Thu, 9 Mar 2006 20:23:04 -0800 Message-ID: <4C0FAAC489C8B74F96BEAD85EAEB262501A9D82D@xmb-sjc-215.amer.cisco.com> Thread-Topic: RADEXT WG Last Call on "RADIUS Delegated IPv6 Prefix Attribute" Thread-Index: AcZDrTR2Q9STH7qbTnqiWM6sLEPFvwAACXGgAAB/wCAAAPse8AARGi1w From: "Glen Zorn \(gwz\)" To: "Nelson, David" Cc: Nelson, David <> supposedly scribbled: > Avi Lior writes... >=20 >> You as chair(s), slowed down other documents that were ready for last >> call a long time ago to wait for completion of the Guideline >> document.=20 >=20 > Readiness for last call is a subjective assessment. Your opinion of > the readiness of a given draft may differ from mine (and from > others). =20 >=20 >> So why does one document get to go over another document? >=20 > It's a case-by-case readiness assessment. Not a FIFO. That should go w/o saying. However, the fact that it needs to be said = begs the question of whom is doing the assessing. I would think that = the authors/editors of a document would be most capable of that = judgment, in conjunction with the rough consensus of the rest of the WG = (the chairs determining such via the mailing list). This is clearly not = the way this WG works, though (just one example: the 802 draft which = emerged horribly broken from the design team & was funneled directly = into last call). I'm not picking on you & Bernard: this seems to be a = kind of fad in the IETF, along with the establishment of design teams = w/o any WG input & for no apparent technical reason. Of course, this = begs another, more interesting question, that of who's working for who. = I consider the position of WG chair to be a service position, with the = major responsibility that (fraught with danger!) of gauging WG = consensus. Apparently I'm out-of-date: I guess we all work for you now. ~gwz Why is it that most of the world's problems can't be solved by simply listening to John Coltrane? -- Henry Gabriel -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 10 Mar 2006 00:20:29 +0000 From: "Alan DeKok" To: "Bernard Aboba" Subject: Re: RADIUS Design Guidelines cc: radiusext@ops.ietf.org Date: Thu, 09 Mar 2006 19:27:58 -0500 Message-Id: <20060310002758.8CA9F16CC1@mail.nitros9.org> "Bernard Aboba" wrote: > "I have no objections to the guidelines permitting the definition of > new attributes that re-use existing formats, however awkward. The > practice should be discouraged, but not forbidden." > > Question: what would you define as "existing formats"? For the most part, attribute contents currently defined in the RFC's. > For example, the following compound attributes are described in > RFC 2865, 2868, 2869 and 3162. Note the similarity between > RFC 2869 ARAP-Features and RFC 3162 Framed-IPv6-Prefix. Yup. There is existing code to deal with those attributes, so adding more attributes of the same "format" isn't a major change to RADIUS. Where those attributes require per-attribute special handling (e.g. CHAP-Password), we should discourage new attributes of the same format. But even for those cases, I think most of the existing "odd" formats are so special purpose that no one will be defining new standards based on them. To iterate over the attributes you quoted: > Section 5.3 CHAP-Password I think the WG will reject any attempt to define new authentication methods based on CHAP. > Attributes utilizing a one-octet tag field: Defining more tagged integers or strings will involve nothing more than dictionary updates for most implementations. > Section 5.5 ARAP-Features I don't even know if anyone is using this. I do know many RADIUS servers don't even support it, and the format is mostly an array of values, which we could support through a slightly more complex data model. > 2.3 Framed-IPv6-Prefix Many implementations have IPv6 prefixes as a data type, so adding more isn't much of a problem. Alan DeKok. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 10 Mar 2006 00:13:18 +0000 From: "Alan DeKok" To: "Nelson, David" Subject: Re: Formats for structured attributes (was RE: RADEXT WG Last Call on "RADIUS Delegated IPv6 Prefix Attribute") cc: radiusext@ops.ietf.org Date: Thu, 09 Mar 2006 19:20:40 -0500 Message-Id: <20060310002040.397C516CC1@mail.nitros9.org> "Nelson, David" wrote: > I think it would be very valuable to allow the expression of compound > data elements in attribute formats that permit an extended form of data > dictionary driven RADIUS server to add new instances of these attributes > into the data dictionary. What I advocate is a mechanism that > regularizes the on-the-wire encoding of the equivalent of C-language > structures in RADIUS attributes, such that new attributes can be added > to a data dictionary, and the sub-elements of the structure can be > described in that fashion. I think many protocol designers would like something similar. This is an issue across multiple WG's other than RADIUS. My previous company had some proposals in this space, but they never went anywhere. > Then maybe we need to discuss a more general notion of a regularized, > and extensible data model for RADIUS that easily encompasses structured > data. That would be extremely valuable. The only caveat is that the data model can't just model the layout of the data, it has to examine the contents of the data in order to determine packing. e.g. Framed-IPv6-Prefix where trailing zeros don't have to be packed into the attribute. The Samba people have an "IDL to C" compiler written in Perl. It's not perfect, but it's not that complicated. Something similar could be used here. Alan DeKok. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 09 Mar 2006 23:30:58 +0000 Message-ID: From: "Bernard Aboba" To: Subject: Re: RADIUS Design Guidelines Date: Thu, 9 Mar 2006 15:30:29 -0800 Message-ID: <000501c643d1$73c1bba0$da1f75ce@ntdev.corp.microsoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Thread-Index: AcZD0XOkgSiGrYrORQy/D5ztdFfDhg== Alan DeKok said: "I have no objections to the guidelines permitting the definition of new attributes that re-use existing formats, however awkward. The practice should be discouraged, but not forbidden." Question: what would you define as "existing formats"? For example, the following compound attributes are described in RFC 2865, 2868, 2869 and 3162. Note the similarity between RFC 2869 ARAP-Features and RFC 3162 Framed-IPv6-Prefix. =========================================================================== RFC 2865 Section 5.3 CHAP-Password 0 1 2 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- | Type | Length | CHAP Ident | String ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- Request Accept Reject Challenge # Attribute 0-1 0 0 0 3 CHAP-Password [Note 1] RFC 2868 Attributes utilizing a one-octet tag field: Tunnel-Type: tag + 3 octet value (Integer) Tunnel-Medium-Type: tag + 3 octet value (Integer) Tunnel-Client-Endpoint: tag + string (String) Tunnel-Server-Endpoint: tag + string (String) Tunnel-Password: tag + 2 octet salt + string (String) Tunnel-Private-Group-ID: tag + string (String) Tunnel-Assignment-ID: tag + string (String) Tunnel-Preference: tag + 3 octet value (Integer) Tunnel-Client-Auth-ID: tag + string (String) Tunnel-Server-Auth-ID: tag + string (String) Request Accept Reject Challenge Acct-Request # Attribute 0+ 0+ 0 0 0-1 64 Tunnel-Type 0+ 0+ 0 0 0-1 65 Tunnel-Medium-Type 0+ 0+ 0 0 0-1 66 Tunnel-Client-Endpoint 0+ 0+ 0 0 0-1 67 Tunnel-Server-Endpoint 0 0+ 0 0 0 69 Tunnel-Password 0+ 0+ 0 0 0-1 81 Tunnel-Private-Group-ID 0 0+ 0 0 0-1 82 Tunnel-Assignment-ID 0+ 0+ 0 0 0 83 Tunnel-Preference 0+ 0+ 0 0 0-1 90 Tunnel-Client-Auth-ID 0+ 0+ 0 0 0-1 91 Tunnel-Server-Auth-ID RFC 2869 Section 5.5 ARAP-Features 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Value1 | Value2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Value3 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Value4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Value5 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Request Accept Reject Challenge # Attribute 0 0-1 0 0-1 71 ARAP-Features RFC 3162 2.3 Framed-IPv6-Prefix 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Reserved | Prefix-Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Prefix +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Prefix +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Prefix +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Prefix | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Request Accept Reject Challenge Accounting # Attribute Request 0+ 0+ 0 0 0+ 97 Framed-IPv6-Prefix -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 09 Mar 2006 21:41:15 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: RE: Does RADIUS need a data model? Date: Thu, 9 Mar 2006 16:41:07 -0500 Message-ID: <3CFB564E055A594B82C4FE89D215656021910F@MABOSEVS2.ets.enterasys.com> Thread-Topic: Does RADIUS need a data model? Thread-Index: AcZC/2M2f9CTcqwWTO+ivKRZqBa0yAABF9dgACxg8xAAAuSRwAAAKFCA From: "Nelson, David" To: Dan Romascanu writes... > Was this issue discussed previously in the wg?=20 It was discussed extensively on the list during the BOF timeframe. As a result of those discussions, the design guidelines work item was added to the charter. It's fair to say, however, that no clear consensus emerged from those discussions as to the exact nature of guidelines that the WG would eventually adopt. > Should you shortly raise it in Dallas, in connection with the Design=20 > Guidelines document (or not)? I think this discussion will be a significant part of the WG dialog on the design guidelines work items. So, yes, we probably should. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 09 Mar 2006 21:35:34 +0000 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: Does RADIUS need a data model? (was RE: RADEXT WG Last Call on "RADIUS Delegated IPv6 Prefix Attribute") Date: Thu, 9 Mar 2006 23:35:11 +0200 Message-ID: Thread-Topic: Does RADIUS need a data model? (was RE: RADEXT WG Last Call on "RADIUS Delegated IPv6 Prefix Attribute") Thread-Index: AcZC/2M2f9CTcqwWTO+ivKRZqBa0yAABF9dgACxg8xAAAuSRwA== From: "Romascanu, Dan \(Dan\)" To: "Nelson, David" , Was this issue discussed previously in the wg? Should you shortly raise it in Dallas, in connection with the Design Guidelines document (or not)? Dan =20 =20 > -----Original Message----- > From: owner-radiusext@ops.ietf.org=20 > [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Nelson, David > Sent: Thursday, March 09, 2006 10:28 PM > To: radiusext@ops.ietf.org > Subject: Does RADIUS need a data model? (was RE: RADEXT WG=20 > Last Call on "RADIUS Delegated IPv6 Prefix Attribute") >=20 > Glen Zorn writes... >=20 > > Syntactically, I think that they are both strings. Semantics are a=20 > > different ballgame, of course, but 2865 isn't really consistent on > this > > either. In fact, RADIUS is (laudably or lamentably,=20 > depending on your > > POV) pretty loose WRT to data typing. >=20 > I think that Glen has summarized this nicely. The loose data=20 > typing in RADIUS is definitely a double-edged sword. >=20 > I believe that one reason that RADIUS (RFC 2865, RFC 2866)=20 > has been successful with its loose data typing is that it was=20 > largely written by a single author (the engineering staff at=20 > Livingston Enterprises). When one has a uniformity of vision=20 > in the authoring process, formal rules for data typing are=20 > much less important. >=20 > I also believe that subsequent RADIUS RFCs, issued after the=20 > closing of the RADIUS WG, have been, in varying degrees,=20 > substantially less successful in maintaining the unstated=20 > data model of RADIUS. I attribute this to the fact that=20 > different authors were involved, with differing design=20 > perspectives, and no guideline to work with. >=20 > I would like to see guidelines that would produce a more=20 > rational and self-consistent data model. I don't think we=20 > need the formalism of something like SMI, as used in SNMP. I=20 > do think some form of unified data typing, as part of a=20 > semi-formal data model, is desirable. >=20 > I believe that the RADIUS Design Guidelines document should=20 > provide that kind of guidance. I don't believe it goes far=20 > enough, in its current version, to address the issue of=20 > compound data types (structures).=20 >=20 >=20 > -- > to unsubscribe send a message to=20 > radiusext-request@ops.ietf.org with the word 'unsubscribe' in=20 > a single line as the message text body. > archive: >=20 -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 09 Mar 2006 20:28:31 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: Does RADIUS need a data model? (was RE: RADEXT WG Last Call on "RADIUS Delegated IPv6 Prefix Attribute") Date: Thu, 9 Mar 2006 15:28:12 -0500 Message-ID: <3CFB564E055A594B82C4FE89D215656021910D@MABOSEVS2.ets.enterasys.com> Thread-Topic: Does RADIUS need a data model? (was RE: RADEXT WG Last Call on "RADIUS Delegated IPv6 Prefix Attribute") Thread-Index: AcZC/2M2f9CTcqwWTO+ivKRZqBa0yAABF9dgACxg8xA= From: "Nelson, David" To: Glen Zorn writes... > Syntactically, I think that they are both strings. Semantics are a > different ballgame, of course, but 2865 isn't really consistent on this > either. In fact, RADIUS is (laudably or lamentably, depending on your > POV) pretty loose WRT to data typing. I think that Glen has summarized this nicely. The loose data typing in RADIUS is definitely a double-edged sword. I believe that one reason that RADIUS (RFC 2865, RFC 2866) has been successful with its loose data typing is that it was largely written by a single author (the engineering staff at Livingston Enterprises). When one has a uniformity of vision in the authoring process, formal rules for data typing are much less important. I also believe that subsequent RADIUS RFCs, issued after the closing of the RADIUS WG, have been, in varying degrees, substantially less successful in maintaining the unstated data model of RADIUS. I attribute this to the fact that different authors were involved, with differing design perspectives, and no guideline to work with. I would like to see guidelines that would produce a more rational and self-consistent data model. I don't think we need the formalism of something like SMI, as used in SNMP. I do think some form of unified data typing, as part of a semi-formal data model, is desirable. I believe that the RADIUS Design Guidelines document should provide that kind of guidance. I don't believe it goes far enough, in its current version, to address the issue of compound data types (structures).=20 -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 09 Mar 2006 19:57:55 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: RE: RADEXT WG Last Call on "RADIUS Delegated IPv6 Prefix Attribute" Date: Thu, 9 Mar 2006 14:57:45 -0500 Message-ID: <3CFB564E055A594B82C4FE89D215656021910B@MABOSEVS2.ets.enterasys.com> Thread-Topic: RADEXT WG Last Call on "RADIUS Delegated IPv6 Prefix Attribute" Thread-Index: AcZDrTR2Q9STH7qbTnqiWM6sLEPFvwAACXGgAAB/wCAAAPse8A== From: "Nelson, David" To: Avi Lior writes... > You as chair(s), slowed down other documents that were ready=20 > for last call a long time ago to wait for completion of the=20 > Guideline document. Readiness for last call is a subjective assessment. Your opinion of the readiness of a given draft may differ from mine (and from others). > So why does one document get to go over another document?=20 It's a case-by-case readiness assessment. Not a FIFO. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 09 Mar 2006 19:26:27 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: RADEXT WG Last Call on "RADIUS Delegated IPv6 Prefix Attribute" Date: Thu, 9 Mar 2006 14:28:57 -0500 Message-ID: Thread-Topic: RADEXT WG Last Call on "RADIUS Delegated IPv6 Prefix Attribute" Thread-Index: AcZDrTR2Q9STH7qbTnqiWM6sLEPFvwAACXGgAAB/wCA= From: "Avi Lior" To: "Nelson, David" , David, You as chair(s), slowed down other documents that were ready for last call a long time ago to wait for completion of the Guideline document. =20 So why does one document get to go over another document? Lets be evenhanded!!! Avi > -----Original Message----- > From: owner-radiusext@ops.ietf.org=20 > [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Nelson, David > Sent: Thursday, March 09, 2006 2:16 PM > To: radiusext@ops.ietf.org > Subject: RE: RADEXT WG Last Call on "RADIUS Delegated IPv6=20 > Prefix Attribute" >=20 > John Schnizlein writes... >=20 > > That does not seem to me to be the (cynical) suggestion. =20 > Rather the=20 > > suggestion is that it is premature to hold up a last-call WG draft=20 > > because it does not comply with an individual draft, not ready for > last > > call. >=20 > I think for this particular draft, we have all agreed that=20 > the proposed format is acceptable. Some of the comments in=20 > this thread, however, are phrased in such a way as to apply=20 > to other documents, not yet in last call. My comments were=20 > intended to draw a distinction between the case for *this*=20 > document and various others. >=20 >=20 > -- > to unsubscribe send a message to=20 > radiusext-request@ops.ietf.org with the word 'unsubscribe' in=20 > a single line as the message text body. > archive: >=20 -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 09 Mar 2006 19:15:55 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: RE: RADEXT WG Last Call on "RADIUS Delegated IPv6 Prefix Attribute" Date: Thu, 9 Mar 2006 14:15:45 -0500 Message-ID: <3CFB564E055A594B82C4FE89D2156560219108@MABOSEVS2.ets.enterasys.com> Thread-Topic: RADEXT WG Last Call on "RADIUS Delegated IPv6 Prefix Attribute" Thread-Index: AcZDrTR2Q9STH7qbTnqiWM6sLEPFvwAACXGg From: "Nelson, David" To: John Schnizlein writes... > That does not seem to me to be the (cynical) suggestion. Rather the > suggestion is that it is premature to hold up a last-call WG draft > because it does not comply with an individual draft, not ready for last > call. I think for this particular draft, we have all agreed that the proposed format is acceptable. Some of the comments in this thread, however, are phrased in such a way as to apply to other documents, not yet in last call. My comments were intended to draw a distinction between the case for *this* document and various others. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 09 Mar 2006 19:11:08 +0000 Mime-Version: 1.0 (Apple Message framework v623) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <30e94fa0df9a50c9a786903f32b776b3@cisco.com> Content-Transfer-Encoding: 7bit Cc: "" , Ralph Droms ((rdroms)) From: John Schnizlein Subject: Re: RADEXT WG Last Call on "RADIUS Delegated IPv6 Prefix Attribute" Date: Thu, 9 Mar 2006 14:10:45 -0500 To: "Nelson, David" On Mar 9, 2006, at 12:11 PM, Nelson, David wrote: > Emile van Bergen writes... > >> Before disregarding C structures as proper solutions, I think that >> each >> alternative solution should be carefully applied to the problem to see >> how it plays out. This process is only just beginning in the WG, and >> deprecating all existing practice *now* seems rather premature. > > Are you suggesting that the RADEXT WG work items of RADIUS Attribute > Design Guidelines and RADIUS Extended Attributes should be applied > *only* to RADIUS related I-Ds that are submitted *after* RADEXT > completes its work on all the other extensions on its charter? IMHO, > it > would be cynical, to say the least, that we establish design guidelines > and new attribute formats for others but exempt ourselves from paying > heed to them. Do as I say, not as I do. :-( That does not seem to me to be the (cynical) suggestion. Rather the suggestion is that it is premature to hold up a last-call WG draft because it does not comply with an individual draft, not ready for last call. February 25, 2006 draft-ietf-radext-delegated-prefix-00.txt - now in last call March 5, 2006 draft-weber-radius-attr-guidelines-02.txt - on the IETF 65 agenda for discussion It has already been noted that the format proposed is consistant with RFC 3162. John -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 09 Mar 2006 17:11:32 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: RE: RADEXT WG Last Call on "RADIUS Delegated IPv6 Prefix Attribute" Date: Thu, 9 Mar 2006 12:11:25 -0500 Message-ID: <3CFB564E055A594B82C4FE89D2156560219105@MABOSEVS2.ets.enterasys.com> Thread-Topic: RADEXT WG Last Call on "RADIUS Delegated IPv6 Prefix Attribute" Thread-Index: AcZDZj2TrE6p6PMsSX+imGM3MuYg2gANZ/Hw From: "Nelson, David" To: Emile van Bergen writes... > Before disregarding C structures as proper solutions, I think that each > alternative solution should be carefully applied to the problem to see > how it plays out. This process is only just beginning in the WG, and > deprecating all existing practice *now* seems rather premature. Are you suggesting that the RADEXT WG work items of RADIUS Attribute Design Guidelines and RADIUS Extended Attributes should be applied *only* to RADIUS related I-Ds that are submitted *after* RADEXT completes its work on all the other extensions on its charter? IMHO, it would be cynical, to say the least, that we establish design guidelines and new attribute formats for others but exempt ourselves from paying heed to them. Do as I say, not as I do. :-( -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 09 Mar 2006 17:06:14 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: Formats for structured attributes (was RE: RADEXT WG Last Call on "RADIUS Delegated IPv6 Prefix Attribute") Date: Thu, 9 Mar 2006 12:06:09 -0500 Message-ID: <3CFB564E055A594B82C4FE89D2156560219104@MABOSEVS2.ets.enterasys.com> Thread-Topic: Formats for structured attributes (was RE: RADEXT WG Last Call on "RADIUS Delegated IPv6 Prefix Attribute") Thread-Index: AcZDZj2TrE6p6PMsSX+imGM3MuYg2gAM8Wzg From: "Nelson, David" To: Emile van Bergen writes... =20 > Where there are two bits of information for one attribute, pre-RADEXT > RADIUS has always taken the approach of simply putting them together > into C struct-like subfields. That can hardly come as a surprise, and > indeed, without a grouping mechanism, it's the most efficient and > sensible approach. >=20 > As long as the compound format made sense for the actual entity > generating or processing the attribute's contents and as long as the > individual member values were not needed in any RADIUS policy nor > generated dynamically by the RADIUS server proper, there's never been a > strong problem with such compound attributes, and I don't think there > necessarily should be any such problem now. I think it would be very valuable to allow the expression of compound data elements in attribute formats that permit an extended form of data dictionary driven RADIUS server to add new instances of these attributes into the data dictionary. What I advocate is a mechanism that regularizes the on-the-wire encoding of the equivalent of C-language structures in RADIUS attributes, such that new attributes can be added to a data dictionary, and the sub-elements of the structure can be described in that fashion. > Case in point: MS-CHAP2-Response (RFC 2548); this attribute only makes > sense as a whole and only to the actual MSCHAPv2 authenticator endpoint; > the values of the individual subfields are neither dynamically generated > at the RADIUS level nor interpreted by the server as part of executing > any local policy. If you implement the MS-CHAP authenticator as a "plug-in" module to the RADIUS server, this makes some sense. =20 > If we want to deprecate ALL forms of C-structure like attributes, and > expose all subfields as individual attributes, however grouped, then for > sure any new proposal for structuring needs a *thorough* assessment > whether it can meet the challenge. I don't want to deprecate them, per se. I want to regularize them for new work, as described above. As to the need to thorough review of any such proposal, and the desired timing of such work, I reiterate that I think that is the single most important work item for RADEXT. That's why it was originally listed as one of the first milestones that WG was supposed to deliver. IMHO, it is lamentable that we are only now giving this serious attention, but better late than never. > The current Extended Attribute draft uses the DIAMETER format, and the > only facility it has toward structured data is the 'Grouped' data type, > which is a *blank* container for *top level* attributes only. Then maybe we need to discuss a more general notion of a regularized, and extensible data model for RADIUS that easily encompasses structured data. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 09 Mar 2006 17:04:02 +0000 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: RADEXT WG Last Call on "RADIUS Delegated IPv6 Prefix Attribute" Date: Thu, 9 Mar 2006 09:03:34 -0800 Message-ID: <4C0FAAC489C8B74F96BEAD85EAEB262501A9D509@xmb-sjc-215.amer.cisco.com> Thread-Topic: RADEXT WG Last Call on "RADIUS Delegated IPv6 Prefix Attribute" Thread-Index: AcZDZk/iBMl11OrOQnCWKBT/55uUtAANPtFA From: "Glen Zorn \(gwz\)" To: "Emile van Bergen" , "Nelson, David" Cc: Emile van Bergen <> supposedly scribbled: ... > Before disregarding C structures as proper solutions, I think that > each alternative solution should be carefully applied to the problem > to see how it plays out. This process is only just beginning in the > WG, and deprecating all existing practice *now* seems rather > premature. =20 Well put. =20 ~gwz Why is it that most of the world's problems can't be solved by simply listening to John Coltrane? -- Henry Gabriel -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 09 Mar 2006 14:15:42 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: RADEXT WG Last Call on "RADIUS Delegated IPv6 Prefix Attribute" Date: Thu, 9 Mar 2006 09:17:57 -0500 Message-ID: Thread-Topic: RADEXT WG Last Call on "RADIUS Delegated IPv6 Prefix Attribute" Thread-Index: AcZC/2Tq/LbLdf3wT7KklAx+mR+dNQAhE9OQ From: "Avi Lior" To: "Alan DeKok" Cc: Hi Alan,=20 See inline..... > I have no objections to the guidelines permitting the=20 > definition of new attributes that re-use existing formats,=20 > however awkward. The practice should be discouraged, but not=20 > forbidden. Okay. =20 > Therefore, I have no objections to this format, or this document. >=20 > Alan DeKok. >=20 -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 09 Mar 2006 10:43:31 +0000 Date: Thu, 9 Mar 2006 11:42:52 +0100 From: Emile van Bergen To: "Nelson, David" Cc: radiusext@ops.ietf.org Subject: Re: RADEXT WG Last Call on "RADIUS Delegated IPv6 Prefix Attribute" Message-ID: <20060309104251.GA3662@note.evbergen.xs4all.nl> Mail-Followup-To: "Nelson, David" , radiusext@ops.ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.9i Hi, On Wed, Mar 08, 2006 at 06:03:11PM -0500, Nelson, David wrote: > Alan DeKok writes... > > > Yes, though this document simply re-uses the existing standards > > track type defined in 3162. > > There are several examples of new data formats, generally speaking > complex or compound data types, that appear in RADIUS RFCs, both > Standards Track and Informational, that were published after the close > of the RADIUS WG and before the chartering of the RADEXT WG. I have no > idea how much review and comment each of these documents received by the > IESG and the IETF at large. Certainly, there was no attribute design > guideline at the time, and probably no designated expert to review > proposed attributes. > > It is important to document these practices in the RADIUS Attribute > Design Guidelines draft. We need to recognize their existence, and > therefore their validity. I also believe that we want to strongly > discourage further use of "novel" attribute formats, in any new work. Let's keep it into perspective. The attribute in this document and in 3162 needs to convey two pieces of information: a prefix length, and the actual prefix. Where there are two bits of information for one attribute, pre-RADEXT RADIUS has always taken the approach of simply putting them together into C struct-like subfields. That can hardly come as a surprise, and indeed, without a grouping mechanism, it's the most efficient and sensible approach. As long as the compound format made sense for the actual entity generating or processing the attribute's contents and as long as the individual member values were not needed in any RADIUS policy nor generated dynamically by the RADIUS server proper, there's never been a strong problem with such compound attributes, and I don't think there necessarily should be any such problem now. Case in point: MS-CHAP2-Response (RFC 2548); this attribute only makes sense as a whole and only to the actual MSCHAPv2 authenticator endpoint; the values of the individual subfields are neither dynamically generated at the RADIUS level nor interpreted by the server as part of executing any local policy. If we want to deprecate ALL forms of C-structure like attributes, and expose all subfields as individual attributes, however grouped, then for sure any new proposal for structuring needs a *thorough* assessment whether it can meet the challenge. The current Extended Attribute draft uses the DIAMETER format, and the only facility it has toward structured data is the 'Grouped' data type, which is a *blank* container for *top level* attributes only. My alternative suggestion for the Extended Attribute contents at allows RFC2868-style tags for all attributes and allows any attribute to refer to a tagged set to create lightly structured data. Attributes that are only meaningful as members of a structured attribute, can use parent attribute dependent Type numbers, so that they need not be assigned a number from the global attribute type registry. Before disregarding C structures as proper solutions, I think that each alternative solution should be carefully applied to the problem to see how it plays out. This process is only just beginning in the WG, and deprecating all existing practice *now* seems rather premature. Cheers, Emile. -- E-Advies - Emile van Bergen emile@e-advies.nl tel. +31 (0)78 6136282 http://www.e-advies.nl -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 08 Mar 2006 23:20:47 +0000 From: "Alan DeKok" To: "Glen Zorn \(gwz\)" Subject: Re: RADEXT WG Last Call on "RADIUS Delegated IPv6 Prefix Attribute" cc: radiusext@ops.ietf.org Date: Wed, 08 Mar 2006 18:27:59 -0500 Message-Id: <20060308232759.9A34916CC1@mail.nitros9.org> "Glen Zorn \(gwz\)" wrote: > Good argument, except that 3162 nowhere uses the word "type" except as > the name of an attribute field. Since RFC 3162 doesn't define any > types, it seems hard to substantiate your claim of an existing type, let > alone a standard one. Format, syntax, string, type, whatever you call it. This document adds nothing new over 3162, and 3162 is standards track. To a large extent, format and syntax define type. Whether the document says this or not is a different story. Alan DeKok. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 08 Mar 2006 23:06:18 +0000 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: RADEXT WG Last Call on "RADIUS Delegated IPv6 Prefix Attribute" Date: Wed, 8 Mar 2006 15:06:12 -0800 Message-ID: <4C0FAAC489C8B74F96BEAD85EAEB262501A9D2BE@xmb-sjc-215.amer.cisco.com> Thread-Topic: RADEXT WG Last Call on "RADIUS Delegated IPv6 Prefix Attribute" Thread-Index: AcZC/2M2f9CTcqwWTO+ivKRZqBa0yAABF9dg From: "Glen Zorn \(gwz\)" To: "Alan DeKok" , "Avi Lior" Cc: Alan DeKok <> supposedly scribbled: > "Avi Lior" wrote: >> The closest RADIUs type would be string. Neither 3162 nor this >> document defines the type as string. In essence both documents (and >> thank god they are consistant) are defining a new type, which is a >> compound type, that contains a length field counting bits, Octet >> based variable length array containing bits. Syntactically, I think that they are both strings. Semantics are a = different ballgame, of course, but 2865 isn't really consistent on this = either. In fact, RADIUS is (laudably or lamentably, depending on your = POV) pretty loose WRT to data typing. >=20 > Yes, though this document simply re-uses the existing standards > track type defined in 3162.=20 Good argument, except that 3162 nowhere uses the word "type" except as = the name of an attribute field. Since RFC 3162 doesn't define any = types, it seems hard to substantiate your claim of an existing type, let = alone a standard one. >=20 >> I don't think EXTATTR folks are thinking about encoding attributes >> the way this document and 3162 is proposing -- so that is out of the >> question.=20 Maybe they should be? Seems kind of useful... >>=20 >> So perhaps the Guidelines document should be changed to allow for >> this encoding. That would be my choice. That's OK, too. >=20 > I have no objections to the guidelines permitting the definition of > new attributes that re-use existing formats, however awkward. The > practice should be discouraged, but not forbidden. =20 >=20 > Therefore, I have no objections to this format, or this document. >=20 > Alan DeKok. Hope this helps, ~gwz Why is it that most of the world's problems can't be solved by simply listening to John Coltrane? -- Henry Gabriel -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 08 Mar 2006 23:03:37 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: RADEXT WG Last Call on "RADIUS Delegated IPv6 Prefix Attribute" Date: Wed, 8 Mar 2006 18:03:11 -0500 Message-ID: <3CFB564E055A594B82C4FE89D2156560219102@MABOSEVS2.ets.enterasys.com> Thread-Topic: RADEXT WG Last Call on "RADIUS Delegated IPv6 Prefix Attribute" Thread-Index: AcZC/v/lfgJLjpoNSWm39oYf95M9XQAAlP4A From: "Nelson, David" To: Alan DeKok writes... =20 > Yes, though this document simply re-uses the existing standards > track type defined in 3162. There are several examples of new data formats, generally speaking complex or compound data types, that appear in RADIUS RFCs, both Standards Track and Informational, that were published after the close of the RADIUS WG and before the chartering of the RADEXT WG. I have no idea how much review and comment each of these documents received by the IESG and the IETF at large. Certainly, there was no attribute design guideline at the time, and probably no designated expert to review proposed attributes. It is important to document these practices in the RADIUS Attribute Design Guidelines draft. We need to recognize their existence, and therefore their validity. I also believe that we want to strongly discourage further use of "novel" attribute formats, in any new work. It is important that the RADIUS Attribute Design Guidelines draft, coupled with the RADIUS Extended Attribute draft, cover all of the needs for attribute data modeling. If an important data type is missing, or cannot be created as derived a data type in a straightforward fashion, then that shortcoming needs to be addressed in the these two documents. I would stop short of saying that any "novel" attribute formats that have been published in any given RADIUS RFC since the closing of the RADIUS WG should be considered suitable for new design. > I have no objections to the guidelines permitting the definition of > new attributes that re-use existing formats, however awkward. The > practice should be discouraged, but not forbidden. Well, as a BCP, the RADIUS Attribute Design Guidelines cannot actually *forbid* anything, but I think the discouragement for creating (or re-using) "novel" formats not included in RFC 2865, the RADIUS Attribute Design Guidelines or the RADIUS Extended Attribute documents should be very strong indeed. The desire is to prevent a fragmentation of the RADIUS attribute data model, such as it is, into some form of Tower of Babel, at least going forward.=20 > Therefore, I have no objections to this format, or this document. Given that we are attempting to quickly address an issue with existing usages (a la RFC 3162) it may be acceptable to re-use that attribute format in this draft. I would not support a general grandfathering of all such attribute formats for new work, including many of the existing RADEXT WG work items. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 08 Mar 2006 22:23:44 +0000 From: "Alan DeKok" To: "Avi Lior" Subject: Re: RADEXT WG Last Call on "RADIUS Delegated IPv6 Prefix Attribute" cc: radiusext@ops.ietf.org Date: Wed, 08 Mar 2006 17:31:03 -0500 Message-Id: <20060308223103.2E2B716CC1@mail.nitros9.org> "Avi Lior" wrote: > The closest RADIUs type would be string. Neither 3162 nor this document > defines the type as string. In essence both documents (and thank god > they are consistant) are defining a new type, which is a compound type, > that contains a length field counting bits, Octet based variable length > array containing bits. Yes, though this document simply re-uses the existing standards track type defined in 3162. > I don't think EXTATTR folks are thinking about encoding attributes the > way this document and 3162 is proposing -- so that is out of the > question. > > So perhaps the Guidelines document should be changed to allow for this > encoding. That would be my choice. I have no objections to the guidelines permitting the definition of new attributes that re-use existing formats, however awkward. The practice should be discouraged, but not forbidden. Therefore, I have no objections to this format, or this document. Alan DeKok. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 08 Mar 2006 22:08:10 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: RADEXT WG Last Call on "RADIUS Delegated IPv6 Prefix Attribute" Date: Wed, 8 Mar 2006 17:10:32 -0500 Message-ID: Thread-Topic: RADEXT WG Last Call on "RADIUS Delegated IPv6 Prefix Attribute" Thread-Index: AcY+/hLgMep5FqxrRoOpeYzM84E71wD7PuvQAAEvJ9AAArbYkA== From: "Avi Lior" To: "Glen Zorn \(gwz\)" Cc: "Bernard Aboba" , Hi Glen,=20 > -----Original Message----- > From: Glen Zorn (gwz) [mailto:gwz@cisco.com]=20 > Sent: Wednesday, March 08, 2006 3:36 PM > To: Avi Lior > Cc: Bernard Aboba; radiusext@ops.ietf.org > Subject: RE: RADEXT WG Last Call on "RADIUS Delegated IPv6=20 > Prefix Attribute" >=20 > Avi Lior <> supposedly scribbled: >=20 > > I hate to bring this up but the format of this attribute does not=20 > > adhere to 2865 >=20 > How so? Where shall I begin? The closest RADIUs type would be string. Neither 3162 nor this document defines the type as string. In essence both documents (and thank god they are consistant) are defining a new type, which is a compound type, that contains a length field counting bits, Octet based variable length array containing bits. > > nor to the RADIUS Attribute Guidelines recommendation.=20 > So which one should change? Ah another good question. It depends who you ask. But lets see what are the options: If you want to keep the encoding then: I think if you read the guideline document, if this format should be allowed to stand then it should be covered by RADIUS EXTATTR. Since the recommendation in the GUIDELINE document is that any new types should conform to that document. Next, the Guideline document could be changed to allow for this encoding. Finally, the document should be changed. If you ask me: The last option would be sad indeed given the consistancy of the proposed encoding with 3162. I don't think EXTATTR folks are thinking about encoding attributes the way this document and 3162 is proposing -- so that is out of the question. So perhaps the Guidelines document should be changed to allow for this encoding. That would be my choice. Maybe others can chirp in. If memory serves me right, based on previous intense discussions, I am totally surprized by the silence of the chairs on this matter. >=20 > >=20 > > Avi > >=20 > >=20 > >> -----Original Message----- > >> From: owner-radiusext@ops.ietf.org > >> [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Bernard Aboba > >> Sent: Friday, March 03, 2006 3:02 PM > >> To: radiusext@ops.ietf.org > >> Subject: RADEXT WG Last Call on "RADIUS Delegated IPv6 Prefix=20 > >> Attribute" > >>=20 > >> This is an announcement of RADEXT WG last call on the "RADIUS > >> Delegated-IPv6 Prefix Attribute" > >> document, prior to sending this document on to the IESG for=20 > >> consideration as a Proposed Standard. > >>=20 > >> The document is available for inspection here: > >>=20 > http://www.ietf.org/internet-drafts/draft-ietf-radext-delegated-prefi > >> x-00.txt > >>=20 > >> RADEXT WG last call will last until Monday March 27, 2006. > >> Please send your comments to the RADEXT WG list > >> (radiusext@ops.ietf.org) in the format described on the=20 > RADEXT Issues=20 > >> List: http://www.drizzle.com/~aboba/RADEXT/ > >>=20 > >> Since all RADEXT WG last calls require at least 5=20 > reviewers in order=20 > >> to advance the document, please respond indicating that=20 > you have read=20 > >> the document and find it acceptable, even if you have no issues to=20 > >> file. > >>=20 > >>=20 > >>=20 > >> -- > >> to unsubscribe send a message to=20 > radiusext-request@ops.ietf.org with=20 > >> the word 'unsubscribe' in a single line as the message text body. > >> archive: >=20 > Hope this helps, >=20 > ~gwz >=20 > Why is it that most of the world's problems can't be solved by simply > listening to John Coltrane? -- Henry Gabriel >=20 -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 08 Mar 2006 20:50:15 +0000 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: radiusext@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-radext-digest-auth-07.txt Message-Id: Date: Wed, 08 Mar 2006 15:50:02 -0500 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the RADIUS EXTensions Working Group of the IETF. Title : RADIUS Extension for Digest Authentication Author(s) : B. Sterman, et al. Filename : draft-ietf-radext-digest-auth-07.txt Pages : 39 Date : 2006-3-8 This document defines an extension to the Remote Authentication Dial In User Service (RADIUS) protocol to enable support of Digest Authentication, for use with HTTP-style protocols like the Session Initiation Protocol (SIP) and HTTP. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-radext-digest-auth-07.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-radext-digest-auth-07.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-radext-digest-auth-07.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-3-8121436.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-radext-digest-auth-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-radext-digest-auth-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-3-8121436.I-D@ietf.org> --OtherAccess-- --NextPart-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 08 Mar 2006 20:36:24 +0000 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: RADEXT WG Last Call on "RADIUS Delegated IPv6 Prefix Attribute" Date: Wed, 8 Mar 2006 12:36:10 -0800 Message-ID: <4C0FAAC489C8B74F96BEAD85EAEB262501A9D1B5@xmb-sjc-215.amer.cisco.com> Thread-Topic: RADEXT WG Last Call on "RADIUS Delegated IPv6 Prefix Attribute" Thread-Index: AcY+/hLgMep5FqxrRoOpeYzM84E71wD7PuvQAAEvJ9A= From: "Glen Zorn \(gwz\)" To: "Avi Lior" Cc: "Bernard Aboba" , Avi Lior <> supposedly scribbled: > I hate to bring this up but the format of this attribute does not > adhere to 2865=20 How so? > nor to the RADIUS Attribute Guidelines recommendation.=20 So which one should change? >=20 > Avi >=20 >=20 >> -----Original Message----- >> From: owner-radiusext@ops.ietf.org >> [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Bernard Aboba >> Sent: Friday, March 03, 2006 3:02 PM >> To: radiusext@ops.ietf.org >> Subject: RADEXT WG Last Call on "RADIUS Delegated IPv6 Prefix >> Attribute"=20 >>=20 >> This is an announcement of RADEXT WG last call on the "RADIUS >> Delegated-IPv6 Prefix Attribute" >> document, prior to sending this document on to the IESG for >> consideration as a Proposed Standard. >>=20 >> The document is available for inspection here: >> = http://www.ietf.org/internet-drafts/draft-ietf-radext-delegated-prefix-00= .txt >>=20 >> RADEXT WG last call will last until Monday March 27, 2006. >> Please send your comments to the RADEXT WG list >> (radiusext@ops.ietf.org) in the format described on the RADEXT >> Issues List: http://www.drizzle.com/~aboba/RADEXT/ >>=20 >> Since all RADEXT WG last calls require at least 5 reviewers in order >> to advance the document, please respond indicating that you have read >> the document and find it acceptable, even if you have no issues to >> file.=20 >>=20 >>=20 >>=20 >> -- >> to unsubscribe send a message to radiusext-request@ops.ietf.org with >> the word 'unsubscribe' in a single line as the message text body. >> archive: Hope this helps, ~gwz Why is it that most of the world's problems can't be solved by simply listening to John Coltrane? -- Henry Gabriel -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 08 Mar 2006 20:11:45 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: RADEXT WG Last Call on "RADIUS Delegated IPv6 Prefix Attribute" Date: Wed, 8 Mar 2006 15:13:57 -0500 Message-ID: Thread-Topic: RADEXT WG Last Call on "RADIUS Delegated IPv6 Prefix Attribute" Thread-Index: AcY+/hLgMep5FqxrRoOpeYzM84E71wD7PuvQ From: "Avi Lior" To: "Bernard Aboba" , I hate to bring this up but the format of this attribute does not adhere to 2865 nor to the RADIUS Attribute Guidelines recommendation.=20 Avi =20 > -----Original Message----- > From: owner-radiusext@ops.ietf.org=20 > [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Bernard Aboba > Sent: Friday, March 03, 2006 3:02 PM > To: radiusext@ops.ietf.org > Subject: RADEXT WG Last Call on "RADIUS Delegated IPv6 Prefix=20 > Attribute" >=20 > This is an announcement of RADEXT WG last call on the "RADIUS=20 > Delegated-IPv6 Prefix Attribute" > document, prior to sending this document on to the IESG for=20 > consideration as a Proposed Standard. >=20 > The document is available for inspection here: > http://www.ietf.org/internet-drafts/draft-ietf-radext-delegate d-prefix-00.txt >=20 > RADEXT WG last call will last until Monday March 27, 2006. =20 > Please send your comments to the RADEXT WG list=20 > (radiusext@ops.ietf.org) in the format described on the=20 > RADEXT Issues List: > http://www.drizzle.com/~aboba/RADEXT/ >=20 > Since all RADEXT WG last calls require at least 5 reviewers=20 > in order to advance the document, please respond indicating=20 > that you have read the document and find it acceptable, even=20 > if you have no issues to file. >=20 >=20 >=20 > -- > to unsubscribe send a message to radiusext-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: >=20 -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 08 Mar 2006 13:58:03 +0000 Message-Id: <1E4CCB2441C5C0409AD8A929482A09F31BB685@S4DE9JSAAIG.ost.t-com.de> From: "Beck01, Wolfgang" To: bernard_aboba@hotmail.com Cc: radiusext@ops.ietf.org Subject: things fixed in RADIUS Digest -07 Date: Wed, 8 Mar 2006 14:56:33 +0100 MIME-Version: 1.0 Content-Type: text/plain IESG Comments ------------- [hartmans] Rejection of Client Nonces - see 3.3 "If the server cannot choose a nonce, it replies with an Access-Reject". [hartmans, townsley (Zorn)] Client Nonce Replay Attack - defined a client nonce format with an embedded sequence number [rhousley] Missing CHAP reference: - fixed MUST for operator advice section 2. "the operator MUST make sure [..] " changed to "the operator must make sure [..]" [bwijnen] IP addresses in examples - changed to 192.0.2.0/24 range [jpeterson] WWW-Authenticate / Response code mismatch in example - fixed Motivation Section - fixed wrong notion that RfC 3261 tries to supplant Digest-Auth [sah] IANA - removed preferred values Issues from the Issue tracker ----------------------------- Issue 151: Abstract - spelled out abbreviations Terminology - spelled out abbreviations - more detailed explanation of protection space Client Behavior - fixed typos - used Kurt's proposed sentence concerning Digest-Nextnonce handling - did not change 'without quotes', as the RADIUS client can be transparent Issue 152: - split up the text in sub sections to enhance readability Issue 159: - added a section about configuration parameters on the RADIUS client Issue: 173-175: see IESG comments Wolfgang -- T-Systems Next Generation IP Services and Systems +49 6151 937 2863 Am Kavalleriesand 3 64295 Darmstadt Germany -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 08 Mar 2006 02:13:39 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C64255.DC9830CB" Subject: FW: I-D ACTION:draft-weber-radius-attr-guidelines-02.txt Date: Tue, 7 Mar 2006 21:13:15 -0500 Message-ID: <15B86BC7352F864BB53A47B540C089B6014C9463@xmb-rtp-20b.amer.cisco.com> Thread-Topic: I-D ACTION:draft-weber-radius-attr-guidelines-02.txt Thread-Index: AcZCL0lrwK4H83/qTNqoYTS8dFZB6gAJgpPg From: "Greg Weber \(gdweber\)" To: This is a multi-part message in MIME format. ------_=_NextPart_001_01C64255.DC9830CB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 FYI, this is an IETF-65 RADEXT agenda item. Comments to the list, please. Greg > -----Original Message----- > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org]=20 > Sent: Tuesday, March 07, 2006 8:50 PM > To: i-d-announce@ietf.org > Subject: I-D ACTION:draft-weber-radius-attr-guidelines-02.txt=20 >=20 > A New Internet-Draft is available from the on-line=20 > Internet-Drafts directories. >=20 >=20 > Title : Design Guidelines for RADIUS Attributes > Author(s) : G. Weber > Filename : draft-weber-radius-attr-guidelines-02.txt > Pages : 15 > Date : 2006-3-7 > =09 > This memo explores various issues related to the data model used by > the Remote Authentication Dial In User Service (RADIUS) protocol. > Recommendations are made to facilitate internal alignment and > uniformity. Attribute design guidelines are also provided. >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-weber-radius-attr-guidelines-0 2.txt >=20 ------_=_NextPart_001_01C64255.DC9830CB Content-Type: application/octet-stream; name="draft-weber-radius-attr-guidelines-02.URL" Content-Transfer-Encoding: base64 Content-Description: draft-weber-radius-attr-guidelines-02.URL Content-Disposition: attachment; filename="draft-weber-radius-attr-guidelines-02.URL" W0ludGVybmV0U2hvcnRjdXRdDQpVUkw9ZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0 cy9kcmFmdC13ZWJlci1yYWRpdXMtYXR0ci1ndWlkZWxpbmVzLTAyLnR4dA0K ------_=_NextPart_001_01C64255.DC9830CB-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 07 Mar 2006 22:01:07 +0000 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B155097B928B@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: stefaan.de_cnodder@alcatel.be, "Wijnen, Bert (Bert)" Cc: "Nelson, David" , radiusext@ops.ietf.org Subject: RE: AD review: radius dynauth client/server mib documents Date: Tue, 7 Mar 2006 23:00:33 +0100 MIME-Version: 1.0 Content-Type: text/plain W.r.t. > -----Original Message----- > From: stefaan.de_cnodder@alcatel.be > [mailto:stefaan.de_cnodder@alcatel.be] > Sent: Tuesday, March 07, 2006 21:13 > To: Wijnen, Bert (Bert) > Cc: Nelson, David; radiusext@ops.ietf.org > Subject: Re: AD review: radius dynauth client/server mib documents > > > > Hi, > > see below... > > Wijnen, Bert (Bert) wrote: > > > Inline > > > > > >>-----Original Message----- > >>From: Nelson, David [mailto:dnelson@enterasys.com] > >>Sent: Friday, March 03, 2006 16:40 > >>To: Wijnen, Bert (Bert); radiusext@ops.ietf.org > >>Subject: RE: AD review: radius dynauth client/server mib documents > >> > >> > >>Bert Wijnen writes... > >> > >> > >>>2. The a whole serioes of Counter32 objects. > >>> I wonder what the object is to indicate a counter-discontinuity? > >>> Or can such only happen at system restart/reboot? > >>> See RFC2578 that explains this in sect 7.1.6 > >>> RFC4181, sect 4.6.1.2 (1st bullet) also speaks to it. > >> > >>RFC2578 Section 7.1.6: > >> > >> The Counter32 type represents a non-negative integer which > >> monotonically increases until it reaches a maximum value > of 2^32-1 > >> (4294967295 decimal), when it wraps around and starts increasing > >> again from zero. > >> > >> Counters have no defined "initial" value, and thus, a > >>single value of > >> a Counter has (in general) no information content. > Discontinuities > >> in the monotonically increasing value normally occur at re- > >> initialization of the management system, and at other times as > >> specified in the description of an object-type using this > >>ASN.1 type. > >> If such other times can occur, for example, the creation > >>of an object > >> instance at times other than re-initialization, then a > >>corresponding > >> object should be defined, with an appropriate SYNTAX clause, to > >> indicate the last discontinuity. Examples of appropriate SYNTAX > >> clause include: TimeStamp (a textual convention defined in [3]), > >> DateAndTime (another textual convention from [3]) or TimeTicks. > >> > >>RFC4181 Section 4.6.1.2 (1st bullet): > >> > >> - It is OK to use Counter32/64 for counters that > may/will be reset > >> when the management subsystem is re-initialized or when other > >> unusual/irregular events occur (e.g., counters > >>maintained on a line > >> card may be reset when the line card is reset). > >>However, if it is > >> possible for such other unusual/irregular events to occur, the > >> DESCRIPTION clause MUST state that this is so and MUST describe > >> those other unusual/irregular events in sufficient > detail that it > >> is possible for a management application to determine whether a > >> reset has occurred since the last time the counter was > >>polled. The > >> RECOMMENDED way to do this is to provide a discontinuity > >>indicator > >> as described in RFC 2578 Sections 7.1.6 and 7.1.10. For > >>an example > >> of such a discontinuity indicator, see the > >> ifCounterDiscontinuityTime object in the IF-MIB [RFC2863]. > >> > >>So I take it that the normal wrapping from maximum value to > >>zero is OK, > >>and reset upon system (re)initialization is OK, but any other > >>"discontinuity" needs special attention. Is that right? > >> > > > > Yes, and that is why I had a very simple solution proposed later in > > my review message. By adding that sentence, we make it clear that > > we have thought about this and that such is indeed the case > (assuming > > that I got it right). By not saying anything about it, it could > > be an unintended omission. > > > > Ok, I will add a sentence the overview section to mention this. I > believe this is better than in the MIB itself to avoid repeating the > same for each object again. > Well, I strongly recommend to put it in the MIB module itself. Normally I ask it to be in the DESCRIPTION clause of every object. SO if you do a revision anyway, then I prefer that. If you find that too much work, I would settle for it to occur once in the xxxTable or xxxEntry DESCRIPTION clause to explain that all COunter32 objets in this table have that behaviour w.r.t. discontinuities. > Also the reference to the IANA copy-right web page will be removed. > Good Bert > thanks, > Stefaan > > > > > > >>> So, the radiusDynAuthClientAddress needs to specify that > >> > >>the address > >>is > >> > >>> formatted according to the value of > >> > >>radiusDynAuthClientAddressType. > >> > >>> Also, as far as I can tell, any addressType could be > present here, > >>> so formally, you would need to describe when a dns name has been > >>> resolved (if it occurs). > >> > >>RADIUS normally deals with IP Addresses, as the RADIUS > client needs to > >>be registered with the RADIUS Server by IP Address, so that > >>the correct > >>shared secret can be used. It is possible to use DNS with RADIUS > >>clients and servers, if sufficient care is taken to always have an > >>accurate inverse name resolution available, but I believe > this is not > >>common practice. > >> > > > > > > I think that answer is suffient for me. > > > > Bert > > > > -- > > to unsubscribe send a message to radiusext-request@ops.ietf.org with > > the word 'unsubscribe' in a single line as the message text body. > > archive: > -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 07 Mar 2006 22:00:59 +0000 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B155097B928A@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "Nelson, David" , stefaan.de_cnodder@alcatel.be Cc: "Nagi Reddy Jonnala (njonnala)" , j.schoenwaelder@iu-bremen.de, radiusext@ops.ietf.org, "Wijnen, Bert (Bert)" Subject: RE: radius dynauth client/server mibs structure Date: Tue, 7 Mar 2006 23:00:32 +0100 MIME-Version: 1.0 Content-Type: text/plain I am happy to chekc a pre-release rev 04 as well. Bert > -----Original Message----- > From: Nelson, David [mailto:dnelson@enterasys.com] > Sent: Tuesday, March 07, 2006 21:24 > To: stefaan.de_cnodder@alcatel.be > Cc: Nagi Reddy Jonnala (njonnala); j.schoenwaelder@iu-bremen.de; > radiusext@ops.ietf.org; Wijnen, Bert (Bert) > Subject: RE: radius dynauth client/server mibs structure > > > Stefaan DeCnodder writes... > > > Since the suggestion has sufficient support it is best to > do so. Is it > > Ok to sent a version -04 of both docs after the IETF containing all > > updates? > > That would be best. You can submit -04 any time that it is ready (all > the changes are incorporated). It won't be published until after > IETF-65. I-D submissions are now queued for publication, as > opposed to > bounced, during the IETF meeting "blackout" periods. > > While you are at it, though, all the other nits in the -03 drafts that > could have been addressed with RFC Editor notes should be > incorporated, > to keep the process as simple as possible. > > It would also be appropriate to send the "diff" text to the RADEXT WG > list before submitting tie -04 drafts, so that the WG gets to look at > the proposed issue resolutions in detail. We have discussed > them on the > list, so I think folks are generally aware, but posting the exact text > would be helpful. > > -- Dave > -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 07 Mar 2006 20:24:14 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: radius dynauth client/server mibs structure Date: Tue, 7 Mar 2006 15:23:56 -0500 Message-ID: <3CFB564E055A594B82C4FE89D21565602190F2@MABOSEVS2.ets.enterasys.com> Thread-Topic: radius dynauth client/server mibs structure Thread-Index: AcZCI/hN6gjOmhafQE6ATIw6/LTRsAAAB/Rg From: "Nelson, David" To: Cc: "Nagi Reddy Jonnala \(njonnala\)" , , , "Wijnen, Bert \(Bert\)" Stefaan DeCnodder writes... =20 > Since the suggestion has sufficient support it is best to do so. Is it > Ok to sent a version -04 of both docs after the IETF containing all > updates? That would be best. You can submit -04 any time that it is ready (all the changes are incorporated). It won't be published until after IETF-65. I-D submissions are now queued for publication, as opposed to bounced, during the IETF meeting "blackout" periods. While you are at it, though, all the other nits in the -03 drafts that could have been addressed with RFC Editor notes should be incorporated, to keep the process as simple as possible. It would also be appropriate to send the "diff" text to the RADEXT WG list before submitting tie -04 drafts, so that the WG gets to look at the proposed issue resolutions in detail. We have discussed them on the list, so I think folks are generally aware, but posting the exact text would be helpful. -- Dave -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 07 Mar 2006 20:16:19 +0000 Message-ID: <440DE9FD.9030905@alcatel.be> Date: Tue, 07 Mar 2006 21:15:57 +0100 From: stefaan.de_cnodder@alcatel.be User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20040910 MIME-Version: 1.0 To: "Wijnen, Bert (Bert)" Cc: "Nelson, David" , "Nagi Reddy Jonnala (njonnala)" , j.schoenwaelder@iu-bremen.de, radiusext@ops.ietf.org Subject: Re: radius dynauth client/server mibs structure Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed Hi, Since the suggestion has sufficient support it is best to do so. Is it Ok to sent a version -04 of both docs after the IETF containing all updates? regards, Stefaan Wijnen, Bert (Bert) wrote: > Inline > > >>-----Original Message----- >>From: Nelson, David [mailto:dnelson@enterasys.com] >>Sent: Friday, March 03, 2006 16:45 >>To: Wijnen, Bert (Bert); Nagi Reddy Jonnala (njonnala); >>j.schoenwaelder@iu-bremen.de; radiusext@ops.ietf.org >>Subject: RE: radius dynauth client/server mibs structure >> >> >>Bert Wijnen writes... >> >> >>>The disadvantage of not doing so is in the future when >> >>adding scalars >> >>>and thing not having grouped as nicely and so more complexity. >> >>In practice, does this inconvenient grouping really affect any SNMP >>applications in a user-visible way, except for MIB-walk and >>MIB-browser applications? >> > > > I know from experience that it made it easier for me to implement the > MIB at the agent side. Of course that could have been caused just by my > owb design, and other may not have trouble with it at all. > > I am somewhat less familiar with mgmt apps. > > >>>This is not a blocking comment, just another MIB-type person believing >>>that the change would be real EASY now, and it will certainly make >>>things cleaner/easier in the future. >> >>It certainly makes the MIB _document_ neater. >> > > > And rigth now (at FIRST or INITIAL version) it is EASY to make the change > to make something neat. Later you cannot correct it without possibly > deprecating/obsoleteing existing and adding new objects. > > Oh well. > > Bert > > -- > to unsubscribe send a message to radiusext-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 07 Mar 2006 20:13:21 +0000 Message-ID: <440DE941.5090502@alcatel.be> Date: Tue, 07 Mar 2006 21:12:49 +0100 From: stefaan.de_cnodder@alcatel.be User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20040910 MIME-Version: 1.0 To: "Wijnen, Bert (Bert)" Cc: "Nelson, David" , radiusext@ops.ietf.org Subject: Re: AD review: radius dynauth client/server mib documents Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed Hi, see below... Wijnen, Bert (Bert) wrote: > Inline > > >>-----Original Message----- >>From: Nelson, David [mailto:dnelson@enterasys.com] >>Sent: Friday, March 03, 2006 16:40 >>To: Wijnen, Bert (Bert); radiusext@ops.ietf.org >>Subject: RE: AD review: radius dynauth client/server mib documents >> >> >>Bert Wijnen writes... >> >> >>>2. The a whole serioes of Counter32 objects. >>> I wonder what the object is to indicate a counter-discontinuity? >>> Or can such only happen at system restart/reboot? >>> See RFC2578 that explains this in sect 7.1.6 >>> RFC4181, sect 4.6.1.2 (1st bullet) also speaks to it. >> >>RFC2578 Section 7.1.6: >> >> The Counter32 type represents a non-negative integer which >> monotonically increases until it reaches a maximum value of 2^32-1 >> (4294967295 decimal), when it wraps around and starts increasing >> again from zero. >> >> Counters have no defined "initial" value, and thus, a >>single value of >> a Counter has (in general) no information content. Discontinuities >> in the monotonically increasing value normally occur at re- >> initialization of the management system, and at other times as >> specified in the description of an object-type using this >>ASN.1 type. >> If such other times can occur, for example, the creation >>of an object >> instance at times other than re-initialization, then a >>corresponding >> object should be defined, with an appropriate SYNTAX clause, to >> indicate the last discontinuity. Examples of appropriate SYNTAX >> clause include: TimeStamp (a textual convention defined in [3]), >> DateAndTime (another textual convention from [3]) or TimeTicks. >> >>RFC4181 Section 4.6.1.2 (1st bullet): >> >> - It is OK to use Counter32/64 for counters that may/will be reset >> when the management subsystem is re-initialized or when other >> unusual/irregular events occur (e.g., counters >>maintained on a line >> card may be reset when the line card is reset). >>However, if it is >> possible for such other unusual/irregular events to occur, the >> DESCRIPTION clause MUST state that this is so and MUST describe >> those other unusual/irregular events in sufficient detail that it >> is possible for a management application to determine whether a >> reset has occurred since the last time the counter was >>polled. The >> RECOMMENDED way to do this is to provide a discontinuity >>indicator >> as described in RFC 2578 Sections 7.1.6 and 7.1.10. For >>an example >> of such a discontinuity indicator, see the >> ifCounterDiscontinuityTime object in the IF-MIB [RFC2863]. >> >>So I take it that the normal wrapping from maximum value to >>zero is OK, >>and reset upon system (re)initialization is OK, but any other >>"discontinuity" needs special attention. Is that right? >> > > Yes, and that is why I had a very simple solution proposed later in > my review message. By adding that sentence, we make it clear that > we have thought about this and that such is indeed the case (assuming > that I got it right). By not saying anything about it, it could > be an unintended omission. > Ok, I will add a sentence the overview section to mention this. I believe this is better than in the MIB itself to avoid repeating the same for each object again. Also the reference to the IANA copy-right web page will be removed. thanks, Stefaan > >>> So, the radiusDynAuthClientAddress needs to specify that >> >>the address >>is >> >>> formatted according to the value of >> >>radiusDynAuthClientAddressType. >> >>> Also, as far as I can tell, any addressType could be present here, >>> so formally, you would need to describe when a dns name has been >>> resolved (if it occurs). >> >>RADIUS normally deals with IP Addresses, as the RADIUS client needs to >>be registered with the RADIUS Server by IP Address, so that >>the correct >>shared secret can be used. It is possible to use DNS with RADIUS >>clients and servers, if sufficient care is taken to always have an >>accurate inverse name resolution available, but I believe this is not >>common practice. >> > > > I think that answer is suffient for me. > > Bert > > -- > to unsubscribe send a message to radiusext-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 07 Mar 2006 15:42:20 +0000 Message-ID: From: "Bernard Aboba" To: radiusext@ops.ietf.org Bcc: Subject: Request for review of RADIUS Digest -07 Document Date: Tue, 07 Mar 2006 07:41:37 -0800 Mime-Version: 1.0 Content-Type: text/plain; format=flowed A new version of the RADIUS Digest document has been submitted in response to IETF last call and IESG DISCUSS comments. Until the specification ends up on the archive, it is available here: http://www.drizzle.com/~aboba/RADEXT/draft-ietf-radext-digest-auth-07.txt When it ends up on the archive, it will be available here: http://www.ietf.org/internet-drafts/draft-ietf-radext-digest-auth-07.txt Please examine this new version of the document to see whether it addresses the open issues, which were filed on the RADEXT WG issues list: http://www.drizzle.com/~aboba/RADEXT/ These include the following: Issue # Title Owner ---------- ------------------------- ---------------------- 150 IANA Considerations John Loughney 151 Another review Kurt Zeilenga 152 Review Alexey Melnikov 159 Negotiation Wolfgang Beck 162 Nonce Replay Issue Wolfgang Beck 173 Client Nonce Generation Sam Hartman 174 Review Russ Housley 175 Some NITs Bert Wijnen In particular, the following questions should have been addressed: * Handling of client/server nonce generation (comments from Sam Hartman, Glen Zorn and others) * Extensibility for new algorithms (Russ Housley) * Editorial comments (many) -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 07 Mar 2006 09:06:42 +0000 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B155097B8E3A@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "Nagi Reddy Jonnala (njonnala)" , "Romascanu, Dan (Dan)" , "Nelson, David" , radiusext@ops.ietf.org Cc: "Wijnen, Bert (Bert)" Subject: RE: radius dynauth client/server mibs structure Date: Tue, 7 Mar 2006 06:31:15 +0100 MIME-Version: 1.0 Content-Type: text/plain I think, that I suggested that the doc could get a new revision after the telechat (so during the week of IETF) and then it could get approved. We prefer to not let RFC-Editor make these type of changes. RFC-Editor DOES do MIB SYNTAX check though, but they do not check if the resuling OID tree is as we expect it to be. Bert > -----Original Message----- > From: Nagi Reddy Jonnala (njonnala) [mailto:njonnala@cisco.com] > Sent: Tuesday, March 07, 2006 05:42 > To: Romascanu, Dan (Dan); Nelson, David; radiusext@ops.ietf.org > Cc: Wijnen, Bert (Bert) > Subject: RE: radius dynauth client/server mibs structure > > > Agree with Dan. Assume that there would be a trigger to the > authors when > these changes are made to re-check the syntax. > > Thanks > Nagi > > -----Original Message----- > From: owner-radiusext@ops.ietf.org > [mailto:owner-radiusext@ops.ietf.org] > On Behalf Of Romascanu, Dan (Dan) > Sent: Tuesday, March 07, 2006 2:24 AM > To: Nelson, David; radiusext@ops.ietf.org > Cc: Wijnen, Bert (Bert) > Subject: RE: radius dynauth client/server mibs structure > > I have no objection, but I am slightly uneasy with changes in the MIB > module being made by the RFC Editor. Maybe they are checking > the syntax > as well, but to be on the safe side I recommend that after > the change is > performed the authors extract the MIB text from the draft > submitted for > verification by the RFC Editor and re-check the syntax using the > recommended tools. > > Regards, > > Dan > > > > > > > -----Original Message----- > > From: owner-radiusext@ops.ietf.org > > [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Nelson, David > > Sent: Monday, March 06, 2006 10:45 PM > > To: radiusext@ops.ietf.org > > Cc: Wijnen, Bert (Bert) > > Subject: RE: radius dynauth client/server mibs structure > > > > Bert Wijnen writes... > > > > (Suggesting a mechanism for addressing the comments from Juergen > > Schoenwalder and himself.) > > > > > Let me see, the RFC-Editor note (for each MIB) would read > something > > aka > > > > > > OLD: > > > radiusDynAuthServerMIBObjects OBJECT IDENTIFIER ::= > > > { > > radiusDynAuthServerMIB 1 } > > > > > > radiusDynAuthServer OBJECT IDENTIFIER ::= > > > { > > radiusDynAuthServerMIBObjects 1 } > > > > > > radiusDynAuthServerDisconInvalidClientAddresses OBJECT-TYPE > > > SYNTAX Counter32 > > > MAX-ACCESS read-only > > > STATUS current > > > DESCRIPTION > > > "The number of Disconnect-Request packets > > received from > > > unknown addresses." > > > ::= { radiusDynAuthServer 1 } > > > > > > radiusDynAuthServerCoAInvalidClientAddresses OBJECT-TYPE > > > SYNTAX Counter32 > > > MAX-ACCESS read-only > > > STATUS current > > > DESCRIPTION > > > "The number of CoA-Request packets received from > > unknown > > > addresses." > > > ::= { radiusDynAuthServer 2 } > > > > > > radiusDynAuthServerIdentifier OBJECT-TYPE > > > SYNTAX SnmpAdminString > > > MAX-ACCESS read-only > > > STATUS current > > > DESCRIPTION > > > "The NAS-Identifier of the RADIUS Dynamic > > Authorization > > > Server. This is not necessarily the same > as sysName > > in > > > MIB II." > > > REFERENCE > > > "RFC 2865, Section 5.32, NAS-Identifier." > > > ::= { radiusDynAuthServer 3 } > > > > > > radiusDynAuthClientTable OBJECT-TYPE > > > SYNTAX SEQUENCE OF RadiusDynAuthClientEntry > > > MAX-ACCESS not-accessible > > > STATUS current > > > DESCRIPTION > > > "The (conceptual) table listing the RADIUS Dynamic > > > Authorization Clients with which the > server shares a > > > secret." > > > ::= { radiusDynAuthServer 4 } > > > > > > NEW: > > > radiusDynAuthServerMIBObjects OBJECT IDENTIFIER ::= > > > { > > radiusDynAuthServerMIB 1 } > > > > > > > radiusDynAuthServerScalars OBJECT IDENTIFIER ::= > > > { > > radiusDynAuthServerMIBObjects 1 } > > > > > > radiusDynAuthServerDisconInvalidClientAddresses OBJECT-TYPE > > > SYNTAX Counter32 > > > MAX-ACCESS read-only > > > STATUS current > > > DESCRIPTION > > > "The number of Disconnect-Request packets > > received from > > > unknown addresses." > > > > ::= { radiusDynAuthServerScalars 1 } > > > > > > radiusDynAuthServerCoAInvalidClientAddresses OBJECT-TYPE > > > SYNTAX Counter32 > > > MAX-ACCESS read-only > > > STATUS current > > > DESCRIPTION > > > "The number of CoA-Request packets received from > > unknown > > > addresses." > > > > ::= { radiusDynAuthServerScalars 2 } > > > > > > radiusDynAuthServerIdentifier OBJECT-TYPE > > > SYNTAX SnmpAdminString > > > MAX-ACCESS read-only > > > STATUS current > > > DESCRIPTION > > > "The NAS-Identifier of the RADIUS Dynamic > > Authorization > > > Server. This is not necessarily the same > as sysName > > in > > > MIB II." > > > REFERENCE > > > "RFC 2865, Section 5.32, NAS-Identifier." > > > > ::= { radiusDynAuthServerScalars 3 } > > > > > > radiusDynAuthClientTable OBJECT-TYPE > > > SYNTAX SEQUENCE OF RadiusDynAuthClientEntry > > > MAX-ACCESS not-accessible > > > STATUS current > > > DESCRIPTION > > > "The (conceptual) table listing the RADIUS Dynamic > > > Authorization Clients with which the > server shares a > > > secret." > > > > ::= { radiusDynAuthServerMIBObjects 2 } > > > > It has been noted that this is a simple change to make > before issuing > > the RFC, and before there are implementations in the field. > > > > Is there any objection among the members of the WG to resolving the > > O&M Area Directorate comments on these documents, as shown? > > > > Upon hearing no objections, the changes will be applied. > > Please respond prior to March 16 (the IESG Telechat at which these > > documents are likely to be discussed). > > > > > > -- > > to unsubscribe send a message to > > radiusext-request@ops.ietf.org with the word 'unsubscribe' > in a single > > > line as the message text body. > > archive: > > > > -- > to unsubscribe send a message to radiusext-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: > -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 07 Mar 2006 04:42:48 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: radius dynauth client/server mibs structure Date: Tue, 7 Mar 2006 10:12:14 +0530 Message-ID: <61D6551D82BC7149967B39B5C66879F8DB7A0B@xmb-blr-416.apac.cisco.com> Thread-Topic: radius dynauth client/server mibs structure Thread-Index: AcY/FSM7xOYyW4O/SkO0yanpZ1e55gCSHfFgAABh2aAAEG4P8A== From: "Nagi Reddy Jonnala \(njonnala\)" To: "Romascanu, Dan \(Dan\)" , "Nelson, David" , Cc: "Wijnen, Bert \(Bert\)" Agree with Dan. Assume that there would be a trigger to the authors when these changes are made to re-check the syntax. Thanks Nagi -----Original Message----- From: owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Romascanu, Dan (Dan) Sent: Tuesday, March 07, 2006 2:24 AM To: Nelson, David; radiusext@ops.ietf.org Cc: Wijnen, Bert (Bert) Subject: RE: radius dynauth client/server mibs structure I have no objection, but I am slightly uneasy with changes in the MIB module being made by the RFC Editor. Maybe they are checking the syntax as well, but to be on the safe side I recommend that after the change is performed the authors extract the MIB text from the draft submitted for verification by the RFC Editor and re-check the syntax using the recommended tools.=20 Regards, Dan =20 =20 > -----Original Message----- > From: owner-radiusext@ops.ietf.org > [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Nelson, David > Sent: Monday, March 06, 2006 10:45 PM > To: radiusext@ops.ietf.org > Cc: Wijnen, Bert (Bert) > Subject: RE: radius dynauth client/server mibs structure >=20 > Bert Wijnen writes... >=20 > (Suggesting a mechanism for addressing the comments from Juergen=20 > Schoenwalder and himself.) >=20 > > Let me see, the RFC-Editor note (for each MIB) would read something > aka > >=20 > > OLD: > > radiusDynAuthServerMIBObjects OBJECT IDENTIFIER ::=3D > > { > radiusDynAuthServerMIB 1 } > >=20 > > radiusDynAuthServer OBJECT IDENTIFIER ::=3D > > { > radiusDynAuthServerMIBObjects 1 } > >=20 > > radiusDynAuthServerDisconInvalidClientAddresses OBJECT-TYPE > > SYNTAX Counter32 > > MAX-ACCESS read-only > > STATUS current > > DESCRIPTION > > "The number of Disconnect-Request packets > received from > > unknown addresses." > > ::=3D { radiusDynAuthServer 1 } > >=20 > > radiusDynAuthServerCoAInvalidClientAddresses OBJECT-TYPE > > SYNTAX Counter32 > > MAX-ACCESS read-only > > STATUS current > > DESCRIPTION > > "The number of CoA-Request packets received from > unknown > > addresses." > > ::=3D { radiusDynAuthServer 2 } > >=20 > > radiusDynAuthServerIdentifier OBJECT-TYPE > > SYNTAX SnmpAdminString > > MAX-ACCESS read-only > > STATUS current > > DESCRIPTION > > "The NAS-Identifier of the RADIUS Dynamic > Authorization > > Server. This is not necessarily the same as sysName > in > > MIB II." > > REFERENCE > > "RFC 2865, Section 5.32, NAS-Identifier." > > ::=3D { radiusDynAuthServer 3 } > >=20 > > radiusDynAuthClientTable OBJECT-TYPE > > SYNTAX SEQUENCE OF RadiusDynAuthClientEntry > > MAX-ACCESS not-accessible > > STATUS current > > DESCRIPTION > > "The (conceptual) table listing the RADIUS Dynamic > > Authorization Clients with which the server shares a > > secret." > > ::=3D { radiusDynAuthServer 4 } > >=20 > > NEW: > > radiusDynAuthServerMIBObjects OBJECT IDENTIFIER ::=3D > > { > radiusDynAuthServerMIB 1 } > >=20 > > > radiusDynAuthServerScalars OBJECT IDENTIFIER ::=3D > > { > radiusDynAuthServerMIBObjects 1 } > >=20 > > radiusDynAuthServerDisconInvalidClientAddresses OBJECT-TYPE > > SYNTAX Counter32 > > MAX-ACCESS read-only > > STATUS current > > DESCRIPTION > > "The number of Disconnect-Request packets > received from > > unknown addresses." > > > ::=3D { radiusDynAuthServerScalars 1 } > >=20 > > radiusDynAuthServerCoAInvalidClientAddresses OBJECT-TYPE > > SYNTAX Counter32 > > MAX-ACCESS read-only > > STATUS current > > DESCRIPTION > > "The number of CoA-Request packets received from > unknown > > addresses." > > > ::=3D { radiusDynAuthServerScalars 2 } > >=20 > > radiusDynAuthServerIdentifier OBJECT-TYPE > > SYNTAX SnmpAdminString > > MAX-ACCESS read-only > > STATUS current > > DESCRIPTION > > "The NAS-Identifier of the RADIUS Dynamic > Authorization > > Server. This is not necessarily the same as sysName > in > > MIB II." > > REFERENCE > > "RFC 2865, Section 5.32, NAS-Identifier." > > > ::=3D { radiusDynAuthServerScalars 3 } > >=20 > > radiusDynAuthClientTable OBJECT-TYPE > > SYNTAX SEQUENCE OF RadiusDynAuthClientEntry > > MAX-ACCESS not-accessible > > STATUS current > > DESCRIPTION > > "The (conceptual) table listing the RADIUS Dynamic > > Authorization Clients with which the server shares a > > secret." > > > ::=3D { radiusDynAuthServerMIBObjects 2 } >=20 > It has been noted that this is a simple change to make before issuing=20 > the RFC, and before there are implementations in the field. >=20 > Is there any objection among the members of the WG to resolving the=20 > O&M Area Directorate comments on these documents, as shown? >=20 > Upon hearing no objections, the changes will be applied. =20 > Please respond prior to March 16 (the IESG Telechat at which these=20 > documents are likely to be discussed). >=20 >=20 > -- > to unsubscribe send a message to > radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single > line as the message text body. > archive: >=20 -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Mon, 06 Mar 2006 21:23:26 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: radius dynauth client/server mibs structure Date: Mon, 6 Mar 2006 16:23:18 -0500 Message-ID: <3CFB564E055A594B82C4FE89D21565602190E7@MABOSEVS2.ets.enterasys.com> Thread-Topic: radius dynauth client/server mibs structure Thread-Index: AcZBY69pPCiwvQfZRrGWgTiYH7OTLQAACIJg From: "Nelson, David" To: Cc: , "Wijnen, Bert \(Bert\)" Juergen Schoenwaelder writes... =20 > I find the OLD / NEW format extremey difficult to read. > I assume this is what your OLD/NEW editing instructions try to achieve > for the server MIB. The RFC Editor has its own preferences for readability, which dictate the OLD/NEW format. YMMV. :-) -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Mon, 06 Mar 2006 21:19:42 +0000 Date: Mon, 6 Mar 2006 22:20:24 +0100 From: Juergen Schoenwaelder To: "Nelson, David" Cc: radiusext@ops.ietf.org, "Wijnen, Bert (Bert)" Subject: Re: radius dynauth client/server mibs structure Message-ID: <20060306212024.GC2594@boskop.local> Reply-To: j.schoenwaelder@iu-bremen.de Mail-Followup-To: "Nelson, David" , radiusext@ops.ietf.org, "Wijnen, Bert (Bert)" Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.10i On Mon, Mar 06, 2006 at 03:44:37PM -0500, Nelson, David wrote: > (Suggesting a mechanism for addressing the comments from Juergen > Schoenwalder and himself.) [...] I find the OLD / NEW format extremey difficult to read. The change being discussed I think is the following (good old unified context diff format): --- RADIUS-DYNAUTH-CLIENT-MIB 2006-03-06 22:10:08.000000000 +0100 +++ RADIUS-DYNAUTH-CLIENT-MIB.new 2006-03-06 22:14:00.000000000 +0100 @@ -63,7 +63,7 @@ radiusDynAuthClientMIBObjects OBJECT IDENTIFIER ::= { radiusDynAuthClientMIB 1 } -radiusDynAuthClient OBJECT IDENTIFIER ::= +radiusDynAuthClientScalars OBJECT IDENTIFIER ::= { radiusDynAuthClientMIBObjects 1 } radiusDynAuthClientDisconInvalidServerAddresses OBJECT-TYPE @@ -73,7 +73,7 @@ DESCRIPTION "The number of Disconnect-Ack and Disconnect-NAK packets received from unknown addresses." - ::= { radiusDynAuthClient 1 } + ::= { radiusDynAuthClientScalars 1 } radiusDynAuthClientCoAInvalidServerAddresses OBJECT-TYPE SYNTAX Counter32 @@ -82,7 +82,7 @@ DESCRIPTION "The number of CoA-Ack and CoA-NAK packets received from unknown addresses." - ::= { radiusDynAuthClient 2 } + ::= { radiusDynAuthClientScalars 2 } radiusDynAuthServerTable OBJECT-TYPE SYNTAX SEQUENCE OF RadiusDynAuthServerEntry @@ -92,7 +92,7 @@ "The (conceptual) table listing the RADIUS Dynamic Authorization Servers with which the client shares a secret." - ::= { radiusDynAuthClient 3 } + ::= { radiusDynAuthClientMIBObjects 2 } radiusDynAuthServerEntry OBJECT-TYPE --- RADIUS-DYNAUTH-SERVER-MIB 2006-03-06 22:11:08.000000000 +0100 +++ RADIUS-DYNAUTH-SERVER-MIB.new 2006-03-06 22:13:48.000000000 +0100 @@ -62,7 +62,7 @@ radiusDynAuthServerMIBObjects OBJECT IDENTIFIER ::= { radiusDynAuthServerMIB 1 } -radiusDynAuthServer OBJECT IDENTIFIER ::= +radiusDynAuthServerScalars OBJECT IDENTIFIER ::= { radiusDynAuthServerMIBObjects 1 } radiusDynAuthServerDisconInvalidClientAddresses OBJECT-TYPE @@ -72,7 +72,7 @@ DESCRIPTION "The number of Disconnect-Request packets received from unknown addresses." - ::= { radiusDynAuthServer 1 } + ::= { radiusDynAuthServerScalars 1 } radiusDynAuthServerCoAInvalidClientAddresses OBJECT-TYPE SYNTAX Counter32 @@ -81,7 +81,7 @@ DESCRIPTION "The number of CoA-Request packets received from unknown addresses." - ::= { radiusDynAuthServer 2 } + ::= { radiusDynAuthServerScalars 2 } radiusDynAuthServerIdentifier OBJECT-TYPE SYNTAX SnmpAdminString @@ -93,7 +93,7 @@ MIB II." REFERENCE "RFC 2865, Section 5.32, NAS-Identifier." - ::= { radiusDynAuthServer 3 } + ::= { radiusDynAuthServerScalars 3 } @@ -106,7 +106,7 @@ "The (conceptual) table listing the RADIUS Dynamic Authorization Clients with which the server shares a secret." - ::= { radiusDynAuthServer 4 } + ::= { radiusDynAuthServerMIBObjects 2 } radiusDynAuthClientEntry OBJECT-TYPE SYNTAX RadiusDynAuthClientEntry I assume this is what your OLD/NEW editing instructions try to achieve for the server MIB. /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Mon, 06 Mar 2006 20:54:08 +0000 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: radius dynauth client/server mibs structure Date: Mon, 6 Mar 2006 22:53:57 +0200 Message-ID: Thread-Topic: radius dynauth client/server mibs structure Thread-Index: AcY/FSM7xOYyW4O/SkO0yanpZ1e55gCSHfFgAABh2aA= From: "Romascanu, Dan \(Dan\)" To: "Nelson, David" , Cc: "Wijnen, Bert \(Bert\)" I have no objection, but I am slightly uneasy with changes in the MIB module being made by the RFC Editor. Maybe they are checking the syntax as well, but to be on the safe side I recommend that after the change is performed the authors extract the MIB text from the draft submitted for verification by the RFC Editor and re-check the syntax using the recommended tools.=20 Regards, Dan =20 =20 > -----Original Message----- > From: owner-radiusext@ops.ietf.org=20 > [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Nelson, David > Sent: Monday, March 06, 2006 10:45 PM > To: radiusext@ops.ietf.org > Cc: Wijnen, Bert (Bert) > Subject: RE: radius dynauth client/server mibs structure >=20 > Bert Wijnen writes... >=20 > (Suggesting a mechanism for addressing the comments from=20 > Juergen Schoenwalder and himself.) >=20 > > Let me see, the RFC-Editor note (for each MIB) would read something > aka > >=20 > > OLD: > > radiusDynAuthServerMIBObjects OBJECT IDENTIFIER ::=3D > > {=20 > radiusDynAuthServerMIB 1 } > >=20 > > radiusDynAuthServer OBJECT IDENTIFIER ::=3D > > {=20 > radiusDynAuthServerMIBObjects 1 } > >=20 > > radiusDynAuthServerDisconInvalidClientAddresses OBJECT-TYPE > > SYNTAX Counter32 > > MAX-ACCESS read-only > > STATUS current > > DESCRIPTION > > "The number of Disconnect-Request packets=20 > received from > > unknown addresses." > > ::=3D { radiusDynAuthServer 1 } > >=20 > > radiusDynAuthServerCoAInvalidClientAddresses OBJECT-TYPE > > SYNTAX Counter32 > > MAX-ACCESS read-only > > STATUS current > > DESCRIPTION > > "The number of CoA-Request packets received from > unknown > > addresses." > > ::=3D { radiusDynAuthServer 2 } > >=20 > > radiusDynAuthServerIdentifier OBJECT-TYPE > > SYNTAX SnmpAdminString > > MAX-ACCESS read-only > > STATUS current > > DESCRIPTION > > "The NAS-Identifier of the RADIUS Dynamic > Authorization > > Server. This is not necessarily the same as sysName > in > > MIB II." > > REFERENCE > > "RFC 2865, Section 5.32, NAS-Identifier." > > ::=3D { radiusDynAuthServer 3 } > >=20 > > radiusDynAuthClientTable OBJECT-TYPE > > SYNTAX SEQUENCE OF RadiusDynAuthClientEntry > > MAX-ACCESS not-accessible > > STATUS current > > DESCRIPTION > > "The (conceptual) table listing the RADIUS Dynamic > > Authorization Clients with which the server shares a > > secret." > > ::=3D { radiusDynAuthServer 4 } > >=20 > > NEW: > > radiusDynAuthServerMIBObjects OBJECT IDENTIFIER ::=3D > > {=20 > radiusDynAuthServerMIB 1 } > >=20 > > > radiusDynAuthServerScalars OBJECT IDENTIFIER ::=3D > > {=20 > radiusDynAuthServerMIBObjects 1 } > >=20 > > radiusDynAuthServerDisconInvalidClientAddresses OBJECT-TYPE > > SYNTAX Counter32 > > MAX-ACCESS read-only > > STATUS current > > DESCRIPTION > > "The number of Disconnect-Request packets=20 > received from > > unknown addresses." > > > ::=3D { radiusDynAuthServerScalars 1 } > >=20 > > radiusDynAuthServerCoAInvalidClientAddresses OBJECT-TYPE > > SYNTAX Counter32 > > MAX-ACCESS read-only > > STATUS current > > DESCRIPTION > > "The number of CoA-Request packets received from > unknown > > addresses." > > > ::=3D { radiusDynAuthServerScalars 2 } > >=20 > > radiusDynAuthServerIdentifier OBJECT-TYPE > > SYNTAX SnmpAdminString > > MAX-ACCESS read-only > > STATUS current > > DESCRIPTION > > "The NAS-Identifier of the RADIUS Dynamic > Authorization > > Server. This is not necessarily the same as sysName > in > > MIB II." > > REFERENCE > > "RFC 2865, Section 5.32, NAS-Identifier." > > > ::=3D { radiusDynAuthServerScalars 3 } > >=20 > > radiusDynAuthClientTable OBJECT-TYPE > > SYNTAX SEQUENCE OF RadiusDynAuthClientEntry > > MAX-ACCESS not-accessible > > STATUS current > > DESCRIPTION > > "The (conceptual) table listing the RADIUS Dynamic > > Authorization Clients with which the server shares a > > secret." > > > ::=3D { radiusDynAuthServerMIBObjects 2 } >=20 > It has been noted that this is a simple change to make before=20 > issuing the RFC, and before there are implementations in the field. >=20 > Is there any objection among the members of the WG to=20 > resolving the O&M Area Directorate comments on these=20 > documents, as shown? >=20 > Upon hearing no objections, the changes will be applied. =20 > Please respond prior to March 16 (the IESG Telechat at which=20 > these documents are likely to be discussed). >=20 >=20 > -- > to unsubscribe send a message to=20 > radiusext-request@ops.ietf.org with the word 'unsubscribe' in=20 > a single line as the message text body. > archive: >=20 -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Mon, 06 Mar 2006 20:44:50 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: radius dynauth client/server mibs structure Date: Mon, 6 Mar 2006 15:44:37 -0500 Message-ID: <3CFB564E055A594B82C4FE89D21565602190E5@MABOSEVS2.ets.enterasys.com> Thread-Topic: radius dynauth client/server mibs structure Thread-Index: AcY/FSM7xOYyW4O/SkO0yanpZ1e55gCSHfFg From: "Nelson, David" To: Cc: "Wijnen, Bert \(Bert\)" Bert Wijnen writes... (Suggesting a mechanism for addressing the comments from Juergen Schoenwalder and himself.) > Let me see, the RFC-Editor note (for each MIB) would read something aka >=20 > OLD: > radiusDynAuthServerMIBObjects OBJECT IDENTIFIER ::=3D > { radiusDynAuthServerMIB 1 } >=20 > radiusDynAuthServer OBJECT IDENTIFIER ::=3D > { radiusDynAuthServerMIBObjects 1 } >=20 > radiusDynAuthServerDisconInvalidClientAddresses OBJECT-TYPE > SYNTAX Counter32 > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "The number of Disconnect-Request packets received from > unknown addresses." > ::=3D { radiusDynAuthServer 1 } >=20 > radiusDynAuthServerCoAInvalidClientAddresses OBJECT-TYPE > SYNTAX Counter32 > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "The number of CoA-Request packets received from unknown > addresses." > ::=3D { radiusDynAuthServer 2 } >=20 > radiusDynAuthServerIdentifier OBJECT-TYPE > SYNTAX SnmpAdminString > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "The NAS-Identifier of the RADIUS Dynamic Authorization > Server. This is not necessarily the same as sysName in > MIB II." > REFERENCE > "RFC 2865, Section 5.32, NAS-Identifier." > ::=3D { radiusDynAuthServer 3 } >=20 > radiusDynAuthClientTable OBJECT-TYPE > SYNTAX SEQUENCE OF RadiusDynAuthClientEntry > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "The (conceptual) table listing the RADIUS Dynamic > Authorization Clients with which the server shares a > secret." > ::=3D { radiusDynAuthServer 4 } >=20 > NEW: > radiusDynAuthServerMIBObjects OBJECT IDENTIFIER ::=3D > { radiusDynAuthServerMIB 1 } >=20 > > radiusDynAuthServerScalars OBJECT IDENTIFIER ::=3D > { radiusDynAuthServerMIBObjects 1 } >=20 > radiusDynAuthServerDisconInvalidClientAddresses OBJECT-TYPE > SYNTAX Counter32 > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "The number of Disconnect-Request packets received from > unknown addresses." > > ::=3D { radiusDynAuthServerScalars 1 } >=20 > radiusDynAuthServerCoAInvalidClientAddresses OBJECT-TYPE > SYNTAX Counter32 > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "The number of CoA-Request packets received from unknown > addresses." > > ::=3D { radiusDynAuthServerScalars 2 } >=20 > radiusDynAuthServerIdentifier OBJECT-TYPE > SYNTAX SnmpAdminString > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "The NAS-Identifier of the RADIUS Dynamic Authorization > Server. This is not necessarily the same as sysName in > MIB II." > REFERENCE > "RFC 2865, Section 5.32, NAS-Identifier." > > ::=3D { radiusDynAuthServerScalars 3 } >=20 > radiusDynAuthClientTable OBJECT-TYPE > SYNTAX SEQUENCE OF RadiusDynAuthClientEntry > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "The (conceptual) table listing the RADIUS Dynamic > Authorization Clients with which the server shares a > secret." > > ::=3D { radiusDynAuthServerMIBObjects 2 } It has been noted that this is a simple change to make before issuing the RFC, and before there are implementations in the field. Is there any objection among the members of the WG to resolving the O&M Area Directorate comments on these documents, as shown? Upon hearing no objections, the changes will be applied. Please respond prior to March 16 (the IESG Telechat at which these documents are likely to be discussed). -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Mon, 06 Mar 2006 20:35:31 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: AD review: radius dynauth client/server mib documents Date: Mon, 6 Mar 2006 15:35:00 -0500 Message-ID: <3CFB564E055A594B82C4FE89D21565602190E4@MABOSEVS2.ets.enterasys.com> Thread-Topic: AD review: radius dynauth client/server mib documents Thread-Index: AcY+2/Q+Brbid62MRoCc0LMyIwlXcQCgMTfg From: "Nelson, David" To: Cc: "Wijnen, Bert \(Bert\)" Bert Wijnen writes... > Yes, and that is why I had a very simple solution proposed later in > my review message. By adding that sentence, we make it clear that > we have thought about this and that such is indeed the case (assuming > that I got it right). By not saying anything about it, it could > be an unintended omission. Is there any objection among the WG members to resolve the AD comment by adding text that clarifies that discontinuities the values of these counters will only occur upon counter wrap from maximum value to zero and upon (re)initialization of the managed entity? Upon hearing no objection, the clarification will be added. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Mon, 06 Mar 2006 18:31:25 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: Issue: Vlan-00 allowing hints in request messages Date: Mon, 6 Mar 2006 10:30:46 -0800 Message-ID: Thread-Topic: Issue: Vlan-00 allowing hints in request messages Thread-Index: AcZBTBW1taflJ88TTYSl1SYu6Yzp2Q== From: "Sanchez, Mauricio (PNB Roseville)" To: Cc: "Bernard Aboba" Submitter name: Mauricio Sanchez Submitter email address: mauricio.sanchez@hp.com Date first submitted: March 6, 2006 Reference:=20 Document: draft-ietf-radext-vlan-00.txt Comment type: T Priority: 2 Section: Table in section 3, individual attributes Rationale/Explanation of issue: Draft-ietf-radext-vlan-00 does not allow the new attributes to be sent in ACCESS-REQUEST messages. If allowed, attributes in the REQUEST message could serve as 'hints' to the RADIUS server during the decision making process.=20 Requested change: Allow attributes to be sent ACCESS-REQUEST message Proposed changes to the document.=20 - Descriptions of individual attribute descriptions would be changed to allow attributes in access request, as follows: Multiple attributes MAY be included in an Access-Request, Access-Accept or CoA-Request packet; this attribute MUST NOT be sent within an Access-Challenge, Access-Reject, Disconnect-Request, Disconnect-ACK, Disconnect-NAK, CoA-ACK, or CoA-NAK. -Table in section 3 would be changed to: Access- Access- Access- Access- CoA- Request Accept Reject Challenge Req # Attribute 0+ 0+ 0 0 0+ TBD Egress-VLANID 0-1 0-1 0 0 0-1 TBD Ingress-Filters 0+ 0+ 0 0 0+ TBD Egress-VLAN-Name 0-1 0-1 0 0 0-1 TBD User-Priority-Table -------------------------------------------- Mauricio Sanchez, CISSP Network Security Architect Procurve Networking Business Hewlett Packard 8000 Foothills Boulevard, ms 5555 Roseville CA, 95747-5557 916.785.1910 Tel 916.785.1815 Fax mauricio.sanchez@hp.com -------------------------------------------- =20 -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 03 Mar 2006 23:23:12 +0000 Message-ID: From: "Bernard Aboba" To: radiusext@ops.ietf.org Bcc: Subject: Update on RADIUS Digest Issues? Date: Fri, 03 Mar 2006 15:22:50 -0800 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Can we get an update on where we are with respect to the open issue on the RADIUS Digest document? The ADs have inquired about where we are and what issues are still open. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 03 Mar 2006 21:27:03 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: [Issue 168] split-out filter draft: IANA Date: Fri, 3 Mar 2006 16:27:58 -0500 Message-ID: <15B86BC7352F864BB53A47B540C089B601464FCD@xmb-rtp-20b.amer.cisco.com> Thread-Topic: [Issue 168] split-out filter draft: IANA Thread-Index: AcY/CVfTb17avNXBTL+4DqfWU5XJSw== From: "Greg Weber \(gdweber\)" To: I see that draft-ietf-radext-filter-rules-00.txt fixes most of the editorial comments I made as part of issue 168. I guess we can close this issue if the authors will just agree to fix this (at some point): - The IANA section says the draft is allocating six attributes, but it's only allocating two. Greg -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 03 Mar 2006 20:38:39 +0000 Message-ID: From: "Bernard Aboba" To: radiusext@ops.ietf.org Bcc: Subject: REMINDER: RADEXT WG Last Call on VLAN and Priority Attributes Document Date: Fri, 03 Mar 2006 12:38:13 -0800 Mime-Version: 1.0 Content-Type: text/plain; format=flowed There is an ongoing RADEXT WG last call on the VLAN and Priority Attributes document, prior to sending it on to the IESG for consideration as a Proposed Standard. The document is available for inspection here: http://www.ietf.org/internet-drafts/draft-ietf-radext-vlan-00.txt RADEXT WG last call will last until Friday, March 17, 2006. Please send your comments to the RADEXT WG mailing list (radext@ops.ietf.org) in the format described on the RADEXT Issues list: http://www.drizzle.com/~aboba/RADEXT/ Since all RADEXT WG last calls require at least 5 reviewers in order to advance the document, please respond indicating that you have read the document and find it acceptable, even if you have no issues to file. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 03 Mar 2006 20:12:55 +0000 Message-ID: From: "Bernard Aboba" To: radiusext@ops.ietf.org Bcc: Subject: RADEXT WG Last Call on "RADIUS Delegated IPv6 Prefix Attribute" Date: Fri, 03 Mar 2006 12:12:43 -0800 Mime-Version: 1.0 Content-Type: text/plain; format=flowed This is an announcement of RADEXT WG last call on the "RADIUS Delegated-IPv6 Prefix Attribute" document, prior to sending this document on to the IESG for consideration as a Proposed Standard. The document is available for inspection here: http://www.ietf.org/internet-drafts/draft-ietf-radext-delegated-prefix-00.txt RADEXT WG last call will last until Monday March 27, 2006. Please send your comments to the RADEXT WG list (radiusext@ops.ietf.org) in the format described on the RADEXT Issues List: http://www.drizzle.com/~aboba/RADEXT/ Since all RADEXT WG last calls require at least 5 reviewers in order to advance the document, please respond indicating that you have read the document and find it acceptable, even if you have no issues to file. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 03 Mar 2006 20:02:53 +0000 Message-ID: From: "Bernard Aboba" To: radiusext@ops.ietf.org Bcc: Subject: RADEXT WG Last Call on "RADIUS Delegated IPv6 Prefix Attribute" Date: Fri, 03 Mar 2006 12:02:14 -0800 Mime-Version: 1.0 Content-Type: text/plain; format=flowed This is an announcement of RADEXT WG last call on the "RADIUS Delegated-IPv6 Prefix Attribute" document, prior to sending this document on to the IESG for consideration as a Proposed Standard. The document is available for inspection here: http://www.ietf.org/internet-drafts/draft-ietf-radext-delegated-prefix-00.txt RADEXT WG last call will last until Monday March 27, 2006. Please send your comments to the RADEXT WG list (radiusext@ops.ietf.org) in the format described on the RADEXT Issues List: http://www.drizzle.com/~aboba/RADEXT/ Since all RADEXT WG last calls require at least 5 reviewers in order to advance the document, please respond indicating that you have read the document and find it acceptable, even if you have no issues to file. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 03 Mar 2006 16:03:18 +0000 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B155097221EA@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "Nelson, David" , "Nagi Reddy Jonnala (njonnala)" , j.schoenwaelder@iu-bremen.de, radiusext@ops.ietf.org Subject: RE: radius dynauth client/server mibs structure Date: Fri, 3 Mar 2006 17:02:47 +0100 MIME-Version: 1.0 Content-Type: text/plain Inline > -----Original Message----- > From: Nelson, David [mailto:dnelson@enterasys.com] > Sent: Friday, March 03, 2006 16:45 > To: Wijnen, Bert (Bert); Nagi Reddy Jonnala (njonnala); > j.schoenwaelder@iu-bremen.de; radiusext@ops.ietf.org > Subject: RE: radius dynauth client/server mibs structure > > > Bert Wijnen writes... > > > The disadvantage of not doing so is in the future when > adding scalars > > and thing not having grouped as nicely and so more complexity. > > In practice, does this inconvenient grouping really affect any SNMP > applications in a user-visible way, except for MIB-walk and > MIB-browser applications? > I know from experience that it made it easier for me to implement the MIB at the agent side. Of course that could have been caused just by my owb design, and other may not have trouble with it at all. I am somewhat less familiar with mgmt apps. > > This is not a blocking comment, just another MIB-type person believing > > that the change would be real EASY now, and it will certainly make > > things cleaner/easier in the future. > > It certainly makes the MIB _document_ neater. > And rigth now (at FIRST or INITIAL version) it is EASY to make the change to make something neat. Later you cannot correct it without possibly deprecating/obsoleteing existing and adding new objects. Oh well. Bert -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 03 Mar 2006 16:03:12 +0000 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B155097221E9@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "Nelson, David" , radiusext@ops.ietf.org Subject: RE: AD review: radius dynauth client/server mib documents Date: Fri, 3 Mar 2006 17:02:47 +0100 MIME-Version: 1.0 Content-Type: text/plain Inline > -----Original Message----- > From: Nelson, David [mailto:dnelson@enterasys.com] > Sent: Friday, March 03, 2006 16:40 > To: Wijnen, Bert (Bert); radiusext@ops.ietf.org > Subject: RE: AD review: radius dynauth client/server mib documents > > > Bert Wijnen writes... > > > 2. The a whole serioes of Counter32 objects. > > I wonder what the object is to indicate a counter-discontinuity? > > Or can such only happen at system restart/reboot? > > See RFC2578 that explains this in sect 7.1.6 > > RFC4181, sect 4.6.1.2 (1st bullet) also speaks to it. > > RFC2578 Section 7.1.6: > > The Counter32 type represents a non-negative integer which > monotonically increases until it reaches a maximum value of 2^32-1 > (4294967295 decimal), when it wraps around and starts increasing > again from zero. > > Counters have no defined "initial" value, and thus, a > single value of > a Counter has (in general) no information content. Discontinuities > in the monotonically increasing value normally occur at re- > initialization of the management system, and at other times as > specified in the description of an object-type using this > ASN.1 type. > If such other times can occur, for example, the creation > of an object > instance at times other than re-initialization, then a > corresponding > object should be defined, with an appropriate SYNTAX clause, to > indicate the last discontinuity. Examples of appropriate SYNTAX > clause include: TimeStamp (a textual convention defined in [3]), > DateAndTime (another textual convention from [3]) or TimeTicks. > > RFC4181 Section 4.6.1.2 (1st bullet): > > - It is OK to use Counter32/64 for counters that may/will be reset > when the management subsystem is re-initialized or when other > unusual/irregular events occur (e.g., counters > maintained on a line > card may be reset when the line card is reset). > However, if it is > possible for such other unusual/irregular events to occur, the > DESCRIPTION clause MUST state that this is so and MUST describe > those other unusual/irregular events in sufficient detail that it > is possible for a management application to determine whether a > reset has occurred since the last time the counter was > polled. The > RECOMMENDED way to do this is to provide a discontinuity > indicator > as described in RFC 2578 Sections 7.1.6 and 7.1.10. For > an example > of such a discontinuity indicator, see the > ifCounterDiscontinuityTime object in the IF-MIB [RFC2863]. > > So I take it that the normal wrapping from maximum value to > zero is OK, > and reset upon system (re)initialization is OK, but any other > "discontinuity" needs special attention. Is that right? > Yes, and that is why I had a very simple solution proposed later in my review message. By adding that sentence, we make it clear that we have thought about this and that such is indeed the case (assuming that I got it right). By not saying anything about it, it could be an unintended omission. > > So, the radiusDynAuthClientAddress needs to specify that > the address > is > > formatted according to the value of > radiusDynAuthClientAddressType. > > Also, as far as I can tell, any addressType could be present here, > > so formally, you would need to describe when a dns name has been > > resolved (if it occurs). > > RADIUS normally deals with IP Addresses, as the RADIUS client needs to > be registered with the RADIUS Server by IP Address, so that > the correct > shared secret can be used. It is possible to use DNS with RADIUS > clients and servers, if sufficient care is taken to always have an > accurate inverse name resolution available, but I believe this is not > common practice. > I think that answer is suffient for me. Bert -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 03 Mar 2006 15:44:47 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: radius dynauth client/server mibs structure Date: Fri, 3 Mar 2006 10:44:41 -0500 Message-ID: <3CFB564E055A594B82C4FE89D21565602190D1@MABOSEVS2.ets.enterasys.com> Thread-Topic: radius dynauth client/server mibs structure thread-index: AcY+0DSXD0oR9cZ8SgKNK7KO8pTe3AACKYzg From: "Nelson, David" To: "Wijnen, Bert \(Bert\)" , "Nagi Reddy Jonnala \(njonnala\)" , , Bert Wijnen writes... > The disadvantage of not doing so is in the future when adding scalars > and thing not having grouped as nicely and so more complexity. In practice, does this inconvenient grouping really affect any SNMP applications in a user-visible way, except for MIB-walk and MIB-browser applications? > This is not a blocking comment, just another MIB-type person believing > that the change would be real EASY now, and it will certainly make > things cleaner/easier in the future. It certainly makes the MIB _document_ neater. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 03 Mar 2006 15:40:40 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: AD review: radius dynauth client/server mib documents Date: Fri, 3 Mar 2006 10:40:20 -0500 Message-ID: <3CFB564E055A594B82C4FE89D21565602190D0@MABOSEVS2.ets.enterasys.com> Thread-Topic: AD review: radius dynauth client/server mib documents thread-index: AcY+1VNifSBujJg4SviB198pBTVEzwAAZzXQ From: "Nelson, David" To: "Wijnen, Bert \(Bert\)" , Bert Wijnen writes... > 2. The a whole serioes of Counter32 objects. > I wonder what the object is to indicate a counter-discontinuity? > Or can such only happen at system restart/reboot? > See RFC2578 that explains this in sect 7.1.6 > RFC4181, sect 4.6.1.2 (1st bullet) also speaks to it. RFC2578 Section 7.1.6: The Counter32 type represents a non-negative integer which monotonically increases until it reaches a maximum value of 2^32-1 (4294967295 decimal), when it wraps around and starts increasing again from zero. Counters have no defined "initial" value, and thus, a single value of a Counter has (in general) no information content. Discontinuities in the monotonically increasing value normally occur at re- initialization of the management system, and at other times as specified in the description of an object-type using this ASN.1 type. If such other times can occur, for example, the creation of an object instance at times other than re-initialization, then a corresponding object should be defined, with an appropriate SYNTAX clause, to indicate the last discontinuity. Examples of appropriate SYNTAX clause include: TimeStamp (a textual convention defined in [3]), DateAndTime (another textual convention from [3]) or TimeTicks. RFC4181 Section 4.6.1.2 (1st bullet): - It is OK to use Counter32/64 for counters that may/will be reset when the management subsystem is re-initialized or when other unusual/irregular events occur (e.g., counters maintained on a line card may be reset when the line card is reset). However, if it is possible for such other unusual/irregular events to occur, the DESCRIPTION clause MUST state that this is so and MUST describe those other unusual/irregular events in sufficient detail that it is possible for a management application to determine whether a reset has occurred since the last time the counter was polled. The RECOMMENDED way to do this is to provide a discontinuity indicator as described in RFC 2578 Sections 7.1.6 and 7.1.10. For an example of such a discontinuity indicator, see the ifCounterDiscontinuityTime object in the IF-MIB [RFC2863]. So I take it that the normal wrapping from maximum value to zero is OK, and reset upon system (re)initialization is OK, but any other "discontinuity" needs special attention. Is that right?=20 > So, the radiusDynAuthClientAddress needs to specify that the address is > formatted according to the value of radiusDynAuthClientAddressType. > Also, as far as I can tell, any addressType could be present here, > so formally, you would need to describe when a dns name has been > resolved (if it occurs). RADIUS normally deals with IP Addresses, as the RADIUS client needs to be registered with the RADIUS Server by IP Address, so that the correct shared secret can be used. It is possible to use DNS with RADIUS clients and servers, if sufficient care is taken to always have an accurate inverse name resolution available, but I believe this is not common practice. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 03 Mar 2006 15:14:45 +0000 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B155097221C8@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: radiusext@ops.ietf.org Subject: AD review: radius dynauth client/server mib documents Date: Fri, 3 Mar 2006 16:13:49 +0100 MIME-Version: 1.0 Content-Type: text/plain 1. In the MIB MODULE IDENTITY DESCRIPTION clause it says: DESCRIPTION "The MIB module for entities implementing the server side of the Dynamic Authorization Extensions to Remote Authentication Dial In User Service (RADIUS) protocol. Copyright (C) The Internet Society (2005). Initial version as published in RFC yyyy; for full legal notices see the RFC itself. Supplementary information may be available on http://www.ietf.org/copyrights/ianamib.html." That last sentence is NOT applicable. There is nothing in this MIB module that is mainatined by IANA, so their copy-right web page is not relevant. Fix is to just remove last sentence. 2. The a whole serioes of Counter32 objects. I wonder what the object is to indicate a counter-discontinuity? Or can such only happen at system restart/reboot? See RFC2578 that explains this in sect 7.1.6 RFC4181, sect 4.6.1.2 (1st bullet) also speaks to it. 3. I see radiusDynAuthClientAddressType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS read-only STATUS current DESCRIPTION "The type of IP address of the RADIUS Dynamic Authorization Client referred to in this table entry." ::= { radiusDynAuthClientEntry 2 } radiusDynAuthClientAddress OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS read-only STATUS current DESCRIPTION "The IP address value of the RADIUS Dynamic Authorization Client referred to in this table entry, using the version neutral IP address format." ::= { radiusDynAuthClientEntry 3 } So, the radiusDynAuthClientAddress needs to specify that the address is formatted according to the value of radiusDynAuthClientAddressType. Also, as far as I can tell, any addressType could be present here, so formally, you would need to describe when a dns name has been resolved (if it occurs). Same for both MIB documents. Point 1 I can do with an RFC-Editor note. Point 2 I can also address with an RFC-Editor not if the intend (default) is that a dsiscuntinuity can only occur at system re-initiatlization. If so, I suggest to add an entry to the DESCRIPTION clause of the table itself that states: Discontinuities for all counter32 objects in this table can only occur at system re-initialization. So no specific discontinuity onjects have been defined. Point 3 Mmm... I guess there will only be ipv4 or ipv6 addresses. If so, I can live with it since this is a read-only MIB module and the doc is Informational. Bert > -----Original Message----- > From: Wijnen, Bert (Bert) > Sent: Friday, March 03, 2006 15:36 > To: 'Nagi Reddy Jonnala (njonnala)'; j.schoenwaelder@iu-bremen.de; > radiusext@ops.ietf.org > Subject: RE: radius dynauth client/server mibs structure > > > Are there implementations already? > If not, I would also recommend to make the change suggested > by Juergen. > If yes, even then the suggested change is still simple now. > > The disadvantage of not doing so is in the future when adding scalars > and thing not having grouped as nicely and so more complexity. > > This is not a blocking comment, just another MIB-type person believing > that the change would be real EASY now, and it will certainly make > things cleaner/easier in the future. > > Bert > > > -----Original Message----- > > From: Nagi Reddy Jonnala (njonnala) [mailto:njonnala@cisco.com] > > Sent: Tuesday, February 14, 2006 11:24 > > To: j.schoenwaelder@iu-bremen.de; radiusext@ops.ietf.org > > Cc: Bert Wijnen > > Subject: RE: radius dynauth client/server mibs structure > > > > > > Juergen, > > > > Your comments may be correct. We authors have discussed about your > > comments and realized that the comments are not directly related to > > these MIBs but in general whether the scalars should be > > grouped together > > or not. The recommended way can best be addressed in the IETF MIB > > guidelines. Since there seem to be plenty of MIBs that don't > > follow your > > commented approach, no recommended way in the IETF MIB > guidelines and > > because it is a stylistic change, we leave the MIBs as they are. > > > > Thanks > > Nagi. > > > > > > > > -----Original Message----- > > From: owner-radiusext@ops.ietf.org > > [mailto:owner-radiusext@ops.ietf.org] > > On Behalf Of Juergen Schoenwaelder > > Sent: Thursday, February 09, 2006 12:03 AM > > To: radiusext@ops.ietf.org > > Cc: Bert Wijnen > > Subject: radius dynauth client/server mibs structure > > > > Hi, > > > > I took a quick look at the radius dynauth client/server mibs today: > > > > draft-ietf-radext-dynauth-client-mib-03.txt > > draft-ietf-radext-dynauth-server-mib-03.txt > > > > While looking at the OID tree, I came up with the following > stylistic > > change. Currently, the OID tree of the two MIBs basically looks like > > this (details of the tables and conformance nodes deleted): > > > > --radiusDynAuthServerMIB(1.3.6.1.2.1.xxx) > > | > > +--radiusDynAuthServerMIBObjects(1) > > | | > > | +--radiusDynAuthServer(1) > > | | > > | +--radiusDynAuthServerDisconInvalidClientAddresses(1) > > | +--radiusDynAuthServerCoAInvalidClientAddresses(2) > > | +--radiusDynAuthServerIdentifier(3) > > | | > > | +--radiusDynAuthClientTable(4) > > | > > +--radiusDynAuthServerMIBConformance(2) > > > > --radiusDynAuthClientMIB(1.3.6.1.2.1.yyy) > > | > > +--radiusDynAuthClientMIBObjects(1) > > | | > > | +--radiusDynAuthClient(1) > > | | > > | +--radiusDynAuthClientDisconInvalidServerAddresses(1) > > | +--radiusDynAuthClientCoAInvalidServerAddresses(2) > > | | > > | +--radiusDynAuthServerTable(3) > > | > > +--radiusDynAuthClientMIBConformance(2) > > > > I was wondering what the value of having the radiusDynAuthServer and > > radiusDynAuthClient nodes is. I do understand if people > like to group > > related scalars together (so additions are numbered using > consecutive > > identifiers), but then the OID structure should more look like the > > following: > > > > --radiusDynAuthServerMIB(1.3.6.1.2.1.xxx) > > | > > +--radiusDynAuthServerMIBObjects(1) > > | | > > | +--radiusDynAuthServerScalars(1) > > | | | > > | | +--radiusDynAuthServerDisconInvalidClientAddresses(1) > > | | +--radiusDynAuthServerCoAInvalidClientAddresses(2) > > | | +--radiusDynAuthServerIdentifier(3) > > | | > > | +--radiusDynAuthClientTable(2) > > | > > +--radiusDynAuthServerMIBConformance(2) > > > > --radiusDynAuthClientMIB(1.3.6.1.2.1.yyy) > > | > > +--radiusDynAuthClientMIBObjects(1) > > | | > > | +--radiusDynAuthClientScalars(1) > > | | | > > | | +--radiusDynAuthClientDisconInvalidServerAddresses(1) > > | | +--radiusDynAuthClientCoAInvalidServerAddresses(2) > > | | > > | +--radiusDynAuthServerTable(2) > > | > > +--radiusDynAuthClientMIBConformance(2) > > > > The benefit of this change is that you can add scalars later > > while keep > > all the scalars rooted together and consecutively numbered > > while in the > > current scheme you end up to have tables intermixed with > scalars over > > time. > > > > Please note that there is nothing technically wrong with the MIBs as > > they are right now. My suggestion is purely stylistic and > > basically just > > increases readability in case updates are done in the future. > > > > I am aware that these MIB modules have passed WG last call and MIB > > review and are in the hands of the ADs and as such I do not > > ask to make > > a change just for stylistic reasons. I just wanted to bring > > this to your > > attention and I like to leave it to the editors/chairs to > > decide whether > > you want to make the relatively simple changes at this point > > in time or > > prefer to go ahead with what you have. > > > > /js > > > > -- > > Juergen Schoenwaelder International > University Bremen > > P.O. Box 750 561, > > 28725 Bremen, > > Germany > > > > -- > > to unsubscribe send a message to > > radiusext-request@ops.ietf.org with the > > word 'unsubscribe' in a single line as the message text body. > > archive: > > > -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 03 Mar 2006 14:37:40 +0000 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B155097221B1@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "Nagi Reddy Jonnala (njonnala)" , j.schoenwaelder@iu-bremen.de, radiusext@ops.ietf.org Subject: RE: radius dynauth client/server mibs structure Date: Fri, 3 Mar 2006 15:36:57 +0100 MIME-Version: 1.0 Content-Type: text/plain Are there implementations already? If not, I would also recommend to make the change suggested by Juergen. If yes, even then the suggested change is still simple now. The disadvantage of not doing so is in the future when adding scalars and thing not having grouped as nicely and so more complexity. This is not a blocking comment, just another MIB-type person believing that the change would be real EASY now, and it will certainly make things cleaner/easier in the future. Bert > -----Original Message----- > From: Nagi Reddy Jonnala (njonnala) [mailto:njonnala@cisco.com] > Sent: Tuesday, February 14, 2006 11:24 > To: j.schoenwaelder@iu-bremen.de; radiusext@ops.ietf.org > Cc: Bert Wijnen > Subject: RE: radius dynauth client/server mibs structure > > > Juergen, > > Your comments may be correct. We authors have discussed about your > comments and realized that the comments are not directly related to > these MIBs but in general whether the scalars should be > grouped together > or not. The recommended way can best be addressed in the IETF MIB > guidelines. Since there seem to be plenty of MIBs that don't > follow your > commented approach, no recommended way in the IETF MIB guidelines and > because it is a stylistic change, we leave the MIBs as they are. > > Thanks > Nagi. > > > > -----Original Message----- > From: owner-radiusext@ops.ietf.org > [mailto:owner-radiusext@ops.ietf.org] > On Behalf Of Juergen Schoenwaelder > Sent: Thursday, February 09, 2006 12:03 AM > To: radiusext@ops.ietf.org > Cc: Bert Wijnen > Subject: radius dynauth client/server mibs structure > > Hi, > > I took a quick look at the radius dynauth client/server mibs today: > > draft-ietf-radext-dynauth-client-mib-03.txt > draft-ietf-radext-dynauth-server-mib-03.txt > > While looking at the OID tree, I came up with the following stylistic > change. Currently, the OID tree of the two MIBs basically looks like > this (details of the tables and conformance nodes deleted): > > --radiusDynAuthServerMIB(1.3.6.1.2.1.xxx) > | > +--radiusDynAuthServerMIBObjects(1) > | | > | +--radiusDynAuthServer(1) > | | > | +--radiusDynAuthServerDisconInvalidClientAddresses(1) > | +--radiusDynAuthServerCoAInvalidClientAddresses(2) > | +--radiusDynAuthServerIdentifier(3) > | | > | +--radiusDynAuthClientTable(4) > | > +--radiusDynAuthServerMIBConformance(2) > > --radiusDynAuthClientMIB(1.3.6.1.2.1.yyy) > | > +--radiusDynAuthClientMIBObjects(1) > | | > | +--radiusDynAuthClient(1) > | | > | +--radiusDynAuthClientDisconInvalidServerAddresses(1) > | +--radiusDynAuthClientCoAInvalidServerAddresses(2) > | | > | +--radiusDynAuthServerTable(3) > | > +--radiusDynAuthClientMIBConformance(2) > > I was wondering what the value of having the radiusDynAuthServer and > radiusDynAuthClient nodes is. I do understand if people like to group > related scalars together (so additions are numbered using consecutive > identifiers), but then the OID structure should more look like the > following: > > --radiusDynAuthServerMIB(1.3.6.1.2.1.xxx) > | > +--radiusDynAuthServerMIBObjects(1) > | | > | +--radiusDynAuthServerScalars(1) > | | | > | | +--radiusDynAuthServerDisconInvalidClientAddresses(1) > | | +--radiusDynAuthServerCoAInvalidClientAddresses(2) > | | +--radiusDynAuthServerIdentifier(3) > | | > | +--radiusDynAuthClientTable(2) > | > +--radiusDynAuthServerMIBConformance(2) > > --radiusDynAuthClientMIB(1.3.6.1.2.1.yyy) > | > +--radiusDynAuthClientMIBObjects(1) > | | > | +--radiusDynAuthClientScalars(1) > | | | > | | +--radiusDynAuthClientDisconInvalidServerAddresses(1) > | | +--radiusDynAuthClientCoAInvalidServerAddresses(2) > | | > | +--radiusDynAuthServerTable(2) > | > +--radiusDynAuthClientMIBConformance(2) > > The benefit of this change is that you can add scalars later > while keep > all the scalars rooted together and consecutively numbered > while in the > current scheme you end up to have tables intermixed with scalars over > time. > > Please note that there is nothing technically wrong with the MIBs as > they are right now. My suggestion is purely stylistic and > basically just > increases readability in case updates are done in the future. > > I am aware that these MIB modules have passed WG last call and MIB > review and are in the hands of the ADs and as such I do not > ask to make > a change just for stylistic reasons. I just wanted to bring > this to your > attention and I like to leave it to the editors/chairs to > decide whether > you want to make the relatively simple changes at this point > in time or > prefer to go ahead with what you have. > > /js > > -- > Juergen Schoenwaelder International University Bremen > P.O. Box 750 561, > 28725 Bremen, > Germany > > -- > to unsubscribe send a message to > radiusext-request@ops.ietf.org with the > word 'unsubscribe' in a single line as the message text body. > archive: > -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 02 Mar 2006 23:50:36 +0000 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: radiusext@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-radext-delegated-prefix-00.txt Message-Id: Date: Thu, 02 Mar 2006 18:50:01 -0500 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the RADIUS EXTensions Working Group of the IETF. Title : RADIUS Delegated-IPv6-Prefix Attribute Author(s) : J. Salowey, R. Droms Filename : draft-ietf-radext-delegated-prefix-00.txt Pages : 5 Date : 2006-3-2 The Delegated-IPv6-Prefix attribute indicates an IPv6 prefix that is to be delegated to the user. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-radext-delegated-prefix-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-radext-delegated-prefix-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-radext-delegated-prefix-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-3-2150647.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-radext-delegated-prefix-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-radext-delegated-prefix-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-3-2150647.I-D@ietf.org> --OtherAccess-- --NextPart-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 02 Mar 2006 20:17:54 +0000 Date: Thu, 2 Mar 2006 15:17:10 -0500 From: Barney Wolff To: radiusext@ops.ietf.org Subject: Re: Extended-Space attribute draft available Message-ID: <20060302201709.GA52065@pit.databus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.11 The draft has now made it to the ietf server: http://www.ietf.org/internet-drafts/draft-wolff-radext-ext-attribute-00.txt In response to comments from Glen Zorn and Dave Nelson, any mention of the imagination, wild or otherwise, of the original designers will be removed in the next version. Comments and corrections are still welcome. Barney On Mon, Feb 27, 2006 at 09:09:21PM -0500, Barney Wolff wrote: > Greg Weber and I have written a draft defining an Extended-Space > attribute. Here's the abstract: > > The RADIUS protocol is being extended beyond the wildest imaginations > of its original designers. These extensions are pushing up against > the existing limitations on the numbers, length, base types and > grouping of RADIUS attributes. This document specifies a method of > relaxing those limitations. > > While it works its way to the IETF draft directory, you're welcome > to retrieve it here: > > http://www.databus.com/.ietf/draft-wolff-radext-ext-attribute-00.txt > http://www.databus.com/.ietf/draft-wolff-radext-ext-attribute-00.html > > This draft is a companion piece the the design guidelines draft, and, > we hope, will be adopted as a RADEXT work item. > > Comments and corrections are welcome, and if necessary I can try to > get a -01 version in before next week's deadline. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 01 Mar 2006 19:43:13 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Extended-Space attribute draft available Date: Wed, 1 Mar 2006 14:41:48 -0500 Message-ID: <3CFB564E055A594B82C4FE89D21565602190BB@MABOSEVS2.ets.enterasys.com> Thread-Topic: Extended-Space attribute draft available thread-index: AcY87dEIv7jIcWNESVeOlw7fuLPOaQAB+fAAABxxDuA= From: "Nelson, David" To: Glen Zorn writes... > Unless we worked at Livingston, I don't think we are the=20 > original designers so how do we know what their wildest=20 > imaginations were? I agree that the colorful rhetoric about the history of RADIUS in the abstract could be omitted without any loss of clarity. > I don't recall when I joined the list, but I did attend > the BOFs... I started at the second BOF. So I remember much of this history... FWIW. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 01 Mar 2006 18:51:00 +0000 From: "Alan DeKok" To: Barney Wolff Subject: Re: Extended-Space attribute draft available cc: radiusext@ops.ietf.org Date: Wed, 01 Mar 2006 13:57:49 -0500 Message-Id: <20060301185750.0788916CC1@mail.nitros9.org> Barney Wolff wrote: > Ah, the avp-header debate begins :) While there is much temptation to "optimize" the format of the attribute for packing efficiency, I don't think that's the highest priority. > allowing a translating gateway to > simply do a bulk copy of the concatenated value fields of all the > Extended-Space attributes in the RADIUS message. I strongly prefer re-using the diameter format. RADIUS servers that implement Diameter gateways or TTLS will already have code to deal with that format. Alan DeKok. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 01 Mar 2006 06:30:26 +0000 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: Extended-Space attribute draft available Date: Tue, 28 Feb 2006 22:29:59 -0800 Message-ID: <4C0FAAC489C8B74F96BEAD85EAEB262551CC73@xmb-sjc-215.amer.cisco.com> Thread-Topic: Extended-Space attribute draft available Thread-Index: AcY87dEIv7jIcWNESVeOlw7fuLPOaQAB+fAA From: "Glen Zorn \(gwz\)" To: "Barney Wolff" Cc: Barney Wolff supposedly scribbled: > On Tue, Feb 28, 2006 at 07:10:35PM -0800, Glen Zorn (gwz) wrote: >> On 2/27/2006 09:09 PM, Barney Wolff wrote: >>> Greg Weber and I have written a draft defining an Extended-Space >>> attribute. Here's the abstract: >>>=20 >>> The RADIUS protocol is being extended beyond the wildest >>> imaginations of its original designers. >>=20 >> Unless we worked at Livingston, I don't think we are the original >> designers so how do we know what their wildest imaginations were?=20 >> OTOH, the kind of extensions happening now were certainly within the >> wildest (or even mundane) imaginations of the RADIUS WG; their >> pursuit was simply not allowed in that venue (thus the whole >> NASREQ/Diameter fiasco). =20 >=20 > I certainly don't claim to be a designer of RADIUS. =20 Nor I. > But I did join > the list in Feb 1995, when RADIUS was at draft -02, and exchanged > quite a lot of cordial email with Carl Rigney, and even some with > Bill Simpson. =20 I don't recall when I joined the list, but I did attend the BOFs... > I have too much respect for the designers to believe > that had imaginations back then predicted the state of things more > than a decade later there would have been no mechanism for extending > Type and Length, at least.=20 IIRC, it was not a lack of imagination or vision on the part of Carl or = Bill (a visionary if ever there was one!) but structural and political = pressures that constrained the protocol design (kind of like now). =20 >=20 > Regards, > Barney Hope this helps, ~gwz Why is it that most of the world's problems can't be solved by simply listening to John Coltrane? -- Henry Gabriel -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 01 Mar 2006 05:06:08 +0000 Date: Wed, 1 Mar 2006 00:05:44 -0500 From: Barney Wolff To: "Glen Zorn (gwz)" Cc: radiusext@ops.ietf.org Subject: Re: Extended-Space attribute draft available Message-ID: <20060301050544.GA47264@pit.databus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.11 On Tue, Feb 28, 2006 at 07:10:35PM -0800, Glen Zorn (gwz) wrote: > On 2/27/2006 09:09 PM, Barney Wolff wrote: > > Greg Weber and I have written a draft defining an Extended-Space > > attribute. Here's the abstract: > > > > The RADIUS protocol is being extended beyond the wildest > > imaginations of its original designers. > > Unless we worked at Livingston, I don't think we are the original designers so how do we know what their wildest imaginations were? OTOH, the kind of extensions happening now were certainly within the wildest (or even mundane) imaginations of the RADIUS WG; their pursuit was simply not allowed in that venue (thus the whole NASREQ/Diameter fiasco). I certainly don't claim to be a designer of RADIUS. But I did join the list in Feb 1995, when RADIUS was at draft -02, and exchanged quite a lot of cordial email with Carl Rigney, and even some with Bill Simpson. I have too much respect for the designers to believe that had imaginations back then predicted the state of things more than a decade later there would have been no mechanism for extending Type and Length, at least. Regards, Barney -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 01 Mar 2006 04:06:20 +0000 Date: Tue, 28 Feb 2006 23:05:59 -0500 From: Barney Wolff To: David Mitton Cc: radiusext@ops.ietf.org Subject: Re: Extended-Space attribute draft available Message-ID: <20060301040559.GA90856@pit.databus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.11 On Tue, Feb 28, 2006 at 09:43:43PM -0500, David Mitton wrote: > > An alternative to this format could be a variation on my RADIUS > Diameter VSA format in > http://www.ietf.org/internet-drafts/draft-mitton-diameter-radius-vsas-01.txt > > where we could do something like: > (he says, editing on the fly).... > > > RADIUS Diameter AVP: > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Type = TBA | Length |r M P r r r r r| Segment | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Type (first segment only?) | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Attribute-Data ... > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Flags M & P retrain their Diameter values. > > RADIUS Type = TBA > RADIUS Length (3~255) > Flags = from Diameter message > Segment = 0-63, Segment number for data lengths greater than 246, > Type = 4 bytes from the Diameter Type code > Data = upto 246 bytes > > For Diameter values with lengths greater than 246, the additional > data would be put in consecutive attributes, in the same manner as > EAP [RADIUS-EAP], [RFC3579]. > > The Segment field will be zero for the first attribute, and each > sucessive attribute data segment will increment the Segment field. > The Vendor-Id and Vendor-Type SHALL not be repeated. > > Note that RADIUS applications that do not understand the > attribute will not honor the Diameter M and P flags. These flags > have no meaning in RADIUS, but are preserved for vendor specific > meaning and potential transport back to Diameter. Ah, the avp-header debate begins :) The choice of the Diameter AVP header format for Extended-Space was certainly not made on the basis of elegance or optimization of RADIUS message size, but rather optimization of calendar time (in the sense of hoping that it would truncate debate over details of header format) and, secondarily, allowing a translating gateway to simply do a bulk copy of the concatenated value fields of all the Extended-Space attributes in the RADIUS message. Had I been designing Diameter's data formats, I would have used ASN.1 and BER (or PER). Is there really any device speaking either RADIUS or Diameter that does not speak SNMP and have access to a BER library? But it's years too late for that. Re the header format suggested above, I'd point out that Segment is unnecessary, as the requirement that instances of a particular RADIUS attribute not be re-ordered provides implicit sequencing. All that's needed is a T-flag to say Type is present. By keeping the Diameter AVP length field, we avoided a requirement to start each Diameter-format attribute with a new Extended-Space attribute. Using the Diameter format accepts the proposition that increasingly servers, and arguably clients as well, will talk both Diameter and RADIUS, and therefore designing a third AVP header format would just add to code complexity. Regards, Barney -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 01 Mar 2006 03:12:38 +0000 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: Extended-Space attribute draft available Date: Tue, 28 Feb 2006 19:10:35 -0800 Message-ID: <4C0FAAC489C8B74F96BEAD85EAEB262551CC71@xmb-sjc-215.amer.cisco.com> Thread-Topic: Extended-Space attribute draft available Thread-Index: AcY82nfoJVsKITnWRHqM+ZKLrAWxJAAAnY0A From: "Glen Zorn \(gwz\)" To: On 2/27/2006 09:09 PM, Barney Wolff wrote: > Greg Weber and I have written a draft defining an Extended-Space > attribute. Here's the abstract: >=20 > The RADIUS protocol is being extended beyond the wildest > imaginations of its original designers. =20 Unless we worked at Livingston, I don't think we are the original = designers so how do we know what their wildest imaginations were? OTOH, = the kind of extensions happening now were certainly within the wildest = (or even mundane) imaginations of the RADIUS WG; their pursuit was = simply not allowed in that venue (thus the whole NASREQ/Diameter = fiasco). Hope this helps, ~gwz Why is it that most of the world's problems can't be solved by simply listening to John Coltrane? -- Henry Gabriel -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 01 Mar 2006 02:47:17 +0000 Message-Id: <6.2.3.4.2.20060228213412.04aaad60@getmail.mitton.com> Date: Tue, 28 Feb 2006 21:43:43 -0500 To: radiusext@ops.ietf.org From: David Mitton Subject: Re: Extended-Space attribute draft available Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed On 2/27/2006 09:09 PM, Barney Wolff wrote: >Greg Weber and I have written a draft defining an Extended-Space >attribute. Here's the abstract: > > The RADIUS protocol is being extended beyond the wildest imaginations > of its original designers. These extensions are pushing up against > the existing limitations on the numbers, length, base types and > grouping of RADIUS attributes. This document specifies a method of > relaxing those limitations. > >While it works its way to the IETF draft directory, you're welcome >to retrieve it here: > >http://www.databus.com/.ietf/draft-wolff-radext-ext-attribute-00.txt >http://www.databus.com/.ietf/draft-wolff-radext-ext-attribute-00.html > >This draft is a companion piece the the design guidelines draft, and, >we hope, will be adopted as a RADEXT work item. > >Comments and corrections are welcome, and if necessary I can try to >get a -01 version in before next week's deadline. > >Barney Wolff An alternative to this format could be a variation on my RADIUS Diameter VSA format in http://www.ietf.org/internet-drafts/draft-mitton-diameter-radius-vsas-01.txt where we could do something like: (he says, editing on the fly).... RADIUS Diameter AVP: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = TBA | Length |r M P r r r r r| Segment | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type (first segment only?) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Attribute-Data ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Flags M & P retrain their Diameter values. RADIUS Type = TBA RADIUS Length (3~255) Flags = from Diameter message Segment = 0-63, Segment number for data lengths greater than 246, Type = 4 bytes from the Diameter Type code Data = upto 246 bytes For Diameter values with lengths greater than 246, the additional data would be put in consecutive attributes, in the same manner as EAP [RADIUS-EAP], [RFC3579]. The Segment field will be zero for the first attribute, and each sucessive attribute data segment will increment the Segment field. The Vendor-Id and Vendor-Type SHALL not be repeated. Note that RADIUS applications that do not understand the attribute will not honor the Diameter M and P flags. These flags have no meaning in RADIUS, but are preserved for vendor specific meaning and potential transport back to Diameter. Dave. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: