Document: draft-ietf-tsvwg-usr-exp Title: User Ports for Experiments Reviewer: Martin Dürst Review result: Ready with Issues Hello everybody, This is my artart review of draft-ietf-tsvwg-usr-exp-10. The document proposes to reserve two ports for use in experiments; different experiments are distinguished by using a kind of 'magic number' at the start of the application data. >From an application perspective, I'd want to see more discussion about what should happen when something moves from an experiment to deployment. (My understanding is that in that case, an actual port should be applied for, and that the document should clearly say so.) In general, the document is well written, but there are too many "could", "might", and similar words. Here is an example (only half of a sentence, because the sentence is very long): "to reduce the potential that experimental uses of PExIDs that could be tested in the public Internet might interfere with each other.": This can (and should) be rewritten without loss of clarity to "to reduce the potential that experimental uses of PExIDs that are tested in the public Internet interfere with each other." There are many similar cases in the document. Individual comments: - I'm not sure why the update text to RFC 4727 is in the introduction. It's fine to mention in the introduction that RFC 4727 is updated by this document, but the actual text should come later. - Section 3 should say that the actual port definitions are given in section 8. - "User ports are also more likely to allow configuration to pass through firewalls, where system and dynamic ports can be difficult to 'un-block'.": The way I understand it, it's data, not configuration, that passes though firewalls. - "the bar for PExID registration is low (first-come, first served) and encouraged.": No, the bar isn't encouraged; it's the registration that's encouraged. - I wonder whether it's necessary to bother IANA with PExID registration. There could potentially be a large number of registrations. Simply requiring random selection would make the potential for collisions quite low, and the fact that PExIDs aren't registered would clearly give the message that these are only experimental, and any protocol/application desiring wider use should apply for a dedicated port. - Section 5 should immediately start with a subsection entitled "General Considerations for PExID Use" (or some such), because the reader expects Section 5 to be as short as the previous ones and is then surprised when seeing the "SCTP and DCCP PExID Use" section. - There should be some advice on whether different PExIDs can/should be used to distinguish protocol versions in the 'same' overall experiment, e.g. to avoid ossification (see e.g. RFC 9170). - "network-standard byte order" (one instance) -> "network standard byte order" - Section 6: The second paragraph is about STUN, then the third paragraph seems to be about TURN, but falls back to STUN. Confusing at least to this reader. - Section 7: DPI is mentioned without expansion. I tried to find out what was meant by looking up Section 5.3.1 of RFC 6973, but that RFC doesn't have a section 5.3.1. - "Experimenters are encouraged to include security in any new experiment...": I'm sure this isn't mean this way, but it sounds as if one could just sprinkle a bit of security over an experiment. Something such as "Experimenters are encouraged to design and implement their experiments with the necessary security features..." seems more appropriate. - Section 8: "system (EXP1, EXP2)" ports: It would be good to give the port numbers here again (they are given in the introduction). It may also be better to use lowercase, to match what IANA does (see https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?&page=16). - At the bottom of https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.txt, I found (regarding the EXP1 and EXP2 system ports) "[1] It is only appropriate to use these values in explicitly-configured experiments; they MUST NOT be shipped as defaults in implementations. See RFC 3692 for details." That text strangely enough doesn't turn up in the paginated version (see last comment). Maybe something similar should also be include in this document? Regards, Martin. -- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
