<?xml version="1.0" encoding="utf-8"?>
This is your product or game page. It should focus on ONLY one product. This is not a replacement for your product’s website, but a quick way for the press to know it faster.
Check the actual rendered page for the code you’ll find below.
If you don’t have a data.xml
yet, the easiest way to start is to run this command in your presskit folder:
presskit new -t product
Then, open the generated data.xml
file and fill the blanks while following this guide.
For your company’ data.xml
, refer to the company documentation.
Don’t forget to set your XML header correctly.
<?xml version="1.0" encoding="utf-8"?>
Use a <product>
or <game>
tag.
<product>
Begin with your product name, website, and miscellaneous information.
<title>My Super Game</title>
<website>http://pizzaburger.studio/mysupergame</website>
You can also add an URL to a request page for this product. A button will be displayed on the page.
<press-copy-request>
http://pizzaburger.studio/mysupergame/request/
</press-copy-request>
If you have one or many publishers for this product, you can add them here.
The <based-in>
and <website>
tags are optional.
<partners>
<partner>
<type>Publisher</type>
<title>Pixelnest Studio</title>
<website>https://pixelnest.io/</website>
<based-in>Rennes, France</based-in>
</partner>
<partner>
<type>Distributor</type>
<title>Pizza Oven LLC</title>
</partner>
</partners>
Add as many dates, platforms and prices as needed.
<release-dates>
<release-date>04 Feb, 2016</release-date>
<release-date>10 Oct, 2016</release-date>
</release-dates>
<platforms>
<platform>
<name>PC / Mac</name>
<link>http://itch.io/</link>
</platform>
<platform>
<name>Steam</name>
<link>http://steampowered.com/</link>
</platform>
<platform>
<name>Inc New Store (TBA)</name>
</platform>
</platforms>
Show the price of your product. Try to be exhaustive, it will be helpful for a reviewer.
<prices>
<price>
<currency>EUR</currency>
<value>20</value>
</price>
<price>
<currency>USD</currency>
<value>20</value>
</price>
<price>
<currency>GBP</currency>
<value>16</value>
</price>
<price>
<currency>JPY</currency>
<value>2300</value>
</price>
</prices>
You can specify relations between products using the <relations>
tag.
Then, on this page product, you will see a new line in the factsheet:
DLC:
My Super Game: Ultimate Edition
Of course, the Product Name
value is clickable.
In the related product page, a new value will also be added:
DLC of:
My Super Game
Obviously, since the name we provide in the example is not a real product (ie., the product data.xml does not exist), this tag will be ignored for this page.
You can have as many relations as you want. You can use it to show DLCs, expansions, sequels, prequels, etc.
Warning: you need to rebuild the presskit to see the changes.
<relations>
<relation>
<type>DLC</type>
<product>My Super Game: Ultimate Edition</product>
</relation>
</relations>
Describe your product here. Be brief.
<description>
Here goes a quick description of your product or game. Be concise and explain in very few words the concept or the gameplay and why it's really cool and why everyone should use or play it.
</description>
Tell the story of your product with the <history>
tag.
You have two possibilities here.
<history>
block like in the example.<histories>
block if you have tons of things to say.You can’t have both.
You can see an example of the <histories>
block in the company page.
<history>
Add some storytelling here. Not the scenario of your game, but rather some backgrounds behind the creation process: why are you making this game? Most projects starts with a cool story.
</history>
Show the most important features of your product.
Focus on what is really important and is a key aspect of it.
<features>
<feature>
List some "Key Sellings Points" to grab player's attention.
</feature>
<feature>
Don't be too generic ("pixel art graphics!"), don't be too pretentious ("most incredible game experience!").
</feature>
<feature>
Also, people like numbers, so you can add some (450 weapons, hundreds of levels, dozens of hours of playtime!).
</feature>
<feature>
Need ideas? Maybe explain some game modes?
</feature>
<feature>
It would be a nice place to say something about multiplayer, if you have some.
</feature>
<feature>
Have you translated your game? (You probably should btw.)
</feature>
</features>
Add your videos. Trailer, teaser, snippets? Let’s roll!
You can use YouTube and/or Vimeo. Only one is needed, and only one is recommended.
Don’t put the full link: just the ID is necessary.
If you want to provide a link to download the video, add this tag in <trailer>
:
<download>https://example.com/video.mp4</download>
<trailers>
<trailer>
<name>Release Trailer</name>
<youtube>EtXajayBLzw</youtube>
</trailer>
<trailer>
<name>Gameplay Video #2</name>
<youtube>EPNK1j3TMjU</youtube>
</trailer>
<trailer>
<name>Early Access Trailer</name>
<youtube>EtyQMcc19xY</youtube>
</trailer>
<trailer>
<name>Short gameplay preview: Burger vs Pizza</name>
<download>https://github.com/pixelnest/presskit.html</download>
</trailer>
</trailers>
Add your widgets to your product here.
If the product is not a game or an app, you won’t probably need that.
We only need the ID of the product on the store.
This section is optional, and you can use as many widgets (or none) as you want.
Warning: widgets import many scripts and assets. This may have a penalty on your page size and responsiveness.
<widgets>
<appstore>950812012</appstore>
<playstore>com.noodlecake.altosadventure</playstore>
<steam>347160</steam>
<humble>steredenn/7SDLfk23hw</humble>
<itch>27992</itch>
<bandcamp>1135613467</bandcamp>
</widgets>
<awards>
<award>
<description>Game of the year without a doubt</description>
<info>Saint-Père-Marc-En-Poulet (France), 04 February, 2016</info>
</award>
<award>
<description>Best soundtrack</description>
<info>A great game festival (World), 01 October, 2015</info>
</award>
<award>
<description>Best MYGAMENGINE game</description>
<info>Deep into the woods (Forest), 31 March, 2014</info>
</award>
</awards>
Quotes are used to show the appreciation of your users.
Show something important, something nice, or something funny, for example.
Optional.
<quotes>
<quote>
<description>This is my favorite game of all time.</description>
<name>Mum</name>
<website>At home</website>
<link>http://at.home/</link>
</quote>
<quote>
<description>A very serious quote you're very proud of by someone you respect.</description>
<name>Master</name>
<website>Master's website</website>
<link>http://mast.er/</link>
</quote>
<quote>
<description>10/10 would play it again and again.</description>
<name>A friendly anonymous Steam reviewer</name>
<website>Steam review</website>
<link>http://steam.review/</link>
</quote>
</quotes>
Need to link to a resource? A small product? An RSS feed? An OST?
A press release?
Put those here, in the <additionals>
tag.
Optional.
<additionals>
<additional>
<title>Original Soundtrack (OST)</title>
<description>Composed by an awesome musician. Listen for free, download for $3 at</description>
<link>http://zandernoriega.bandcamp.com/album/steredenn-original-soundtrack</link>
</additional>
<additional>
<title>Release announcement</title>
<description>Announcement are exciting, so we usually make blog posts or news about it on</description>
<link>http://pixelnest.io/journal/</link>
</additional>
</additionals>
An “About Your Company” section is automatically generated from the content of the company page.
This
This is this the place to do it.
For example, if you have a publisher, you can speak a bit more about it here.
Most of the time, you should link that to the
The tag is optional.
<abouts>
<about>
<title>Pixelnest Studio</title>
<description>Pixelnest Studio is a small French studio which creates games, websites and apps. They made Steredenn, a roguelike-shmup in big pixels. They are also behind presskit.html, which you are probably using if you are reading this.</description>
<link>https://pixelnest.io/</link>
</about>
<about>
<title>Pizza Oven LLC</title>
<description>This is a fake company to illustrate the fact that you can have multiple about tags in your product page.</description>
</about>
</abouts>
This is for the product team.
Add yourself, of course, but also your collaborators, freelancers and/or partners for example.
The <role>
tag can be anything you want. But we recommend to, at least, put the company name for the founders/employees. This will distinguish this person from the external collaborators.
The <website>
tag is optional.
<credits>
<credit>
<person>Krokmou</person>
<role>Bot Leader, Game Designer, Pixelnest Studio</role>
</credit>
<credit>
<person>Hiccup</person>
<role>Developer, Pixelnest Studio</role>
</credit>
<credit>
<person>Astrid</person>
<website>http://www.astridsupergame.com</website>
<role>Musician, Freelancer</role>
</credit>
</credits>
Add more contact information.
Add links to your product social accounts, as well as mail specific to this product. And the website.
For each item, pick one between a <link>
and <mail>
tag.
<contacts>
<contact>
<name>Inquiries</name>
<EMAIL_ADDRESS></contact>
<contact>
<name>Twitter</name>
<link>
https://twitter.com/pizzaburgerstudio
</link>
</contact>
<contact>
<name>Facebook</name>
<link>
https://facebook.com/pizzaburgerstudio
</link>
</contact>
<contact>
<name>Web</name>
<link>
http://mysupergame.pizzaburger.studio/
</link>
</contact>
</contacts>
All done! 🍾
</product>


Administrative Assistant to Imams
Administrative Assistant to Imams Job Description
The Islamic Association of Raleigh (IAR) is seeking a motivated, trustworthy individual to serve in the role of Administrative Assistant to the Imams. The position is a paid, part-time position requiring 20 hours per week with the potential for additional hours during peak periods.
The IAR is an Islamic center serving as a mosque, school, and a gathering place for the Muslim community in the Research Triangle region of North Carolina. The IAR is one of the oldest mosques in the area and hosts over three thousand congregants every Friday.
The IAR is an active center providing services for people of all backgrounds and all ages across the the capital city of Raleigh and the Research Triangle region.
Overall Objectives
- To promote and assist the smooth, professional operations of the Office of the Imam and the Islamic Association of Raleigh.
- To provide administrative and execution support to the Office of the Imam, Education Committee, and Outreach Committee of the IAR
- To deliver an outstanding, professional, courteous service experience to the congregants and community of IAR
Essential Job Functions
The Assistant to the Imam is responsible for supporting the Office of the Imam in execution of its duties including religious program & service design, marketing, and communication; management of the Imams' calendars, correspondence (voicemail, e-mail, regular mail, etc.), website and speaking engagements. The Assistant to the Imam will serve as the primary contact person for the Imams on all matters requiring their attention.
These duties fall in three main areas. It is expected that the successful applicant will have broad experience or ability to be trained in multiple areas, while excelling in one or more of these areas. The Assistant to the Imam will work closely with IAR Imams to learn and execute his/her job responsibilities.
Program Planning & Execution
- Administrate the planning and design of worship services, including volunteer coordination, under direction of the Imam
- Administrate the planning and design of key Education and Outreach activities in coordination with the Imam and appropriate committee leads
- Setup and maintain filing systems as needed to ensure easy access to important information
- Assist in executing special assignments related to job duties as assigned
Communications
- Manage the Imam's calendar, functioning as the primary contact person for meetings, speeches, marriage & funeral services, and other schedule commitments
- Manage all forms of correspondence including e-mail, voicemail, and regular mail, maintaining the strictest confidentiality and highest standards of Islamic ethics and character.
Marketing & Congregant Relations
- Maintain Imam's Corner on IAR website and contributions to social media including content updates, email processing, and other activities as directed.
- Execute or manage development, printing, and distribution of marketing material such as flyers and social media posts
Required Skills and Qualifications
- High school diploma or equivalent
- Excellent command of the English language, including basic composition, grammar, and punctuation
- Strong computer skills, including use of the Internet, e-mail, calendar, word-processing, and spreadsheets
Refined interpersonal skills and capacity to act as a liaison between the Imam and the public. Ability to handle complaints and problems with tact, patience, and diplomacy.
Excellent Islamic character and trustworthiness, as evidenced through references and interview. Commitment to maintain confidentiality of private communications and sensitive information.
Competence in operating standard office machines such as printer, copier, and scanner
Internet and phone access for any approved hours worked telecommuting (by prior arrangement and advance approval)
Discipline to adhere to IAR policies, procedures, and workflows and to work in a flexible, high-paced environment
Demonstrated flexibility, good judgment and the ability to set priorities and respond to changes. A self-starter with the ability to work independently.
Ability to be trained and acquire new skills
Some weekend and evening hours may be required as services and meetings dictate
Desired Skills and Qualifications
- Previous administrative, office, or service experience
- Advanced computer skills, such as proficiency in presentation, desktop publishing, video recording & editing, and graphic design.
- Arabic language proficiency
Compensation & Benefits: Compensation is commensurate with experience. The employee will be a non-exempt hourly employee. IAR Personnel policy governs work conditions and benefits. All staff members are on probation for the first 90 days and are reviewed annually.
To apply, send résumé and three references by e-mail to<EMAIL_ADDRESS>with the job code of IAR-ImamAssistant in the email subject line.
Deadline for applications is is March 9, 2019. However, IAR reserves the right to keep this position open until filled. IAR is an equal opportunity employer.


