Re: [regext] WG LAST CALL: draft-ietf-regext-unhandled-namespaces-03

"Gould, James" <jgould@verisign.com> Mon, 26 October 2020 12:42 UTC

Return-Path: <jgould@verisign.com>
X-Original-To: regext@ietfa.amsl.com
Delivered-To: regext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 914CD3A097C for <regext@ietfa.amsl.com>; Mon, 26 Oct 2020 05:42:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=verisign.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D5mWxsMQ0xI7 for <regext@ietfa.amsl.com>; Mon, 26 Oct 2020 05:42:44 -0700 (PDT)
Received: from mail1.verisign.com (mail1.verisign.com [72.13.63.30]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 078633A097E for <regext@ietf.org>; Mon, 26 Oct 2020 05:42:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=verisign.com; l=4344; q=dns/txt; s=VRSN; t=1603716164; h=from:to:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version:subject; bh=1UdOrV7ZaEWuSOKUV3wtzq9eST0PsrlpKG1SQ+sXn64=; b=bhgMIiAqCv1h2jxx+htBw37iFgtr+cqvczs5BiZ30J6EwZgJXaK6mzwK NJNNoi1ZY/Megr+lgJGvV0uAvM+T5DNb+AlOE434sqzIZHsV7zOd9YOYk G01daHL3BpwLuPHjmT5Co7TR5CXHghSl2xuM7wcbCSRHVZhXWHYu90SYg X+thWK9DBaFDlobml4ZJ5OriPOGYbjSdHdUSytlCjetuNnF25IImVXPwU uUF+Nm8GIAT771IegRDdL1FNd9zmKblBmfd5xarpIsIZEGWU8kW6Ik7u8 nQt+H7d8tPmhUlChEHKBRzFWDjeiW3VSxKV+X/vQRMkgRBwnJOShZOV5X g==;
IronPort-SDR: 2RUeQBM61Q78Lgg2FOzljdfjkIGUJ7A+J8mu/fXKCKDNMsaOlkg6LAmYdyIGK+WOLpw08lCd// mNceMRkKkEDaFsq6HEPvuI0QhF4B/u+Colc7HwfOBBiRrP6YxuzBdRdnShps9wJS2Zxq25E+sp YCzp5VlvWeaadP4iAHSybQqUuY1GQgBDZNf9KQlEpntLKcJYDIkiQigXY676cq58jV+88d03Ba RYLEdQ+D+2bibUwdo+98szpV2aDpi3LqtOfTQzrTbqmh8dYS7y058UpYxdPRosWPl2qeQ//T3w bxU=
X-IronPort-AV: E=Sophos;i="5.77,419,1596499200"; d="scan'208";a="3689189"
IronPort-PHdr: 9a23:+3zwphak/9T7v2UtC514Vp3/LSx+4OfEezUN459isYplN5qZpsy5YB7h7PlgxGXEQZ/co6odzbaP7OawBidYvN6oizMrSNR0TRgLiMEbzUQLIfWuLgnFFsPsdDEwB89YVVVorDmROElRH9viNRWJ+iXhpTEdFQ/iOgVrO+/7BpDdj9it1+C15pbffxhEiCCybL9vLhi6twbcu8sZjYd+Kqs61wfErGZPd+lK321jOEidnwz75se+/Z5j9zpftvc8/MNeUqv0Yro1Q6VAADspL2466svrtQLeTQSU/XsTTn8WkhtTDAfb6hzxQ4r8vTH7tup53ymaINH2QLUpUjms86tnVBnlgzoBOjUk8m/Yl9Zwgbpbrhy/uhJ/34DaboKbNPV8cKzdfM8VS2VOUctKSyxOGYa8Y5cTA+cbP+tVqZT2qVsUrRu5AAmhHO3jxD5Phn/r2a01zvwtGhzC0gM6GtIBrm/UoNvoP6oVU+C1w67IzSjHb/xLwjr99pbHcgogofGXXLJwfszRxVMzGAPCi1WdsIroNC6a2eoRqWaU9fZgVf6xhG49rQF8ujqiy8gxh4XXmo8bxVHJ+CV6zYsxKtO0VUB1bNGkHZdMuSyWKoR4T8w/Tmxnpio3xaMLtICmcSUKxpopxwLTZ+KBfoOV7BzjU+ORLi15hHJjYL+/mQi98VKhyu3nV8m031BKritDktbQrHwCyxvT6s2fRvRh/0ehwiqA1wfJ5u5YJkA0kLLXK58/zb4smJofq0PDHjX5mEjwkaSYdV0k9/C15+j7eLnqu52ROoFuhg3jMqkjlNazDOs7PwQWQmSX5f6w2KDh8EHlWrlGk/I7n6rDvJzHJskWoLOyDRVP3YY58Rm/Ci+r0NEfnXYaMl1IYAmHj431O1HWJ/D4EOu/j0yskDh1w/DGOaXsD4jRIHbbjbvufa5z5UFdxwYv0NxT/YxUBa0GIPLpQk/9rsbXAQIjPwyq2ebnE9N92pkCVmKIB6+VKKLSsVmW6eIzO+SAeZMZtCzgJ/Un6fPil2I1lF8TcKWz0pYaa2i0HvF8LEWYZXrsjM0BEWAPvgcmTuzqh1qCUSNXZ3mvRK88+C80CJinDYfYR4Ctj7qB0D2nEZ1RY2BKEkqMHmvwd4WYR/cMbzqfItdkkjEfSLehTJMh2guotADn17VnKfDY9TEftZLmzNJ1/fHclQku9TxoCMSQy3uNQH97nmwWSD42wLtyoU1jxVef36h0mftYFcZc56ABbgBvf4bZ5+B9F9n0VgnGONyOTRzuFs2jKT02Uts3z9QJJU16HoPmxlrZ0iWnE6M9lrGXCtoz6K2WlyzrKslw22ru1aQ9gR8hWMQZZkO8gasqvSfUGorF1w27nqOnbu5UiCzC83qHwUKQsVtZSw9/V+POWnVJNRielsjw+k6XF+zmMr8gKAYUkcM=
X-IPAS-Result: A2F6BAB/vpZf/zCZrQpdA4EJgU+DGoE0CoQykGwmg3mWQ4EsPQsBAQEBAQEBAQEIAR8QBAEBAoRIAheBdiY3Bg4CAwEBCwEBAQUBAQEBAQYDAQEBAoZKDII3Ins9CT0BAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEFAggHTQdHAR4BAQEBAgEjETobAgEIGAICEQEBEwICAjAVEAIEARKDJgGCXKtsdoEyhVeEc4EOKoZihnKBQj6BOAwQgk0+g3YRHi8KHggBAoJNM4IsBJA1gx2kNAMHgmqJBItahh4fgxeBKohjlDqTPYkBEoFjlUICBAIEBQIVgWqBfHAVOyoBgj4JRxcCDY5WgzqKVnQOJwMCBgEJAQEDCYwEDx6BBoERAQE
Received: from BRN1WNEX01.vcorp.ad.vrsn.com (10.173.153.48) by BRN1WNEX01.vcorp.ad.vrsn.com (10.173.153.48) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2106.2; Mon, 26 Oct 2020 08:42:41 -0400
Received: from BRN1WNEX01.vcorp.ad.vrsn.com ([fe80::a89b:32d6:b967:337d]) by BRN1WNEX01.vcorp.ad.vrsn.com ([fe80::a89b:32d6:b967:337d%4]) with mapi id 15.01.2106.002; Mon, 26 Oct 2020 08:42:41 -0400
From: "Gould, James" <jgould@verisign.com>
To: "pm@dotandco.com" <pm@dotandco.com>, "regext@ietf.org" <regext@ietf.org>
Thread-Topic: [EXTERNAL] Re: [regext] WG LAST CALL: draft-ietf-regext-unhandled-namespaces-03
Thread-Index: AQHWpbyiL6cvTJWd/k2IcHWB7mIWQKme7L0AgAOXQoCAAAntgIAASzyAgADPGgCABYolAIAArRyA
Date: Mon, 26 Oct 2020 12:42:41 +0000
Message-ID: <2FF281F9-C194-4599-9F2F-2BC9C4073AC4@verisign.com>
References: <04DF4069-4B02-489C-BB6E-94DEB581F862@elistx.com> <1596663b-1d40-44a7-beb4-dd41172dea91@www.fastmail.com> <75A43B1C-5D7B-4CE6-B126-303B3F34AB35@verisign.com> <84785f0d-cc30-43dd-bf49-894caa1feeb2@www.fastmail.com> <605837F6-B907-457B-B5D0-54D485358AD4@verisign.com> <4b52009c-80b3-4c10-a919-086a732a0c2f@www.fastmail.com> <092857B2-DC47-4D59-AC35-6A1BFB745D8E@verisign.com> <a0926c87-04e2-455d-8cf5-15a0f0c00b15@www.fastmail.com>
In-Reply-To: <a0926c87-04e2-455d-8cf5-15a0f0c00b15@www.fastmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/16.41.20091302
x-originating-ip: [10.170.148.18]
Content-Type: text/plain; charset="utf-8"
Content-ID: <C9B95730B5836749B7F035FB1E6CBABC@verisign.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/regext/50u0R3CJnN9bIsxV_W6OliSsHes>
Subject: Re: [regext] WG LAST CALL: draft-ietf-regext-unhandled-namespaces-03
X-BeenThere: regext@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Registration Protocols Extensions <regext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/regext>, <mailto:regext-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/regext/>
List-Post: <mailto:regext@ietf.org>
List-Help: <mailto:regext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/regext>, <mailto:regext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 26 Oct 2020 12:42:46 -0000

Patrick,

We'll agree to disagree with the value and risk of draft-ietf-regext-unhandled-namespaces, since I can't think of a theoretical or real risk to existing clients with at least two independent implementations.  Your objection can be included in the document shepherd writeup, but as noted before there is no consensus to make a change.      

-- 
 
JG



James Gould
Fellow Engineer
jgould@Verisign.com <applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/jgould@Verisign.com>

703-948-3271
12061 Bluemont Way
Reston, VA 20190

Verisign.com <http://verisigninc.com/>

On 10/25/20, 6:23 PM, "regext on behalf of Patrick Mevzek" <regext-bounces@ietf.org on behalf of pm@dotandco.com> wrote:



    On Thu, Oct 22, 2020, at 08:47, Gould, James wrote:
    > I do need to clarify one 
    > thing, there was no specific changes needed on the client-side to 
    > support draft-ietf-regext-unhandled-namespaces other than ensuring that 
    > the draft-ietf-regext-unhandled-namespaces XML namespace is included in 
    > the login services. 

    There was no specific changes needed on the client-side... for YOUR client.
    Great for you, but from that you can not draw a conclusion that your draft
    creates no problem whatsoever.

    Please take into account there are other clients out there, that may work
    differently and do different assumptions.

    Your draft changes the assumptions in RFC 5730. And hence may break existing
    clients. By saying that there was no problem for one client is not a proof
    that interoperability was not broken.

    > Clients should be capable of parsing and marshaling the 
    > <extValue> element regardless of whether or not 
    > draft-ietf-regext-unhandled-namespaces is supported.  

    This is unrelated. You are changing the text from RFC 5730 that says
    explicitly this content is client provided. You are now redefining what
    is in RFC 5730 by saying "any content is fine here".

    > The 
    > approach taken with draft-ietf-regext-unhandled-namespaces enables the 
    > information to be returned without the chance of breaking a validating 
    > client that doesn't support the service,

    This is untrue, as you change the semantics of RFC 5730 at least twice
    (content of extValue, and possibly having value/extValue with NON error codes)

    Your draft *clearly* creates a _risk_ for any existing client starting to break
    once a server enables this feature. Saying that one client works fine is
    not a measure of interoperability risks when it is deployed.

    -- 
      Patrick Mevzek
      pm@dotandco.com

    _______________________________________________
    regext mailing list
    regext@ietf.org
    https://secure-web.cisco.com/1JXSBPoG-78NoxpuH19NNm2nvZTdQOhccfcp1QWP5dIEoQ6ekz0xXZM5s-sjWAtHoyCWUf_2JEydMxz45_96qI1YCrzvVHqo_auUMjwRjm8-vzii5f9vyKuSHuvmM1k3cQ0yIXjkmvgHMVJvCVWmcpbbHGNx0ZiX0M2UoaJSC_KsQkylfiD2W2c6kKOzUDsOD0A0YpWshVU8cx2Vl5xPIwkFkeDUxrAEM1QqgxxgX8Kl-TSaiWE0mnRbAdMiJ2hnWnQNYliLaaS3GpmXxZ8naGmsuWA4vrGgPbftN8s8SJt0/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fregext