On Wed, Feb 17, 2021 at 6:29 PM Murray S. Kucherawy <[email protected]> wrote:
>
> On Wed, Feb 17, 2021 at 10:57 AM Rene Struik <[email protected]> wrote:
>>
>> I am sure you have much more process experience than I do. However, I have
>> trouble understanding how having a IANA section makes this suddenly a
>> process violation. Do I understand correctly that, in your mind, this
>> process issue would be moot if I would simply partition the doc into two
>> parts A and B, where C:=A+B is the current document and where A=C\B and
>> B:={Section 12.2, Section 12.3}?
>>
>> [...]
>>
>> I simply would like to understand, since I do not right now.
>
>
> Hopefully this helps rather than muddies things further, and Magnus (and
> Erik, and Ben, etc.) can correct me if I'm wrong:
>
> The first issue: The Last Call announcement for this document indicated that
> the working group wants it to have Informational status when published.
> After that Last Call was completed, our procedures assert that the document,
> with any Last Call feedback worked into it, has IETF consensus to be
> published with that specific status. Changing the status being sought to
> Standards Track without also running a new Last Call saying so violates our
> procedures; the document can't go forward unless that status change is
> reverted, or a second Last Call is done indicating the new intended status.
> This point has nothing at all to do with the content of the document, but
> rather the path it has followed through the process so far.
Agreed, and failure to notice this was my fault.
> The second issue: The LWIG working group does not appear (on a cursory read)
> to be chartered to produce a document that does this sort of work with
> cryptographic algorithms. Since a working group's charter is in effect a
> contract between the working group and the IESG to describe exactly the work
> it will produce, the delta between what this document is doing and what
> LWIG's charter says is large enough that this is something worthy of
> discussion and resolution before the document should advance. If the charter
> is wrong, let's renegotiate it; if this work needs to be done in a different
> venue, let's make that arrangement; etc.
>
> I believe Magnus is right to put the brakes on until these issues are sorted
> out.
>
> -MSK
I had a sync with Suresh to get more historical context. I understand
and agree that lwig is chartered primarily for Information document
work (and not specification). I had thought that this registration
might be a minor side-effect of documenting the Weierstrass curve
elements, "and oh by the way here's a code point if you want to use it
explicitly", but this was harmful naivety on my part.
I'd still like to understand the best way forward in service of the
work. Split the doc in two and do the registrations somewhere else
(where?), or bring the document to another venue (also: where?).
It has been pointed out to me that the formally correct way to deal
with this question at this point, given all the feedback to date, is
probably to withdraw the document from this telechat ("it is premature
for the IESG to evaluate text that is in flux") and to add a
management item for tomorrow's telechat to discuss the path forward.
This is what I will now do.
Thanks to all,
-Erik
_______________________________________________
Lwip mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lwip
