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
[email protected]
https://www1.ietf.org/mailman/listinfo/gen-art
