Folks, In future emails please use this email address for me: [EMAIL PROTECTED] I won't be reachable on my current email address in a couple of days.
Thanks, Hesham > -----Original Message----- > From: Spencer Dawkins [mailto:[EMAIL PROTECTED] > Sent: Thursday, November 23, 2006 1:05 AM > To: Soliman, Hesham > Cc: General Area Review Team; Jari Arkko; Mark Townsley; Bob > Hinden; Brian Haberman; Thomas Narten; Erik Nordmark; > William Allen Simpson > Subject: Re: [Gen-art] RE: gen-art review of > draft-ietf-ipv6-2461bis-09.txt > > Hi, Hesham, > > (dropping off several of the mailing lists from the CC line) > > I'm not involved in this discussion, except that I'm also a Gen-ART > reviewer, so wanted to respond to the discussion of SHOULDs in this > thread... > > It's not that specifications need to explain all possible > reasons for not > following a SHOULD - I agree with your statement that > successful protocols > are used in amazing ways - but I do think listing ONE > possible reason as > justification for a SHOULD instead of a MUST is reasonable. > > In this case ("a draft name that ends in bis" ;-), saying > that existing > deployed implementations do something else might very well > serve as that > justification. > > The problem that we are trying to avoid is loss of > interoperability because > some implementations implement a SHOULD while others do not. > If there is no > loss of interoperability, by definition the MUST would not > be justified in > any case. > > Thanks, > > Spencer > > From: "Soliman, Hesham" <[EMAIL PROTECTED]> > > In this draft, "otherwise ... SHOULD" implies that there are > > situations in which the link layer address is known, and the > > source address is included, but the link layer address may be > > omitted. RFC2119 says that deserves explanation. As > guidance to > > implementors, who are supposed to understand the full > > implications > > and carefully weigh them, when would this be appropriate? For > > load balancing? If so just say so. For example down below in > > Router Advertisement Message, you say "A router MAY omit this > > option in order to enable inbound load sharing across multiple > > link-layer addresses." Something like that would > work here -- if > > nothing else add a pointer to text elsewhere. > > => I'd appreciate comments on this from Thomas or Erik if > they want to > add something here. Personally, while I appreciate the clarity > requirements, I think it's not necessary to always explain > all possible > options for not following a SHOULD. From personal experience, I found > people using specs in ways that were not originally thought of, while > being legitimate (due to the use of MAYs and SHOULDs). So > I'm inclined > to leave it as is but would like to hear if others see such ways of > clarification necessary. > > > _______________________________________________ Gen-art mailing list Gen-art@ietf.org https://www1.ietf.org/mailman/listinfo/gen-art
