Hello, Thanks for the (off-list) comments on the draft.
According to the following suggestion from the chairs, I'm now responding to the comments at this timing. >>>>> On Fri, 14 May 2004 06:13:05 -0400, >>>>> Brian Haberman <[EMAIL PROTECTED]> said: > Hi Tim, > I have copied Jinmei, who is the primary editor, on this so he > is aware of your comments. > We can take these into consideration at the same time that we > handle any IESG feedback on the document. > Timothy Gleeson (tgleeson) wrote: >> Brian, >> >> I'm sending this to you as co-chair/co-author hoping you'll know of an >> appropriate disposition. >> >> I missed the last call, for which many apologies. Here are a few >> comments on the scoped address architecture, almost entirely >> editorial, so I don't think any isuses will arise. >> >> Thanks. >> >> Tim >> General >> ------- >> >> The phrase "scope type" (also "type of scopes") is used in several >> places. I was going to ask "please add a definition". But I think it >> means "scope value" or just "scope". If this is right, could you >> update as appropriate? After re-reading the draft, I think we can simply replace "scope type" (and "type of scopes", etc) with "scope". >> Section 11.2 >> ------------ >> The title of this section is "Zone Indices", but it's all about "zone >> id". Maybe you could change the title to "Zone Indices and >> <zone_id>". Since this section talks about the <zone_id> part of the textual representation, I've simply changed the section title to "The <zone_id> Part". >> Although a zone index is expected to contain the scope type >> ---> >> Although a zone index is expected to contain enough information to >> deterimine the scope type >> >> ["scope type" may need replacing with "scope value" depending on your >> response to my first point] Okay, replaced this part with the suggested one (with s/deterimine/determine/). I've also replaced "scope type" with "scope". >> more readable than other representation that contains the scope type >> ---> >> more readable than other representations that contains the scope type >> >> ["scope type" may need replacing with "scope value" depending on your >> response to my first point] Okay, replaced this part with the suggested one (with s/contains/contain/). I've also replaced "scope type" with "scope". I've simply accepted the suggested change for the other editorial issues (with s/scope value/scope/ when necessary). For reference, the full text of (the candidate of) new revision is available at: http://www.jinmei.org/draft-ietf-ipv6-scoping-arch-02rc1.txt Thanks, JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. [EMAIL PROTECTED] >> Section 6 >> --------- >> >> Each zone index of a particular scope should contain an information >> to represent the scope type >> >> Maybe a more general phrasing is needed here, e.g. >> >> Each zone index of a particular scope should contain enough >> information to allow the determination of the scope type >> >> ["scope type" may need replacing with "scope value" depending on your >> response to my first point] >> >> default zones for each of those three scopes. (Perhaps the selection >> algorithm is to choose the first zone that includes an interface >> other than the loopback interface as the default for each scope.) >> >> "Perhaps" doesn't feel like an appropriate word to have in a technical >> specification. Try replacing "Perhaps the" with "One possible". >> >> Section 11 >> ---------- >> >> The following subsections describe detail definitions, concrete ---> >> The following subsections describe detailed definitions, concrete >> >> >> Section 11.2 >> ------------ >> >> With this loosened property, an implementation can use convenient >> representation as <zone_id>. ---> >> With this loosened property, an implementation can use a convenient >> representation for <zone_id>. >> >> One possible candidate of such strings would be interface names, ---> >> One possible candidate for such strings would be interface names, >> >> belongs to a same (multicast) site ---> >> belongs to the same (multicast) site >> >> It cannot be assumed that a same index is common to all nodes in a >> zone (see Section 6). Hence, the format MUST be used only within a ---> >> It cannot be assumed that indices are common across all nodes in a >> zone (see Section 6). >> >> >> Section 11.3 >> ------------ >> >> (Here we assume a natual translation from a zone index to the ---> >> (Here we assume a natural translation from a zone index to the >> >> >> However, the typed URL is often sent on a wire, and it would cause ---> >> However, the typed URL is often sent on the wire, and it would cause >> >> format for IPv6 literal addresses itself has same kind of conflict. ---> >> format for IPv6 literal addresses itself has the same kind of conflict. >> >> Section 12 >> ---------- >> >> Since the use of the textual representation of non-global addresses >> is restricted within a single node, ---> >> Since the use of the textual representation of non-global addresses >> is restricted to use within a single node, -------------------------------------------------------------------- IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
