Tom, thanks again for thorough comments, very much appreciated!
> Section 4 > --------- > > It might be best to describe operations with respect to shared addresses > first, then describe the exceptions for full IPv4 addresses or IPv4 prefixes > at the end. As it is, you switch back and forth from these to shared > addresses and it is not totally clear what applies to one versus the other. > The main question that arises in my mind as a result of the current > arrangement of text is whether a NAPT is required if a full address or prefix > is provisioned. If so, what does it do? Beyond that, I would even question > whether a MAP module is needed for a full address or an address derived from > a prefix, and not simply an RFC6052-compliant encapsulator. I tend to agree with your concerns with regards to the shared address, full address, prefix split. would you be able to create a proposal for how the document would be organised, e.g. with section titles, if we refactor it this way? at NA(P)T is optional in the full IPv4 address or IPv4 prefix case. it would in that case work exactly like IPv4 NAT does on CPEs today. RFC2473 compliant encapsulator? RFC2473 only specifies a point to point tunnel. the MAP modules gives provisioning and it gives mesh mode. > Paragraph 4 talks about MAP provisioning a full address or prefix. I don't > think MAP is a provisioning process -- just talk about whether a full address > or a prefix was provisioned. what would be a better wording? MAP "calculates" an IPv4 address based on some information from a DHCP option and some (or none) information from the IPv6 prefix. what's the verb describing that? "the MAP CE _implies_ its IPv4 addressing information". deduces, calculates, configures? > Typo in the first line of the section: s/e.g. For/e.g., for/. fixed. > Section 5 > --------- > > Where is the definition of the optional port parameters? it is currently described under "a-bits" section 5.1. the optional port parameters only include the offset. although -02 alluded to also a "well known ports" flag. flexibility versus simplicity. in my opinion we should drop the port parameters from the base MAP spec, and fix the offset to 4. > Section 5.2 > ----------- > > The first sentence of paragraph 3 relates to the naive algorithm specified in > paragraph 2 and should be part of that paragraph. I was confused the first > time I read this part. could you point out the exact paragraphs, I'm not quite sure which ones you mean? > Section 5 has now abstracted the port mapping algorithm, leaving it > unspecified. But the GMA is still there implicitly. I believe it wouldn't > hurt to say that the underlying algorithm allocates ports to a given CE as a > series of contiguous ranges, occupying the same relative position in each in > a series of fixed-sized blocks. thanks, I've added that more or less verbatim. Best regards, Ole _______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
