Network december release --- DDoS policy customization

.github/CONTRIBUTING.md

@@ -2,7 +2,7 @@
 First, thank you for contributing to Azure specs repository! Swagger specs are the basis for generating Azure SDKs in multiple different languages, Azure CLIs for interacting with the services, and can provide documentation for these services.
 
 ## Basics
-If you're a spec author looking for information about all of of the repositories and steps in the pipeline, go to the [adx-documentation-pr](https://github.com/Azure/adx-documentation-pr) repository. Make sure to [join the Github Azure organization](http://aka.ms/azuregithub) to get access to that repo.
+If you're a spec author looking for information about all of the repositories and steps in the pipeline, go to the [adx-documentation-pr](https://github.com/Azure/adx-documentation-pr) repository. Make sure to [join the Github Azure organization](http://aka.ms/azuregithub) to get access to that repo.
 
 ## Table of Contents
 [Before starting](#before-starting)
@@ -86,7 +86,7 @@ Use the git tools you have available to you, such as amend, rebase, etc.
 
 
 ## Review process
-We review spec PRs to maintain a high bar of quality for all products that will be generated from these specs (including SDKs in all languages, CLIs and documentation). It's critical that spec files are both sytactically and semantically correct, as well as conform to common patterns that make it possible to generate SDKs and CLIs that are usable for customers. Since specs are the base input for all of these products, the review process starts with PRs to this repository. Please refer to [Swagger Review Process](https://github.com/Azure/adx-documentation-pr/wiki/Swagger-Review-Process) for more details.
+We review spec PRs to maintain a high bar of quality for all products that will be generated from these specs (including SDKs in all languages, CLIs and documentation). It's critical that spec files are both syntactically and semantically correct, as well as conform to common patterns that make it possible to generate SDKs and CLIs that are usable for customers. Since specs are the base input for all of these products, the review process starts with PRs to this repository. Please refer to [Swagger Review Process](https://github.com/Azure/adx-documentation-pr/wiki/Swagger-Review-Process) for more details.
 
 The expectation is that every spec in a PR will be correct JSON, syntactically correct, will semantically agree with the service it applies to, and will follow the recommended patterns.
 
@@ -95,7 +95,7 @@ A spec file must be valid JSON, according to the [JSON specification](https://to
 
 #### Semantic correctness
 Your spec file must correctly represent your service. Even if a spec passes all of the rules listed above, it might not accurately describe the service that it is intended to describe. This could include 
-- Incorrect schemas for responses or requests (both missing and superfluous properities)
+- Incorrect schemas for responses or requests (both missing and superfluous properties)
 - Missing operations
 - Missing parameters (especially required ones)
 - etc (this list is not comprehensive)

.github/PULL_REQUEST_TEMPLATE.md

@@ -1,15 +1,7 @@
-This checklist is used to make sure that common issues in a pull request are addressed. This will expedite the process of getting your pull request merged and avoid extra work on your part to fix issues discovered during the review process.
-
-### PR information
-- [ ] The title of the PR is clear and informative.
-- [ ] There are a small number of commits, each of which have an informative message. This means that previously merged commits do not appear in the history of the PR. For information on cleaning up the commits in your pull request, [see this page](https://github.com/Azure/azure-powershell/blob/master/documentation/development-docs/cleaning-up-commits.md).
-- [ ] Except for special cases involving multiple contributors, the PR is started from a fork of the main repository, not a branch.
-- [ ] If applicable, the PR references the bug/issue that it fixes.
-- [ ] Swagger files are correctly named (e.g. the `api-version` in the path should match the `api-version` in the spec).
-
-### Quality of Swagger
-- [ ] I have read the [contribution guidelines](https://github.com/Azure/azure-rest-api-specs/blob/master/.github/CONTRIBUTING.md).
-- [ ] My spec meets the review criteria:
-  - [ ] The spec conforms to the [Swagger 2.0 specification](https://github.com/OAI/OpenAPI-Specification/blob/master/versions/2.0.md).
-  - [ ] The spec follows the guidelines described in the [Swagger checklist](https://github.com/Azure/azure-rest-api-specs/blob/master/documentation/swagger-checklist.md) document.
-  - [ ] [Validation tools](https://github.com/Azure/azure-rest-api-specs/blob/master/documentation/swagger-checklist.md#validation-tools-for-swagger-checklist) were run on swagger spec(s) and have all been fixed in this PR.
+### Latest improvements:
+<i>MSFT employees can try out our new experience at <b>[OpenAPI Hub](https://aka.ms/openapiportal) </b> - one location for using our validation tools and finding your workflow. 
+</i><br>
+### Contribution checklist:
+- [ ] I have reviewed the [documentation](https://github.com/Azure/azure-rest-api-specs#basics) for the workflow.
+- [ ] [Validation tools](https://github.com/Azure/azure-rest-api-specs/blob/master/documentation/swagger-checklist.md#validation-tools-for-swagger-checklist) were run on swagger spec(s) and have all been fixed in this PR.
+- [ ] The [OpenAPI Hub](https://aka.ms/openapiportal) was used for checking validation status and next steps.

README.md

@@ -7,7 +7,9 @@
 This repository is the canonical source for REST API specifications for Microsoft Azure.
 
 ## Basics
-If you're a spec author looking for information about all of of the repositories and steps in the pipeline, go to the [adx-documentation-pr](https://github.com/Azure/adx-documentation-pr) repository. Make sure to [join the Github Azure organization](http://aka.ms/azuregithub) to get access to that repo. 
+If you're a spec author looking for information about all of the repositories and steps in the pipeline, go to the [adx-documentation-pr](https://github.com/Azure/adx-documentation-pr) repository. Make sure to [join the Github Azure organization](http://aka.ms/azuregithub) to get access to that repo. 
+
+<b>Latest improvement:</b><i> Microsoft employees can try out our new experience at [OpenAPI Hub](https://aka.ms/openapihub) - online experience for using our validation tools and finding your workflow.</i>
 
 Please check the [announcements page](https://github.com/Azure/azure-rest-api-specs/wiki/Announcements) for any new updates since your last visit.
 

arm-compute/quickstart-templates/aliases.json

@@ -56,6 +56,12 @@
         },
 
         "Windows":{
+          "Win2019Datacenter":{
+            "publisher":"MicrosoftWindowsServer",
+            "offer":"WindowsServer",
+            "sku":"2019-Datacenter",
+            "version":"latest"
+          },
           "Win2016Datacenter":{
             "publisher":"MicrosoftWindowsServer",
             "offer":"WindowsServer",

arm-compute/quickstart-templates/swagger.json

@@ -242,7 +242,7 @@
         },
         "outputs": {
           "type": "object",
-          "description": "Gets or sets key/value pairs that represent deploymentoutput."
+          "description": "Gets or sets key/value pairs that represent deployment output."
         },
         "providers": {
           "type": "array",
@@ -344,7 +344,7 @@
       "required": [
         "uri"
       ],
-      "description": "Entity representing the reference to the deployment paramaters."
+      "description": "Entity representing the reference to the deployment parameters."
     },
     "Provider": {
       "properties": {

documentation/creating-swagger.md

@@ -59,7 +59,7 @@ The **title** field is used as the name of the generated client.
 }
 ```
 
-```
+```csharp
 var client = new MyClientName();
 ```
 Override the title client name by passing the `-ClientName` to AutoRest.
@@ -224,7 +224,7 @@ are `in` the `path` must have a `true` value for the `required` field. In this e
 is populated with the value of userId provided in the client method.
 ```json5
 "paths": {
-  "/users/{userid}": {
+  "/users/{userId}": {
     "get": {
       "operationId": "users_getById",
       "parameters": [
@@ -334,7 +334,7 @@ Each operation defines the possible responses by HTTP status code:
 Swagger allows for specifying a `default` response. AutoRest treats the `default` response as defining an error 
 response status code unless `default` is the only status code defined. The reason for imposing this convention is 
 to produce higher quality API signatures. The return type of the generated API is determined by finding a common 
-base type of the success responses. In practice, if the default is considered as a potential success defintion, 
+base type of the success responses. In practice, if the default is considered as a potential success definition, 
 the common ancestor of success responses and error responses ends up being Object.
 
 ### Negative Responses<a name="NegativeResponses"></a>
@@ -372,7 +372,7 @@ You can describe all the [possible HTTP Response status codes](http://www.w3.org
                         Exception will not be thrown.",
       },
       "default": {
-        "description": "Default Response. It will be deserialized as per the Error defintion 
+        "description": "Default Response. It will be deserialized as per the Error definition 
                         specified in the schema. Exception will be thrown.",
         "schema": {
           "$ref": "#/definitions/Error"
@@ -414,7 +414,7 @@ Please note, that the use of "x-ms-paths" should be minimized to the above scena
 The request body and response definitions become simple model types in the generated code. The models include 
 basic validation methods, but are generally stateless serialization definitions.
 
-### Understanding the importance of "type" keyword while definining model types.
+### Understanding the importance of "type" keyword while defining model types.
 "Type-specific" keywords such as properties, items, minLength, etc. do not enforce a type on the schema. It works the other way around – when an instance is validated against a schema, these keywords only apply when the instance is of the corresponding type, otherwise they are ignored. Here's the relevant part of the [JSON Schema Validation](https://tools.ietf.org/html/draft-fge-json-schema-validation-00#section-4.1) spec:
 
 > 4.1. Keywords and instance primitive types
@@ -674,8 +674,8 @@ as an enum. However, not all enumeration values should necessarily be represente
 considerations, such as how often expected values might change, since adding a new value to a C# enum is a breaking change 
 requiring an updated API version. Additionally, there is some metadata that is required to create a useful C# enum, such 
 as a descriptive name, which is not represented in swagger.  For this reason, enums are not automatically turned into 
-enum types in C# - instead they are rendered in the documentation comments for the property or parameter to indcate allowed 
-values.  To indicate that an enum will rarely change and that C# enum semantics are desired, use the `x-ms-enum` exension.
+enum types in C# - instead they are rendered in the documentation comments for the property or parameter to indicate allowed 
+values.  To indicate that an enum will rarely change and that C# enum semantics are desired, use the `x-ms-enum` extension.
 
 In C#, an enum type is generated and is declared as the type of the related request/response object. The enum is serialized 
 as the string expected by the REST API.
@@ -697,7 +697,7 @@ as the string expected by the REST API.
 ```
 
 ### x-ms-enum extension structure <a name="enum-structure"></a>
-```
+```json5
 {
   "x-ms-enum": {
     "name" : "Specify the name for the Enum."