Hi Spencer,
> 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.
=> Ok, but my other point is that you only use MUST when avoiding it
causes the protocol to break. So, a SHOULD is used when something is
recommended, but its lack would not break the protocol. Now, that
doesn't mean you have to explain how the protocol can be used without
that SHOULD. I don't have to provide an application for something to use
a SHOULD, all I need to know is that it's not a MUST, but recommend that
it be done in a certain way. There are ample examples of that in specs
today. I'd hate to put this, IMO, editorial requirements on spec
writers.
> 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.
=> Exactly, which is the case every time the spec in question uses a
SHOULD.
Hesham
>
> 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
