diff --git a/doc/design/arch/vic-port-layer-overview.md b/doc/design/arch/vic-port-layer-overview.md
index f963e8025a..346ad68dcc 100644
--- a/doc/design/arch/vic-port-layer-overview.md
+++ b/doc/design/arch/vic-port-layer-overview.md
@@ -40,4 +40,4 @@ It stands to reason that Networking, Storage and Execution are obvious areas for
 
 For example, what is a container storage Volume and how should one be configured? The Port Layer API should be responsible for deciding what vSphere construct most appropriately represents a Volume and also that it is configured appropriately. It should do this based on the parameters passed in, the vSphere features currently installed in the system and the resources that the tenant has the authorization to access. It can pass back a handle to that Volume that can then be used in the creation of a container. By doing this, the Port Layer made a choice about the most appropriate underlying representation and it also made sure it was appropriately configured and indexed.
 
-To some extent there is an inevitable overlap with the goals of other projects in this sphere, such as https://github.com/opencontainers/runc. While this is hardly surprising given that the Port Layer is attempting to make opinionated choices in exactly the same problem domain, it would be wrong to infer that this makes it an intentional fragementation or competing API. It is our explicit intention that the two should be entirely complimentary and that the Port Layer should be the lowest level of abstraction that a VIC implementation of runc would end up calling. If the abstractions are correct, it should be just as possible to build an implementation of https://github.com/coreos/rkt/blob/master/Documentation/app-container.md using the same APIs.
+To some extent there is an inevitable overlap with the goals of other projects in this sphere, such as https://github.com/opencontainers/runc. While this is hardly surprising given that the Port Layer is attempting to make opinionated choices in exactly the same problem domain, it would be wrong to infer that this makes it an intentional fragmentation or competing API. It is our explicit intention that the two should be entirely complimentary and that the Port Layer should be the lowest level of abstraction that a VIC implementation of runc would end up calling. If the abstractions are correct, it should be just as possible to build an implementation of https://github.com/coreos/rkt/blob/master/Documentation/app-container.md using the same APIs.
diff --git a/lib/install/validate/validator.go b/lib/install/validate/validator.go
index f79ef54600..5c0e6fbc36 100644
--- a/lib/install/validate/validator.go
+++ b/lib/install/validate/validator.go
@@ -401,7 +401,7 @@ func (v *Validator) credentials(ctx context.Context, input *data.Data, conf *con
 
 	vimClient, err := vim25.NewClient(ctx, soapClient)
 	if err != nil {
-		v.NoteIssue(fmt.Errorf("Failed to create client for validaiton of operations credentials: %s", err))
+		v.NoteIssue(fmt.Errorf("Failed to create client for validation of operations credentials: %s", err))
 		return
 	}