From: Ted Lemon <mellon@fugue.com>
Message-Id: <C099032E-F538-43AD-970F-F71A1A9E15D8@fugue.com>
Content-Type: multipart/alternative;
 boundary="Apple-Mail=_3C878D77-1F36-4C34-B434-B02066DB4B48"
Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\))
Subject: Re: [dhcwg] [Int-dir] Review of
 draft-ietf-dhc-relay-server-security-02
Date: Thu, 26 Jan 2017 13:36:59 -0500
In-Reply-To: <B3CE8C9D-C20C-4FAB-9054-0F09B2B87F63@gmail.com>
To: "jouni.nospam" <jouni.nospam@gmail.com>
References: <148541310715.6205.3276873953603821357.idtracker@ietfa.amsl.com>
 <ff898bc0-81ce-7598-c3f3-2e114d30df30@gmail.com>
 <e996599692ff4584b8ace30a36ea6881@XCH-ALN-003.cisco.com>
 <B3CE8C9D-C20C-4FAB-9054-0F09B2B87F63@gmail.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/ycpgCPefRKFPxw-FGBM37E4IXjA>
Cc: "ietf@ietf.org" <ietf@ietf.org>, "int-dir@ietf.org" <int-dir@ietf.org>,
 Tomek Mrugalski <tomasz.mrugalski@gmail.com>,
 Jouni Korhonen <jounikor@gmail.com>, "dhcwg@ietf.org" <dhcwg@ietf.org>,
 "draft-ietf-dhc-relay-server-security.all@ietf.org"
 <draft-ietf-dhc-relay-server-security.all@ietf.org>
Precedence: list


--Apple-Mail=_3C878D77-1F36-4C34-B434-B02066DB4B48
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

On Jan 26, 2017, at 1:25 PM, jouni.nospam <jouni.nospam@gmail.com> =
wrote:
> Hmm.. I really do not like specification =E2=80=9Cgames=E2=80=9D like =
this. If you cannot justify a MUST into RFC3315bis, then trying to =
circumvent the fact in another document (that does not update the =
RFC3315 or RFC3315bis) should not be a Standards Track document. I could =
accept this as a BCP or a like.

Hm, then you are saying that every extension ever done to a protocol =
that, if it contains MUSTs, MUST update that protocol, even if =
implementations that support the extension can interoperate with =
implementations that do not and vice versa.   What's your basis for =
this?



--Apple-Mail=_3C878D77-1F36-4C34-B434-B02066DB4B48
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html =
charset=3Dutf-8"></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" =
class=3D"">On Jan 26, 2017, at 1:25 PM, jouni.nospam &lt;<a =
href=3D"mailto:jouni.nospam@gmail.com" =
class=3D"">jouni.nospam@gmail.com</a>&gt; wrote:<div><blockquote =
type=3D"cite" class=3D""><div class=3D""><span style=3D"font-family: =
Menlo-Regular; font-size: 14px; font-style: normal; font-variant-caps: =
normal; font-weight: normal; letter-spacing: normal; orphans: auto; =
text-align: start; text-indent: 0px; text-transform: none; white-space: =
normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; =
float: none; display: inline !important;" class=3D"">Hmm.. I really do =
not like specification =E2=80=9Cgames=E2=80=9D like this. If you cannot =
justify a MUST into RFC3315bis, then trying to circumvent the fact in =
another document (that does not update the RFC3315 or RFC3315bis) should =
not be a Standards Track document. I could accept this as a BCP or a =
like.</span></div></blockquote><br class=3D""></div><div>Hm, then you =
are saying that every extension ever done to a protocol that, if it =
contains MUSTs, MUST update that protocol, even if implementations that =
support the extension can interoperate with implementations that do not =
and vice versa. &nbsp; What's your basis for this?</div><div><br =
class=3D""></div><br class=3D""></body></html>=

--Apple-Mail=_3C878D77-1F36-4C34-B434-B02066DB4B48--