DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=kuehlewind.net; 
 b=AP/Ed0tleD0gPb3QXIb48vWdSIaOeJMbxjrvzNqvUXQbqYyyNd3SOz43RJR98ZlIYbxYPcNGXHQOFzqUVA1nDCeoD5YpTDddDXwHZB4Csc8CuxwaJgAbhA0w+yGMPYB0Wyonmqn4SaGc/bPuHvIE3tfLIWa0i7T8L9RIxBYa+Zc=;
 h=Received:Received:Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:X-Mailer:X-PPP-Message-ID:X-PPP-Vhost;
Content-Type: text/plain;
	charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\))
From: "Mirja Kuehlewind (IETF)" <ietf@kuehlewind.net>
In-Reply-To: <727594E8-0B83-420F-858C-1081F38BE72A@kuehlewind.net>
Date: Mon, 12 Feb 2018 22:11:13 +0100
Cc: Anna Brunstrom <anna.brunstrom@kau.se>,
 "rmcat WG (rmcat@ietf.org)" <rmcat@ietf.org>,
 draft-ietf-rmcat-sbd.all@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <B083DFF2-2386-445C-82B9-1455E50EA673@kuehlewind.net>
References: <227D2FC6-A331-4311-A8BF-E783B9F0B8EB@kuehlewind.net>
 <1b78e928-3fb3-7959-552a-e4c9bbcd7af6@kau.se>
 <1E245578-0EC9-4496-A683-9FBFBA1FC5C2@kuehlewind.net>
 <5E43ED74-2BBF-4E1E-8C4B-21D2D718E2F2@ifi.uio.no>
 <fcdafb8d-d3ff-5bd0-f502-9baea1dac615@kau.se>
 <c0b1e043-8a4c-140f-ba39-7abe44539a8d@kuehlewind.net>
 <859142F1-3EE6-44E2-875F-77D0CC9C982A@ifi.uio.no>
 <727594E8-0B83-420F-858C-1081F38BE72A@kuehlewind.net>
To: Michael Welzl <michawe@ifi.uio.no>
Archived-At: <https://mailarchive.ietf.org/arch/msg/rmcat/vbHnHBUezScobYbD-7RIYvMx0S0>
Subject: Re: [rmcat] AD review of draft-ietf-rmcat-sbd-09
Precedence: list

Hi,

when will you likely submit an update?

Mirja


> Am 07.02.2018 um 10:25 schrieb Mirja Kuehlewind (IETF) =
<ietf@kuehlewind.net>:
>=20
> Hi Michael,
>=20
> that=E2=80=99s okay. Please go ahead and make the updates. I moved the =
draft to the later telechat.
>=20
> Mirja
>=20
> P.S.: By spec I actually meant protocol spec=E2=80=A6
>=20
>=20
>> Am 06.02.2018 um 18:07 schrieb Michael Welzl <michawe@ifi.uio.no>:
>>=20
>> Hi,
>>=20
>> I=E2=80=99m cutting away some things and only answering on the part =
that speaks to me as one of the authors:
>>=20
>>=20
>>>>> We believe that Experimental status is more fitting; we looked at =
the checklist here, from which this seems a pretty clear decision to us:
>>>>> =
https://www.ietf.org/standards/process/informational-vs-experimental
>>>=20
>>> So I would like to add something here. I don't know why you think =
from this text that experimental is the better fit, but I think both are =
suitable and therefore I'm also fine to move on with experimental but I =
wanted to make sure that this has been considered.
>>=20
>> 1. If it can't be practiced, it's Informational.  =3D> this is an =
algorithm, it can be practiced.
>> 2. If it's not going to be changed no matter what the result is, it's =
Informational  =3D> that=E2=80=99s not the case, see my answer below =
regarding =E2=80=9Cwill never touch it again=E2=80=9D.
>> 3. (..)work that could be practiced, was developed in the IETF, has =
been dropped for some reason, but is being published for the record(..) =
Informational or Historic  =3D> that=E2=80=99s also not the case.
>> 4. If the IETF may publish something based on this on the standards =
track once we know how well this one works, it's Experimental  =3D> =
again the point below, I do think this can go to standards track after =
more experience.
>> 5. If the document contains implicit or explicit success/failure =
criteria, and it's clear that the outcome can be used as the basis for a =
recommendation to the IETF community, it's Experimental  =3D> well =
there=E2=80=99s a section on expected feedback from experiments.
>>=20
>>=20
>>> So both informational and experimental do not need to have IETF =
consensus (but as I said they usually have); so no difference in this =
aspect. Experimental docs are usually specs that are not ready for =
proposed standard yet but experimentation in the Internet is needed to =
move forward. However, sbd is not really a spec, it's more a =
documentation of a mechansims. As such I think it could also be moved =
forward as informational.
>>=20
>> I don=E2=80=99t see what makes you say that this isn=E2=80=99t really =
a spec? It should be, it=E2=80=99s meant to be a spec.
>>=20
>>=20
>>> The difference for me at this point is, are there any plans to move =
it forward to proposed standard as any point in the future, or do we =
keep this document as a documentation of the proposed mechanism and =
probably will never touch it again?
>>=20
>> Well, it=E2=80=99s certainly my plan as one of the authors to move =
this forward to proposed standard at some point in the future. We=E2=80=99=
re actively working on this.
>>=20
>>=20
>>>> Ok, thanks for the feedback Michael. Then we stay with =
experimental.
>>>=20
>>> Assuming, we have a decision on the indented status (going for exp =
as the current version said). Would you like to submit another update =
before IETF last call, or should I just start the IETF last right away?
>>=20
>> We=E2=80=99d like to do another update - there were some =
recommendations here: removing the reference to coupled-cc from the =
abstract, different boilerplate and your editorial comments. This may =
take a little bit (I=E2=80=99m not the only author).
>>=20
>> Cheers,
>> Michael
>>=20
>=20