Re: Updating the rules?

[Brian E Carpenter <brian.e.carpenter at gmail.com>]

On 2007-07-07 08:30, Keith Moore wrote:
> > Also from the draft:
> > "At least for the strong security requirement of BCP 61 [RFC3365], the
> > Security Area, with the support of the IESG, has insisted that all
> > specifications include at least one mandatory-to-implement strong
> > security mechanism to guarantee universal interoperability."
> >
> > I do not think this is a factual statement, at least when it comes to
> > HTTP, which is where my interest lies.
> note that it is not necessary to have at least one
> mandatory-to-implement strong security mechanism to guarantee
> interoperability.  consider, for example, a client-server protocol for
> which conforming servers are required to implement
> _two_ strong security methods and for which clients are required to
> implement _at least one_ of those two methods.  this
> would ensure interoperability even though there were no single
> mandatory-to-implement for clients.
>
> depending on the circumstances, putting a greater burden on the server
> than the client, or vice versa, might make sense.

As far as 2026bis goes, my idea would be to have language that defines
the bounding requirements. There are specifics in BCP 61 = RFC 3365
which would be out of place in 2026bis.

In the above quote I would suggest
s/to guarantee universal interoperability/in the interests of universal interoperability/

    Brian

_______________________________________________
Ietf mailing list
Ietf at ietf.org
https://www1.ietf.org/mailman/listinfo/ietf





5000201 at gmail.com>
Date: Sat, 07 Jul 2007 08:54:14 +0200
From: Brian E Carpenter <brian.e.carpenter at gmail.com>
User-Agent: Thunderbird 1.5.0.12 (Windows/20070509)
MIME-Version: 1.0
To: Keith Moore <moore at cs.utk.edu>
References: <468C9DC5.1070805 at gmail.com>
	<68fba5c50707062119l43e230edsd2361b55b2e2225b at mail.gmail.com>
	<468F331F.7000409 at cs.utk.edu>
In-Reply-To: <468F331F.7000409 at cs.utk.edu>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d
Cc: IETF discussion list <ietf at ietf.org>
Subject: Re: Updating the rules?
X-BeenThere: ietf at ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ietf>,
	<mailto:ietf-request at ietf.org?subject=unsubscribe>
List-Post: <mailto:ietf at ietf.org>
List-Help: <mailto:ietf-request at ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ietf>,
	<mailto:ietf-request at ietf.org?subject=subscribe>
Errors-To: ietf-bounces at ietf.org

On 2007-07-07 08:30, Keith Moore wrote:
> > Also from the draft:
> > "At least for the strong security requirement of BCP 61 [RFC3365], the
> > Security Area, with the support of the IESG, has insisted that all
> > specifications include at least one mandatory-to-implement strong
> > security mechanism to guarantee universal interoperability."
> >
> > I do not think this is a factual statement, at least when it comes to
> > HTTP, which is where my interest lies.
> note that it is not necessary to have at least one
> mandatory-to-implement strong security mechanism to guarantee
> interoperability.  consider, for example, a client-server protocol for
> which conforming servers are required to implement
> _two_ strong security methods and for which clients are required to
> implement _at least one_ of those two methods.  this
> would ensure interoperability even though there were no single
> mandatory-to-implement for clients.
>
> depending on the circumstances, putting a greater burden on the server
> than the client, or vice versa, might make sense.

As far as 2026bis goes, my idea would be to have language that defines
the bounding requirements. There are specifics in BCP 61 = RFC 3365
which would be out of place in 2026bis.

In the above quote I would suggest
s/to guarantee universal interoperability/in the interests of universal interoperability/

    Brian

_______________________________________________
Ietf mailing list
Ietf at ietf.org
https://www1.ietf.org/mailman/listinfo/ietf