Network Working Group P. Congdon Request for Comments: 3580 Hewlett Packard Company Category: Informational B. Aboba Microsoft A. Smith Trapeze Networks G. Zorn Cisco Systems J. Roese Enterasys September 2003 IEEE 802.1X Remote Authentication Dial In User Service (RADIUS) Usage Guidelines Status of this Memo This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved. Abstract This document provides suggestions on Remote Authentication Dial In User Service (RADIUS) usage by IEEE 802.1X Authenticators. The material in this document is also included within a non-normative Appendix within the IEEE 802.1X specification, and is being presented as an IETF RFC for informational purposes. Congdon, et al. Informational [Page 1] RFC 3580 IEEE 802.1X RADIUS September 2003 Table of Contents 1.                                                         Introduction
IEEE 802.1X enables authenticated access to IEEE 802 media, including Ethernet, Token Ring, and 802.11 wireless LANs. Although Remote Authentication Dial In User Service (RADIUS) support is optional within IEEE 802.1X, it is expected that many IEEE 802.1X Authenticators will function as RADIUS clients. IEEE 802.1X [IEEE8021X] provides "network port authentication" for IEEE 802 [IEEE802] media, including Ethernet [IEEE8023], Token Ring and 802.11 [IEEE80211] wireless LANS. IEEE 802.1X does not require use of a backend Authentication Server, and thus can be deployed with stand-alone bridges or Access Points, as well as in centrally managed scenarios. In situations where it is desirable to centrally manage authentication, authorization and accounting (AAA) for IEEE 802 networks, deployment of a backend authentication and accounting server is desirable. In such situations, it is expected that IEEE 802.1X Authenticators will function as AAA clients. This document provides suggestions on RADIUS usage by IEEE 802.1X Authenticators. Support for any AAA protocol is optional for IEEE 802.1X Authenticators, and therefore this specification has been incorporated into a non-normative Appendix within the IEEE 802.1X specification.1.1. Terminology
This document uses the following terms: Access Point (AP) A Station that provides access to the distribution services via the wireless medium for associated Stations. Congdon, et al. Informational [Page 3] RFC 3580 IEEE 802.1X RADIUS September 2003 Association The service used to establish Access Point/Station mapping and enable Station invocation of the distribution system services. Authenticator An Authenticator is an entity that requires authentication from the Supplicant. The Authenticator may be connected to the Supplicant at the other end of a point-to-point LAN segment or 802.11 wireless link. Authentication Server An Authentication Server is an entity that provides an Authentication Service to an Authenticator. This service verifies, from the credentials provided by the Supplicant, the claim of identity made by the Supplicant. Port Access Entity (PAE) The protocol entity associated with a physical or virtual (802.11) Port. A given PAE may support the protocol functionality associated with the Authenticator, Supplicant or both. Station (STA) Any device that contains an IEEE 802.11 conformant medium access control (MAC) and physical layer (PHY) interface to the wireless medium (WM). Supplicant 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.1.2. Requirements Language
In this document, several words are used to signify the requirements of the specification. These words are often capitalized. 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]. Congdon, et al. Informational [Page 4] RFC 3580 IEEE 802.1X RADIUS September 20032. RADIUS Accounting Attributes
With a few exceptions, the RADIUS accounting attributes defined in [RFC2866], [RFC2867], and [RFC2869] have the same meaning within IEEE 802.1X sessions as they do in dialup sessions and therefore no additional commentary is needed. Attributes requiring more discussion include: Acct-Terminate-Cause Acct-Multi-Session-Id Acct-Link-Count2.1. Acct-Terminate-Cause
This attribute indicates how the session was terminated, as described in [RFC2866]. [IEEE8021X] defines the following termination cause values, which are shown with their RADIUS equivalents in the table on the next page. IEEE 802.1X RADIUS dot1xAuthSessionTerminateCause Acct-Terminate-Cause Value Value ------------- -------------------- SupplicantLogoff(1) User Request (1) portFailure(2) Lost Carrier (2) SupplicantRestart(3) Supplicant Restart (19) reauthFailed(4) Reauthentication Failure (20) authControlForceUnauth(5) Admin Reset (6) portReInit(6) Port Reinitialized (21) portAdminDisabled(7) Port Administratively Disabled (22) notTerminatedYet(999) N/A When using this attribute, the User Request (1) termination cause corresponds to the situation in which the session terminated due to an EAPOL-Logoff received from the Supplicant. When a session is moved due to roaming, the EAPOL state machines will treat this as a Supplicant Logoff. A Lost Carrier (2) termination cause indicates session termination due to loss of physical connectivity for reasons other than roaming between Access Points. For example, if the Supplicant disconnects a point-to-point LAN connection, or moves out of range of an Access Point, this termination cause is used. Lost Carrier (2) therefore equates to a Port Disabled condition in the EAPOL state machines. A Supplicant Restart (19) termination cause indicates re-initialization of the Supplicant state machines. Congdon, et al. Informational [Page 5] RFC 3580 IEEE 802.1X RADIUS September 2003 A Reauthentication Failure (20) termination cause indicates that a previously authenticated Supplicant has failed to re-authenticate successfully following expiry of the re-authentication timer or explicit re-authentication request by management action. Within [IEEE80211], periodic re-authentication may be useful in preventing reuse of an initialization vector with a given key. Since successful re-authentication does not result in termination of the session, accounting packets are not sent as a result of re-authentication unless the status of the session changes. For example: a. The session is terminated due to re-authentication failure. In this case the Reauthentication Failure (20) termination cause is used. b. The authorizations are changed as a result of a successful re-authentication. In this case, the Service Unavailable (15) termination cause is used. For accounting purposes, the portion of the session after the authorization change is treated as a separate session. Where IEEE 802.1X authentication occurs prior to association, accounting packets are not sent until an association occurs. An Admin Reset (6) termination cause indicates that the Port has been administratively forced into the unauthorized state. A Port Reinitialized (21) termination cause indicates that the Port's MAC has been reinitialized. A Port Administratively Disabled (22) termination cause indicates that the Port has been administratively disabled.2.2. Acct-Multi-Session-Id
The purpose of this attribute is to make it possible to link together multiple related sessions. While [IEEE8021X] does not act on aggregated ports, it is possible for a Supplicant roaming between Access Points to cause multiple RADIUS accounting packets to be sent by different Access Points. Where supported by the Access Points, the Acct-Multi-Session-Id attribute can be used to link together the multiple related sessions of a roaming Supplicant. In such a situation, if the session context is transferred between Access Points, accounting packets MAY be sent without a corresponding authentication and authorization exchange, Congdon, et al. Informational [Page 6] RFC 3580 IEEE 802.1X RADIUS September 2003 provided that Association has occurred. However, in such a situation it is assumed that the Acct-Multi-Session-Id is transferred between the Access Points as part of the Inter-Access Point Protocol (IAPP). If the Acct-Multi-Session-Id were not unique between Access Points, then it is possible that the chosen Acct-Multi-Session-Id will overlap with an existing value allocated on that Access Point, and the Accounting Server would therefore be unable to distinguish a roaming session from a multi-link session. As a result, the Acct-Multi-Session-Id attribute is unique among all the bridges or Access Points, Supplicants and sessions. In order to provide this uniqueness, it is suggested that the Acct-Multi- Session-Id be of the form: Original AP MAC Address | Supplicant MAC Address | NTP Timestamp Here "|" represents concatenation, the original AP MAC Address is the MAC address of the bridge or Access Point at which the session started, and the 64-bit NTP timestamp indicates the beginning of the original session. In order to provide for consistency of the Acct- Multi-Session-Id between roaming sessions, the Acct-Multi-Session-Id may be moved between Access Points as part of IAPP or another handoff scheme. The use of an Acct-Multi-Session-Id of this form guarantees uniqueness among all Access Points, Supplicants and sessions. Since the NTP timestamp does not wrap on reboot, there is no possibility that a rebooted Access Point could choose an Acct-Multi-Session-Id that could be confused with that of a previous session. Since the Acct-Multi-Session-Id is of type String as defined in [RFC2866], for use with IEEE 802.1X, it is encoded as an ASCII string of Hex digits. Example: "00-10-A4-23-19-C0-00-12-B2- 14-23-DE-AF-23-83-C0-76-B8-44-E8"2.3. Acct-Link-Count
The Acct-Link-Count attribute may be used to account for the number of ports that have been aggregated.3. RADIUS Authentication
This section describes how attributes defined in [RFC2865], [RFC2867], [RFC2868], [RFC2869], [RFC3162] and [RFC3579] are used in IEEE 802.1X authentication. Congdon, et al. Informational [Page 7] RFC 3580 IEEE 802.1X RADIUS September 20033.1. User-Name
In IEEE 802.1X, the Supplicant typically provides its identity via an EAP-Response/Identity message. Where available, the Supplicant identity is included in the User-Name attribute, and included in the RADIUS Access-Request and Access-Reply messages as specified in [RFC2865] and [RFC3579]. Alternatively, as discussed in [RFC3579] Section 2.1., the User-Name attribute may contain the Calling-Station-ID value, which is set to the Supplicant MAC address.3.2. User-Password, CHAP-Password, CHAP-Challenge
Since IEEE 802.1X does not support PAP or CHAP authentication, the User-Password, CHAP-Password or CHAP-Challenge attributes are not used by IEEE 802.1X Authenticators acting as RADIUS clients.3.3. NAS-IP-Address, NAS-IPv6-Address
For use with IEEE 802.1X, the NAS-IP-Address contains the IPv4 address of the bridge or Access Point acting as an Authenticator, and the NAS-IPv6-Address contains the IPv6 address. If the IEEE 802.1X Authenticator has more than one interface, it may be desirable to use a loopback address for this purpose so that the Authenticator will still be reachable even if one of the interfaces were to fail.3.4. NAS-Port
For use with IEEE 802.1X the NAS-Port will contain the port number of the bridge, if this is available. While an Access Point does not have physical ports, a unique "association ID" is assigned to every mobile Station upon a successful association exchange. As a result, for an Access Point, if the association exchange has been completed prior to authentication, the NAS-Port attribute will contain the association ID, which is a 16-bit unsigned integer. Where IEEE 802.1X authentication occurs prior to association, a unique NAS-Port value may not be available.3.5. Service-Type
For use with IEEE 802.1X, the Framed (2), Authenticate Only (8), and Call Check (10) values are most commonly used. A Service-Type of Framed indicates that appropriate 802 framing should be used for the connection. A Service-Type of Authenticate Only (8) indicates that no authorization information needs to be returned in the Access-Accept. As described in [RFC2865], a Congdon, et al. Informational [Page 8] RFC 3580 IEEE 802.1X RADIUS September 2003 Service-Type of Call Check is included in an Access-Request packet to request that the RADIUS server accept or reject the connection attempt, typically based on the Called-Station-ID (set to the bridge or Access Point MAC address) or Calling-Station-ID attributes (set to the Supplicant MAC address). As noted in [RFC2865], it is recommended that in this case, the User-Name attribute be given the value of Calling-Station-Id.3.6. Framed-Protocol
Since there is no value for IEEE 802 media, the Framed-Protocol attribute is not used by IEEE 802.1X Authenticators.3.7. Framed-IP-Address, Framed-IP-Netmask
IEEE 802.1X does not provide a mechanism for IP address assignment. Therefore the Framed-IP-Address and Framed-IP-Netmask attributes can only be used by IEEE 802.1X Authenticators that support IP address assignment mechanisms. Typically this capability is supported by layer 3 devices.3.8. Framed-Routing
The Framed-Routing attribute indicates the routing method for the Supplicant. It is therefore only relevant for IEEE 802.1X Authenticators that act as layer 3 devices, and cannot be used by a bridge or Access Point.3.9. Filter-ID
This attribute indicates the name of the filter list to be applied to the Supplicant's session. For use with an IEEE 802.1X Authenticator, it may be used to indicate either layer 2 or layer 3 filters. Layer 3 filters are typically only supported on IEEE 802.1X Authenticators that act as layer 3 devices.3.10. Framed-MTU
This attribute indicates the maximum size of an IP packet that may be transmitted over the wire between the Supplicant and the Authenticator. IEEE 802.1X Authenticators set this to the value corresponding to the relevant 802 medium, and include it in the RADIUS Access-Request. The RADIUS server may send an EAP packet as large as Framed-MTU minus four (4) octets, taking into account the additional overhead for the IEEE 802.1X Version (1), Type (1) and Body Length (2) fields. For EAP over IEEE 802 media, the Framed-MTU values (which do not include LLC/SNAP overhead) and maximum frame length values (not including the preamble) are as follows: Congdon, et al. Informational [Page 9] RFC 3580 IEEE 802.1X RADIUS September 2003 Maximum Frame Media Framed-MTU Length ========= =============== ============== Ethernet 1500 1522 802.3 1500 1522 802.4 8174 8193 802.5 (4 Mbps) 4528 4550 802.5 (16 Mbps) 18173 18200 802.5 (100 Mb/s) 18173 18200 802.6 9191 9240 802.9a 1500 1518 802.11 2304 2346 802.12 (Ethernet) 1500 1518 802.12 (Token Ring) 4502 4528 FDDI 4479 4500 NOTE - the Framed-MTU size for IEEE 802.11 media may change as a result of ongoing work being undertaken in the IEEE 802.11 Working Group. Since some 802.11 stations cannot handle an MTU larger than 1500 octets, it is recommended that RADIUS servers encountering a NAS-Port-Type value of 802.11 send EAP packets no larger than 1496 octets.3.11. Framed-Compression
[IEEE8021X] does not include compression support. Therefore this attribute is not understood by [IEEE8021X] Authenticators.3.12. Displayable Messages
The Reply-Message attribute, defined in section 5.18 of [RFC2865], indicates text which may be displayed to the user. This is similar in concept to the EAP Notification Type, defined in [RFC2284]. As noted in [RFC3579], Section 2.6.5, when sending a displayable message to an [IEEE8021X] Authenticator, displayable messages are best sent within EAP-Message/EAP-Request/Notification attribute(s), and not within Reply-Message attribute(s).3.13. Callback-Number, Callback-ID
These attributes are not understood by IEEE 802.1X Authenticators. Congdon, et al. Informational [Page 10] RFC 3580 IEEE 802.1X RADIUS September 20033.14. Framed-Route, Framed-IPv6-Route
The Framed-Route and Framed-IPv6-Route attributes provide routes that are to be configured for the Supplicant. These attributes are therefore only relevant for IEEE 802.1X Authenticators that act as layer 3 devices, and cannot be understood by a bridge or Access Point.3.15. State, Class, Proxy-State
These attributes are used for the same purposes as described in [RFC2865].3.16. Vendor-Specific
Vendor-specific attributes are used for the same purposes as described in [RFC2865]. The MS-MPPE-Send-Key and MS-MPPE-Recv-Key attributes, described in section 2.4 of [RFC2548], MAY be used to encrypt and authenticate the RC4 EAPOL-Key descriptor [IEEE8021X, Section 7.6]. Examples of the derivation of the MS-MPPE-Send-Key and MS-MPPE-Recv-Key attributes from the master key negotiated by an EAP method are given in [RFC2716]. Details of the EAPOL-Key descriptor are provided in Section 4.3.17. Session-Timeout
When sent along in an Access-Accept without a Termination-Action attribute or with a Termination-Action attribute set to Default, the Session-Timeout attribute specifies the maximum number of seconds of service provided prior to session termination. When sent in an Access-Accept along with a Termination-Action value of RADIUS-Request, the Session-Timeout attribute specifies the maximum number of seconds of service provided prior to re- authentication. In this case, the Session-Timeout attribute is used to load the reAuthPeriod constant within the Reauthentication Timer state machine of 802.1X. When sent with a Termination-Action value of RADIUS-Request, a Session-Timeout value of zero indicates the desire to perform another authentication (possibly of a different type) immediately after the first authentication has successfully completed. When sent in an Access-Challenge, this attribute represents the maximum number of seconds that an IEEE 802.1X Authenticator should wait for an EAP-Response before retransmitting. In this case, the Session-Timeout attribute is used to load the suppTimeout constant within the backend state machine of IEEE 802.1X. Congdon, et al. Informational [Page 11] RFC 3580 IEEE 802.1X RADIUS September 20033.18. Idle-Timeout
The Idle-Timeout attribute is described in [RFC2865]. For IEEE 802 media other than 802.11 the media are always on. As a result the Idle-Timeout attribute is typically only used with wireless media such as IEEE 802.11. It is possible for a wireless device to wander out of range of all Access Points. In this case, the Idle-Timeout attribute indicates the maximum time that a wireless device may remain idle.3.19. Termination-Action
This attribute indicates what action should be taken when the service is completed. The value RADIUS-Request (1) indicates that re- authentication should occur on expiration of the Session-Time. The value Default (0) indicates that the session should terminate.3.20. Called-Station-Id
For IEEE 802.1X Authenticators, this attribute is used to store the bridge or Access Point MAC address in ASCII format (upper case only), with octet values separated by a "-". Example: "00-10-A4-23-19-C0". In IEEE 802.11, where the SSID is known, it SHOULD be appended to the Access Point MAC address, separated from the MAC address with a ":". Example "00-10-A4-23-19-C0:AP1".3.21. Calling-Station-Id
For IEEE 802.1X Authenticators, this attribute is used to store the Supplicant MAC address in ASCII format (upper case only), with octet values separated by a "-". Example: "00-10-A4-23-19-C0".3.22. NAS-Identifier
This attribute contains a string identifying the IEEE 802.1X Authenticator originating the Access-Request.3.23. NAS-Port-Type
For use with IEEE 802.1X, NAS-Port-Type values of Ethernet (15) Wireless - IEEE 802.11 (19), Token Ring (20) and FDDI (21) may be used. Congdon, et al. Informational [Page 12] RFC 3580 IEEE 802.1X RADIUS September 20033.24. Port-Limit
This attribute has no meaning when sent to an [IEEE8021X] Authenticator.3.25. Password-Retry
In IEEE 802.1X, the Authenticator always transitions to the HELD state after an authentication failure. Thus this attribute does not make sense for IEEE 802.1X.3.26. Connect-Info
This attribute is sent by a bridge or Access Point to indicate the nature of the Supplicant's connection. When sent in the Access- Request it is recommended that this attribute contain information on the speed of the Supplicant's connection. For 802.11, the following format is recommended: "CONNECT 11Mbps 802.11b". If sent in the Accounting STOP, this attribute may be used to summarize statistics relating to session quality. For example, in IEEE 802.11, the Connect-Info attribute may contain information on the number of link layer retransmissions. The exact format of this attribute is implementation specific.3.27. EAP-Message
Since IEEE 802.1X provides for encapsulation of EAP as described in [RFC2284] and [IEEE8021X], the EAP-Message attribute defined in [RFC3579] is used to encapsulate EAP packets for transmission from the IEEE 802.1X Authenticator to the Authentication Server. [RFC3579] Section 2.2. describes how the Authentication Server handles invalid EAP packets passed to it by the Authenticator.3.28. Message-Authenticator
As noted in [RFC3579] Section 3.1., the Message-Authenticator attribute MUST be used to protect packets within a RADIUS/EAP conversation.3.29. NAS-Port-Id
This attribute is used to identify the IEEE 802.1X Authenticator port which authenticates the Supplicant. The NAS-Port-Id differs from the NAS-Port in that it is a string of variable length whereas the NAS- Port is a 4 octet value. Congdon, et al. Informational [Page 13] RFC 3580 IEEE 802.1X RADIUS September 20033.30. Framed-Pool, Framed-IPv6-Pool
IEEE 802.1X does not provide a mechanism for IP address assignment. Therefore the Framed-Pool and Framed-IPv6-Pool attributes can only be used by IEEE 802.1X Authenticators that support IP address assignment mechanisms. Typically this capability is supported by layer 3 devices.3.31. Tunnel Attributes
Reference [RFC2868] defines RADIUS tunnel attributes used for authentication and authorization, and [RFC2867] defines tunnel attributes used for accounting. Where the IEEE 802.1X Authenticator supports tunneling, a compulsory tunnel may be set up for the Supplicant as a result of the authentication. In particular, it may be desirable to allow a port to be placed into a particular Virtual LAN (VLAN), defined in [IEEE8021Q], based on the result of the authentication. This can be used, for example, to allow a wireless host to remain on the same VLAN as it moves within a campus network. The RADIUS server typically indicates the desired VLAN by including tunnel attributes within the Access-Accept. However, the IEEE 802.1X Authenticator may also provide a hint as to the VLAN to be assigned to the Supplicant by including Tunnel attributes within the Access- Request. For use in VLAN assignment, the following tunnel attributes are used: Tunnel-Type=VLAN (13) Tunnel-Medium-Type=802 Tunnel-Private-Group-ID=VLANID Note that the VLANID is 12-bits, taking a value between 1 and 4094, inclusive. Since the Tunnel-Private-Group-ID is of type String as defined in [RFC2868], for use with IEEE 802.1X, the VLANID integer value is encoded as a string. When Tunnel attributes are sent, it is necessary to fill in the Tag field. As noted in [RFC2868], section 3.1: The Tag field is one octet in length and is intended to provide a means of grouping attributes in the same packet which refer to the same tunnel. Valid values for this field are 0x01 through 0x1F, inclusive. If the Tag field is unused, it MUST be zero (0x00). Congdon, et al. Informational [Page 14] RFC 3580 IEEE 802.1X RADIUS September 2003 For use with Tunnel-Client-Endpoint, Tunnel-Server-Endpoint, Tunnel- Private-Group-ID, Tunnel-Assignment-ID, Tunnel-Client-Auth-ID or Tunnel-Server-Auth-ID attributes (but not Tunnel-Type, Tunnel- Medium-Type, Tunnel-Password, or Tunnel-Preference), a tag field of greater than 0x1F is interpreted as the first octet of the following field. Unless alternative tunnel types are provided, (e.g. for IEEE 802.1X Authenticators that may support tunneling but not VLANs), it is only necessary for tunnel attributes to specify a single tunnel. As a result, where it is only desired to specify the VLANID, the tag field SHOULD be set to zero (0x00) in all tunnel attributes. Where alternative tunnel types are to be provided, tag values between 0x01 and 0x1F SHOULD be chosen.4. RC4 EAPOL-Key Frame
The RC4 EAPOL-Key frame is created and transmitted by the Authenticator in order to provide media specific key information. For example, within 802.11 the RC4 EAPOL-Key frame can be used to distribute multicast/broadcast ("default") keys, or unicast ("key mapping") keys. The "default" key is the same for all Stations within a broadcast domain. The RC4 EAPOL-Key frame is not acknowledged and therefore the Authenticator does not know whether the Supplicant has received it. If it is lost, then the Supplicant and Authenticator will not have the same keying material, and communication will fail. If this occurs, the problem is typically addressed by re-running the authentication. The RC4 EAPOL-Key frame is sent from the Authenticator to the Supplicant in order to provision the "default" key, and subsequently in order to refresh the "default" key. It may also be used to refresh the key-mapping key. Rekey is typically only required with weak ciphersuites such as WEP, defined in [IEEE80211]. Where keys are required, an EAP method that derives keys is typically selected. Therefore the initial "key mapping" keys can be derived from EAP keying material, without requiring the Authenticator to send an RC4 EAPOL-Key frame to the Supplicant. An example of how EAP keying material can be derived and used is presented in [RFC2716]. Congdon, et al. Informational [Page 15] RFC 3580 IEEE 802.1X RADIUS September 2003 While the RC4 EAPOL-Key frame is defined in [IEEE8021X], a more complete description is provided on the next page. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Version | Packet Type | Packet Body Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Key Length |Replay Counter... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Replay Counter... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Replay Counter | Key IV... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Key IV... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Key IV... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Key IV... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Key IV... |F| Key Index | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Key Signature... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Key Signature... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Key Signature... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Key Signature... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Key... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Version The Version field is one octet. For IEEE 802.1X, it contains the value 0x01. Packet Type The Packet Type field is one octet, and determines the type of packet being transmitted. For an EAPOL-Key Descriptor, the Packet Type field contains 0x03. Packet Body Length The Packet Body Length is two octets, and contains the length of the EAPOL-Key descriptor in octets, not including the Version, Packet Type and Packet Body Length fields. Congdon, et al. Informational [Page 16] RFC 3580 IEEE 802.1X RADIUS September 2003 Type The Type field is a single octet. The Key descriptor is defined differently for each Type; this specification documents only the RC4 Key Descriptor (Type = 0x01). Key Length The Key Length field is two octets. If Packet Body Length = 44 + Key Length, then the Key Field contains the key in encrypted form, of length Key Length. This is 5 octets (40 bits) for WEP, and 13 octets (104 bits) for WEP-128. If Packet Body Length = 44, then the Key field is absent, and Key Length represents the number of least significant octets from the MS-MPPE-Send-Key attribute [RFC2548] to be used as the keying material. Note that the MS- MPPE-Send-Key and MS-MPPE-Recv-Key attributes are defined from the point of view of the Authenticator. From the Supplicant point of reference, the terms are reversed. Thus the MS-MPPE-Recv-Key on the Supplicant corresponds to the MS-MPPE-Send-Key on the Authenticator, and the MS-MPPE-Send-Key on the Supplicant corresponds to the MS-MPPE-Recv-Key on the Authenticator. Replay Counter The Replay Counter field is 8 octets. It does not repeat within the life of the keying material used to encrypt the Key field and compute the Key Signature field. A 64-bit NTP timestamp MAY be used as the Replay Counter. Key IV The Key IV field is 16 octets and includes a 128-bit cryptographically random number. F The Key flag (F) is a single bit, describing the type of key that is included in the Key field. Values are: 0 = for broadcast (default key) 1 = for unicast (key mapping key) Key Index The Key Index is 7 bits. Key Signature The Key Signature field is 16 octets. It contains an HMAC-MD5 message integrity check computed over the EAPOL-Key descriptor, starting from the Version field, with the Key field filled in if present, but with the Key Signature field set to zero. For the computation, the 32 octet (256 bit) MS-MPPE-Send-Key [RFC2548] is used as the HMAC-MD5 key. Congdon, et al. Informational [Page 17] RFC 3580 IEEE 802.1X RADIUS September 2003 Key If Packet Body Length = 44 + Key Length, then the Key Field contains the key in encrypted form, of length Key Length. If Packet Body Length = 44, then the Key field is absent, and the least significant Key Length octets from the MS-MPPE-Send-Key attribute is used as the keying material. Where the Key field is encrypted using RC4, the RC4 encryption key used to encrypt this field is formed by concatenating the 16 octet (128 bit) Key-IV field with the 32 octet MS-MPPE-Recv-Key attribute. This yields a 48 octet RC4 key (384 bits).5. Security Considerations
Since this document describes the use of RADIUS for purposes of authentication, authorization, and accounting in IEEE 802.1X-enabled networks, it is vulnerable to all of the threats that are present in other RADIUS applications. For a discussion of these threats, see [RFC2607], [RFC2865], [RFC3162], [RFC3579], and [RFC3576]. Vulnerabilities include: Packet modification or forgery Dictionary attacks Known plaintext attacks Replay Outcome mismatches 802.11 integration Key management issues5.1. Packet Modification or Forgery
RADIUS, defined in [RFC2865], does not require all Access-Requests to be authenticated or integrity protected. However, IEEE 802.1X is based on EAP. As described in [3579], Section 3.1.: The Message-Authenticator attribute MUST be used to protect all Access-Request, Access-Challenge, Access-Accept, and Access-Reject packets containing an EAP-Message attribute. As a result, when used with IEEE 802.1X, all RADIUS packets MUST be authenticated and integrity protected. In addition, as described in [3579], Section 4.2.: To address the security vulnerabilities of RADIUS/EAP, implementations of this specification SHOULD support IPsec [RFC2401] along with IKE [RFC2409] for key management. IPsec ESP [RFC2406] with non-null transform SHOULD be supported, and IPsec ESP with a non-null encryption transform and authentication Congdon, et al. Informational [Page 18] RFC 3580 IEEE 802.1X RADIUS September 2003 support SHOULD be used to provide per-packet confidentiality, authentication, integrity and replay protection. IKE SHOULD be used for key management.5.2. Dictionary Attacks
As discussed in [RFC3579] Section 4.3.3., the RADIUS shared secret is vulnerable to offline dictionary attack, based on capture of the Response Authenticator or Message-Authenticator attribute. In order to decrease the level of vulnerability, [RFC2865], Section 3 recommends: The secret (password shared between the client and the RADIUS server) SHOULD be at least as large and unguessable as a well- chosen password. It is preferred that the secret be at least 16 octets. In addition, the risk of an offline dictionary attack can be further mitigated by employing IPsec ESP with a non-null transform in order to encrypt the RADIUS conversation, as described in [RFC3579], Section <IP_ADDRESS>. Known Plaintext Attacks
Since IEEE 802.1X is based on EAP, which does not support PAP, the RADIUS User-Password attribute is not used to carry hidden user passwords. The hiding mechanism utilizes MD5, defined in [RFC1321], in order to generate a key stream based on the RADIUS shared secret and the Request Authenticator. Where PAP is in use, it is possible to collect key streams corresponding to a given Request Authenticator value, by capturing RADIUS conversations corresponding to a PAP authentication attempt using a known password. Since the User- Password is known, the key stream corresponding to a given Request Authenticator can be determined and stored. The vulnerability is described in detail in [RFC3579], Section 4.3.4. Even though IEEE 802.1X Authenticators do not support PAP authentication, a security vulnerability can still exist where the same RADIUS shared secret is used for hiding User-Password as well as other attributes. This can occur, for example, if the same RADIUS proxy handles authentication requests for both IEEE 802.1X (which may hide the Tunnel-Password, MS-MPPE-Send-Key and MS-MPPE-Recv-Key attributes) and GPRS (which may hide the User-Password attribute). The threat can be mitigated by protecting RADIUS with IPsec ESP with a non-null transform, as described in [RFC3579], Section 4.2. In addition, the same RADIUS shared secret MUST NOT be used for both IEEE 802.1X authentication and PAP authentication. Congdon, et al. Informational [Page 19] RFC 3580 IEEE 802.1X RADIUS September 20035.4. Replay
As noted in [RFC3579] Section 4.3.5., the RADIUS protocol provides only limited support for replay protection. Replay protection for RADIUS authentication and accounting can be provided by enabling IPsec replay protection with RADIUS, as described in [RFC3579], Section 4.2. As with the Request Authenticator, for use with IEEE 802.1X Authenticators, the Acct-Session-Id SHOULD be globally and temporally unique.5.5. Outcome Mismatches
[RFC3579] Section 2.6.3. discusses the issues that arise when the EAP packet encapsulated in an EAP-Message attribute does not agree with the RADIUS Packet Type. For example, an EAP Success packet might be encapsulated within an Access-Reject; an EAP Failure might be sent within an Access-Accept; or an EAP Success or Failure might be sent within an Access-Challenge. As described in [RFC3579] Section 2.6.3., these conflicting messages are likely to cause confusion. To ensure that access decisions made by IEEE 802.1X Authenticators conform to the wishes of the RADIUS server, it is necessary for the Authenticator to make the decision solely based on the authentication result (Access-Accept/Reject) and not based on the contents of EAP-Message attributes, if present.5.6. 802.11 Integration
[IEEE8021X] was developed for use on wired IEEE 802 networks such as Ethernet, and therefore does not describe how to securely adapt IEEE 802.1X for use with 802.11. This is left to an enhanced security specification under development within IEEE 802.11. For example, [IEEE8021X] does not specify whether authentication occurs prior to, or after association, nor how the derived keys are used within various ciphersuites. It also does not specify ciphersuites addressing the vulnerabilities discovered in WEP, described in [Berkeley], [Arbaugh], [Fluhrer], and [Stubbl]. [IEEE8021X] only defines an authentication framework, leaving the definition of the authentication methods to other documents, such as [RFC2716]. Since [IEEE8021X] does not address 802.11 integration issues, implementors are strongly advised to consult additional IEEE 802.11 security specifications for guidance on how to adapt IEEE 802.1X for use with 802.11. For example, it is likely that the IEEE 802.11 Congdon, et al. Informational [Page 20] RFC 3580 IEEE 802.1X RADIUS September 2003 enhanced security specification will define its own IEEE 802.11 key hierarchy as well as new EAPOL-Key descriptors.5.7. Key Management Issues
The EAPOL-Key descriptor described in Section 4. is likely to be deprecated in the future, when the IEEE 802.11 enhanced security group completes its work. Known security issues include: [1] Default key-only support. IEEE 802.1X enables the derivation of per-Station unicast keys, known in [IEEE80211] as "key mapping keys." Keys used to encrypt multicast/broadcast traffic are known as "default keys". However, in some 802.11 implementations, the unicast keys, derived as part of the EAP authentication process, are used solely in order to encrypt, authenticate and integrity protect the EAPOL-Key descriptor, as described in Section 4. These implementations only support use of default keys (ordinarily only used with multicast/broadcast traffic) to secure all traffic, unicast or multicast/broadcast, resulting in inherent security weaknesses. Where per-Station key-mapping keys (e.g. unicast keys) are unsupported, any Station possessing the default key can decrypt traffic from other Stations or impersonate them. When used along with a weak cipher (e.g. WEP), implementations supporting only default keys provide more material for attacks such as those described in [Fluhrer] and [Stubbl]. If in addition, the default key is not refreshed periodically, IEEE 802.1X dynamic key derivation provides little or no security benefit. For an understanding of the issues with WEP, see [Berkeley], [Arbaugh], [Fluhrer], and [Stubbl]. [2] Reuse of keying material. The EAPOL-Key descriptor specified in section 4 uses the same keying material (MS-MPPE-Recv-Key) both to encrypt the Key field within the EAPOL-Key descriptor, and to encrypt data passed between the Station and Access Point. Multi-purpose keying material is frowned upon, since multiple uses can leak information helpful to an attacker. [3] Weak algorithms. The algorithm used to encrypt the Key field within the EAPOL-Key descriptor is similar to the algorithm used in WEP, and as a result, shares some of the same weaknesses. As with WEP, the RC4 stream cipher is used to encrypt the key. As input to the RC4 engine, the IV and key are concatenated rather than being combined within a mixing function. As with WEP, the IV is not a counter, and therefore there is little protection against reuse. Congdon, et al. Informational [Page 21] RFC 3580 IEEE 802.1X RADIUS September 2003 As a result of these vulnerabilities, implementors intending to use the EAPOL-Key descriptor described in this document are urged to consult the 802.11 enhanced security specification for a more secure alternative. It is also advisable to consult the evolving literature on WEP vulnerabilities, in order to better understand the risks, as well as to obtain guidance on setting an appropriate re-keying interval.6. IANA Considerations
This specification does not create any RADIUS attributes nor any new number spaces for IANA administration. However, it does require assignment of new values to existing RADIUS attributes. These include: Attribute Values Required ========= =============== NAS-Port-Type Token-Ring (20), FDDI (21) Tunnel-Type VLAN (13) Acct-Terminate-Cause Supplicant Restart (19) Reauthentication Failure (20) Port Reinitialized (21) Port Administratively Disabled (22)7. References
7.1. Normative References
[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2284] Blunk, L. and J. Vollbrecht, "PPP Extensible Authentication Protocol (EAP)", RFC 2284, March 1998. [RFC2865] Rigney, C., Willens, S., Rubens, A. and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000. [RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000. [RFC2867] Zorn, G., Aboba, B. and D. Mitton, "RADIUS Accounting Modifications for Tunnel Protocol Support", RFC 2867, June 2000. Congdon, et al. Informational [Page 22] RFC 3580 IEEE 802.1X RADIUS September 2003 [RFC2868] Zorn, G., Leifer, D., Rubens, A., Shriver, J., Holdrege, M. and I. Goyret, "RADIUS Attributes for Tunnel Protocol Support", RFC 2868, June 2000. [RFC2869] Rigney, C., Willats, W. and P. Calhoun, "RADIUS Extensions", RFC 2869, June 2000. [RFC3162] Aboba, B., Zorn, G. and D. Mitton, "RADIUS and IPv6", RFC 3162, August 2001. [RFC3280] Housley, R., Polk, W., Ford, W. and D. Solo, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3280, April 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. [RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication Dial In User Service) Support For Extensible Authentication Protocol (EAP)", RFC 3579, September 2003. [IEEE8021X] IEEE Standards for Local and Metropolitan Area Networks: Port based Network Access Control, IEEE Std 802.1X-2001, June 2001.7.2. Informative References
[RFC2104] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997. [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. [RFC2548] Zorn, G., "Microsoft Vendor-specific RADIUS Attributes", RFC 2548, March 1999. [RFC2607] Aboba, B. and J. Vollbrecht, "Proxy Chaining and Policy Implementation in Roaming", RFC 2607, June 1999. [RFC2716] Aboba, B. and D. Simon, "PPP EAP TLS Authentication Protocol", RFC 2716, October 1999. Congdon, et al. Informational [Page 23] RFC 3580 IEEE 802.1X RADIUS September 2003 [MD5Attack] Dobbertin, H., "The Status of MD5 After a Recent Attack." CryptoBytes Vol.2 No.2, Summer 1996. [IEEE802] IEEE Standards for Local and Metropolitan Area Networks: Overview and Architecture, ANSI/IEEE Std 802, 1990. [IEEE8021Q] IEEE Standards for Local and Metropolitan Area Networks: Draft Standard for Virtual Bridged Local Area Networks, P802.1Q, January 1998. [IEEE8023] ISO/IEC 8802-3 Information technology - Telecommunications and information exchange between systems - Local and metropolitan area networks - Common specifications - Part 3: Carrier Sense Multiple Access with Collision Detection (CSMA/CD) Access Method and Physical Layer Specifications, (also ANSI/IEEE Std 802.3- 1996), 1996. [IEEE80211] Information technology - Telecommunications and information exchange between systems - Local and metropolitan area networks - Specific Requirements Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications, IEEE Std. 802.11-1999, 1999. [Berkeley] Borisov, N., Goldberg, I. and D. Wagner, "Intercepting Mobile Communications: The Insecurity of 802.11", ACM SIGMOBILE, Seventh Annual International Conference on Mobile Computing and Networking, July 2001, Rome, Italy. [Arbaugh] Arbaugh, W., Shankar, N. and J.Y.C. Wan, "Your 802.11 Wireless Network has No Clothes", Department of Computer Science, University of Maryland, College Park, March 2001. [Fluhrer] Fluhrer, S., Mantin, I. and A. Shamir, "Weaknesses in the Key Scheduling Algorithm of RC4", Eighth Annual Workshop on Selected Areas in Cryptography, Toronto, Canada, August 2001. [Stubbl] Stubblefield, A., Ioannidis, J. and A. Rubin, "Using the Fluhrer, Mantin and Shamir Attack to Break WEP", 2002 NDSS Conference. Congdon, et al. Informational [Page 24] RFC 3580 IEEE 802.1X RADIUS September 20038. Table of Attributes
The following table provides a guide to which attributes MAY be sent and received as part of IEEE 802.1X authentication. L3 denotes attributes that require layer 3 capabilities, and thus may not be supported by all Authenticators. For each attribute, the reference provides the definitive information on usage. 802.1X # Attribute X 1 User-Name [RFC2865] 2 User-Password [RFC2865] 3 CHAP-Password [RFC2865] X 4 NAS-IP-Address [RFC2865] X 5 NAS-Port [RFC2865] X 6 Service-Type [RFC2865] 7 Framed-Protocol [RFC2865] L3 8 Framed-IP-Address [RFC2865] L3 9 Framed-IP-Netmask [RFC2865] L3 10 Framed-Routing [RFC2865] X 11 Filter-Id [RFC2865] X 12 Framed-MTU [RFC2865] 13 Framed-Compression [RFC2865] L3 14 Login-IP-Host [RFC2865] L3 15 Login-Service [RFC2865] L3 16 Login-TCP-Port [RFC2865] 18 Reply-Message [RFC2865] 19 Callback-Number [RFC2865] 20 Callback-Id [RFC2865] L3 22 Framed-Route [RFC2865] L3 23 Framed-IPX-Network [RFC2865] X 24 State [RFC2865] X 25 Class [RFC2865] X 26 Vendor-Specific [RFC2865] X 27 Session-Timeout [RFC2865] X 28 Idle-Timeout [RFC2865] X 29 Termination-Action [RFC2865] X 30 Called-Station-Id [RFC2865] X 31 Calling-Station-Id [RFC2865] X 32 NAS-Identifier [RFC2865] X 33 Proxy-State [RFC2865] 34 Login-LAT-Service [RFC2865] 35 Login-LAT-Node [RFC2865] 36 Login-LAT-Group [RFC2865] 802.1X # Attribute Congdon, et al. Informational [Page 25] RFC 3580 IEEE 802.1X RADIUS September 2003 802.1X # Attribute L3 37 Framed-AppleTalk-Link [RFC2865] L3 38 Framed-AppleTalk-Network [RFC2865] L3 39 Framed-AppleTalk-Zone [RFC2865] X 40 Acct-Status-Type [RFC2866] X 41 Acct-Delay-Time [RFC2866] X 42 Acct-Input-Octets [RFC2866] X 43 Acct-Output-Octets [RFC2866] X 44 Acct-Session-Id [RFC2866] X 45 Acct-Authentic [RFC2866] X 46 Acct-Session-Time [RFC2866] X 47 Acct-Input-Packets [RFC2866] X 48 Acct-Output-Packets [RFC2866] X 49 Acct-Terminate-Cause [RFC2866] X 50 Acct-Multi-Session-Id [RFC2866] X 51 Acct-Link-Count [RFC2866] X 52 Acct-Input-Gigawords [RFC2869] X 53 Acct-Output-Gigawords [RFC2869] X 55 Event-Timestamp [RFC2869] 60 CHAP-Challenge [RFC2865] X 61 NAS-Port-Type [RFC2865] 62 Port-Limit [RFC2865] 63 Login-LAT-Port [RFC2865] X 64 Tunnel-Type [RFC2868] X 65 Tunnel-Medium-Type [RFC2868] L3 66 Tunnel-Client-Endpoint [RFC2868] L3 67 Tunnel-Server-Endpoint [RFC2868] L3 68 Acct-Tunnel-Connection [RFC2867] L3 69 Tunnel-Password [RFC2868] 70 ARAP-Password [RFC2869] 71 ARAP-Features [RFC2869] 72 ARAP-Zone-Access [RFC2869] 73 ARAP-Security [RFC2869] 74 ARAP-Security-Data [RFC2869] 75 Password-Retry [RFC2869] 76 Prompt [RFC2869] X 77 Connect-Info [RFC2869] X 78 Configuration-Token [RFC2869] X 79 EAP-Message [RFC3579] X 80 Message-Authenticator [RFC3579] X 81 Tunnel-Private-Group-ID [RFC2868] L3 82 Tunnel-Assignment-ID [RFC2868] X 83 Tunnel-Preference [RFC2868] 84 ARAP-Challenge-Response [RFC2869] 802.1X # Attribute Congdon, et al. Informational [Page 26] RFC 3580 IEEE 802.1X RADIUS September 2003 802.1X # Attribute X 85 Acct-Interim-Interval [RFC2869] X 86 Acct-Tunnel-Packets-Lost [RFC2867] X 87 NAS-Port-Id [RFC2869] L3 88 Framed-Pool [RFC2869] L3 90 Tunnel-Client-Auth-ID [RFC2868] L3 91 Tunnel-Server-Auth-ID [RFC2868] X 95 NAS-IPv6-Address [RFC3162] 96 Framed-Interface-Id [RFC3162] L3 97 Framed-IPv6-Prefix [RFC3162] L3 98 Login-IPv6-Host [RFC3162] L3 99 Framed-IPv6-Route [RFC3162] L3 100 Framed-IPv6-Pool [RFC3162] X 101 Error-Cause [RFC3576] 802.1X # Attribute Key === X = May be used with IEEE 802.1X authentication L3 = Implemented only by Authenticators with Layer 3 capabilities Congdon, et al. Informational [Page 27] RFC 3580 IEEE 802.1X RADIUS September 20039. Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any intellectual property 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; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards- related documentation can be found in BCP-11. Copies of claims of rights made available for publication 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 implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director.10. Acknowledgments
The authors would like to acknowledge Bob O'Hara of Airespace, David Halasz of Cisco, Tim Moore, Sachin Seth and Ashwin Palekar of Microsoft, Andrea Li, Albert Young and Dave Bagby of 3Com for contributions to this document. Congdon, et al. Informational [Page 28] RFC 3580 IEEE 802.1X RADIUS September 200311. Authors' Addresses
Paul Congdon Hewlett Packard Company HP ProCurve Networking 8000 Foothills Blvd, M/S 5662 Roseville, CA 95747 Phone: +1<PHONE_NUMBER> Fax: +1<PHONE_NUMBER> EMail<EMAIL_ADDRESS>Bernard Aboba Microsoft Corporation One Microsoft Way Redmond, WA 98052 Phone: +1<PHONE_NUMBER> Fax: +1<PHONE_NUMBER> EMail<EMAIL_ADDRESS>Andrew Smith Trapeze Networks 5753 W. Las Positas Blvd. Pleasanton, CA 94588-4084 Fax: +1<PHONE_NUMBER> EMail<EMAIL_ADDRESS>John Roese Enterasys Phone: +1<PHONE_NUMBER> EMail<EMAIL_ADDRESS>Glen Zorn Cisco Systems, Inc. 500 108th Avenue N.E., Suite 500 Bellevue, WA 98004 Phone: +1<PHONE_NUMBER> Fax: +1<PHONE_NUMBER> EMail<EMAIL_ADDRESS>Congdon, et al. Informational [Page 29] RFC 3580 IEEE 802.1X RADIUS September 200312. Full Copyright Statement
Copyright (C) The Internet Society (2003). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees.  Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Congdon, et al. Informational [Page 30]


2 references to PSDynamicMember
System.Management.Automation (2)
engine\MshMemberInfo.cs (1)
3662
return new
PSDynamicMember
(Name);
FormatAndOutput\common\Utilities\Mshexpression.cs (1)
198
x = new
PSDynamicMember
(_stringValue);


You may be asking youself what is the meaning of Akan names, don't worry I gatchu! ;) Here's a brief description of what they are:
Akan names are derived from Ghanian culture. Frequently in Ghana, children are given their first name as a 'day name' which corresponds to the day in the week they were born. Here are Ghanian day names. Do you want to know what your Akan name would be if you were Ghanaian? I do too! Please fill in the form below to get your answer.Make sure to press submit!
Compare the results you get to the table below;
| # | DAY | MALE | FEMALE |
|---|---|---|---|
| 1 | Sunday | Kwasi | Akosua |
| 2 | Monday | Kwadwo | Adwoa |
| 3 | Tuesday | Kwabena | Abenaa |
| 4 | Wednesday | Kwaku | Akua |
| 5 | Thursday | Yaw | Yaa |
| 6 | Friday | Kofi | Afua |
| 7 | Saturday | Kwame | Ama |
I hope this was an interesting experience for you!! Tell a friend to tell a friend so they can all know their Akan names!


freshop
Back
Confirm your order
Firstname
Lastname
Adress
Mailing address + Zipcode
City
Email
Click here to confirm your order


cw settings
made by justin brower
Enabled
CW/TW/CN only?
only block posts containing explicit content warnings.


New Hook Job
Assignments to be Processed:
Previous Years Submissions
Exclusions
Drag file here to upload! Or browse from your computer


SignIn
SignIn
SignIn
SignIn
SignIn
SignIn
SignIn
Link
SignIn
Download
Download
SignOff
Basic
Default
Primary
Success
Info
Warning
Danger
Link
Click to Dropdown
Home
Books
Videos
Tips
Personal
Contact US
About US
Login US
Click to Dropdown
Home
Books
Videos
Tips
Personal
Contact US
About US
Login US
Click to Dropdown
Home
Books
Videos
Tips
Personal
Contact US
About US
Login US


20min Talks
Intersections of Buddhism, Art & Animation
Chair: Yin Ker
Graham Barton, Birgitta Hosea:
Animation as Mindful Practice
Hu Tze-Yue Gigi:
Animating the Buddha and His Teachings
Yin Ker:
Animation for Teaching Buddhist Art History
Masao Yokota:
Buddhism and Kawamoto’s the Book of the Dead
20min Talks
The Scope from New Wave to Pervasive Animation in Korea
Chair: Dallim Park
Jinny Hye Jin Choo:
Challenge and New Vision for the future of the Korean Indie Animation
Yumi Kim:
Animated Shorts in Korea
April Youngok Kim:
Interactive Games/Animations for the Restoration of Communication in Digital Era
Seehee Kim:
The Public Interest in Korea Animation
Yong Chu Suh:
Experimented & Expanded
20-Min talks
Animation Aesthetics
Chair: Kirsten Thompson
Sabrina Schmid:
Current global trends in animation productions by students: ideas, styles and techniques - what matters most?
Karen Kriss:
Tactility and the Changing Close-up in CGI Animation
Yanyun Chen:
On Blinking: Looking closely at Don Hertzfeldt’s animations
Chen Yun Shen:
Integration of Sexual Representation and Warfare
20-Min talks
Animation and Sound
Chair: Juan Camilo Gonzalez
Sarah-Tabea Sammel:
Drawn to Sound
Max Hattler:
Visual Mahler
Francisco Ortega, Jorgelina Orfila:
Mainstream Characters, Subaltern Voices: From "Top Cat" to "Don Gato"
Eric Adrian Patrick:
Animating the Sonic Residue
20min Talks
Asian Animation History
Chair: Hassan Muthalib
Daisy Yan Du:
The Dis/appearance of Animals in Animated Films during the Chinese Cultural Revolution, 1966-1976
Davide Benvenuti, Cheak Yen Hui:
The Artist's Spirit: Ronald Searle in Singapore during World War 2
Donna Lee Brien:
Troy Chin and the graphic memoir
20min Talks
Producing, Distributing and Reimagining Animation in Turkey and Greece
Chair: Zeynep Akcay
Zeynep Akçay:
The Turkish Animation Industry: What has changed in 15 years
Panagiotis Kyriakoulakos, Angelos Rouvas:
70 years of Greek Animation(1945-2015): How the Past informs the Future
20min Talks
Japanese Animation
Chair: Erwin Feyersinger
Katharine Buljan:
Religious Traces in Japanese Animation
Nurul Lina Mohd Nor:
A Discourse on Puppet Animation: Kihachiro Kawamoto's The Book of The Dead
Richard J. Leskosky:
Eat Fast, Fight Hard: The Role of Food and Its Preparation in Takahashi Rumiko’s Ranma ½ Japanese animation
20min Talks
Asian Musings about Animation
Chair: Ben Seide
Ai-Ting Chung:
From Dreamwork to Cyberspace: A Playground of Satoshi Kon
Chunning Guo:
Exploration of Memories Through Animated Documentary
Constance Hui Peng Goh:
Cinema of Cognition: Burton's Opening Sequences as Cultural Analyses


{% extends "base.html" %} {% import 'bootstrap/wtf.html' as wtf %} {% block app_content %} {% set help_import_package_id, help_import_package_title, help_import_package_content = help[0] %} {% set help_import_package_btn = help_import_package_id ~ '_btn' %} {% set help_import_package_dialog = help_import_package_id ~ '_dialog' %}
Import an ezEML Data Package |
{{ macros.help_button(help_import_package_btn) }} |


This page requires JavaScript to work. Please enable JavaScript and reload this page.
0
0
0
0
0
Update Circular Boxes


“It would be absurd and ridiculous to suppose that any person, however great, or learned, or wise, could employ language correctly without a knowledge of the things expressed by that language… It would not be like the sweet notes of the choral songsters of the grove, for they warble hymns of gratitude to God; not like the boding of the distant owl, for that tells the profound solemnity of night; not like the hungry lion roaring for his prey, for that tells of death and plunder; not like the distant notes of the clarion, for that tells of blood and carnage, of tears and anguish, of widowhood and orphanage. It can be compared to nothing but a Babel of confusion in which their own folly is worse confounded.” — William S Balch, Lectures On Language


Your quiz
information
You need higher level to pass for this quiz.
Last score: {{this.quizSelectionInfo.userQuiz.score}}%
Required percentage: {{this.quizSelectionInfo.quiz.minCorrectQuestionsPercentage}}%
You achieved this! with a score of {{this.quizSelectionInfo.userQuiz.score}}%. Congrats!
Your level in
{{quizSelectionInfo.categoryPreference.category.name + ': ' + quizSelectionInfo.categoryPreference.skillScore}}
View quiz dashboard


This is where I will post podcasts, coding projects, videos, and writing samples.
My name is Brendan, or Bmac. I am a young adult who resides in Orange County, California. I have many hobbies including podcasting, video games, anime, cycling, martial-arts, coding, and writing. I volunteer at my church and value the relationships in my life.  If you ever see me, please introduce yourself. I would love to meet you. I am...
For I know that iron sharpens iron.


Dev Tools
Overview
Development on the iVXjs Library could be difficult. To help streamline the process, there is an internal build tools that allows developers the ability run a local server and continuously build out as they develop. This documentation will go over some basic CLI commands that can get you started.
Requirements
To get started you will need to get node that supports ES6. To figure out which version meets this requirement you can go to this site node.green
After a suitable nodejs version is download, make sure to run npm install
.
Interactive Tutorial
For an interactive guide on contributing and developing on iVXjs, go to the Favorite Color Tutorial
npm run setup
Description
Sets up and generates static files into a public
forlder at the root. This should run only when the public folder needs to be reset or initially. The static files generated are
meant to support the Favorite Color Tutorial.
npm start
Description
Creates a webpack dev server using the the public/index.js file as the entry point. This method also will inject a basic iVXjs config so you won’t have to set it up. However, there are a few modules that will require to edit the config to load in set up information.
Properties
To set up the modules, you have to declare your properties before running npm start
MODULE_TYPE="MODULE_NAME" npm start
Availabled Properties
UI="MODULE_NAME"
- Watches the source for this UI module and injects all dependencies into the index.html file in the public folderDATA="MODULE_NAME"
- Watches the source for this data module and injects all dependencies into the index.html file in the public folderVALIDATION="MODULE_NAME"
- Watches the source for this validation module and injects all dependencies into the index.html file in the public folderANALYTICS="MODULE_NAME"
- Watches the source for this analytics module and injects all dependencies into the index.html file in the public folder
Example
If as a developer, I wanted to work on the Firebase data module and the Semantic UI module the command I would use is:
UI="semantic-ui" DATA="firebase" npm start


EL TOPO (1971)
"I do not fear killing you, for there is no death."
4 out of ****
Starring Alejandro Jodorowsky, Brontis Jodorowsky, Mara Lorenzio, Paula Romo, Jacqueline Luis; Written & Directed by Alejandro Jodorowsky; Cinematography by Rafael Corkidi
To trash EL TOPO requires no effort, for its flaws are plain to see. It makes no sense. It is punctuated by abrupt and inconsistent tonal shifts. It is full of exaggerated violence and gratuitous nudity. It features hordes of physically "abnormal" people who are paraded across the screen in service of the film's freakshow aesthetic. There are absurd gunfights and duels in which wounds are represented by immense quantities of patently fake blood. It offers itself up to harsh criticism with an abandon that is almost perverse. I loved it.
EL TOPO ignores all traditional approaches to narrative and characterization and thematic development. One can still judge it by those standards, of course, but why bother? They are meaningless within its parameters. Instead, the movie indulges all the tasteless or risky or extreme impulses which other filmmakers tiptoe around, perhaps in fear of what might be set loose. It starts as a Western of sorts, ends as an apocalyptic spiritual drama, and never bothers to explain itself in the interim. It is to be experienced, not understood.
In the opening sequence, a gunslinger in black--El Topo, played by writer/director Alejandro Jodorowsky--rides out of the desert and dismounts. Seated behind him is a naked seven-year-old boy; he too dismounts, and hunkers down in the sand. The gunslinger hands the boy a teddy bear and a picture of his mother. He tells the boy that he is a man now, and so must bury his first toy and the picture of his mother. The boy does so. They ride off, and the film is already pregnant with potential Oedipal conflicts (Freud would have a field day with this movie).
El Topo and the boy arrive in a village where the people have been slaughtered. They learn that some bandits led by The Colonel are responsible for the bloodbath. They locate them in a monastery, and slay them. El Topo then leaves the boy in the care of the monks and rides off into the desert with The Colonel's kept woman. She asks El Topo to prove his love to her by duelling four mysterious Masters. He agrees to do so. None of these events are linked by recognisable logic. With either a sinking heart or a sense of liberation--depending on your taste--you abandon all hope of making sense of what is going on.
Events become stranger, until the action seems to exist as an excuse for a succession of grotesque and memorable images. Some of these images are merely parodic: gunfights which end in characters dying protracted deaths after being shot by an inordinate number of bullets. Some are absurd and blatant Freudianisms: a woman drinking a jet of water spurting from a phallic rock in the middle of a desert. Some are outrageous and inspired: in a church in a strange town, members of the congregation prove their faith by taking a gun loaded with a single bullet from the minister and playing Russian roulette--those who have no faith die.
There is much more. It is simple enough to describe EL TOPO as a catalogue of freakish, disconnected images, because that is how it unfolds. On a narrative and thematic level, it never seems to add up, nor does that seem to be the intention. The overall effect is, however, wildly subversive. Jodorowsky explodes conventions at every turn, upsetting preconceived notions of gender and character.  Men kiss men. Men dress up as women. Men speak with the voices of women, and vice versa. The protagonist dies, and is reborn, his black hair now white, and he becomes a benign pilgrim instead of a murderous gunslinger. All is in flux.
The gunslinger's rebirth divides the movie in two. The second half is better; it seems more purposeful. El Topo comes to life in a cavern, inhabited by crippled, misshapen, and otherwise deformed people. They are trapped, wishing to escape to a nearby town. El Topo shaves his head, dons a monkish robe, leaves the cavern with his midget attendant, and goes to the town. It is inhabited by people dressed in incongruous Victorian clothing. They act out strange parodies of recognisable social situations--a church service, a boxing match, a brothel--as if their behaviour is twisted out of true by the force of the primal urges they are striving to contain.
El Topo's actions lead to an apocalyptic finale: a confrontation between the "civilized" folk of the town and those who have emerged, like insects, from their hole in the mountain, the very embodiment of the marginalized and repressed of society. This is the return of the unconscious, with a vengeance. Jodorowsky's sympathies are clearly with the outcasts. His film stands in relation to mainstream cinema as the pariahs do to the townfolk. It reveals what the majority prefers to keep concealed. It embraces the physical in all its manifestations, human and animal, beautiful and grotesque. It is saturated with acts of violence, blood, sex, bodies of all kinds.
It is unlikely that anyone will ever call EL TOPO a perfect movie. In some sense, it is not even a good movie. But it is unique. And while good movies are plentiful, unique movies are, by definition, one of a kind, and so to be cherished. The presence of other directors can be felt--Fellini, Bu˝uel, and, in the Western-derived material, Sergio Leone--but even if those filmmakers had never made a single movie, one senses that EL TOPO would look much as it does now. It is the work of a man possessed by not one vision but by a thousand: a man who wants to cram them all into two hours, and will use whatever internal logic suits his purposes to achieve that end.
The result is a kind of divine madness, celebratory in its excess. Werner Herzog, one of the other great mad visionaries of the cinema, has said that the twentieth century is starved for great images. If we are starving, then EL TOPO is like the miracle of the loaves and fishes: with a few primitive ingredients, it can nourish multitudes.
Review by David Dalgleish (subjective.freeservers.com) -- February 9th, 2000
The review above was posted to the
rec.arts.movies.reviews newsgroup (de.rec.film.kritiken for German reviews).
The Internet Movie Database accepts no responsibility for the contents of the
review and has no editorial control. Unless stated otherwise, the copyright
belongs to the author.
Please direct comments/criticisms of the review to relevant newsgroups.
Broken URLs inthe reviews are the responsibility of the author.
The formatting of the review is likely to differ from the original due
to ASCII to HTML conversion.
Related links: index of all rec.arts.movies.reviews reviews


|
MoveToCode
|
A set of parameter values that are used to define the metallic-roughness material model from Physically-Based Rendering (PBR) methodology. More...
Public Attributes | |
| float[] | baseColorFactor = { 1f, 1f, 1f, 1f } |
| The RGBA components of the base color of the material. More... | |
| GltfTextureInfo | baseColorTexture |
| The base color texture. More... | |
| double | metallicFactor = 1 |
| The metalness of the material. More... | |
| double | roughnessFactor = 1 |
| The roughness of the material. More... | |
| GltfTextureInfo | metallicRoughnessTexture |
| The metallic-roughness texture has two components. More... | |
| Public Attributes inherited from Microsoft.MixedReality.Toolkit.Utilities.Gltf.Schema.GltfProperty | |
| readonly Dictionary< string, string > | Extensions = new Dictionary<string, string>() |
| https://github.com/KhronosGroup/glTF/blob/master/specification/2.0/schema/extension.schema.json More... | |
| readonly Dictionary< string, string > | Extras = new Dictionary<string, string>() |
| https://github.com/KhronosGroup/glTF/blob/master/specification/2.0/schema/extras.schema.json More... | |
A set of parameter values that are used to define the metallic-roughness material model from Physically-Based Rendering (PBR) methodology.
| float [] Microsoft.MixedReality.Toolkit.Utilities.Gltf.Schema.GltfPbrMetallicRoughness.baseColorFactor = { 1f, 1f, 1f, 1f } |
The RGBA components of the base color of the material.
The fourth component (A) is the opacity of the material. These values are linear.
| GltfTextureInfo Microsoft.MixedReality.Toolkit.Utilities.Gltf.Schema.GltfPbrMetallicRoughness.baseColorTexture |
The base color texture.
This texture contains RGB(A) components in sRGB color space. The first three components (RGB) specify the base color of the material. If the fourth component (A) is present, it represents the opacity of the material. Otherwise, an opacity of 1.0 is assumed.
| double Microsoft.MixedReality.Toolkit.Utilities.Gltf.Schema.GltfPbrMetallicRoughness.metallicFactor = 1 |
The metalness of the material.
A value of 1.0 means the material is a metal. A value of 0.0 means the material is a dielectric. Values in between are for blending between metals and dielectrics such as dirty metallic surfaces. This value is linear.
| GltfTextureInfo Microsoft.MixedReality.Toolkit.Utilities.Gltf.Schema.GltfPbrMetallicRoughness.metallicRoughnessTexture |
The metallic-roughness texture has two components.
The first component (R) contains the metallic-ness of the material. The second component (G) contains the roughness of the material. These values are linear. If the third component (B) and/or the fourth component (A) are present, they are ignored.
| double Microsoft.MixedReality.Toolkit.Utilities.Gltf.Schema.GltfPbrMetallicRoughness.roughnessFactor = 1 |
The roughness of the material.
A value of 1.0 means the material is completely rough. A value of 0.0 means the material is completely smooth. This value is linear.


{% extends 'layout.html' %} {% block pageTitle %} Check your answers template - NHS.UK prototype kit {% endblock %} {% block content %}
Consent: {{ data['have-consent'] }} Change
Registered doctor: {{ data['list'] }} Change
Needs help with: {{ data['support-needs'] }} Change
First name: {{ data['first-name'] }}
Middle name: {{ data['middle-name'] }}
Surname: {{ data['surname'] }}
Address: {{ data['address-postcode'] }}
Date of birth: {{ data['day'] }}
Phone number: {{ data['contact-number'] }}
Ethnicity: {{ data['ethnicity'] }}
School: {{ data['school'] }}
Person 1 name: {{ data['person-one-name'] }}
Relationship {{ data['person-one-relationship'] }}
Date of birth {{ data['person-one-relationship'] }}
School {{ data['person-one-relationship'] }}
By submitting this notification you are confirming that, to the best of your knowledge, the details you are providing are correct.
Your details with be sent to Rose Medical Practice to begin your registration.
Accept and send referral


Part I
Well after all of the recent talk about Morning Glory, I tried it for the first time. In fact this is really, my first experience with psychedelics, other than grass.
Very Strange. First off, I decided that an appropriate dose would be about 100 seeds. I guess that this would correspond to approximately 100ug LSA. I took the seeds and ground them very fine with my coffee grinder. I remembered that some posts mentioned that nausea, is a common side effect, so I decided to use an enema. Big mistake. I mixed the ground powder with water, and poured the solution into the bag. Something in the seeds swelled up unbelievably, clogging the tube. What a mess. Eventually, I got most of the liquid inside of me, and I will omit the gory details.
Within maybe, five minutes, the tiles in the bathroom began to swim, almost as though my vision didn't like the hard edged lines of the grout. Circular objects didn't present as much of a problem, only anything with a corner. I decided to have a warm bath. I drew the bath and soaked for maybe fifteen minutes.
When I closed my eyes, I found that I was perfectly calm and centered, as if nothing was going on. Then I'd open them up, and everything would look O.K. for a couple of seconds, and then would start to swim. Closing my eyes, would bring me back together again. I lost sense of time, though, and I started to feel very tired. I don't know if it was the MG or the bath, that was making me feel that way.
I lay down on the couch, and sleep rapidly came over me. It was almost as if I couldn't keep my eyes open. I don't remember much after this, except for a small part of the dream which I had.
Towards the end, when I was getting up or preparing to wake up, I was in some type of garden. It was somewhat tropical, but it didn't quite feel natural. Almost as though it was cultivated. All of the normal elements, which I associate with nature were absent. There were no sounds, no feeling of sunlight, no winds. And yet this garden was very dense with plants. It wasn't even as though I was in the garden, I was watching myself in the garden. (It's strange, as I try to write about this, it becomes hazy.) Because, I WAS in the garden?!?!
All in all, a very strange experience, although I only remember a few minutes at the start, and those split seconds before I woke from the dream. The hours in between are gone. Definitely, interesting, though. I felt strange for the rest of the day, and since then have had a couple of days, where I just felt 'right'.
Now for the questions, How can I eliminate whatever material swells up? I've got some of the information on extraction, but chemistry is not my field. Is Robonsol lighter fluid a substitute for ether? I'm not sure if Robonsol is like Zippo or not. (And I'll be damned, if I can figure out what 'ether' is.) or anything about solvents. (If I can't even do a MG extraction, what on earth am I going to do with canary seed.)
Second, is the extraction into ethanol, only to deal with nausea? I guess that an enema eliminates this or am I wrong.
Then as far as the experience itself goes:
Does MG, have a sedating effect. This stuff knocked me out.
Second, what is this entity that's spoken of. Somehow, I could say that there was a definite presence there with me, but I couldn't identify it. Although it did seem that we were communing.
This experience was definitely interesting. Nothing at all like my yoga experiences. And definitely worth repeating.
Part II
Well, I finally did the morning glory trip. The first time I tried it, I ended up falling asleep, and didn't get the whole expereince. But it left me feeling alive and happy for days afterwards. Now there's any emptiness in my soul. But it's not an emptyness, from using the potion. No, quite the opposite. It's an emptiness, because of what it is that isn't here right now. (Semantics of dubious distinction.)
Let me just say, that I have never had an experience like this. Sure, I've smoked a couple of joints, and tried one or two substances, but this is beyond all description. I took 500 Heavenly blue seeds, ground them up into a fine powder; and did a bit of an extraction. I dried the seed powder, mixed it in a glass with a Jolt and a shot of Vodka. And tried to down as much of it as I could. This stuff is awful tasting.
I drank the potion at 10:00 last night. What a night I've had. it's beyond words. I've practiced yoga for many years now, and I think it really helped me for this experience. By 11:00, I felt strange, but in an unquantifiable way. I'm posting from Canada, and we had our big birthday celebration here yesterday, so I wanted to go out and enjoy myself. I tried to have a bath, but I had forgotten how to. Or more precisely, I just wasn't washing parts of my body by rote. I had to think, of what I was doing. At 12:00, I finally made it out the door.
And then the adventure began...
What an adventure. Bars are an absolutely fascinating place. Who needs a rave. It isn't a time or a space, it's a frame of reference. This was indescribable. I finally understood, Warhol's, statement about everyone's 15 minutes. And I understood about everyone's game. It's amazing how all of the pretence, all of the falsehood melts away. And it's great how you can take someone's energy and build it, or take it and leave it behind. A feeling of sadness can just flood you, and then in a moment it's gone, because you realize it's just a feeling, but ecstasy is different. THAT stays. Call it a real world, where all of the nonsense just disappears.
On the dance floor, the energy was fantastic. The crowd was all up and together because of the Canada day celebration. And the music and the sounds and the lights. (This is all beyond words.) But I heard the sounds of the natives, a chant, but it wasn't; more like a click sound, the sound of everyone who has taken it before. (This is all beyond words.) But I bought, things, and then just left them. It's amazing, that you can just go and give someone money, and then they'll give you something. THIS WAS A REVELATION. Dancing to a remix of the Village People's YMCA, and doing the bump and grind, and chattanooga with everyone on the dance floor.  'Life's Short, stay hard,' it said. People would read it, and then look up at me, (I'm very tall), and then they would just get this beautiful smile. Having people dance, is incredible. Especially natives. It's just beyond words.
I got tired after a while, and went and bought some chicken wings. Not to actually eat, mind you. (That would have made me ill.) But just the actual experience. But I did ask the bartender for a couple pieces of lime. The fruit was far more nourishing than anything else. And from there the experience began.
I'll leave out the part about going to the other bar, and seeing more games of a different type. And of the two people who were screwing in their motor home, parked outside of a funeral parlour which was just being built, and of the Masonic temple, with the two dead tree stumps guarding the front entrance. And get to the garden. The garden in the middle of the city. I realized that the key to a garden are the spirits who live there. And how important it is to make a place for them. I stayed in the garden till dawn, feeling the soft earth, give under my every step, the magnetic draw of fallow ground, the dancing of water over the rocks, and the waterfalls. This garden is in the middle of the city, with soaring skyscrapers all around. This little piece of paradise in the middle of the city.
The only thing I can say is wow. Total amazement. I know this all sounds very disjointed, but it's beyond all words.
This post is getting far too long. There is so much to say, And yet words can't possibly do it any justice. If there is any such thing as a cathartic experience, this is it. It's been enough for me to think of reevaluating my entire life.
Do I recommend it to anyone? Well, yes, and no. I think if the time and the mood is right, it will happen. There's no need to go searching for it somewhere else, because happiness, and bliss isn't anywhere else. It's all right here, right under our noses, if we would only stop the nonsense, and listen. 'Stop Making Sense', indeed, 'True Stories' from the twilight zone. And a foro.
Experience Reports are the writings and opinions of the individual authors who submit them.
Some of the activities described are dangerous and/or illegal and none are recommended by Erowid.


# install.packages("devtools")
devtools::install_github("CogDisResLab/KRSA")
The KRSA Vignette is now available in R (using browseVignettes(“KRSA”)). To have the KRSA Vignette locally accessible, the build_vignettes argument must be set as TRUE when installing the package:
devtools::install_github(build_vignettes = T)
R (>= 3.5.0) version
For Windows users:
installment of Rtools (https://cran.r-project.org/bin/windows/Rtools/).
Kinome Random Sampling Analyzer, or KRSA, is an R Shiny application that automates many of the steps required to analyze PamChip datasets, including peptide filtering, random sampling, heatmap generation, and kinase network generation. This new software makes analyzing kinome array datasets accessible and eliminates much of the human workload that the previous method required. More importantly, KRSA represents the results in a bigger biological context by visualizing altered kinome signaling networks instead of individual kinases.
More info on the PamStation12 platform can be found here: PamGene
The user-supplied kinase-peptide association file and the raw kinome array data file are selected as input. The kinase-peptide associations should be based on the known/predicted interactions found in databases like GPS 3.0 and Kinexus Phosphonet. Expected inputs should be formatted as shown in the example files: vignettes/data_files/example_Median_SigmBg.txt
For technical issues, please start a new issue on this repo: Link
For biological interpretation questions please email: khaled.alganem@rockets.utoledo.edu


Relive the logic of Crick and colleagues as they discover the "words" of the genetic code.
Sign in or Sign up to see scenarios.


Deep Learning Concept 6: cross entropy loss
The most common loss function used in machine learning are MAE (mean absolute error), MSE (mean squared error) and cross entropy loss. This blog introduces cross entropy loss.
We calcualte this loss for classification model which outputs a probability for each class.
Explanation with intuition
this loss increases when the probability of prediction diverges from ground truth, namely if the gt label is 1 while we predict 0.1 probability for label 1. Because we are calculating log, the loss increase rapidly when the probability is close to 0.
Explanation with math
Calculation of probability happens only when the prediction matches with the ground truth.
For binary classification:
where p is the probability for class 1.
For multi-class classification:
where M is number of classes;
y is the binary indicator (0 or 1) if class label c is the correct classification for observation o;
p is the predicted probability observation o is of class c..
Explanation with code
Code for binary classification:
def CrossEntropy(yHat, y):
if y == 1:
return -log(yHat)
else:
return -log(1 - yHat)
Code for multi-class classification:
def CrossEntropy(probability_list, ground_truth_label):
# probability_list is a list of probability that corresponds with each label
# ground_truth_label is an integer ranging from 0 to len(probability_list) - 1
return -log(probability_list[ground_truth])


Project Blurple Appeals
Case information
Ban
Kick
Mute
Warning
User Statement
Why should we appeal your punishment?


{% extends "layout.html" %} {% block propositionHeader %} {% include "includes/propositional_navigation.html" %} {% endblock %} {% block content %} {% include "includes/main_nav.html" %} Settings - amend user {% set currentSettingsPage = 'maintainUser' %} {% include "includes/settings_menu.html" %} Confirmation {%if data.amendUserOption === 'nameChange' %} You are about to change a user from {{data.nameChangeFrom}} to {{data.nameChangeTo}} {%else%} You are about to remove {{data.userToRemove}} from the workcoach list {%endif%} Are you sure you want to do this? Yes No {% endblock %}
Confirmation
You are about to change a user from {{data.nameChangeFrom}} to {{data.nameChangeTo}}
You are about to remove {{data.userToRemove}} from the workcoach list
Are you sure you want to do this?