Hi, Thanks for very careful and thoughful responses. This is the kind of editing we need! :-)
Comments to remaining issues inline.. On Tue, 11 Nov 2003, JINMEI Tatuya / [ISO-2022-JP] [EMAIL PROTECTED]@C#:H wrote: > > 1) the number of authors is too many (6). No more than 5 is allowed. I'd > > suggest removing one, or putting everyone except the current document editor > > as only authors and list only one editor of the document. > > Sorry, I don't understand the latter suggestion. Could you reword > this one please? > > Anyway, I see your point, but I don't have a good idea on how to deal > with this. I don't even know if the "no more than 5" rule must > strictly be applied here (I guess you meant the third paragraph of > Section 2.12(1), draft-rfc-editor-rfc2223bis-07.txt). I'm open to > suggestions from wg. This issue comes from: http://www.ietf.org/ID-nits.html http://www.rfc-editor.org/policy.html#policy.auth2 The documents with >5 authors at the header need to be specially agreed to with the IESG. So, I think the options are either: 1) get the special agreement with the IESG (would't bother trying) 2) strike off 1-2 most inactive authors and put them in a "Contributors" section 3) replace all the authors with just one entry, like "J. Tatuya (Ed.)" and put everybody down in an "Authors" section .. obviously 2) would IMHO be a best choice if we/you could just decide who to strike off.. > > Further, note > > that the second-last paragraph is not suitably clear about the connection > > of the link-local mapped addresses and the equivalent IPv4 addresses. > > I guess you meant the "second-last sentence" here. And honestly, I > don't see a significant difference between the current text and your > suggestion, but I'm fine with revising the text as suggested. Yes, I meant the sentence, sorry. The my text pointed out the prefix explicitly, and tries to use a better name to properly describe the addresses.. > This looks fine, thanks for the suggestion. I'll basically replace > the paragraph with this one, with one exception: we may need to be > consistent about the terms between > - IPv4 auto-configured link-local addresses > and > - IPv4 link-local auto-configuration addresses > > I'm not sure if the difference was intentional, but I'll probably be > consistent by using the former one only. It was unintentional; good catch. Consistency doesn't hurt :-) > > 3) I think this statement in section 5 needs to be spelled out a bit more: > > > Each interface belongs to exactly one zone of each possible scope. > > > .. that is, this could be read either as it's probably intended ("no > > interface must belong to more than one zone"), or as "each interface must > > be in a zone of each scope, even if it would have no addresses etc. from > > that scope". If the intent is the latter, this needs to be spelled out a > > bit more, if the former, a different wording should be used. > > Hmm, I think it is Steve who can answer this question with confidence, > but I believe the intention is the latter (including the former one, > of course). For example, I believe the latter intention is more > consistent with Section 6. > > I don't know if this is so substantial that we need to revise the > text, but I'll think about it more and try to propose a better wording. > > In any event, I think this is rather an editorial issue and does not > cause a significant problem. Ok. > > 5) In the section 7, "sending packets", IMHO it would be useful to actually > > describe the process of how the outgoing interface is identified, or refer > > to a section describing this (if it's in the default zone, no problem, but > > if you have e.g. two link-local interfaces....): > > > Although identification of an outgoing interface is sufficient to > > identify an intended zone (because each interface is attached to no > > more than one zone of each scope), that is more specific than desired > > in many cases. > > Sorry, I don't really understand the point...did you mean "how the > outgoing *zone* is identified", not "how the outgoing *interface* is > identified"? Not sure, because interface implies the zone. Reading this again, it seems this problem is actually already resolved in the next sentences in the same paragraph. > > 6) In the section 9, "Forwarding", I think the text about picking the > > destination address zone could be enhanced a bit: > > > o The zone of the destination address is determined by the scope of > > the address and arrival interface of the packet. The next-hop > > interface is chosen by looking up the destination address in a > > (conceptual) routing table specific to that zone. That routing > > table is restricted to refer only to interfaces belonging to that > > zone. > > > ==> that is, this does not seem to spell out whether the routing table > > could include more than just the interfaces of destination address zone -- > > i.e., in the case of a global destination address, the "interfaces belonging > > to that zone" is a bit confusing :-) > > Hmm, perhaps I was too familiar with the concept, but I don't see the > problem. In the case of a global destination address, the zone for > the destination address is the single global zone, and the "interfaces > belonging to that zone" are all the interfaces that the receiving node > has. What is confusing here? The last sentence. I guess this is more of the specific global case, that is, referring _only_ to the interfaces belonging to zone X is a bit misnomer, because if you have a global address, all the interfaces are already there, i.e., that "only" is redundant in this case? (I don't feel strongly about this though.) > > 8) multicast routing in section 10 is rather weak. This is a direct > > resolution of switching from unicast site-locals to multicast > > organization-local addresses. However, with multicast addresses, it is > > not appropriate to use the terms "prefixes" to refer to multicast traffic. The > > multicast routing is so different from unicast, and the term is not > > qualified to convey the intended message here. Some rewording is needed, > > maybe express this using (*,G) or (S,G) state creation where the limits are > > placed on the group G. > > (in the citation I've corrected the lack of "not" pointed out in your > 2nd message) > > I see your point. But it seems to me too much to use the term like > (*, G) or (S, G). At least (*, G) is a notion very specific to a > particular type of multicast routing protocols such as PIM-SM. > > Isn't it enough to revise the text here using "group" instead of > "prefix(es)"? For example, > > say > > * All global groups > > instead of > > * All global prefixes This would probably make sense, seems reasonable here at least. > > 10) Similar bad ideas are described in section 11.7, about how to use IPv6 > > addresses in URL's. The text seems to say that the apps should then strip > > the zone index and be able to parse it.. This would imply that apps handling > > URL's should be made aware of link-local addresses and the zone index > > parsing. This seems like a very, very wrong way to go: > > At least I didn't intend to give an impression that applications need > to parse/strip the format with a zone ID. I see the point, however, > and I'm willing to revise the text if it makes the point clearer. Yes, I thought the impression was not intentional, but that's how it could be read, so if an alternative text can be thought of to be less ambiguous, it would probably be best.. > > ==> suggestion either revise the text significantly or add reword the middle > > sentence: > > > However, the typed URL is often sent on a wire, and it would cause > > confusion if an application did not strip the <zone_id> portion > > before sending. Note that the applications should not need to care > > about which kind of addresses they're using, much less parse or strip out > > the <zone_id> portion of the address. Also, the format for non-global > > addresses might conflict with the URI syntax [10], since the syntax > > defines the delimiter character (%') as the escape character. > > I don't see a problem with the suggested text. Do you think if it is > enough to make the point clear? If so, I'll simply use the rewording. This is probably good enough. > > 11) Note that there is a normative reference to the ICMPv6-bis document, > > which has been pretty much stalled for the last 2 years or so. This > > document cannot be published before ICMPv6-bis is also published. The > > ICMPv6-bis seems integral to this specification, so I think the options are > > either to revise the text about sending ICMP DU "beyond the scope of source > > address" messages (removing it), or kicking off the effort for getting > > ICMPv6-bis out of the door: > > > [4] Conta, A. and S. Deering, "Internet Control Message (ICMPv6) for > > the Internet Protocol Version 6 (IPv6)", Internet Draft draft- > > ietf-ipngwg-icmp-v3-02.txt, November 2001. > > Another good catch. I think you're talking about the rule described > in the 3rd paragraph of draft-rfc-editor-rfc2223bis-07.txt, Section > 2.7. Hmm, we have an agenda item on icmp-v3-02 in the 1st ipv6 wg > meeting tomorrow, so for now I'll see what happens on this. Agreed. > > o The zone of the new destination address is determined by the scope > > of the next address in the Routing Header and arrival interface of > > the packet. The next-hop interface is chosen just like the first > > bullet of the rules above. > > > ==> reword to something like below, to spell out what the next address was: > > (also, add "the" before arrival): > > > o The zone of the new destination address is determined by the scope > > of the next address in the Routing Header (the original destination > > address of the received packet) and the arrival interface of > > the packet. The next-hop interface is chosen just like the first > > bullet of the rules above. > > ... > > This "the next address in the Routing Header" should now be in the > destination address of the IPv6 header (swapped with the original > destination address of the received packet). Did you mean "(swapped > with the original destination address of the received packet)"? Yes. > Perhaps we can simply say "the next address" (removing "in the Routing > Header"). OK. > > Note that it is possible, though generally inadvisable, to use a > > Routing Header to convey a non-global address across its associated > > zone boundary. > > > ==> I'd be a bit more explicit than this.. the convey in this case means > > that a link-local address is encapsulated in the "next address" field but is > > not going to be used. Try e.g.: > > > Note that it is possible, though generally inadvisable, to use a > > Routing Header to convey a non-global address across its associated > > zone boundary in the previously-used next address field, similar as > > one can convey the information in the protocol payloads as well. > > > (could also omit from "similar.." not sure if that's good..) > > I don't see the need for the "similar..." part. So I'll revise the > text as follows: > > Note that it is possible, though generally inadvisable, to use a > Routing Header to convey a non-global address across its associated > zone boundary in the previously-used next address field. OK. > > When an implementation interprets the format, it should construct the > > "full" zone ID, which contains the scope type, from the <zone_id> > > part and the scope type specified by the <address> part. > > > ==> unless I have completely misunderstood the spec, the first "scope type" > > should actually be "scope zone" :-) > > I don't think you misunderstand the spec, but the first "scope type" > is correct. It corresponds to the following part of Section 6: > > Each zone index of a particular scope should contain an information > to represent the scope type, so that all indices of all scopes are > unique within the node and zone indices themselves can be used for a > dedicated purpose. > > So, at least one person read this to mean differently than originally > intended...do we need to be clearer by revising the text? Reading the first snippet (the first above), I got the feeling "but hey, why is full zone ID including the scope type, and the scope type being overridden from the <address>". So there probably has to be some revision to clarify that? > I don't need to revise the text, but we might just remove the > "unnumbered", and say > > Also assume that the point-to-point interfaces have link-local > addresses only. > > The removal of the possibly confusing word doesn't matter, IMO, > particularly because this is the only occurrence of "unnumbered". > Does this change make sense. The proposal you stated above seems very good to me. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------------------------------------------------------------- IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
