Hi Med,
On 16. Jul 2025, at 12:03, mohamed.boucadair@xxxxxxxxxx wrote:
Hi Michael,
Thank you for the review.
Please see inline.
Cheers,
Med (as author)
-----Message d'origine-----
De : Michael Tüxen via Datatracker <noreply@xxxxxxxx>
Envoyé : mercredi 16 juillet 2025 11:06
À : tsv-art@xxxxxxxx
Cc : draft-ietf-netconf-port-numbers.all@xxxxxxxx; last-
call@xxxxxxxx; netconf@xxxxxxxx
Objet : draft-ietf-netconf-port-numbers-03 ietf last call Tsvart
review
Document: draft-ietf-netconf-port-numbers
Title: NETCONF Transport Port Numbers
Reviewer: Michael Tüxen
Review result: Ready with Nits
This document has been reviewed as part of the transport area review
team's ongoing effort to review key IETF documents. These comments
were written primarily for the transport area directors, but are
copied to the document's authors and WG to allow them to address any
issues raised and also to the IETF discussion list for information.
When done at the time of IETF Last Call, the authors should consider
this review as part of the last-call comments they receive. Please
always CC tsv-art@xxxxxxxx if you reply to or forward this review.
I have only found the following three nits:
1. The abstract mentions that port number assignments that not stood
the
test of time are removed. However, the introduction mentions that
also
port number assignments are removed for which the protocols do
not
apply (like SSH/UDP).
For consistency, I would list both motivations for assignment
removal
in the abstract and introduction.
[mj] This should be addressed in the document.
2. The introduction mentions that
"... many of these assignments are for a transport protocol
(i.e., UDP)
for which the requesting application does not apply"
and then the document actually removes one.
Maybe the use of "many" can be improved to be more precise.
[Med] "many" refers to: 830(udp), 831(udp), 832(udp), and 833(udp). I think that part is accurate.
I see. I was considering: * 830(udp) as being removed because ssh/udp isn't used. * 831(udp), 832(udp), 833(udp) being removed since BEEP, SOAP/BEEP, SOAP/HTTP are Historic. I guess that depends on how you are counting...
[mj] I think Michael has a point. While 830(udp) is being removed because it does not apply, 831(udp), 832(udp) and 833(udp) are being removed because those protocols are historic. In other words, different reasons for removing different port numbers. I would suggest:
OLD: However, many of these assignments are for a transport protocol (i.e., UDP) for which the requesting application does not apply. Also, several of the assignments are for protocols that are not deployed and were tagged as Historic: [RFC4743] and [RFC4744].
NEW: However, one such assignment is for a transport protocol (i.e., UDP) for which the requesting application does not apply, and three assignments are for protocols that are not deployed and were tagged as Historic: [RFC4743] and [RFC4744].
Thanks. Best regards Michael
3. The introduction mentions that
"... many of the assignments are for protocols that are not
deployed
and were tagged as Historic"
and then the document actually removes three.
Maybe the use of "many" can be improved to be more precise.
[Med] This refers to 3 out of 4 assignments. Made: s/many/several
____________________________________________________________________________________________________________
Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.
_______________________________________________
Tsv-art mailing list -- tsv-art@xxxxxxxx
To unsubscribe send an email to tsv-art-leave@xxxxxxxx
|
