[lamps] Gorry Fairhurst's No Objection on draft-ietf-lamps-rfc5273bis-08: (with COMMENT)

[Gorry Fairhurst via Datatracker <[e-mail]>]

Gorry Fairhurst has entered the following ballot position for
draft-ietf-lamps-rfc5273bis-08: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-lamps-rfc5273bis/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Please find 3 non-blocking COMMENTS, these concern the recommendations for the
use of ports:

(1) The current text says:
/Client implementations MAY want to continue to allow for this to occur/
- I know this is taken from a published RFC, but, for me, permitting a “wish”
using an RFC2119 keyword does not say anything useful. Please consider if this
MAY could be rewritten to say which port (range) this requirement refers to,
and avoids saying “want”. Perhaps something like: -  “Client implementations
MAY continue to use a port chosen from the Private Port range”.

(2) The current text says:
/Servers SHOULD change to use the new port. /
- Please could you update the text to clarify which service uses the “new port”
? Is it: TCP? HTTP/TCP? both? - I’d strongly also suggest noting the port
number in the sentence with the RFC2119 keyword e.g.: A TCP server SHOULD use
port  5318 assigned to the CMC service. Prior to [RFC6402], CMC did not have a
registered port number and used an externally configured port from the Private
Port range.

(3) I was going to raise a DISCUSS on the final comment, but I’m not sure this
is critical, and I expect some rewording will clarify the port usage: It seems
like the client and the server could use different ways to identify the
service. I think that possibility seems like it needs more clarification.