When running swagger validation tools (https://github.com/Azure/openapi-validation-tools) against example payloads extracted from .Net test recordings, one class of issue reported is "Expected type X but found type null", particularly on responses. Example: #766
Swagger 2.0 specification does not support null, so there's no standard way to specify it.
To resolve the issue, there are a few of options to consider:

1. Properties coming back in responses with null values may not need to be sent back in the response. If the properties are not required, then they should not be part of the service response, so allowing null value would not be necessary.
2. If we need to allow properties with null values, then we could:
   A. Consider adding an extension for it. There have been conversation in the openapispec initiative about adding this to the next version of the spec (add "null value support" in spec? OAI/OpenAPI-Specification#229). It's not clear when the new specification will be released. Before that happens, we may need to implement 'x-ms-nullable' extension to allow for these cases, "x-ms-nullable" could be a boolean value applicable to each property, indicating whether the property is allowed to be null or not.
   B. For swagger validation purposes only, we could skip errors on null values (which avoids modifications to the specs for now), and filter out those errors from the result presented to the user of the validation tool. This could be part of implementing some kind of "exclusion list" for errors from the tool (Support for exclusion of reported issues in tool oav#57).

@amarzavery, @johanste, @salameer, @fearthecowboy, @lmazuel , @begoldsm please take a look and let me know your thoughts.
@fearthecowboy is 'x-ms-nullable' expected to be implemented as an extension in AutoRest? There seems to be some support for C# but didn't see it for others.