/netbsd/external/apache2/llvm/dist/llvm/utils/release/ |
H A D | test-release.sh | 292 Phase="$1" 352 Phase="$1" 388 2>&1 | tee $LogDir/llvm.configure-Phase$Phase-$Flavor.log 394 2>&1 | tee $LogDir/llvm.configure-Phase$Phase-$Flavor.log 400 Phase="$1" 414 2>&1 | tee $LogDir/llvm.make-Phase$Phase-$Flavor.log 419 2>&1 | tee $LogDir/llvm.install-Phase$Phase-$Flavor.log 424 Phase="$1" 437 2>&1 | tee $LogDir/llvm.check-Phase$Phase-$Flavor.log ) ; then 438 deferred_error $Phase $Flavor "check-all failed" [all …]
|
/netbsd/crypto/dist/ipsec-tools/src/racoon/rfc/ |
H A D | draft-ietf-ipsec-isakmp-hybrid-auth-05.txt | 45 used within Phase 1 of the Internet Key Exchange (IKE). The proposed 51 establish, at the end of Phase 1, an IKE SA which is unidirectionally 53 Phase 1 is immediately followed by an X-Auth Exchange [XAUTH]. The 99 Mutual authentication within Phase 1 is now discussed in [XAUTH]. 104 during Phase 1. 124 is based on Phase 1 Exchange, while the latter authenticates the 213 the Phase 1 authentication methods described in [XAUTH] should be 291 Phase 1 Exchange can use either Aggressive Mode or Main Mode. The 292 initiator of the Phase 1 Exchange can be either the Client or the 296 The Phase 1 Exchange MUST be immediately followed by a Transaction [all …]
|
H A D | rfc3947.txt | 67 3. Phase 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 89 needed in IKE Phase 1 for NAT-Traversal support. This includes 133 3. Phase 1 136 the path between the two IKE peers occurs in IKE [RFC2409] Phase 1. 178 exchange of vendor ID payloads. In the first two messages of Phase 268 The following example is of a Phase 1 exchange using NAT-Traversal in 287 The following example is of Phase 1 exchange using NAT-Traversal in 354 Similarly, if the responder has to rekey the Phase 1 SA, then the 368 Here is an example of a Phase 1 exchange using NAT-Traversal in Main 436 After Phase 1, both ends know whether there is a NAT present between
|
H A D | draft-ietf-ipsec-nat-t-ike-08.txt | 67 3. Phase 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 90 needed in IKE Phase 1 for NAT-Traversal support. This includes detecting 131 3. Phase 1 134 the path between the two IKE peers occurs in IKE [RFC-2409] Phase 1. 162 exchange of vendor ID payloads. In the first two messages of Phase 1, 250 An example of a Phase 1 exchange using NAT-Traversal in Main Mode 262 An example of Phase 1 exchange using NAT-Traversal in Aggressive Mode 323 Similarly, if the responder needs to rekey the Phase 1 SA, then the 337 Here is an example of a Phase 1 exchange using NAT-Traversal in Main 404 After the Phase 1 both ends know if there is a NAT present between them.
|
H A D | rfc2409.txt | 268 Phase 1 is where the two ISAKMP peers establish a secure, 544 intent. When using public keys for authentication, the Phase 1 547 Phase 1 exchanges with different authentication options. 549 5.1 IKE Phase 1 Authenticated With Signatures 623 5.2 Phase 1 Authenticated With Public Key Encryption 847 5.4 Phase 1 Authenticated With a Pre-Shared Key 881 5.5 Phase 2 - Quick Mode 1280 7.1 Phase 1 using Main Mode 1375 7.2 Phase 2 using Quick Mode 1494 Using a single ISAKMP Phase 1 negotiation makes subsequent Phase 2 [all …]
|
H A D | rfc3715.txt | 204 Protocol (IKE) Phase 1 [RFC2409] or Phase 2, modification of the 210 In order to avoid use of IP addresses as IKE Phase 1 and Phase 2 217 certificates are exchanged in Phase 1. While use of USER_FQDN or 231 Since the source address in the Phase 2 identifier is often used 250 Phase 2 identifiers, they can negotiate overlapping SPD entries 412 problems with re-keying, since Phase 1 re-keys typically will not 766 claimed within the original IKE Phase 1 and Phase 2 security
|
H A D | draft-ietf-ipsec-nat-t-ike-00.txt | 66 3. Phase 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 106 3. Phase 1 114 exchange of vendor strings; in Phase 1 two first messages, the vendor id 221 After the Phase 1 both ends know if there is a NAT present between. The
|
H A D | draft-ietf-ipsec-nat-t-ike-01.txt | 66 3. Phase 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 106 3. Phase 1 141 exchange of vendor strings; in Phase 1 two first messages, the vendor id 247 After the Phase 1 both ends know if there is a NAT present between. The
|
H A D | rfc2408.txt | 1133 Phase 1 exchange, prior to completing the establishment of an SA. 1307 original ISAKMP Phase 2 SA negotiation. This is done to 1321 Phase 2 SA negotiation message following a Phase 1 exchange or 1326 Phase 2 SA negotiation message or encrypted traffic), then 1355 is randomly generated by the initiator of the Phase 2 1506 be used for any protocol during the Phase 2 exchange. The 2116 Notification which occurs during, or is concerned with, a Phase 1 2135 Notification which occurs during, or is concerned with, a Phase 2 3167 meterial during an ISAKMP Phase 1 negotiation, there will be no 3987 material during an ISAKMP Phase 1 negotiation there will be no [all …]
|
H A D | rfc2407.txt | 79 o define the syntax for DOI-specific SA Attributes (Phase II) 140 Identification Payload in at least one of the Phase I Oakley 306 simultaneous negotiation of multiple Phase II security protocol 327 Phase I of the ISAKMP protocol. The specific protection mechanism 365 As part of an ISAKMP Phase I negotiation, the initiator's choice of 369 lists the defined ISAKMP Phase I Transform Identifiers for the 650 The following SA attribute definitions are used in Phase II of an IKE 1031 During Phase I negotiations, the ID port and protocol fields MUST be 1614 o added restriction for ID port/protocol values for Phase I
|
/netbsd/external/apache2/llvm/dist/llvm/lib/Passes/ |
H A D | PassBuilder.cpp | 522 static bool isLTOPreLink(ThinOrFullLTOPhase Phase) { in isLTOPreLink() argument 523 return Phase == ThinOrFullLTOPhase::ThinLTOPreLink || in isLTOPreLink() 524 Phase == ThinOrFullLTOPhase::FullLTOPreLink; in isLTOPreLink() 579 isLTOPreLink(Phase))); in buildO1FunctionSimplificationPipeline() 966 ThinOrFullLTOPhase Phase) { in buildInlinerPipeline() argument 1026 buildFunctionSimplificationPipeline(Level, Phase))); in buildInlinerPipeline() 1039 Phase != ThinOrFullLTOPhase::ThinLTOPostLink) in buildModuleSimplificationPipeline() 1106 if (Phase != ThinOrFullLTOPhase::ThinLTOPreLink && in buildModuleSimplificationPipeline() 1107 Phase != ThinOrFullLTOPhase::FullLTOPreLink) in buildModuleSimplificationPipeline() 1127 if (Phase == ThinOrFullLTOPhase::ThinLTOPostLink) in buildModuleSimplificationPipeline() [all …]
|
/netbsd/external/bsd/wpa/dist/hostapd/ |
H A D | hostapd.eap_user | 23 # EAP-PEAP, EAP-TTLS, and EAP-FAST require Phase 2 configuration. 41 # version based on the Phase 1 identity. Without this flag, the EAP 58 # Phase 1 users 85 # Phase 2 (tunnelled within EAP-PEAP or EAP-TTLS) users
|
/netbsd/external/apache2/llvm/dist/llvm/include/llvm/Passes/ |
H A D | PassBuilder.h | 330 ThinOrFullLTOPhase Phase); 348 ThinOrFullLTOPhase Phase); 353 ThinOrFullLTOPhase Phase); 708 ThinOrFullLTOPhase Phase);
|
/netbsd/crypto/dist/ipsec-tools/src/racoon/samples/ |
H A D | racoon.conf.sample-natt | 58 # Phase 1 configuration (for ISAKMP SA) 89 # Phase 2 proposal (for IPsec SA)
|
/netbsd/external/bsd/wpa/dist/wpa_supplicant/ |
H A D | eap_testing.txt | 236 packet from Supplicant looks like the one sent in the Phase 1. The 237 server generates a valid looking reply in the same way as in Phase 256 seems to get confused and fails to send proper Phase 2 data. 265 seems to get confused and fails to send proper Phase 2 data. 306 (Failed to decrypt Phase 2 data)
|
/netbsd/share/locale/ctype/ |
H A D | ja_JP.SJIS.src | 6 * (C) Sin'ichiro MIYATANI / Phase One, Inc 19 * This product includes software developed by Phase One, Inc. 20 * 4. The name of Phase One, Inc. may be used to endorse or promote products
|
/netbsd/external/apache2/llvm/dist/llvm/docs/ |
H A D | LinkTimeOptimization.rst | 148 Phase 1 : Read LLVM Bitcode Files 166 Phase 2 : Symbol Resolution 175 Phase 3 : Optimize Bitcode Files 186 Phase 4 : Symbol Resolution after optimization
|
/netbsd/external/apache2/llvm/dist/llvm/include/llvm/Transforms/IPO/ |
H A D | Attributor.h | 1132 if (ForceUpdate && Phase == AttributorPhase::UPDATE) 1142 if (Phase == AttributorPhase::SEEDING && !shouldSeedAttribute(AA)) { 1187 if (Phase == AttributorPhase::MANIFEST) { 1194 AttributorPhase OldPhase = Phase; 1195 Phase = AttributorPhase::UPDATE; 1199 Phase = OldPhase; 1271 if (Phase == AttributorPhase::SEEDING || Phase == AttributorPhase::UPDATE) 1734 } Phase = AttributorPhase::SEEDING;
|
/netbsd/external/gpl3/gcc.old/dist/libgcc/ |
H A D | unwind.inc | 35 _Unwind_Resume and we'll continue Phase 2 there. */ 96 /* Phase 1: Search. Unwind the stack, calling the personality routine
|
/netbsd/external/gpl3/gcc/dist/libgcc/ |
H A D | unwind.inc | 35 _Unwind_Resume and we'll continue Phase 2 there. */ 96 /* Phase 1: Search. Unwind the stack, calling the personality routine
|
/netbsd/external/apache2/llvm/dist/clang/lib/Driver/ |
H A D | Driver.cpp | 3620 for (phases::ID Phase : types::getCompilationPhases(HeaderType)) in handleArguments() local 3621 ClangClPch = ConstructPhaseAction(C, Args, Phase, ClangClPch); in handleArguments() 3717 for (phases::ID Phase : PL) { in BuildActions() local 3721 Current, InputArg, Phase, PL.back(), FullPL); in BuildActions() 3726 if (Phase == phases::Link) { in BuildActions() 3737 if (Phase == phases::IfsMerge) { in BuildActions() 3747 if (Phase == phases::Precompile && HeaderModuleAction && in BuildActions() 3826 for (auto Phase : PhaseList) { in BuildActions() local 3827 switch (Phase) { in BuildActions() 3842 assert(Phase == PhaseList.back() && in BuildActions() [all …]
|
/netbsd/external/apache2/llvm/dist/llvm/docs/Proposals/ |
H A D | VectorPredication.rst | 74 - Phase out VP intrinsics, only keeping those that are not equivalent to
|
/netbsd/external/bsd/openldap/dist/doc/rfc/ |
H A D | rfc3928.txt | 93 4.3.1. Returning Results During the Persistent Phase . . 15 94 4.3.2. No Mixing of Sync Phase with Persist Phase. . . . 16 95 4.3.3. Returning Updated Results During the Sync Phase . 16 123 5.6. Multiple Copies of Same Entry During Sync Phase. . . . . 21 131 6.4. Persist Phase Response Time. . . . . . . . . . . . . . . 23 832 4.3.1. Returning Results During the Persistent Phase 847 4.3.2. No Mixing of Sync Phase with Persist Phase 856 4.3.3. Returning Updated Results During the Sync Phase 1158 5.6. Multiple Copies of Same Entry During Sync Phase 1263 6.4. Persist Phase Response Time
|
/netbsd/sys/arch/ |
H A D | README | 8 amigappc powerpc 20000525 Phase 5 Amiga
|
/netbsd/external/apache2/llvm/dist/clang/include/clang/Driver/ |
H A D | Driver.h | 505 Compilation &C, const llvm::opt::ArgList &Args, phases::ID Phase,
|