Re: [pcp] WGLC: draft-ietf-pcp-base-12.txt

[Stuart Cheshire <[e-mail]>]

My comments are below. I have text in mind to fix these things, but I haven't had time to write it up yet.

1. The definition of "subscriber" needs to be tightened up.

2. Why are some IP address fields "always 128 bits", and others are "32 or 128 bits"? Can we make this consistent?

3. Where a 128-bit IP address field contains an IPv4 address, we need to ensure that it can't inadvertently look like a valid IPv6 address as well as being a zero-padded IPv4 address.

4. Handling of the "O" bit is not fully specified for clients.

5. The THIRD_PARTY scenarios are a bit confused and self-contradictory.

6. Security for the THIRD_PARTY option needs more detailed specification.

7. PROCESSING_ERROR is unused.

8. ADDRESS_MISMATCH value is undefined.

9. How to handle responses from multiple PCP servers is underspecified. Responses don't arrive simultaneously. One arrives first, and then the other arrives later. What should the client do when the later one arrives? Undo everything it did in response to the first one?

10. Document uses both "NAT" and "NAPT". We should pick one and be consistent.

11. Use of wildcard ("0") address, port and protocol fields could be explained more clearly.

12. Don't match External_AF when validating response.

13. Is option length in bytes or 32-bit words?

14. Is FILTER Option mandatory to implement? How many filters per mapping?

15. Non-EIM seems like a confusing double negative ("non-independent"). Can we just say "EDM" ("dependent") instead?

16. Saying that an "Ethernet switch needs to perform ingress filtering" seems to be putting unreasonable demands on devices that know nothing about PCP, NAT, or even IP.

17. Why are new OpCodes "Standards Action" but new Result Codes are only "Specification Required"?

Stuart Cheshire <[e-mail]>
* Wizard Without Portfolio, Apple Inc.
* www.stuartcheshire.org