[Nut-upsuser] I-D: ISE request for more detail on command STARTTLS

Roger Price roger at rogerprice.org
Sun Mar 27 20:39:27 BST 2022

On Sun, 27 Mar 2022, Manuel Wolfshant wrote:

> On March 27, 2022 6:57:23 PM GMT+03:00, Greg Troxel <gdt at lexort.com> wrote:
>> Roger Price <roger at rogerprice.org> writes:
>>> The IETF Independent Submissions Editor (ISE) has asked for more
>>> detail on the command STARTTLS, in particular the use of certificates.
>> That's interesting, given how the overall state of PKI is not
>> particularly about NUT.
> Right.

>> I am guessing their concern was lack of clarity about client certs and the 
>> path to authorization.

> I'd need more details from the IES. I do not really understand why is he 
> inferring differences between nut and other applications relying on SSL

I understand that the Internet Engineering Steering Group (IESG) (a body 
composed of the IETF chair and the area directors) which provides the final 
technical review of Internet standards is insisting on much better security, 
including encryption, for all protocols which might cross the global internet. 
This message has been passed to the Independent Submission Editors (ISE), and 
NUT will get the required attention.  I have been warned that there will be 
another review of our I-D, and that section 6 "Security Considerations" will 
need more work.

Quoting « Just a heads up that I will need to do a separate review of your 
Security and IANA Considerations sections.  You can speed things up by having a 
look at RFCs 3552, 8126, and 8726. Mostly I think your IANA considerations 
section is okay, but your language in various places referring to the NUT ports 
may need some tidying. Your security considerations is a different matter; it's 
going to need some simplifying of the form THREAT/Mitigation. »

I have not heard it explicitly, but I get the impression that protocol I-Ds are 
usually Standards Track and are prepared by specially created working groups, 
rather than individuals.  So we may be getting the attention normally reserved 
for Working Group activity.

In the long term, nothing prevents NUT from one day re-presenting the future RFC 
as a proposed Standards Track I-D, but I think it better to wait and see what 
the reaction is to the current I-D before going further.  (I would not be a 
volunteer to edit that Standards Track document - that would need a new 


More information about the Nut-upsuser mailing list