May I suggest that Tom to become the editor of MAP-E draft? Behcet
On Fri, Jan 25, 2013 at 3:47 AM, Ole Troan <[email protected]> wrote: > 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 >
_______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
