[Last-Call] Re: [OPS-DIR]draft-ietf-netconf-port-numbers-03 ietf last call Opsdir review

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Dhruv,

Thank you for the review.

Please see inline.

Cheers,
Med (as author)

> -----Message d'origine-----
> De : Dhruv Dhody via Datatracker <noreply@xxxxxxxx>
> Envoyé : lundi 14 juillet 2025 12:06
> À : ops-dir@xxxxxxxx
> Cc : draft-ietf-netconf-port-numbers.all@xxxxxxxx; last-
> call@xxxxxxxx; netconf@xxxxxxxx
> Objet : [OPS-DIR]draft-ietf-netconf-port-numbers-03 ietf last call
> Opsdir review
> 
> 
> Document: draft-ietf-netconf-port-numbers
> Title: NETCONF Transport Port Numbers
> Reviewer: Dhruv Dhody
> Review result: Ready
> 
> Reviewer: Dhruv Dhody
> Review Result: Ready (with comments)
> 
> I have reviewed this document as part of the Operational
> Directorate's ongoing effort to review all IETF documents being
> processed by the IESG.  These comments were written with the intent
> of improving the operational aspects of the IETF drafts. Comments
> that are not addressed in the last call may be included in AD
> reviews during the IESG review.  Document editors and WG chairs
> should treat these comments just like any other last call comments.
> 
> Thanks for doing this cleanup exercise.
> 
> # IANA
> 
> While the OLD/NEW style is clear, I am unsure if that should be
> preserved in the IANA consideration section of the published RFC.
> Does IANA have any opinion on this style?

[Med] didn't receive a comment on the style so far. Will adjust to take into account any IANA advice on this.

> 
> Also, since RFC 6335 asks the de-assigned port to be marked as
> Reserved, I am unsure whether leaving the port number empty (as
> currently done in the new
> text) will align with the updated IANA registry page.

[Med] You are right, but I'm hesitating to have a "frozen" reserved in the document in case some of these port numbers are reassigned for some ongoing netconf-related transport (over quic, for example). Idem as for the previous point, will follow whatever IANA recommends here. Thanks.

> 
> Related question: Should this update also fill in some of the empty
> fields (like Assignee and Contact), or is it better to keep them
> empty as done in the past?

[Med] Not sure that is useful to include those.

> 
> # Minor
> 
> The introduction lists two issues - (1) the use of transport
> protocols (udp),
> (2) protocols not deployed. On the other hand, the abstract only
> mentions "(2)". Should it also mention "(1)"?
> 

[Med] The wording of the abstract is generic and covers both (Thanks, Tom Petch). (2) is listed as an example.

> Thanks!
> Dhruv
> 
> 
> _______________________________________________
> OPS-DIR mailing list -- ops-dir@xxxxxxxx To unsubscribe send an
> email to ops-dir-leave@xxxxxxxx
____________________________________________________________________________________________________________
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.
-- 
last-call mailing list -- last-call@xxxxxxxx
To unsubscribe send an email to last-call-leave@xxxxxxxx




[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Mhonarc]     [Fedora Users]

  Powered by Linux