[netconf] Gorry Fairhurst's Discuss on draft-ietf-netconf-port-numbers-06: (with DISCUSS and COMMENT)

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

Gorry Fairhurst has entered the following ballot position for
draft-ietf-netconf-port-numbers-06: Discuss

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-netconf-port-numbers/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Thank you previous discussions with the IANA port experts on the requested IANA
actions, and the follow-up with me to refine the request to IANA this document.

I have some topics I'd like too DISCUSS to see if this document could be
improved. I hope these are simple to address, and if addressed I intend to
ballot "YES".

1. The para starting "However, three..."  seems to require some small editorial
work: The current document identifies three set of port usage, and (I think
correctly requests 2 of these are "released" because those protocols have not
been deployed, but it mentions "3" in the text.

2. A statement is made: "All these assignments are undesirable." I am unsure
what it means for the IETF to declare something as undesirable, and would like
to discuss the reason behind this sentence, because think that this text ought
to be updated. For instance, it could say use of these ports to configure
security policies may be problematic, or maybe give some other reason?

3. Please check carefully the words used to describe the action proposed. At
various places the document speaks of de-assigning and releasing. (Note to the
IESG: The result of this RFC will be to trigger an IANA policy to reserve these
ports, which may allow future use, per Section 8.2 of [RFC6335].)

4. I note the Security Considerations does not introduce a new vulnerability,
but maybe this ought to consider also adding the advice that security policies
that are based around using the previous port assignments need to be updated to
not associate these ports with the named services.


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


I also note that the abstract could be slightly more descriptive.