Re: [Lwip] Magnus Westerlund's Discuss on draft-ietf-lwig-curve-representations-19: (with DISCUSS)

[Rene Struik <[e-mail]>]

Hi Magnus:

According to Section 16.11 of RFC 8152 [1], registration of IANA code 
points does not require a specification that is actually an IETF draft 
or RFC document (I could have posted the specification on my own website 
for that matter). {Obviously, unambiguous specifications have to be 
there, see the very first draft of Nov 13, 2017, almost 3 1/2 years ago 
[2].} The same Section 16.11 also does not seem to require a iana cose 
section.

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}?

Just for your info: I do hold the editorial organizational principle 
dear, where I think I serve the community at large best by having a 
coherent treatment of all relevant material in one carefully edited 
document (rather than sprinkled around).

In case the A+B partitioning is your preference, how does this help an 
implementer, who may be more interested in finding what he/she needs 
than in procedural matters somewhere along the way? Where would they 
find part B, in case they are interested in this?

I simply would like to understand, since I do not right now.

Best regards, Rene

[1] [excerpt of Section 16.11 of RFC 8152 - Expert Review Instructions]
Specifications are required for the standards track range of point assignment.  Specifications should exist for specification required ranges, but early assignment before
a specification is available is considered to be permissible.  Specifications are needed for the first-come, first-serve range if they are expected to be used outside of closed
environments in an interoperable way. When specifications are not provided, the description provided needs to have sufficient information to identify what the point is being used for.


[2] 
https://datatracker.ietf.org/doc/html/draft-struik-lwig-curve-representations-00#section-3

[excerpt of your email]

I have after that initial realization tried to understand a bit how we ended up with this situation. As I said this scope issues should have been detected and handled much earlier. That is why I briefly looked at -00 and -04, where the later is the point where this document definitely had crossed the line for LWIG's charter scope. The fact that the document contained IANA considerations for crypto algorithms was all I needed to make that determination. It is an organizational failure in my view that this scope issue was not address already in 2019.


Ref: [1] https://tools.ietf.org/html/rfc8152#section-16.11

On 2021-02-17 12:30 p.m., Magnus Westerlund wrote:
> Hi Rene,
>
> I think you are not correctly understanding my discuss. This is a discuss on the
> failures in following IETF process that has occurred for this document.
>
>  From my perspective there is no question that the current draft put in front of
> IESG is not within the chartered scope for the LWIG WG. It attempts to register
> a new, not before existing COSE algorithms. That is clearly specification work,
> something LWIG is not chartered to do.
>
> It is good that you gotten some feedback on the draft. However, I am convinced
> more feedback would have been provided had this work been done in a more
> appropriate venue. I would also note that the email from John Mattsson that you
> quote below also do indicate issues with coordination with COSE WG for example.
> https://mailarchive.ietf.org/arch/msg/lwip/PHKTq30QucdjdtAfqsYqqbVep4A/
>
> To be clear, I have no interest in killing your document, simply ensure that
> IETF process is followed correctly to enable that your document can eventually
> published.
>
>  From my perspective, what is most important to you and the WG proponents, define
> the new algorithms or describe how you implement existing algorithms with this
> transform methodlogy? If it is the first then I think moving this document to
> another WG where defining new algorithms are in scope. If it is the later, then
> you and the WG have to strip down the document to not define new algorithms,
> only how they can be implemented.
>
> On Wed, 2021-02-17 at 10:50 -0500, Rene Struik wrote:
>> Hi Magnus:
>>
>> I don't think a brief glimpse at 00 document does this document or my efforts
>> on this justice ("my       brief review of the 00"). However, let me walk you
>> through this draft document. Perhaps, this helps in appreciating it better.
> Let me attempt to clarify what my I see as my role as AD are in the document
> approval process are. I review documents to find where my expertise and
> experience of IETF may find significant issues that has gone unnoticed so far.
>
> This particular week we have 11 documents (407 pages in total) and two charters
> to review. I at least don't read the documents in detail. I skim a lot to find
> those documents and parts of documents where I need to understand. Simply so
> that I can determine if there are any issue. For your document I am not a
> subject matter expert. To me it was sufficent to briefly look at the document to
> understand on a high level what the document does. That high level understanding
> was sufficient to see that there was an process issue here due to the scope of
> the document and the scope the WG's charter defines.
>
> I have after that initial realization tried to understand a bit how we ended up
> with this situation. As I said this scope issues should have been detected and
> handled much earlier. That is why I briefly looked at -00 and -04, where the
> later is the point where this document definitely had crossed the line for
> LWIG's charter scope. The fact that the document contained IANA considerations
> for crypto algorithms was all I needed to make that determination. It is an
> organizational failure in my view that this scope issue was not address already
> in 2019.
>
> So can we please focus on what is important to resolve the situation, i.e. which
> path should be taken here.
>
> Cheers
>
> Magnus Westerlund
>

-- 
email: [e-mail] | Skype: rstruik
cell: [phone] | US: [phone]