Changes to resolve github issue #6 filed by Greg.

content/en/Architecture/onboarding/_index.md

@@ -85,8 +85,9 @@ in the data center and assigning them to a connector. Its upto the customer to d
 together but apps grouped together should have similar security requirements. An AppGroup is mapped to a
 Connector, hence this step basically defines the Connectors.
 
-An AppGroup is also created in controller.nextensio.net with just another username (in email id format)
-and password ! Customer also specifies the URLs for the applications that are members of the AppGroup.
+An AppGroup is also created in controller.nextensio.net with just another username (in email id format but
+does not need to be a valid email ID) and password ! Customer also specifies the URLs for the applications
+that are members of the AppGroup.
 For example, if the customer domain is awesomecustomer.com, App-X might have the URL appx.awesomecustomer.com
 and App-Y might be appy.awesomecustomer.com.
 
@@ -97,7 +98,7 @@ Add AppGroup
 For initial bootstrapping, the comment about "You have no attributes for AppGroup" can be ignored. It will be 
 covered in step 4 below and also explained in more detail in section [Policies and Attributes](/architecture/policyattr.html)
 
-* The AppGroup ID is an email id. 
+* The AppGroup ID is any unique ID in an email format (does not have to be a valid email ID).
 * The AppGroup Name is just a descriptive string
 * The AppGroup Compute Pods (default 1). This represents the number of connectors per AppGroup ID. There can be multiple connectors for scale (load balancing) and/or redundancy. The default value of one connector is a good start!
 * Services: in our example, customer will enter the application URLs appx.awesomecustomer.com, appy.awesomecustomer.com

content/en/Configurations/appgroups/_index.md

@@ -51,7 +51,7 @@ based at least on similar security requirements so that an access control policy
 connector level. Further sub-grouping can always be done based on things like bandwidth and/or latency
 requirements.
 
-Every AppGroup is expected to have an id in email id format in the tenant's domain, eg., [email protected]
+Every AppGroup is expected to have an email id format in the tenant's domain, eg., [email protected]
 for the tenant awesomecustomer.com. Note that this id does not have to be a valid email id.
 As additional information about the AppGroup, a descriptive name also needs to be provided. There may be
 additional informational fields provided in future for urgent contact information of the admin, etc.
@@ -136,8 +136,8 @@ AppGroup Configuration
 :-------------------------:
 ![](/configurations/appgroups/appgroup_add.jpg)
 
-* AppGroup ID: This is just an email id that will uniquely identify and authenticate an appgroup, 
-note that this does NOT have to be a valid email, it just needs to be in an email id format as
+* AppGroup ID: This is just in an email id format that will uniquely identify and authenticate an appgroup.
+Note that it does NOT have to be a valid email id, it just needs to be in an email id format as
 of today.
 
 * AppGroup Name: Name is just any descriptive string