dear Tom, thanks a lot for the comments. sorry for the delay though. now maoke is replying in line regarding the section 5.
2013/5/16 Tom Taylor <tom.taylor.s...@gmail.com> > I have a number of trivial editorial comments, which I will share > privately with the authors. However, I also have a few points for broader > review. > ... > > Section 5.1 step B1 > =================== > > The example uses working addresses. It should use addresses from the > documentation ranges in the IANA IPv4 Special Purpose Address Registry: > 192.0.2.0/24, 198.51.100.0/24, and/or 203.0.113.0/24. > yes. only a little difficult that originally we took /16 examples but there is no /16 documentary ranges. :P i am handling with the text by using the /24 above for the example. however, as the IPv4 space is now limited, the supported number of CEs with reasonable sharing ratio must be smaller than the original 2^20. i would like to change it to 2^10. > > Section 5.1 step B2 > =================== > > Do I misunderstand, or was the 3-bit PSID length chosen arbitrarily as > part of the example? Actually, I would expect the sharing ratio (or more > likely the number of ports per subscriber) to be the starting point, so you > might say instead (following the first sentence): > > "Suppose the intended sharing ratio is 8 subscribers per address, > resulting in (65536 - 1024)/8 = 8064 ports per subscriber assuming that the > well-known ports are excluded. Then the PSID length to achieve this will be > log2(8) = 3 bits. Bearing in mind the IPv4 16 bit prefix length for each of > our two prefixes, the EA-bit length is (32 - 16) + 3 = 19 bits." > thanks a lot for suggesting the text. it is true that we firstly have the sharing ratio as the part of service specification, then we may have the length of PSID. however, the logic is not only about the sharing ratio. for example, we have 2^10 CEs, and now we have the service specification that share per IPv4 address among each 8 CEs, then at least 2^7 IPv4 addresses are needed. if our held space is less than /25, we cannot play the game unless we relax the sharing ratio to 16 CEs per address resulting in less usable ports for each subscriber (CE). i'd like to take your suggest text as the base and refine the paragraph taking this understanding into account. > > Section 5.1 step B3 > =================== > > I found this step rather mysterious until I got to step C3. Presumably the > purpose is to generate a unique IPv6 prefix per MAP rule. I suggest you > start by stating that as a requirement. Instead of the term "index", which > to me suggests consecutive values, how about "prefix extension"? > yes. there needs a statement on the requirement too. prefix extension is an accurate term. thanks a lot for suggesting that. > > A couple of minor points: > -- in the second paragraph, > s/contiguous block/contiguous address block/ > I have ports on the brain from recent work. Others > may also be confused. > thanks. > > -- Is there a more usual notation for a binary value x, instead of > bin(x)? > i have the same question but no answer. :P anyone has any suggestion? > > I'll read the rest of the document, so there may be more comments, but > this is a start. thanks in advance. best regards, maoke > > > Tom Taylor > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires >
_______________________________________________ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
