[netconf] Re: [Tsv-art] draft-ietf-netconf-port-numbers-03 ietf last call Tsvart review

[Mahesh Jethanandani <[e-mail]>]

Hi Med,

> On Jul 16, 2025, at 3:03 PM, Michael Tuexen <[e-mail]> wrote:
> 
>> On 16. Jul 2025, at 12:03, [e-mail] wrote:
>> 
>> Hi Michael, 
>> 
>> Thank you for the review.
>> 
>> Please see inline. 
>> 
>> Cheers,
>> Med (as author)
>> 
>>> -----Message d'origine-----
>>> De : Michael Tüxen via Datatracker <[e-mail]>
>>> Envoyé : mercredi 16 juillet 2025 11:06
>>> À : [e-mail]
>>> Cc : [e-mail]; last-
>>> [e-mail]; [e-mail]
>>> 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 [e-mail] 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 -- [e-mail]
>> To unsubscribe send an email to [e-mail]
> 


Mahesh Jethanandani
[e-mail]