User-Agent: Cyrus-JMAP/3.3.0-dev0-351-g9981f4f-fmstable-20200421v1
Mime-Version: 1.0
Message-Id: <9c9a9fa1-db18-4f85-b27a-cb73429d9801@www.fastmail.com>
In-Reply-To: <50276493-87ad-291e-a6cd-ff26fce77868@iit.cnr.it>
References: <CF2EE8CE-DB07-4AFF-84D0-B80BA5E76D39@antoin.nl>
 <b79a4641-bade-4901-b3f0-bb7decbdb41e@www.fastmail.com>
 <50276493-87ad-291e-a6cd-ff26fce77868@iit.cnr.it>
Date: Mon, 27 Apr 2020 10:45:17 -0500
From: "Patrick Mevzek" <pm@dotandco.com>
To: regext@ietf.org
Content-Type: text/plain;charset=utf-8
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/regext/9FoTRTTbMY_m1g4ms9pnFsuoLJ8>
Subject: Re: [regext] WG LAST CALL: draft-ietf-regext-rdap-partial-response
Precedence: list

Hello Mario,

A quick follow-up that could be a closure in fact, as your answer fills
the missing points I had.

On Mon, Apr 27, 2020, at 10:30, Mario Loffredo wrote:
> Il 27/04/2020 07:45, Patrick Mevzek ha scritto:
> >
> > On Fri, Feb 28, 2020, at 09:43, Antoin Verschuren wrote:
> >> The following working group document is believed to be ready for
> >> submission to the IESG for publication as a standards track documen=
t:
> >>
> >> https://datatracker.ietf.org/doc/draft-ietf-regext-rdap-partial-res=
ponse/
> >>
> >> This WG last call will end at close of business, Friday, 13 March 2=
020.
> > I am too late, I know.
> >
> > But anyway I fear that at least the "brief" case will create interop=
erability
> > problems, or at least complexity in clients because there is a risk =
of each
> > RDAP server thinking of it differently.
>=20
> I published a draft version, namely=20
> draft-loffredo-regext-rdap-partial-response-03, including a definition=
=20
> of the "brief" field set which was based on those WHOIS response field=
s=20
> identified in RFC 7485 as mostly supported (i.e. by more than one thir=
d=20
> of contacted services). As you can see from the "Change Log", that=20
> definition was removed in draft-ietf-regext-rdap-partial-response-01=20=

> because the WG had clearly recommended to separate the technology,=20
> described in the RFC, from its operational aspects, described in an RD=
AP=20
> profile.
>=20
> The same feedback was recently provided by Karl Heinz Wolf and now I'm=
=20
> giving you the same answer as I gave him.
>=20
> Anyway, if the WG members reconsider their position about this point, =
I=20
> will be happy to refine my old proposal or work on a new one.
>=20
> > The "subsetting_metadata" is only a SHOULD not a MUST, so clients co=
uld
> > remain completely without real explanations on why "brief" for serve=
r A
> > is different from "brief" result for server B.
>=20
> It's not a MUST because the available field sets could be defined in a=
=20
> document published elsewhere, for example, in a specific RDAP profile.=

>=20
> Therefore, in my opinion, it would be recommended but not required.

I agree with all the above, in theory.
My main fear is once the draft being put into active use, I am not sure =
people
will bother creating other proper IETF documentation on what "brief" is,=

and hence the pretty much result I see coming is multiple servers using =
"brief"
in completely different senses, without always to use the metadata, and =
hence clients
will need again to hardcode on their side assumptions per server, which =
is very
bad for interoperability.

I do however profoundly disagree with:

> because the WG had clearly recommended to separate the technology,=20
> described in the RFC, from its operational aspects, described in an RD=
AP=20
> profile.

As this argument is used when wanted but not always. At the same time, w=
e (the WG)
see no problem (but I do) to define a BCP on "secure transfers", which i=
s certainly
just operational stuff and not protocol stuff, so sometimes we do hardco=
de operational
stuff in WG documents. So we should either do it always, or never, but u=
sing that
argument only in some case and not others is not something I find good p=
rocess.
That is just my generic view, nothing specific to the one draft discusse=
d in this thread.

> > It would have been nice to provide a template for "brief", at least =
a SHOULD,
> > per objects described in the RDAP RFCs.
> See my response above.
> > Specially since the document has this text:
> > "the
> >     name, as well as the list of fields for each field set, should b=
e
> >     shared by most of RDAP providers."
>=20
> Obviously, the field set approach is valuable if there is a wide=20
> consensus on both the name and the content of a possible field set.

I agree, but I am not sure there is such consensus. Or even if there is =
here
on the mailing-list how can be sure there will be among all RDAP servers=
 working?

> Three possible field set names have been recommended in the document i=
n=20
> order to ease interoperability. For the field sets representing the tw=
o=20
> extremes, namely "id" and "full", the corresponding content is evident=
.

Yes, clearly my worries are about "brief".=20

> > Written like that, this is not a protocol specification, and does no=
t even
> > give tools at the protocol level to enforce that.
> >
> > Or, and this could be an easy solution, another draft defining rdapC=
onformance
> > subsetting_brief_level_0
> > should define exactly what is brief and then servers are free to pro=
perly
> > signal if they adhere to this definition of fields or not.
> > There could be multiple drafts in fact for multiple definitions.
>=20
> This is an interesting solution but I dont' see, at least in the case =
of=20
> "brief",=C2=A0 why the WG should approve to define in a separate draft=
 what=20
> has been considered unsuitable in this draft :-(

Understood. I am probably once again possibly at odd's with the WG but i=
t is not
something unheard of already :-)
So anyway, I believe we will see problems in the future, but we will hav=
e to wait
and see them I guess.

> I would like the other WG members to manifest their opinions so that I=
=20
> could change the document where appropriate.

As you said, the issue I raised was already discussed and settled so pro=
bably
no need to rehash it, I was the one being late here, I should have taken=

more attention to the previous discussion, but I was not able to reserve=

the time I wanted to participate in this WG lately, sorry about that.
So no need to spend energy on my late points.

--=20
  Patrick Mevzek
  pm@dotandco.com