IESG Narrative Minutes
Narrative Minutes of the IESG Teleconference on 2015-03-05. These are not an official record of the meeting.
Narrative scribe: John Leslie and Susan Hares (The scribe was sometimes uncertain who was speaking.)
Corrections from: John
2. Protocol Actions
2.1 WG Submissions
2.1.1 New Items
2.1.2 Returning Items
2.2 Individual Submissions
2.2.1 New Items
2.2.2 Returning Items
2.3 Status Changes
2.3.1 New Items
2.3.2 Returning Items
3. Document Actions
3.1 WG Submissions
3.1.1 New Items
3.1.2 Returning Items
3.2 Individual Submissions Via AD
3.2.1 New Items
3.2.2 Returning Items
3.3 Status Changes
3.3.1 New Items
3.3.2 Returning Items
3.4 IRTF and Independent Submission Stream Documents
3.4.1 New Items
3.4.2 Returning Items
1218 EST no break
4 Working Group Actions
4.1 WG Creation
4.1.1 Proposed for IETF Review
4.1.2 Proposed for Approval
4.2 WG Rechartering
4.2.1 Under evaluation for IETF Review
4.2.2 Proposed for Approval
5. IAB News We can use
6. Management Issues
7. Agenda Working Group News
Amy: please plan for US daylight-savings change
1244 EST Adjourned
(at 2015-03-05 07:30:21 PST)
I am somewhat discouraged that this document doesn't make stronger recommendations, and question whether the consensus process was really run correctly. I think that there was a fair amount of content-free posturing during the discussion, and that this held more sway over the eventual outcome than was really appropriate. That said, I appreciate the efforts of the authors, working group chairs and AD to come to a resolution of the process, and I think this document is better than no document, so I am balloting No Objection.
Thank you for the progress with this document since I first balloted No Objection.
(1) Why repeat stuff from draft-ietf-v6ops-6to4-advisory? I think just referring to that document would be better since it gives a fuller and better explanation. That could lead to just removing section 3 entirely I think. (2) I have no strong opinion as to whether deprecating the domain and addresses in section 5 is right or wrong. However, I do think that since draft-ietf-v6ops-6to4-advisory does have what look like some very useful recommendations about these, that a reference to that document in the IANA considerations section would be good since the current text there looks like its saying "turn all that off please" and I don't think that's what you're trying to say. Maybe something like: "Note however that [I-D.ietf-v6ops-6to4-advisory] recommends that various actors take various actions related to these addresses. The reader is encouraged to follow those recommendations and is not encouraged to simply turn off these addresses." If putting that in the IANA considerations section is wrong, then I think correcting the impression elsewhere would be good, maybe with something like: "Despite what you might think from reading the IANA considerations section of this document, we are not recommending that people turn off the addresses deprecated there. The IANA considerations section is simply a set of instructions to IANA. Please consult [I-D.ietf-v6ops-6to4-advisory] for the actual set of actions recommended." (I'm sure the phrase "turn off" in the suggested text above is wrong, but that should be easily corrected and it may need to also say something about the domain as well, I don't know.)
For additional color, see: https://labs.ripe.net/Members/rbarnes/world-ipv6-day-asymmetric-6to4-measurements
I appreciate the difficulty in getting consensus on this document and applaud the diligence of the authors and chairs in finding that consensus.
The -07 version of the document encourages the use of a single port for both secure and non-secure communication. I am concerned that the outcome will be to encourage the use of mechanisms analogous to STARTTLS in future protocol specifications. A two-port secure/non-secure model is preferable to any mechanism that supports a downgrade attack: the port number signals that the connection must be secure, or is not expected to be secure. Barry raised a DISCUSS on this text, but unfortunately it looks like the conversation that followed did not fix the issue, and indeed may have made it worse. I am concerned that the document as written and with the proposed changes will lead protocol designers to rely on a single port for secure and non-secure communications in situations where this unavoidably exposes the communication to a man-in-the-middle downgrade attack. I would expect that pretty much any dual-use port would be subject to this risk: dependably preventing it is possible, but hard, and only possible if the thing that signals the initiator to connect to that port can securely indicate whether to use the secure or non-secure mode. I would therefore like to see the text emphasize this concern, rather than emphasizing the concern that if two ports are used, administrators will default to using the non-secure mode. I agree that this latter issue is a concern, but it is a concern for any protocol that allows a non-secure mode, whether it uses the port number to signal that or the signaling is done out of band. The only sense in which using a single port mitigates this concern is if the single port _only_ support secure, authenticated communication. An alternative would be to simply not take a position either way, but the text currently makes some good points about the tradeoffs, which would have to be lost in order to avoid taking a position, so I don't really want to encourage that solution.
Overall this is an excellent document and I support publication: the DISCUSS I've entered should not be taken as an indication otherwise. Thanks for doing this--it's very complete and should serve as a good guide for working groups designing new protocols.
[Updated to remove the middle of three points to the Comments section] Thanks for this work. I think it is helpful for authors and protocol designers to understand the way that the port experts approach this issue. But I have some concerns that I hope we can work out quite simply. --- I understand that the current situation with the number of free ports is in some respects due to the "policing" by the port experts. But I disagree that the situation is such a severe state that fierce rules are needed. And "compliance statements" are fierce rules not recommendations or guidance. Furthermore, this document brings to the fore the thin line between the opinions of the port experts and the opinions of the IETF community. If, for example, the community chooses (with appropriate discussion and consideration) to request IANA to allocate a port via an IETF consensus standards track document, I believe that request should be honored. Obviously the port experts should express their opinions as firmly as they hold them, and the TSV ADs may support their opinions, but I do not think that the port experts should ultimately be able to override the community consensus. I would appreciate it if this document made it clearer that the "rules" it defines are guidance only, and that exceptions may be made when there is community consensus to make such exceptions. --- Section 7.6 has >> Services SHOULD NOT use UDP as a performance enhancement over TCP, i.e., to circumnavigate TCP's congestion control. Is this a port use issue, or guidance about how to use transport protocols in a harmonious Internet? I think it is the latter and has no place in this document.
I appreciate that this document was sent for early cross-area review as noted in the shepherd write-up. It's a little disappointing that Routing wasn't included in that process given the recent interesting debates about the use of ports for indicating UDP tunnel payloads, and about ports for different types of BFD usage. Well, no point in bitching about that now. There was an IETF last call, and --- I agree with Ted's Discuss about secure and insecure variants on different port numbers. RFC 6335 says Note: At the time of writing of this document, there is no IETF consensus on when it is appropriate to use a second port for an insecure version of a protocol. I don't see that Section 7.4 of this document has established that consensus, and I believe that there are good reasons to distinguish secure and insecure protocol versions (esepecially with legacy, insecure protocols) by use of separate port numbers. Furthermore, Section 7.4 goes *way* beyond the scope of the document by stating how new "services" should be designed. Is it the place of this document to tell protocol designers what security they should put in their protocols? (It doesn't matter whether the advice is good or not, it seems unlikely that this section has been reviewed by people who believed that the document was only about recommendations for port number assignment and uses). [I almost made this a Discuss in it's own right, but I think it can piggy-back on Ted's Discuss.] --- Notwithstanding our disagreement about quite how critical conservation may be and how practical some of the principles in 6.1 are, I find the compliance requirement in Section 6 hard to parse. >> Each port requested MUST be justified as independently necessary. Could you explain or reword "independently necessary"? Independent of what? "Justified" by whom / to whom (I think that is more obvious, but it wouldn't hurt to spell it out). --- Section 7.6 has However, to conserve space and to reflect increasing use of other transports, assignments are now specific only to the transport being used. Can you clarify what space you are referring to? If this is text space on a web page, then this is not a particularly meaningful reason. --- Section 7.6 has >> Services SHOULD NOT use UDP as a performance enhancement over TCP, i.e., to circumnavigate TCP's congestion control. Is this a port use issue, or guidance about how to use transport protocols in a harmonious Internet? I think it is the latter and has no place in this document. --- Shouldn't Section 7.6 say something about the use of the same port number for different services with different transports? That is, you have that port xyz will only be registered for the transport protocols that service A uses. But you don't go on to say that port xyz having been registered for service A on transport protocol Z MUST NOT be registered for service B on transport protocol Y. --- Section 7.7 Deployments that use port numbers before deployment complicate IANA management of the port number space. Keep in mind that this I think s/before deployment/before assignment/ ---- [This item removed from my Discuss] I think that the "guiding principle" in 6.1 that says... o Copies of an existing service can be differentiated by using different IP addresses, either on different hosts or as different real or virtual interfaces (or even operating systems) on the same host. ... describes an option, but it is wrong to suggest it as a solution. The main thrust of the document says that it is wrong to include a demultiplex reference at the transport layer when what is being multiplexed is really at the application layer (or at last at the level of the payload of the transport protocol). Yet this suggested remedy actually pushes the demultiplex identifier to the network layer. That really is not a good thing to recommend. ...Further to email discussion with the author, I think that this is describing a situation where copies of a host are being made, not copies of a service. It is not a significant Comment, but I feel that this bullet is distracting from the main list of suggested solution.
Mostly for the IESG: I agree that this document does not update 6335. I agree that it is supplemental. And I agree that it's a BCP. So let's make it part of BCP165. This doesn't need a new BCP number. It's part of the same series. 1: A bit of clarification would be useful: OLD Note that this document provides information to potential port number applicants that complements the IANA process described in BCP165 [RFC6335], but it does not update that document. NEW Note that this document provides information to potential port number applicants that complements the IANA process described in BCP165 [RFC6335], but it does not change any of the port number assignment procedures described therein. I don't think you need to say anything about the "update" status. 2: In this document, the characters ">>" preceding an indented line(s) indicates a compliance requirement statement using the key words listed above. This convention aids reviewers in quickly identifying or finding the explicit compliance requirements of this RFC. Generally, this sort of things simply produces eye-rolling in me and nothing more. 2119 keywords are not about "compliance", and so to claim above that you are using them "as described in RFC-2119" and then go on to include them in "compliance requirements" is bogus. However, most of these "compliance requirements" in the rest of the document are simply summary advice regarding what's going to be useful and what won't, so really what's in the ">>" is not a "compliance requirement", but rather an "Important Summary Note". I'd really prefer you call them that here. That said, one of them in 7.4 actually gave me pause: >> When simultaneously requesting both a secure and an insecure port, strong justification MUST be provided for the insecure port. Precedent (citing other protocols that use an insecure port) is not strong justification by itself. A strong case for utility of the insecure service is REQUIRED for approval of the insecure port. Here it sounds like you *are* imposing a requirement, and it sure sounds to me like you're specifying a registration procedure to be enforced by the Designated Expert or IANA, not giving a piece of advice to the registrant. If it wasn't for the last sentence in the above, I wouldn't have thought twice about it. So my two suggestions are: - Change the text in section 2 to not call these "compliance requirements". If you don't like "Important Summary Note", choose something else. - Change or delete the last sentence in the paragraph from 7.4. (I think delete is fine; it's repetitive anyway.) 7.4/7.5: I agree with Alissa's comments regarding the ">>" statements. Either re-word them to be about port assignment or ditch them.
- I share the concern that this needs to be in-whack with RFC6335 but sometimes overstates things, e.g. some of the MUST NOTs in 7.7. I'm fine that that's being discussed already. - The one-port/two-port thing: I don't think there's a real seurity difference here in general, so that is not a basis on which to prefer to discourage the registration of two ports, nor is it a reason to prefer to do that. It is however, also reasonable to want two ports, one e.g. using TLS and one not, and it is equally reasonable to use STARTTLS. Basically, please move on, there's nothing to see here, find another argument:-) - I would like to see a statement that, in allocating a new port for a "secure" variant of an existing protocol, the port experts will consider actual deployment, even if it is the case that some RFC says that one can do security stuff on the currently assigned port. If we do not allocate such ports, then we would be getting in the way of improving real security, and that would be bad. I'm not sure from the text what the port experts do in such cases, but as that is not addressed by the current document, the RFC that results won't be a block on such allocations (where justified). - 7.8, "easily resolved" to be the squatter's fault is not true - in general people will I think consider the most widely deployed use of a port to be in the right, and most people won't even go look at the IANA registry. (Some will, including no doubt the port experts.)
Thanks for writing this document! Just one nit: On page 6 in this paragraph: As a concept, a service is the combination of ISO Layers 5-7 that represents an application protocol capability. For example www (port number 80) is a service that uses HTTP as an application protocol and provides access to a web server [RFC7230]. However, it is possible to use HTTP for other purposes, such as command and control. This is why some current service names (HTTP, e.g.) are a bit overloaded - they describe not only the application protocol, but a particular service. This paragraph introduces the term „service names“ which has not been used before. It would be good to define the term in contrast to the port numbers for naive readers. The explanation of service names comes later, probably too late (just before the beginning of Section 6). How about introducing service names just before?
Some of the ">>" compliance points here are only marginally related to the subject matter, e.g.: ">> New services SHOULD support security, either directly or via a secure transport such as TLS [RFC5246]." ">> UDP over IPv4 multi-host services SHOULD use multicast rather than broadcast." ">> Services SHOULD NOT use UDP as a performance enhancement over TCP, i.e., to circumnavigate TCP's congestion control." While these may be good things to say, they don't belong in this document.
I share Alissa's comments that the rationale for conservation is a bit shaky. Clearly conservation is prudent, but it doesn't seem like there's a crisis here. Section 3: The values in the "Binary" column are decimal, as indeed they are labelled in RFC 758. Section 7.4: I agree with Stephen here. Separate ports and STARTTLS are equivalent from a security/downgrade POV -- either you need to know to use the secure port, or you need to know to require STARTTLS to succeed. The only difference is that STARTTLS adds latency if you're doing TLS. You can avoid that by starting secure (STOPTLS?), but in either case, there's a loser. But ISTM that the document addresses this point sufficiently.
You may already have the few sentences queued up as a result of your response to the SecDir review: https://www.ietf.org/mail-archive/web/secdir/current/msg05422.html Essentially adding mention of DTLS and IPsec as options to secure sessions in addition to TLS. I do think the point Dan raised was good and appreciated your response, but this draft version is prior to that discussion. This is a placeholder to check for that text. If you have a version to look at, let me know and I'll peek at that one.
Thanks for your work on this draft. I do have some comments I'd like to chat about, but others already had discuss items on a few of these, so I am either weighing in or providing suggestions to help resolve. For what it's worth, I read 6.2 as informational background and think the text is helpful. Alissa has a discuss on this, so if the text is changed, I'd be interested to see what the suggested changes would be so that the draft still conveys the helpful information (which she was not opposed to in the discuss). I've configured hundreds of firewalls and what is described is what folks need to know when configuring such devices. Alternate port use can be used to get around rules you put in place and services like FTP in the old days would have used an FTP proxy and today that type of analysis on traffic to open the correct ports is called DPI. The following "much debated" text was raised on the SAAG list by Stephen & I and so far there's no consensus for multiple ports. I'll update if there is, but I suspect there won't be. I do think that some changes to the text could be helpful and I'm not sure where to look for changes that happened from Barry's review... I am fine with the text Barry suggested to replace the first of the following two paragraphs and I don't think the second one is needed, perhaps deleting it as Barry's new text covers that enough. I just wasn't sure if that was already part of the updates in the works. o Separate port numbers are not intended for insecure versions of existing (or new) secure services. A service that already requires security would be made more vulnerable by having the same capability accessible without security. Note that the converse is different, i.e., it can be useful to create a new, secure service that replicates an existing insecure service on a new port number assignment. This can be necessary when the existing service is not backward-compatible with security enhancements, such as the use of TLS [RFC5246]. 7.4 - I'm fine with the text in this section discouraging the use of a second port for an insecure version of the protocol as we are pushing back on creating insecure versions anyway. Typically, this is all over one port with options to upgrade to increased security (encryption & authentication). I don't think this draft is the right place to go further than you already have, so I'm good with most of it. I think it was Alissa that raised a point on this sentence in the paragraph following the compliance bullets and I agree with it, so I suggest a change from: Either approach is currently permitted, although use of a single port number is consistent with port number conservation. To: Either approach is currently permitted. The second sentence of the paragraph after that should be deleted, leaving the argument just between performance and security. Delete: As discussed earlier, port numbers are a critical resource and it is inappropriate to consume assignments to increase performance. Thanks!
Thanks for quickly addressing my DISCUSS points, two of which are cleared and two of which are now comments here: -- Section 7.4 -- >> New services SHOULD support security, either directly or via a secure transport such as TLS [RFC5246]. In this context, "security" is too vague a term: what, exactly, does "SHOULD support security" mean? Are you talking about authentication? Access/authorization controls? Confidentiality? Specifically, encrypted communication? I think you mean the last. << Joe Touch responds: It would be useful to explain. Security depends on the service being offered; for some, encryption, integrity protection, and source identity are all expected, but for many services only a subset of these might be relevant. >> We should add such an explanation. -- Section 7.4 -- >> When simultaneously requesting both a secure and an insecure port, strong justification MUST be provided for the insecure port. Precedent (citing other protocols that use an insecure port) is not strong justification by itself. A strong case for utility of the insecure service is REQUIRED for approval of the insecure port. This seems significantly stronger than what RFC 6335 said, and this point was hotly debated in the development of that document. RFC 6335, Section 9, says this: Services are expected to include support for security, either as default or dynamically negotiated in-band. The use of separate service name or port number assignments for secure and insecure variants of the same service is to be avoided in order to discourage the deployment of insecure services. As this document does not update 6335, I don't see how the MUST and the REQUIRED are appropriate. But perhaps I can be convinced by some discussion. Joe Touch responds: << Again, one doc applies to IANA, the other to protocol designers. RFC6335 explains why IANA should avoid such an assignment; this doc explains that a designer is expected to justify the need in an request to IANA. It might be useful, as a result, to remove the 2119 language, e.g., to write this from the perspective of advice to the applicant: >> When simultaneously requesting both a secure and an insecure port, strong justification is expected for the utility and safety of a separate insecure port. Precedent (citing other protocols that use an insecure port) is not strong justification by itself. >> The rest of these are non-blocking, but please consider them -- many are meant to clarify the text, and I hope they succeed in that. In three places: -- Abstract -- This document provides recommendations to application and service designers on how to use the transport protocol port number space. -- Section 1 -- It also provides specific recommendations to designers on how to use assigned port numbers. -- Section 2 -- In this document, the characters ">>" preceding an indented line(s) indicates a compliance requirement statement using the key words listed above. First, recommendations on how to use *port number space* is not the same as recommendations on how to use *assigned port numbers*. I interpret the former as recommendations about making requests for port numbers, and the latter as recommendations about use of the port numbers after they've been assigned. These should be worded consistently. Second, recommendations, whichever type of recommendations they be, are not the same as compliance requirements. I read the former as suggestions, and the latter as, well, requirements. If the document is giving requirements that cover port-number requests -- and it is, complete with MUSTs -- it needs to clearly say that up front, and get rid of the "recommendations" stuff (or say both, that there are both requirements and recommendations here). -- Section 5 -- Consider a user wanting to run a web server. That service could run on any port number, provided that all clients knew what port number to use to access that service at that host. Such information can be distributed out-of-band, e.g., in the URI: http://www.example.com:51509/ It's a fine point, but having the port number in the URI doesn't actually distribute it "out of band" (which doesn't need hyphens in this context). I would say, "Such information can be explicitly distributed -- for example, by putting it in the URI:". IANA assigns port numbers so that Internet endpoints do not need pairwise, explicit coordination of the meaning of their port numbers. This is the primary reason for requesting assigned port numbers with IANA - to have a common agreement between all endpoints on the Internet as to the default meaning of a port number. This only says half of it, and omits a very important piece, I think. May I suggest this?: NEW IANA assigns port numbers so that Internet endpoints do not need pairwise, explicit coordination of the meaning of their port numbers. This is the primary reason for requesting assigned port numbers with IANA - to have a common agreement between all endpoints on the Internet as to the default meaning of a port number, and to provide the endpoints with a default port number for a particular protocol or service. END >> Each port requested MUST be justified as independently necessary. This is a fair statement, and yet I worry that including "necessary" may result in arguments between protocol designers and port experts about what is and isn't "necessary", and what the community's consensus is on it. I'm not sure how to minimize that. I'd say "MUST be independently justified," which does get the point you want (the independent justification) without using the loaded word "necessary". I'd prefer that wording, though I admit that it can just as easily result in the same arguments. -- Section 6.1 -- o Copies of an existing service can be differentiated by using different IP addresses, either on different hosts or as different real or virtual interfaces (or even operating systems) on the same host. As a guiding principle for protocol designers, this worries me: it's an operational point, not a point of protocol design. I'd have no objection if this were explicitly cast as an operational suggestion. o Services requiring varying performance properties can already be supported using separate endpoint associations (connections or other associations), each configured to support the desired properties. I can't figure out what you mean here. Do you have an example, or can you tweak the explanation? -- Section 7 -- 7. How to Use Assigned Port Numbers Port numbers are assigned by IANA by a set of documented procedures [RFC6335]. The following section describes the steps users can take to help assist with the use of assigned port numbers, and with preparing an application for a port number assignment. In both the title and the paragraph, you refer to the "use" of "assigned port numbers", and yet the entire section talks about getting port assignments, not about using the port numbers after they're assigned. I suggest this instead: NEW 7. Considerations for Requesting Port Number Assignments Port numbers are assigned by IANA by a set of documented procedures [RFC6335]. The following section describes the steps designers can take to help assist with the responsible assignment of port numbers, and with preparing an application for a port number assignment. END -- Section 7.1 -- o Port numbers are not intended for indicating different service versions. Version differentiation should be handled in-band, e.g., using a version number at the beginning of an association (e.g., connection or other transaction). This may not be possible with legacy assignments, but all new assignments should incorporate support for version indication. Is this meant to say "but all new protocols should incorporate support for version indication."? It's not the assignment that does that. Some users may not need assigned port numbers at all Is this meant to say "some uses may not" (or "some protocols", but not "some users")? -- Section 7.2 -- There are a variety of known ways to reduce port number use. Although some may be cumbersome or inefficient, they are always preferable to consuming additional port numbers. 1. I think "reduce port number consumption" might be a better way to say what you mean here. 2. I don't think "always preferable" is consistent with the consensus on RFC 6335. I would accept "usually preferable", but not something as strong as "always". Although automatic configuration protocols have been proposed and developed (e.g., STUN [RFC5389], TURN [RFC5766], and ICE [RFC5245]), application and service designers cannot yet rely on their presence. I wouldn't call STUN, TURN, and ICE "automatic configuration protocols". I'd refer to them as "NAT traversal protocols". -- Section 7.3 -- Would a TCP (or other transport protocol) port number assignment be useful by itself? If so, a TCP (UDP) port number can be assigned whose port number is already (or can be subsequently) assigned to a different transport protocol. I'm not sure what you're getting at here. Are you saying that if you need a TCP port, you might pick one where the UDP port of the same number is (or can be) used for something else, and vice versa? If so, I don't think it says that at all clearly. In any case, can you please rephrase this to make it clearer? >> Developers SHOULD NOT apply for System port numbers because the increased privilege they are intended to provide is not always enforced. Hm. This sounds odd to me: it seems that it's setting up a feedback loop that's self sustaining. You might want a system port number to get protection against running on that port by non-root. But you won't always get that protection. So you shouldn't ask. So no one asks, and so no one gets the protection even when it's available. Do you think this works as well for you?: NEW >> Developers SHOULD request User port numbers, to avoid using the more limited System port number space. Consider that the increased protection that System ports are intended to provide is not always enforced. END I would also move that paragraph down one, so that it's after the "Even when developers" paragraph. -- Section 7.4 -- >> Security SHOULD NOT rely on port number distinctions alone; every service, whether secure or not, is likely to be attacked. I find this underspecified. I don't know what I should be doing about this. As in the DISCUSS, "security" is a vague term, and I don't know how to determine whether I've met this requirement, nor how to assess whether my situation is suitable one for not following it. Optional security can penalize performance, requiring additional round-trip exchanges before a connection or other association can be established. As discussed earlier, port numbers are a critical resource and it is inappropriate to consume assignments to increase performance. As a result, the need for separate ports for both secure and insecure variants is not justified merely for performance Where was this discussed earlier? The only thing I see related to performance that was discussed earlier is that it's not appropriate to have different ports to support different performance levels. That's not the same thing that you're talking about here. I agree with the conclusion (in the final sentence I quote). - either for the connection or association establishment performance or differences in data performance between secure and insecure variants. I can't parse this. Are there words missing or some such? Note however that a new service might not be eligible for IANA assignment of both an insecure and a secure variant of the same service, and similarly applications requesting assignment for both an insecure port number for a secure service might not be appropriate. I'm having trouble with this one also; I can't parse what comes after the comma. Maybe split the sentence into two, and rephrase? -- Section 7.5 -- How can this apply retroactively to current assignments? And "the multiple versions" should probably lose the "the". -- Section 7.6 -- Spencer has been picking on the use of 793 as a reference for TCP. Spencer, is 793 an acceptable reference for TCP here? It would probably be better to attach the references to their protocols, rather than to have them in a group at the end of the list. Originally, IANA port number assignments were concurrent for both UDP and TCP; other transports were not indicated. Total nit: I think this sentence doesn't work well with a semicolon, and would prefer changing the ";" to ", and". When the services differ, their service names and descriptions should reflect that difference. I had a little trouble with this and the discussion leading up to it, which I think can be fixed by saying explicitly that in this case, it's OK (perhaps even encouraged) to use the same port, but different service names. Perhaps something like this?: NEW When the services differ, it may be acceptable or preferable to use the same port number, but the service names and descriptions should be different, reflecting the differences in the services. END The following convention has been used by IANA for several years to distinguish discovery services, such as are used to identify endpoints capable of a given service: >> Names of discovery services SHOULD use an identifiable suffix; the suggestion is "-disc". It reads oddly to have "the following convention" point to a normative requirement, and not just to the convention. Again, a nit, but I think it would read better like this: NEW IANA has, for several years, used the suffix "-disc" in service names to distinguish discovery services, such as are used to identify endpoints capable of a given service. >> Names of discovery services SHOULD use an identifiable suffix; the suggestion is "-disc". END because IP routers do not forward "all nodes" (all 1's, i.e., 255.255.255.255 for IPv4) broadcasts and have not been required The phrase << "all nodes" broadcasts >> needs to stay together, and splitting it with the explanation made me trip over it. I suggest moving the word "broadcasts" before the parenthesized bit. >> Services SHOULD NOT use UDP as a performance enhancement over TCP, i.e., to circumnavigate TCP's congestion control. Is circumventing congestion control the only possible performance enhancement here? This sentence really makes one ask whether "i.e." is correct, or you mean "e.g.", and I think it'd be better done one of these ways: If you mean to say that congestion control is the only reason: NEW >> Services SHOULD NOT use UDP to enhance performance by circumventing TCP's congestion control. END If there might be other performance-enhancement reasons: NEW >> Services SHOULD NOT use UDP as a performance enhancement over TCP. For example, do not use UDP to circumvent TCP's congestion control. END (The right word is "circumvent", not "circumnavigate".) -- Section 7.7 -- Applications made through Internet Draft / RFC publication (in any stream) ... When a document has been approved for publication and proceeds to IESG Approval The first sentence tries to make this stream-independent, but the "IESG Approval" later in the paragraph is specific to the IETF stream. Because you already say "approved for publication", you can just omit the "and proceeds to IESG Approval" phrase. -- Section 7.8 -- Such "squatted" port numbers remain unassigned, and IANA retains the right to assign them when requested by applicants. It might be good to be completely clear and say "requested by other applicants," lest readers think you mean to be talking about when the squatters make an application later. The last paragraph in this section starts by encouraging squatters to make registrations now, but then shifts to a discouraging tone. I wonder if you mind changing the tone a little, maybe changing the idea of "not justified" to something more like "unable to accommodate". Perhaps like this?: NEW Designers who are using such port numbers are encouraged to apply for an assignment. Every effort will be made to accommodate such requests, though even with widespread de-facto use, if the port number has already been assigned to another applicant such accommodation might not be possible. Note also that the application must pass review by the IANA Ports Expert Review team, as must any port application. END -- Section 8 -- The port number alone should not be used to avoid denial of service or firewall traffic because their use is not regulated or validated. To "avoid ... firewall traffic"? What's that mean? I think you mean "to avoid denial-of-service attacks or to manage firewall traffic", yes? And then what is the "they" in "their use"?
I agree with Adrian's DISCUSS
I have many of the same questions as Barry.
Thanks for writing this. Overall I agree with its conclusions. But the way that it reaches those conclusions seems lacking or misguided in a couple of respects, so I'd like to discuss those. The document argues that port numbers should be conserved and gives basically three reasons why (my summary): 1. Port numbers are designed for a specific purpose and conservation helps maintain that specificity. 2. The port number space is smaller than other number spaces. 3. Because of firewall and NAT interactions. Reason (1) seems unobjectionable. Reason (2) is true, but it doesn't really offer a compelling argument in light of the pace of assignments to date. The document indicates that about 11% of the port number space has been allocated over several decades. Does that really create cause to worry about running out of space? Are we suddenly being flooded with port number requests? If the rate of assignments doubled or tripled, would we worry about running out of port numbers? Again, I'm not saying this isn't worth pointing out, but in terms of making a compelling argument to developers about the need to conserve port numbers, I don't think this works. That leaves reason (3), and in this case it seems like the document is making contradictory statements at times. On the one hand, many of the recommendations seem motivated by the fact that firewalls make judgments on the basis of port numbers, and therefore conservation makes firewall configuration easier and reduces application fragility that can arise from having some ports blocked. On the other hand, the document notes that port numbers should only be considered meaningful to endpoints and details some of the complications that arise when firewalls instead associate meaning to them. The message comes across as contradictory -- intermediaries are interpreting port numbers in all kinds of ways that they shouldn't, but we should take a conservative attitude towards port number assignment so that they can keep doing it. I think it's totally fine to represent the state of affairs when it comes to how firewalls treat ports. But if that treatment is in some ways a perversion of the motivation for having port numbers in the first place (and if it wreaks some havoc on application development/deployment, which it does), I don't think it's appropriate for us to publish a BCP that predicates its recommendations on that perversion. The upshot of these comments would result in some editing of sections 5 and 6, but I wanted to have the discussion before suggesting edits.
I think I may have some overlapping comments with Barry, but I wrote this before I saw his comments, so my apologies. -- Sec 5: "Port numbers can also be useful for other purposes." I would suggest s/useful/used/ because whether the purposes listed in the previous paragraph (e.g., monitoring, blocking, etc. based on port number) are considered "useful" is in the eye of the beholder. -- Sec 7.4: The term "security" is really vague. It would help to define what is meant by "security" or "secure service." -- Sec 7.4 and 7.5: Both of these sections contain recommendations that are good, but seem out of place in this document unless they could be made more specific to port use. The ones that jumped out at me are: >> New services SHOULD support security, either directly or via a secure transport such as TLS [RFC5246]. >> Insecure versions of new or existing secure services SHOULD be avoided because of the new vulnerability they create. >> Version support SHOULD be included in new services. I would say to either remove these or add in the context of what they have to do with port number assignment (e.g., "Version support SHOULD be included in new services rather than relying on different port number assignments for different versions.") -- Sec 7.7: "Deployments that use port numbers before deployment complicate IANA management of the port number space." I think this is supposed to say "before assignment" rather than "before deployment." -- Sec 7.8: ""Squatting" describes the use of a number from the assigned range in deployed software without IANA assignment. It is hazardous because IANA cannot track such usage and thus cannot avoid making legitimate assignments that conflict with such unauthorized usage. Such "squatted" port numbers remain unassigned, and IANA retains the right to assign them when requested by applicants." This is a little confusing -- is the first sentence supposed to say "unassigned range"? If not, what is the assigned range, and why is IANA said to retain the right to assign numbers that are already assigned? I would have thought squatting would be understood as using unassigned numbers in the system and user ranges. "In particular, any unassigned code from the assigned ranges will be assigned by IANA, and any conflict will be easily resolved as the protocol designer's fault once that happens (because they would not be the assignee). This may reflect in the public's judgment on the quality of their expertise and cooperation with the Internet community." This seems a little over-the-top to me. I would suggest: "IANA may assign any code from the system or user ranges to applicants that meet all of the relevant criteria, and is not obligated to take into consideration the existence of squatters when doing so. Squatting is viewed as uncooperative behavior in the Internet community."
At some future date, it might be useful to deprecate the distinction between System and User port numbers altogether. Services typically require elevated ('root') privileges to bind to a System port number, but many such services go to great lengths to immediately drop those privileges just after connection or other association establishment to reduce the impact of an attack using their capabilities. Such services might be more securely operated on User port numbers than on System port numbers. operationaly we already have dropped the distinction. there is not practical distiction for a new service allocated out of the remaining 180 system ports and one allocated out of the user ports so we might as well treat the port space as flat.
I support Stephen's DISCUSS, but don't otherwise object.
I have No Objection to the publication of this document. I don't think the use of "MAY" in section 5 adds anything over "may"
I'm concerned that the information model of this log format encourages the sharing of far more granular information than is justified by the use cases. All of the use cases in Section 2 are focused on statistical information, in which case collecting things like individual IP addresses and ports is unnecessary.
Let me preface the specific discuss points with an overall point - I do not think our job here is to force CDNs to behave well in relation to privacy. However, it is our job to provide an API that encourages and effectively supports behaving well in relation to privacy. So, that said... (1) 188.8.131.52: there's no interoperability need for this section, and even if there are data retention requirements to be met, I don't see how the logging API is relevant to that. For example, a dCDN would not have it's data retention requirements met by a uCDN I think. I think just deleting this is the right action. (2) 3.3: MD5 is no longer good enough for data integrity and 128 bits in 32 ascii-hex is too short for SHA-256, which ought be the MUST alg here. (Some variable length is needed or else put the algorithm name in the field name.) (3) c-ip-anonymizing: guidance is needed that IPv4 and IPv6 aren't the same here. Why isn't the same idea done for c-port and other fields? Has there been any analysis of the effectiveness of this scheme in not allowing identification or re-identification? If not, isn't that really needed if we are serious about defining an API that can protect privacy? If that was discussed on the list, please send some pointers so I can get familiar with the work during the discussion. (4) Why is c-ip MTI but the (hopefully) privacy friendly variant is not? (5) I'm not clear why you need to be able to send HTTP header values or session IDs via this i/f. Why is that needed? (And it seems very dangerous, e.g. "cs(COOKIE)" could be a doosy.) (6) Just checking - given relevations of snooping, why not say "MUST use TLS with mutual-auth"? In particular if we don't end up with a usefully privacy-friendly version of this, where is the safe-but-cleartext use-case described that justifies the current SHOULD?
- I support Richard's discuss. Isn't it ironic that the dCDN's privacy (that of a company) is better supported than that of the end user (a person) - 2.2.1 - why is per-chunk always needed? - 184.108.40.206: what's "track audience" mean? - 220.127.116.11: there are more security goals in the universe - 18.104.22.168: seems like the user is the enemy, that's odd - 22.214.171.124.2: there is no "browser type header" that I know of, but there is the well-known UA string. Being specific about that is better. - 3.1: SS.S - does that imply a time granularity of 100ms? If so, please say so. - 3.4.4: cs-uri: please not that these can be privacy sensitive, though presumably less so than e.g. logged URIs on a search engine. - 3.4.4: foo-uri: do these contain fragments or not?
Thanks for working on this very useful specification. I think it is soon ready to move forward, but there are a couple of things that we should try to address before the final approval. Martin raised a number of comments in the Gen-ART review, and I'd like to see the resolution of those. For me, I think the following issues at least deserve a document change: I'm not sure the definition of <CDNI Logging File> is correct. I would simply do CDNI-LOG-FILE = 1*(DIRGROUP / RECGROUP) For the reasons that Martin outlined. Also, Section 3.4.1 needs an update, given that HTTP 2 specifications have been approved. I suspect you could simply say that the work applies to both HTTP 1 and 2, and that any new information derived from HTTP 2 specifically is outside the scope of this spec. Security considerations should rather refer to existing mandates in TLS specifications (such as the UTA document that was recently approved) rather than make their own specific crypto requirements.
I am very concerned about the syntax specification here. I'm not convinced it's complete and correct. I am certainly willing to be talked out of my concern, but I think this could use a massive edit by someone who knows ABNF, as well as a discussion about intended contents. Details: 3.1: I always prefer to import the rules you are using simply by reference rather than of copying them. Prevents silly errors. On these, let's see if you really mean what you say you mean: NAMEFORMAT = ALPHANUM *(ALPHANUM / "_" / "-") So, are you really OK with a NAMEFORMAT of "1---___---"? Often what people really want is: NAMEFORMAT = ALPHANUM *(["_" / "-"] ALPHANUM) Is that what you want? On the next bit: QSTRING = DQUOTE *NDQUOTE DQUOTE ; where NDQUOTE = <any OCTET excluding DQUOTE> / 2DQUOTE ; whereby a DQUOTE is conveyed inside a QSTRING unambiguously by repeating it. NHTABSTRING = *NHTAB ; where NHTAB = <any OCTET excluding HTAB, CR and LF> (By way of formatting, outdent NDQUOTE and NHTAB, and get rid of "; where".) When you say <any OCTET excluding ...>, is that what you really mean? You want to allow control characters? Seems to me that that is going to introduce a whole new set of security considerations. Also, the fact that you call these things xSTRING sends up a flag for me that you maybe want them to be textual. Are you allowing for things outside of US-ASCII? Section 3.2 seems to say only US-ASCII. Finally, do you really want NDQUOTE to allow for CR, LF, and HTAB? That means that parsers have to be a bit smarter, and the line in 3.2 that says, "Each line ... MUST contain either a directive of a CDNI Logging Record", and the line in 3.4 that says, "CDNI Logging Fields MUST be separated by the HTAB character", both seem bogus. So, assuming you want only US-ASCII and that you don't want CR LF or HTAB in any of these, these should be: QSTRING = DQUOTE *NDQUOTE DQUOTE NDQUOTE = SP / %x21 / %x23-7E / (DQUOTE DQUOTE) ; DQUOTE is conveyed inside a QSTRING unambiguously by repeating ; it. NHTABSTRING = *NHTAB NHTAB = SP / VCHAR or if you like, simply: NHTABSTRING = *( SP / VCHAR ) If you want non-US-ASCII, I'd include UTF-8 and call that out. I can tell you how to do that, but I hope you're not doing that. If you want CR and LF in both QSTRING and NHTABSTRING, and HTAB in QSTRING, you need to fix the lines in 3.2 and 3.4. If don't want them, you're going to have to describe how to unfold and de-tab the HTTP header field values somewhere. 3.2: RECLINE = <CDNI Logging Record> CRLF RECGROUP = *RECLINE <CDNI Logging File> = 1*<DIRGROUP RECGROUP> These seem kind of a cop-out. Seems like you could easily define RECLINE as: RECLINE = date HTAB time HTAB time-taken HTAB ... date = DATE time = TIME time-taken = DEC [...] The last line is nowhere near legitimate ABNF. How about just defining a proper LOGFILE as: LOGFILE = 1*(DIRGROUP RECGROUP) If you're going to bother with ABNF, use ABNF. The explanations can still appear in 3.3 and 3.4.1. 3.3: The top-level ABNF for DIRNAME and DIRVAL give the implementer no help with regard to what is legitimate syntax. You mention the syntax for DIRNAME in 6.1, but that's not where it belongs. At least you should put in: DIRNAME = NAMEFORMAT For DIRVAL, you should probably have at least the most general format of: DIRVAL = NHTABSTRING / QSTRING and then give specifics below. But you could also change 3.2 and say something like: DIRGROUP = version uuid [claimed-orig] [established-orig] 1*record-type 1*fields [integrity-hash] *new-dir Then in 3.3, you could define: version = "Version:" HTAB "CDNI" "/" 1*DIGIT "." 1*DIGIT uuid = "UUID:" HTAB NHTABSTRING ... new-dir = <Newly registered directives> and indicate that unknown directives must be ignored, or something like that. This is wrong: o Fields: * format: FIENAME *<HTAB FIENAME> Angle brackets don't appear like that in ABNF. 3.4: Again, incorrect ABNF, if that's what it's meant to be.
Thanks for your work on this draft. I'd like to discuss a few points rom the security considerations section that we should be able to clear up quickly. In order for the following statements to be true, a little more text is needed, so I'll provide a suggestion. I see that you've recommended one of the cipher suites recommended in the new TLS BCP (in the RFC editor queue), so it appears a reference to that would be good to help with the strong statement already offered about TLS protections (true, if configured with best practice recommendations). Old: The use of TLS for transport of the CDNI Logging feed and CDNI Logging File pull allows: o the dCDN and uCDN to authenticate each other (to ensure they are transmitting/receiving CDNI Logging File from an authenticated CDN) o the CDNI Logging information to be transmitted with confidentiality o the integrity of the CDNI Logging information to be protected during the exchange New: The use of mutually authenticated TLS for transport, configured according to best practices [draft-ietf-uta-tls-bcp] of the CDNI Logging feed and CDNI Logging File pull allows: o the dCDN and uCDN to authenticate each other (to ensure they are transmitting/receiving CDNI Logging File from an authenticated CDN) o the CDNI Logging information to be transmitted with confidentiality o the integrity of the CDNI Logging information to be protected during the exchange I found the next paragraph a little difficult to read, so I'll offer a suggestion for that text as well. Old: In an environment where any such protection is required, TLS SHOULD be used (including authentication of the remote end) by the server- side and the client-side of the CDNI Logging feed and the CDNI Logging File pull mechanism unless alternate methods are used for ensuring the confidentiality of the information in the logging files (such as setting up an IPsec tunnel between the two CDNs or using a physically secured internal network between two CDNs that are owned by the same corporate entity). New: In an environment where any such protection is required, the use of a mutually authenticated encrypted transport MUST be used to ensure confidentiality of the log information. TLS SHOULD be used (including authentication of the remote end) by the server- side and the client-side of the CDNI Logging feed as well as by the CDNI Logging File pull mechanism unless alternate methods are used. Alternate methods could include establishing an IPsec tunnel between the two CDNs or using a physically secured internal network between two CDNs that are owned by the same corporate entity). Thanks for also putting thought into the privacy considerations and including anonymization options as that is one of the better options. I'd like to make a suggestion for the second paragraph as TLS is just protecting data in transit. Old: The use of TLS for transport of the CDNI Logging feed and CDNI Logging pull as discussed in Section 7.1 protects the confidentiality of logged information by preventing any other party than the authorised uCDN to gain access to the logging information. New: The use of mutually authenticated TLS to establish a secure session for the transport of the CDNI Logging feed and CDNI Logging pull as discussed in Section 7.1 protects access to the logged information. This provides confidentiality while the logs are in transit and prevents any other party than the authorised uCDN to gain access to the logging information. Thanks to the SecDir review which raised some of these issues. https://www.ietf.org/mail-archive/web/secdir/current/msg05452.html
I wish this draft had both a picture or two to show the message paths and had something that clearly showed what fields were copied and which generated and what the conditions were for the various message replies. I don't have concerns about the details of the text - but it is hard to pull the full picture together of what is happening. Sadly, I'm not expecting changes now.
IANA asked a question on 2/27 that hasn't been answered > Two comments/questions: > 1) For future reference purposes, please update the next version to include the > "K Octets" values for each of the new DS Mapping TLV: > > For IpV4 - 16 > For IPV6 - 40. > > Please note that IANA cannot reserve specific values. Value 5 is not > available. > However, early allocation is available for some types of registrations. > For more information, please see RFC 7120. > > 2) There is a place holder <TBA> in section 1.2 of this draft: > > [Note (to be removed after assignments occur): <TBA> = to be assigned > by IANA] > > Any value for <TBA>?
Review comments from Tom Taylor and Tom Yu appear to have been fumbled
+1 on diagrams.
- the security considerations seems to use the term "proxy node" when "proxy lsr" is used (there and) elsewhere. Maybe that could do with a bit of clean up? In particular the 3rd last para is unclear as to which node is meant in the 2nd sentence. (Or it wasn't clear to me at least.)
Thanks for writing this document, and for working through issues raised in the Gen-ART review. There was still a couple of questions in the review that I also looked into, and after reading the text in question, I also do not know the answer to. Perhaps some clarifications would be useful? Or otherwise, maybe there is some other explanation that at wasn't obvious to me. --- 2. Section 3.2.1, third paragraph, second sentence currently reads: "If the Proxy LSR is a budnode, a MPLS proxy ping reply SHOULD be sent to the initiator with the return code set to 3 (Reply router is Egress for FEC) with return Subcode set to 0 and DS/DDMAPs only if the Proxy initiator requested information to be returned in a MPLS proxy ping reply." Do you mean that the DS/DDMAP TLV is included only if the initiator asked for it (which seems like redundant advice) or do you mean that the reply is sent only if the initiator asked for the DS/DDMAP information? 3. Same paragraph, next sentence: why SHOULD rather than MUST? What is the exception? 4. Section 3.2.1, last paragraph (dealing with MP2MP case): the second to fourth sentences read: "LSP pings sent from a leaf of a MP2MP has different behavior in this case. MPLS Echo Request are sent to all upstream/downstream neighbors. The Proxy LSRs need to be consistent with this variation in behavior." s/has/have/ to get that out of the way. Do you mean that the initiator is a leaf of the MP2MP? How does the Proxy LSR know this? Does it matter?
That always makes me a sad when I see OAM technologies developed in silo. At least, existing OAM terminology and concepts should be reused. At the minimum, a mapping should be explained. Why? Because this is what network operators will have to do: here is yet another OAM technology they have to learn and integrate, how does it fit with the existing OAM tools? Note that LIME was created with that goal in mind. Anyway, I'm getting sidetracked: this issue is actually an issue for the IESG, not for this document. Hence a COMMENT and not a DISCUSS. For example, RFC 5357 +----------------+ +-------------------+ | Session-Sender |<-TWAMP-Test-->| Session-Reflector | +----------------+ +-------------------+ ^ ^ | | | | | | | +----------------+<----------------+ | | Server | | +----------------+ | ^ | | | TWAMP-Control | | v v +----------------+ | Control-Client | +----------------+ I've been trying to modify this picture with the concepts/terminology in this draft. So I contemplated the following definitions for some time (and read the text around it obviously)... Initiator - the node which initiates the ping operation by sending an MPLS Proxy Ping Request message Proxy LSR - the node which is the destination of the MPLS Proxy Ping Request message and potential initiator of the MPLS Echo Request Receiver(s) - the nodes which receive the MPLS Echo Request message Responder - A receiver that responds to an MPLS Proxy Ping Request or an MPLS Echo Request We note that in some scenarios, the initiator could also be the responder, in which case the response would be internal to the node. ... and I gave up. As mentioned by the Alia, Brian, Richard, without a diagram this is really not easy. Let me quote Alia's COMMENT: "Sadly, I'm not expecting changes now." I guess (and trust your routing AD) that the draft is fine from OPS point of view!
The security considerations looks good, thanks for that. I don't see a response on the SecDir review. The comments are mainly ones that might help a reader less familiar with the space as there are a few requests for clarifying details. https://www.ietf.org/mail-archive/web/secdir/current/msg05454.html
It's a nit, but in this text: It is anticipated that very large Point-to-Multipoint and Multipoint- to-Multipoint (MP2MP) Label Switched Paths will exist. I'm not understanding what dimension "very large" is conjuring up. Is this bandwidth, or length, or something else?
I agree with Alia's assessment that a diagram or two would have made the document much easier to understand.
Suresh Krishnan made some suggestions that I agree with in his Gen-ART review. The authors are looking into the comments, and hopefully they are given a chance to do so before the document is sent off to the RFC-Editor.
Thanks for the manageablity section. An example to follow. Regards, Benoit
I have No Objection to the publication of this document, but I should have liked more clarify on how the three updated RFCs are updated. Section 4.3 makes this very clear for 4861, but the updates to 4862 and 4429 are less clear. How about a new section 1.3 called "Updates to existing RFCs" that can summarise for all three RFCs and give a forward pointer to 4.3?
I'm a bit confused here - you use a field from SEND, and then say that that could be borked, so the mitigation is that one might use SEND to protect that. Why not just use SEND - can you explain?
A very quick read of the document indicates no App related issues or concerns.
You should precise when using the RFC 2119 keywords OLD: A Service Provider router, such as an access concentrator, or network core router, SHOULD support this mitigation strategy. NEW: A Service Provider router, such as an access concentrator, or network core router, SHOULD support the DAD desactivation per interface Same remark for "this solution" in This solution SHOULD be enabled by default, and MUST be a configurable option if the layer-2 technology provides means for detecting loopback messages on an interface circuit. Please expand it.
Thanks for your work on this draft. The SecDir reviewer had a few comments that you should respond on and in terms of security, the statement in section 5 on trust should be clarified. https://www.ietf.org/mail-archive/web/secdir/current/msg05436.html Section 5: Any other network that follows the same trust model MAY use the automated actions proposed in this section. The problem is that as nearly as I can tell, there is only one such action in the section, the one in the immediately preceding sentence.
Comment from Tim Chown's opsdir review: Hi, 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 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. I believe this draft is on the IESG telechat agenda for tomorrow. There have been a minor update from -13 to -14 in the last couple of days to clarify the RFCs that the draft updates, which now seems resolved between the advice from the two ADs in question. My view is that the document is Ready. Very minor nits: The last sentence of section 1 is a little clumsy, and perhaps unnecessary: "The Changes to RFC 4861 section includes an update to RFC 4861." The first paragraph in the Problem Statement could be broken into two or three. Tim
Why do people so like saying there are no new security considerations? Anyway, LI would seem to be a fine way to DoS a thing so surely that is new here?
- section 7: As in other cases, this might be better to refer to the generic UTA work rather than have it's own list of preferred ciphersuites. - I wondered why you'd not just moved all the way to make TLS mutual-auth mandatory to use for this.
thank you especially for Section 6.2 . Unreliable Transport :)
Thanks for the hard work on this protocol. I have some comments, based on a review by Suresh Krishnan, that I think should be addressed before final approval of the document. First, Section 5.1 should be clear that when used over a reliable transport, not only should the F flag be ignore but that the fragment fields (last four bytes) are not in the packet. Second, Section 6.2.3 should be clear that the header accompanies all fragments. As a result, the current formula for calculating the number of fragments is probably wrong. This too should be updated.
Thanks for your work on this draft, it was very well written which is much appreciated. I just have one item I'd like to discuss that should be very easy to resolve. This should be considered with Spencer's question on what happens when the fragments are larger or smaller than the path MTU. It's important to state this to prevent fragmentation overlap attacks (unless you can explain why we don't need to worry about that). In the second sentence on page 42, adding the ending clause may be helpful: The size of each of these N messages MUST be smaller than the path MTU to help prevent fragmentation overlap attacks.
Spencer asked what happens when TLS/DTLS is not used, so perhaps rewording of the intro to the security considerations section would help to clear up his point. TLS/DTLS is the MTI with flexibility left in to support some other undefined mechanism to secure the channel. Since no MTU is set, but recommended, the first few sentences are a bit confusing. The rest of the paragraph is clear in terms of MTI and recommendations when TLD/DTLS is used as well as alternates options supporting the listed desired security properties. Security Considerations BFCP uses TLS/DTLS to provide mutual authentication between clients and servers. TLS/DTLS also provides replay and integrity protection and confidentiality.
The IANA Considerations are a bit confusing, as they appear to ask IANA to do things that were already done long ago. I understand that you want to leave the main text of the IANA Considerations intact, for posterity, and you've put in some "Editorial note" things. Maybe the best way to do this is to (1) change "Editorial note" to "IANA note" or "Note to IANA" throughout, (2) change the first IANA note (in the base Section 15) to clearly state that all *changes* that IANA is being asked to make are spelled out in "IANA note" items in the appropriate places, and (3) make sure that item 2 is true. And you do need to respond to Pearl Liang's IANA review from 2 March, and answer her questions.
Thanks VERY much for leaving it so that a diff with 4582 was still useful for review. That helped a great deal. It's a little nothing, so ignore this if you like, but you consistently use "MUST" throughout the document, except for one "SHALL" in Section 8.3.3. If it were me, I'd be consistent and use "MUST" there as well, to avoid any question of why that one is different. Thanks for making the editorial changes to the ABNF; I do prefer "*(X)" to "*[X]". On the other hand, I actually prefer "*X" to both of those: there's no need to use parentheses around a single production name. So, for example, this: BENEFICIARY-INFORMATION = (BENEFICIARY-INFORMATION-HEADER) [USER-DISPLAY-NAME] [USER-URI] *(EXTENSION-ATTRIBUTE) Is the same as this: BENEFICIARY-INFORMATION = BENEFICIARY-INFORMATION-HEADER [USER-DISPLAY-NAME] [USER-URI] *EXTENSION-ATTRIBUTE No harm either way, so leave it as is if you really like it, but... why the parentheses, especially as long as you're changing them anyway?
For the moment, I'm balloting a process Discuss, because I'm not seeing a response to Gorry Fairhurst's TSV-DIR review sent on March 2, at https://www.ietf.org/mail-archive/web/ietf/current/msg92156.html. Did I miss it? During my review, I did not see a definition of "transaction failure window". I can guess what that means, but would love to know for sure. I'm understanding that in RFC 4582, the version number (1) was a version number, but in this draft, version 1 means "reliable transport" and version 2 means "unreliable transport". Is that right? If so, how does an RFC 4582 TCP-only floor control server receive a message with a version field set to 2, which would have been sent over UDP? I'm also wondering whether overloading the version number field as a transport reliability indicator would cause a problem in the future. If you end up with a mandatory extension that applies to both reliable and unreliable transport, does that mean you'd use two version numbers (possibly 2 for reliable and 3 for unreliable)? Within Gorry's review, these are the points I thought were Discuss-worthy. It's probably best for you to reply to these in his e-mail, rather than try to juggle two sets of overlapping comments. I'm just pointing out what I think matters most. On the others, please do the right thing. - Gorry asked in Section 5: What is the security model when TLS/DTLS is not used? - has the protocol protection from off-path attacks, and how is this provided? I'm especially interested in this question when unreliable transport is used without DTLS. This is probably related to the question about randomizing Conference ID later in Gorry's review. - Payload Length: - What happens when using a datagram format if the datagram length (e.g. UDP-Length) is less or more than the value specified within the BFCP? - Fragment Length: - What happens if the datagram length (e.g. UDP-Length) is less or more than the value specified within the BFCP?
(1) In Section 3.1, the "civic location" description here mentions the use of a location URI, but there's no corresponding Format for it. Is that what you actually mean to have for XML Encoding (1)? You're not going to fit much XML in 253 octets anyway. I would suggest having format 0 be the RFC 4776 format, and format 1 be a URI pointing to an XML document. (2) It would help interoperability if you could constrain the classes of location URI that are supported. For example, if the mechanism in RFC 6753 is sufficient for your purposes, you could require that geolocation values in format 1 use an HTTPS URI to be dereferenced using that mechanism. Likewise, unless there's a known, compelling need to support HTTP URIs, you should require HTTPS. The fact that you have 253 format codes remaining means that if there are future needs for other URI types, you can liberalize. (3) To ensure that the location information referenced by location URIs is protected, please comment on the assumed access control model for these URIs. Can anyone with the URI dereference it? Or are they required to be access-controlled? Section 4 of RFC 6753 should provide a helpful framework. (4) Alternatively to (2) and (3), you could just remove the option for a XML/URI-based location altogether. Is there a compelling use cases here for very precise location? Even with the 253-octet limit, the RFC 4776 format would allow you to specify down to roughly the neighborhood level in most cases. For example, encoding "Washington, DC 20001, US" takes only 26 octets. Even looking at some Japanese addresses, which are more verbose, the examples I'm finding are still on the order of 70-100 octets. (5) Did the WG consider constraining the set of civic address elements that can be used? It's not clear to me that the use cases for this document require very granular information, e.g., to the individual building, floor, or room. The RFC 4776 format makes it fairly easy to express these constraints, by saying something like "The civic addresses carried in the civic location sub option MUST NOT contain elements other than A1, ..., A6 and PC."
Thanks for a good discussion of confidentiality protections in the Security Considerations. It would be helpful if you could also note that another way to address the concerns here is to provision location information at the least granular level possible. Suggested: "The other way to protect the sensitive location information of network users is of course to not send it in the first places. Users of the civic location sub option should provision location values with the highest possible level of granularity, e.g., to the province or city level, rather than provisioning specific addresses. In addition to helping protect private information, reducing granularity will also reduce the size of the civic location sub option."
- OTR works for xmpp. I think (not sure) it could be made work for MSRP or SIMPLE, and presumably then it might work here. If that's true, be good to note that and explain a bit how to do that. (And I don't mean the long-promised OTR I-D, just a pointer at the inevitably bad best reference we can find.) - End of p12: "are suggested" is odd to see in an RFC, it might be better if you find some other wording.
Looks good, but a question: Shouldn't F6 in section 4 and F18 in section 5 result in sending an XMPP Chat State Notification of "active" or "inactive" to the XMPP client? If so, adding that, and a discussion in section 6, seems useful.
I support Stephen's comment on OTR, if it is possible to add mention of how to do this, that would be good to have some end-to-end reference for confidentiality. Thanks.
-- Section 1 -- In SIP-based systems that use MSRP, a chat session is formally negotiated just as any other session type is using SIP. Nit: you need an appositive comma before "using SIP". -- Section 6 -- Here the idle state indicates that the sender is not actively composing a message, and the active state indicates that the sender is indeed actively composing a message (the sending client simply toggles between the two states, changing to active if the user is actively composing a message and changing to idle if the user is no longer actively composing a message). This really sounds repetitious (because the repeating sounds repetitious when it repeats). I think you could end the parenthetical after "toggles between the two states", because you've really already said the rest. -- Section 11 -- The second paragraph looks like it's exactly the same as what's added in stox-im, and that's a normative reference already. Why not add a citation to the security considerations in stox-im, and delete the second paragraph, incorporating it by reference?
No objection to the publication of this document, but I do have a question for you to consider... Sections 4 and 6 talk about implementing timers to deal with the lack of a GONE message in XMPP. Any thoughts on having this document suggest possible values for such timers? Not sure if that makes sense for protocols much closer to real users, but thought I would ask.
I'm disappointed but unsurprised that this does not address the question of end-to-end encryption especially as it addressed signaling through protocol translating middleboxes, it seems like if it works there it can work anywhere.
- I'm surprised it's so easy to be honest;-) - The reference to rfc 3923 isn't that useful is it? I mean because nobody really does that afaik. If someone does do it (I could imagine an enterprise scale thing working), then maybe better to say that while it'd work, it's really uncommon, or some such.
Thanks for your work on this series!
-- Section 4 -- stanza, including required and optional elements and attributes, is defined in [RFC6121] (for single instant messages, the value of the 'to' address SHOULD be a "bare JID" of the form "localpart@domainpart", as per [RFC6121]). I gather that this is adding a new SHOULD that isn't in 6121; you should probably make that clear, because this looks to me as a restatement of something from 6121. -- Section 8 -- Other sections talk about how you MUST map this into that. This section say, basically, "Both XMPP and SIP support language tagging," but does not say anything about whether you MAY, SHOULD, or MUST map the language tagging from one into the other. Is that intentional? My sense (and I just asked Joe, who agrees) is that this ought to say that you SHOULD map between SIP and XMPP language tagging.
I'm glad to see these specifications moving forward. Thanks for that. I have a couple of you-need-smarter-ADs questions. As prologue, please remember I have a decent understanding of SIP, an indecent understanding of SIMPLE, and mostly, I just stare uncomprehendingly when I see raw XMPP. It did not jump out at me when reading this specification, whether there is any assurance to a sender on one side of the gateway that a message was delivered successfully to a receiver on the other side of the gateway. If there's not, that might be worth pointing out a bit earlier than a Note: halfway through page 5. Is there a possible mismatch between what a sender thinks is happening, TLS-wise, on one side of the gateway, and what a receiver actually receives, TLS-wise, on the other side? I'm not smart enough to ask the right question, but if an XMPP sender knows she's sending over TLS, but the XMPP-to-SIP gateway maps that into a non-TLS SIP transaction on the other side, is the kind of scenario I'm thinking of. If so, perhaps it's worth pointing that out someplace (the Security Considerations section would be fine).
- Figure 1 is way complicated. I guess it might just need to be but it's fairly unreadable. If you think it worth looking at again, then maybe dropping the outer boundary "lines" might make it clearer. - 5.4: is the use of ellipsis for the SIP version of xmpp's "from" in table 3 sufficiently clear? Are there any quote characters or other stuff that might be gotten wrong? I wonder if the tables are a little too terse.
Two question about this text out of the ACK section: "Some text in this document was borrowed from [RFC7247] and from [XEP-0045]." This draft has the standard IETF copyright template upfront and 'borrows' text from [XEP-0045]. I assume borrows actually mean copying text, isn't it? Do the authors and the responsible AD see any conflicts between the copyright of [XEP-0045] and the copyright of this document? Are the borrowed text parts out of [XEP-0045] marked somehow? I could find the parts.
4: There's a noun missing here: By contrast, in MSRP sessions (including groupchat sessions) are considered to be a type of media (similar to audio/video sessions) The bullet list refers to "muc.example.com", but Figure 1 shows "rooms.example.com". The particular endpoints for both romeo and juliet are not shown in the figure, but the bullet list doesn't say, "not shown in diagram".
-- Section 5.5.2 -- The XMPP message type ought to be "chat" (and is not allowed to be "groupchat"). I think this is fine, but because of your careful and measured use of 2119 throughout the document set, I wonder how this is meant to be different from 'and MUST NOT be "groupchat"'? -- Section 5.8 -- I suggest: OLD | <status>Time to go!</status> NEW | <status>O, look! methinks I see my cousin's ghost</status> END -- Section 10 -- My comment in stox-chat applies here, as well, though I note that in this case you do not already have a reference to stox-im to work with.
Some minor editorial bits and pieces we can pickup after the telechat. (Thanks to Dave Black and Alvaro Retana for the reviews). --- Something can be added to the Introduction (which is a bit short) to explain what a covering prefix is. Probably breaking the second paragraph after the first sentence and adding a new sentence that begins "A covering prefix is..." --- The fields in Figures 1 are briefly described after the figure, but in some cases the description is exceeding brief. For example, minlen. Can you look at the text and see where you can beef it up either with a forward reference to where the field is described, or with a simple statement about what the field is used for. --- Final paragraph of Section 3 OLD> When the ROUTE-REFRESH message includes one or more CP-ORF entries, the BGP speaker MUST re-advertise routes that have been affected by ORF entries carried by the message. While the speaker MAY also re- advertise the routes that have not been affected by the ORF entries carried in the message, this memo RECOMMENDS not to re-advertise the routes that have not been affected. <OLD NEW> When the ROUTE-REFRESH message includes one or more CP-ORF entries, the BGP speaker MUST re-advertise routes that have been affected by CP-ORF entries carried by the message. While the speaker MAY also re- advertise the routes that have not been affected by the CP-ORF entries carried in the message, it is RECOMMENDED not to re-advertise the routes that have not been affected. <NEW --- Section 8 has a paragraph that begins "Section 5…” I think this applies specifically to the first bullet in the list (of two) immediately above. If I'm right, can you move the paragraph into that bullet? --- Can you move RFC 4364 to be an Informative reference.
The Gen-ART review pointed out that the draft was difficult to read. For what it is worth, I found the draft relatively hard to read and I knew much of the terminology already. But I was able to understand what the draft specified. But I think it would be useful make some additional edits along the lines of Adrian’s suggestions or perhaps beyond. One thing that I often find useful is to explain the semantics of a concept or field as early as possible. There were a few cases in this document where you talked about something for a while but it was only clear later what its meaning was. Example: there’s a lot of rules about the minlen field early in the draft, but it is only on page six that the spec actually says what it does. Explaining what it is for would have made understanding easier. In any case, these are just comments from my perspective. This is a No-Obj position.
I found myself wishing that the Abstract and/or Introduction included a sentence describing what a "covering prefix" was. "ORF" is nicely explained in the Introduction, but all I get on "covering prefix" is that they're applicable in Virtual Hub-and-Spoke VPNs and BGP/MPLS Ethernet VPN networks. I actually know most of the terms defined in the Terminology section, but "covering prefix" isn't explained there, either. The first clue I could find (searching for "cover") is on page 8, in this sentence. However, because Loc-RIB also contains a more specific covering route (3:192.0.2.0/89), 2:192.0.2.0/88 does not match. I can guess what a covering prefix is using context clues, but I'm guessing.
I agree with Adrian's suggestions for this document. Additionally, I would like to see the acronym RT expanded on first use. While making any other edits, please s/Contstrain/Constrain.
I suggest s/MUST be/is throughout sections 8 & 9.
The introduction needs to change per discussion resulting from the Gen-ART review Re: the 3 or 5 RFCs being updated. I assume the sponsoring AD will ensure that change happens.
No objection to the publication of this document, but I want to point out one thing... The Updates meta data identifies three RFCs being updated, but the Introduction lists 5 RFCs being updated.
It's not at all clear to me why this document is going for Standards Track or why it updates 4379 and 6424, nor does the ballot nor shepherd writeup explain. It's creating a registry, which doesn't change the protocol in either of those documents. Seems to me fine that it be Informational, and that it doesn't update anything. 2.2, 2.3, 2.4: OLD The registration policies [RFC5226] for this registry are: 0-250 Standards Action 251-254 Experimental 255 Standards Action NEW The registration policies [RFC5226] for this registry is Standards Action. The registration policy for the entire registry is "Standards Action". Within the registry itself, the values 251-254 should be marked Experimental (which they are) and 255 should be marked Reserved (which it is), but that doesn't change the registration policy.
Pete's comments make perfect sense to me, too. That said, I think Section 2.2 is not wrong and not confusing the way it is, so it's not a big deal either way (if I had to be picky, I'd say that with respect to the specification of the registration policy at the top of the section, 5226 uses "Experimental Use", not "Experimental" ("Experimental" is for labelling the code points, as later in the section); but I would never be so picky).
Pete's comments make perfect sense to me.
This could have been a Discuss, but I don't think it needs to be ... I struggle with this text in Section 5. Remedies: At the other end of the spectrum the Ombudsteam could decide that the Respondent is no longer permitted to participate in a particular IETF activity, for example, ejecting them from a meeting or requiring that the Respondent can no longer attend future meetings. (The Ombudsteam can recommend, but can not impose, that a Respondent who is in a IETF management position be removed from that position. There are existing mechanisms within IETF process for the removal of people from IETF management positions that may be used as necessary.) I don't understand how a recommendation for removal works in practice. My understanding is that we're not adding a way to remove I-star folk from their positions, and what's available is the recall procedure in https://tools.ietf.org/html/rfc7437#section-7. So, who would the Ombudsteam make a recommendation to, in order to remove a Respondent? <speculation> I suspect that the most the Ombudsteam could do, is to point out the existence of the recall procedure to the Reporter and/or Subject, and trust that the right thing happens. My thought is that if privacy matters, having the Ombudsteam even initiate a recall petition tells the community quite a bit about what's happened ("the Ombudsteam is petitioning to recall Spencer, what did he do now?!?"). If a recall seems appropriate to the Reporter and/or Subject, they can tell as much or as little of their story as necessary, and they can decide what's necessary. </speculation>
- This defines harassment by reference to the IESG statement, which does have a good enough definition, and that is quoted. However, it's unclear unclear which text wins if the IESG modify the definition in the IESG statement in some odd way. While that's very unlikely, I like the idea of modifying the IESG statement to say that the BCP wins. - intro: "often more interpersonal" is odd, I think you just mean "often more personal" actually - intro: I think the sentence that "These procedures are intended to be used when other IETF policies and procedures do not apply or have been ineffective." should be in its own paragraph. It's a standalone point and important and easy to miss at the end of a paragraph. A separate para there might cause a reporter to first try a less nuclear option, which I think is preferable in cases where it's correct. - section 2: "interpersonal" again - I still think you mean "personal" - section 2: "is more easily handled by" is a pretty confident prediction which is not what I think you meant. I think what you're trying to say is something like "the more the problem matches the definition of harassment, then the more you should consider using this process instead of other mechanisms" - 3.5: Probably too late to do it now, but it might have been nice if, before IETF LC, we'd thought to add "Given the sensitivity of, and training required for, this role and the ideal being a lack of activity, it is likely the IETF chair may choose to re-appoint a successful and still-willing ombudsperson for a number of two-year terms." If folks think that would be ok to add now, then I think it might be useful to set an expectation that 2 or 4 years is not the norm for this one since I think if we do find good ombudspersonages we probably want to keep 'em and aim for minimal turnover. - section 4: https://www.ietf.org/ombudsteam is still a 404, email@example.com also bounces ("user unknown") Please fix soon and definitely before the RFC issues. Immediately after IESG approval is probably a good point in time to put things in place, even if there aren't yet selected ombudsfolks - 4.1: holy crap batman, we're recalling the entire IESG? The language there seems a bit overblown;-) - 11.2: use https URIs please, and  and  are the same; is 11.2 normative or informative? (see my earlier point)
Additional round of discussion needed with the legal review team.
One minor point, and some editorial nits: There are a couple of instances of "... Reporter if there is no individual Subject". Isn't it also possible that there is a specific Subject, but Reporter != Subject? Or in this latter case, does the Reporter's involvement stop after the reporting, with the Subject being responsible afterward? It might be helpful to clarify. Nits: Section 3.3: Are the quotes around "as needed" needed? Section 3.6: Isn't "compensation" more common usage than "recompense"? Section 4. Reference  seems kind of silly. I hope this isn't an indication of the wonders that increased use of XML is expected to bring.
Thanks for this document. The IESG statement must be updated with a link to the new BCP. Whether this is done with "This IESG Statement is superseded by BCP xx" or "The IETF's procedures for handling cases of harassment are documented in BCP xx" is less important to me ... even if I have a small preference for the superseded version, as the BCP integrates the IESG statement definition.
Thanks for your work on this draft. I have no new points to add, but like Barry will wait on the legal review. I didn't see anything that would prevent someone from multiple 2-year terms, so I think that text is ok if they are up for it as this is very difficult work.
Pending Jari's legal review...
I'm a Yes because this draft is helpful to the largely uninitiated (that would include me), but I was consistently encountering questions that Adrian's Discuss and Comments answered, so I'd encourage you to work through his Comments, as well as his Discuss. Beyond that: In this text: 3.3.1. LISP Encapsulation ITRs encapsulate data packets towards ETRs. LISP data packets are encapsulated using UDP (port 4341), the source port is usually selected by the ITR using a 5-tuple hash of the inner header (so to be consistent in case of multi-path solutions such as ECMP [RFC2992]) and ignored on reception. would you ever use "virtual xTRs" with the same outermost IP addresses? If not, fine, but if so, would you need to use different destination ports to disambiguate them? Or does the Instance ID provide enough isolation to meet this need? I ask because adding virtual hosts to HTTP was a drag, so best for me to ask early! Further in the same paragraph, in this text: A particularity of LISP is that UDP packets should include a zero checksum [RFC6935] [RFC6936] that it is not verified in reception, LISP also supports non-zero checksums that may be verified. This decision was made because the typical transport protocols used by the applications already include a checksum, by neglecting the additional UDP encapsulation checksum xTRs can forward packets more efficiently. I'm wobbling between "should include a zero checksum" and "also supports non-zero checksums". Is that text saying something like this? LISP data packets are often encapsulated in UDP packets that include a zero checksum [RFC6935] [RFC6936] that is not verified when it is received, because LISP data packets typically include an inner transport protocol header with a non-zero checksum. By omitting the additional outer UDP encapsulation checksum, xTRs can forward packets more efficiently. If LISP data packets are encapsulated in UDP packets with non-zero checksums, the outer UDP checksums are verified when the UDP packets are received, as part of normal UDP processing.
Thank you for this document. It is really helpful to have a clear introduction to LISP, and I appreciate the hard work that has gone into producing this text. I have a small Discuss that is easily fixed. The essence is that you should limit this document to a description of LISP and not try to use it to bash other solutions. In Section 4.2 On the contrary BGP is a push architecture, where the required network state is pushed by means of BGP UPDATE messages to BGP speakers. You will be aware of RFC 5291 and the use of ORF to make BGP a pull-mode protocol. (I won't say to you that LISP is push mode because a Map-Reply pushes the mapping information from the map server to the client :-) So, my advice is to describe LISP in this document and to not make comments about other systems. It isn't a beauty contest and it isn't wise to try to say "my system is better/different from yours". The solution is to just remove this sentence. Similarly in 7.1 BGP is the standard protocol to implement inter-domain routing. With BGP, routing information are propagated along the network and each autonomous system can implement its own routing policy that will influence the way routing information are propagated. The direct consequence is that an autonomous system cannot precisely control the way the traffic will enter the network. As opposed to BGP, a LISP site can strictly impose via which ETRs the traffic must enter the the LISP site network even though the path followed to reach the ETR is not under the control of the LISP site. Let's not get into the "BGP this, BGP that" debate. Just remove the first paragraph and the first four words of the second paragraph. That way you avoid all contention and write a document about LISP.
I have a few questions and editorial nits I hope you will pick up as additional polish. Some of the nits come from Deborah's review as AD in-training --- Section 1 I'm really not comfortable with your text... "Indeed and as pointed out by the unpublished Internet Draft by Noel Chiappa [Chiappa]" This isn't a stable reference and I don't think you need it. You could either rely on the later reference to RFC 4984, reference RFC 6830 itself, or take out the aside "and as... ... [Chiappa]" --- Section 1 has LISP creates two separate namespaces, EIDs (End-host IDentifiers) and RLOCs (Routing LOCators), both are typically syntactically identical to the current IPv4 and IPv6 addresses. The "typically" here opens a bit of door. RFC 6830 explains this in the definitions of EID, but seems to be clear that an RLOC is an IP address. If you are opening up the RLOC to be something other than an IP address (a MAC address or even something else?) then how do you deal with: - lack of ICMP - non-uniqueness Possibly you can say that this is "not my problem" since the problem would already exist in the routing system that handles the non-IP addresses. But maybe, for an introduction to the topic this is over- reaching towards the many potential applications rather than the basic explanation of the architecture? But in your own definitions in Section 2, you have Endpoint IDentifier (EID): EIDs are IPv4 or IPv6 addresses used to uniquely identify nodes irrespective of their topological location and are typically routed intra-domain. Routing LOcator (RLOC): RLOCs are IPv4 or IPv6 addresses assigned topologically to network attachment points and typically routed inter-domain. Neither of which offers any possiblitity to vary "always" into "typically". The again, 3.2 has... EIDs are typically -but not limited to- IPv4 or IPv6 addresses ...and... With LISP, the core uses RLOCs, an RLOC is typically -but not limited to- an IPv4 or IPv6 address Some concistency is needed! In 3.4.1 you finally get there... Typical mappings in LISP bind EIDs in the form of IP prefixes with a set of RLOCs, also in the form of IPs. IPv4 and IPv6 addresses are encoded using the appropriate Address Family Identifier (AFI) [RFC3232]. However LISP can also support more general address encoding by means of the ongoing effort around the LISP Canonical Address Format (LCAF) [I-D.ietf-lisp-lcaf]. Why don't you talk about everything in terms of IP adresses and then add a section somewhere near the end to talk about LCAF? --- Section 1 introduces "overlay" and "underlay". I think that a certain class of network engineer understands these concepts really well. And, in my experience, another class has no idea what you are talking about! This would probably show very easily on a simple diagram showing the overlay and underlay networks. But perhaps the summary in the Introduction is launching in a bit deep nd fast? This is probably the hardest part of the document to write: how do you summarise what you haven't yet talked about? There are some bits, however, that really need work. For example... o EIDs have meaning only in the overlay network unless they are leaked into the underlay network. The overlay is the encapsulation relationship between LISP-capable routers. Furthermore EIDs are not assigned from the reserved address blocks. So they have meaning only in one place, unless they have meaning in more than one place? :-) And what is a "resrved address block"? --- Section 3.2 With LISP, LISP sites (edge) and the core of the Internet are interconnected by means of LISP-capable routers (e.g., border routers) using tunnels. I don't think this is right. It is true that LISP sites and the core of the Internet are interconnected by means of LISP-capable routers But the tunnels connect those border routers. So you probably need... LISP sites (at the edge of the Internet) are connected to the core of the Internet by means of LISP-capable routers (e.g., border routers). LISP sites are connected across the core of the Internet using tunnels between the LISP-capable routers. --- Section 3.2 OLD A typically distributed database, called the Mapping System, stores mappings between EIDs and RLOCs. NEW A database which is typically distributed, called the Mapping System, stores mappings between EIDs and RLOCs. --- 3.2 Such LISP capable routers, in most cases, only require a software upgrade. That's a little disconcerting. Can you add to "in most cases"? --- 4.1 Time-To-Live (TTL): Each mapping contains a TTL set by the ETR, upon expiration of the TTL the ITR has to refresh the mapping by sending a new Map-Request. Typical values for TTL defined by LISP are 24 hours. Presumably it doesn't *have to*. It can choose to delete it and not refresh it. Maybe this should be worded as MUST NOT use after the expiration of the TTL. --- Section 5 says The separation between locators and identifiers in LISP was initially proposed for traffic engineering purpose where LISP sites can change their attachment points to the Internet (i.e., RLOCs) without impacting endpoints or the Internet core. RFC 6830 says Creation of LISP was initially motivated by discussions during the IAB-sponsored Routing and Addressing Workshop held in Amsterdam in October 2006 (see [RFC4984]). RFC 4984 says The primary goal of the workshop was to develop a shared understanding of the problems that the large backbone operators are facing regarding the scalability of today's Internet routing system. I conclude that Section 5 here is somewhat wrong. --- Section 7.1 "the possibility for a site to issue a different mapping for each remote site, implementing so precise routing policies." Suggest "the possibility for a site to support a different mapping policy for each remote site." --- I think some examination of the classification of normative and informative references would be useful. For example, RFC 6836 is used only in 126.96.36.199 and is Normative. I think that is fine because it is where to go for a definition of LISP+ALT. But 188.8.131.52 defines LISP-DDT by means of a reference to [I-D.ietf-lisp-ddt] which turns out to be Informative. --- Appendix A "The LISP system.." Haven't seen a "LISP system" defined. Suggest "The LISP architecture.." --- Appendix A "A small group of like-minded personnel from various scattered locations within Cisco, spontaneously formed immediately after that workshop, to work on an idea that came out of informal discussions at the workshop and on various mailing lists." Suggest deleting this sentence (unless you want this to look like a Cisco-only initiative).
I would also find this document much improved if the authors could address Adrian's comments, as well as those in Radia's SECDIR review.
It appears the SecDir review didn't make it to LISP list for some reason. There is one important security request from Radia's review and many other good suggestions. https://www.ietf.org/mail-archive/web/secdir/current/msg05415.html Expanding the Security Considerations section would be helpful, here is the background on the request: There is a security considerations section, which focuses on a class of denial of service attacks. There are presumably security considerations sections in the other documents, including one that focuses entirely on security, so it is not necessary that all security issues be brought up here. That said, I think that if you were to write an "introduction to security considerations", there are more important ones than the DoS threat. in particular, as a routing protocol care must be taken to make sure a bad actor cannot attract someone else's traffic with mechanisms like those we are trying to address with BGP security. Much of the routing information is maintained in a database "like DNS". If it *were* DNS, DNSSEC could be used to address the integrity issues. If it is home grown, some equivalent mechanism will be necessary. Why not use DNS?
Please do look at the other suggestions from the review as they should help clarify a few points in the draft and provide the background needed for an introduction draft. https://www.ietf.org/mail-archive/web/secdir/current/msg05415.html
I support Adrian's discuss. In a similar vein: In Sec 3.2: Please either remove the claim of "Such LISP capable routers, in most cases, only require a software upgrade." or explain how you can justify the need to add and remove new encapsulations and handle the various flag triggers and caching at line rate. There is no need for such marketing in this document.
1) Sec 1, second paragraph: "LISP creates two separate namespaces, EIDs (End-host IDentifiers) and RLOCs (Routing LOCators), both are typically syntactically identical to the current IPv4 and IPv6 addresses." What does "typically" mean? As far as I'm aware, they are syntactically identical. This is reiterated in Sec 3.2; are you just trying to preserve the point of architectural freedom? I've found the third instance of insisting that the EID or RLOC now is only "typically" an IPv4 or IPv6 address. Please lose "typically". Minorly, the , before both should be a ;. 2) top paragraph of p.4: "The initial motivation in the LISP effort is to be found in the routing scalability problem [RFC4984], where, if LISP is completely deployed, the Internet core is populated with RLOCs while Traffic Engineering mechanisms are pushed to the Mapping System." Instead of "LISP is completely deployed" to "LISP were to be completely deployed" - making it subjunctive. 3) Last paragraph in Sec 1: "This document describes the LISP architecture, its main operational mechanisms as its design rationale." I think you mean "This document describes the LISP architecture and its main operational mechanisms as well as its design rationale." 4) In Sec 3.1, second paragraph: "Locator/Identifier split: By decoupling the overloaded semantics of the current IP addresses the Internet core can be assigned identity meaningful addresses and hence, can use aggregation to scale." I assume that you mean "topologically meaningful addresses" instead of "identity meaningful addresses".
I don't object to the publication of this document, but I have a swathe of Comments that I think you should address before the draft is published as an RFC. Some of these comments arise from Deborah Brungard's review as "AD in training". In general, I found this document a very heavy way of saying "we need an adaptation function, and we need a control plane that can determine and enforce end-to-end paths subject to timeslot assignment." I don't suppose there is anything to be done about that now, but you used a lot of words! --- There are a number of abbreviations that the RFC Editor will ask you to expand on first use both in the Abstract and in the main body of text. If you have te document open for other edits, you should take a pass at this to make sure the right expansions are used. --- Section 1, para 3 Not sure whether "ultra-lower power" is a typo or an undefined term. --- Section 1 Bringing industrial-like performance into the LLN stack... I'm not sure what "industrial-like performance" is supposed to mean. Two paragraphs earlier you described the industrial environment, but not anything that matches the term "industrial-like performance". Could you usefully reword as "Enabling the LLN protocol stack to operate in industrial environments..." --- Section 1 What is missing is a Logical Link Control (LLC) layer between the IP abstraction of a link and the TSCH MAC, which is in charge of scheduling a timeslot for a given packet coming down the stack from the upper layer. I found this odd. Do you mean to say... What is missing is a link layer control protocol that is in charge of scheduling a timeslot for a given IP packet that will be encapsulated in the TSCH MAC. But in Section 4 I see you have come back to the term "LLC". I'm not comfortable with this use of the term. It doesn't fit (as far as I can see) with the conventional (i.e., OSI) usage of the term. You might look to GMPLS for the way that this terminology issue was handled for adaptation into layer 2 or 1 technologies, and the way that those technologies are controlled by signaling or management protocols. --- It would seem that Section 2 is redundant and can be removed. --- Section 3 Low-power WPANs are characterized by small packet sizes Is this the characterisation that you want to call to our attention or is it the small maximum frame size? --- The last paragraph of Section 3 seems to be out of place. It is certainly worth noting any implementation information, but, as recommended by RFC 6982 this information is better placed either in an implementation report (a separate document) or in a wiki. There are good political reasons for doing this, and also good practical reasons as the RFC will be an ossified record - you don't want endless updates to the RFC just because someone else has written some more code! --- Section 4 As highlighted in Appendix A, TSCH differs from traditional low-power MAC protocols because of its scheduled nature. Is there a long tradition? Did your father's father code low-power MAC protocols, perhaps whittling them by hand from a single piece of hornbeam? :-) Maybe s/traditional/other/ --- Section 4.1 1. Define the Information Elements included in the Enhanced Beacons advertising the presence of the network. Am I supposed to know what an "Enhanced Beacon" is? Should there be an explanation of a reference? --- Section 4.1 4. Define a mechanism to secure the joining process and the subsequent optional process of scheduling more communication cells. This is the first mention of a cell. It would hav helped to either explain it or give a reference. Ah! There is the definition in 4.5. Is something out of order, or would a forward pointer be enough? Turns out a "cell" was not what I thought it was. --- Section 4.5 mentions PCE. That is OK, but you will need to expand the abbreviation, and you should give a reference. Similarly, while 4.8 does expand "PCE" a reference would help. --- Section 4.6 has The LLC needs to: 1. Define a queuing policy for incoming and outgoing packets. It is not clear (to me) whether this needs to be a network-wide policy, a per-node policy that can be standardised and/or communicated, or is a per-node policy that can be configured or hard-wired at implementation. Maybe "the LLC has to allow for the implementation and configuration of a policy..." --- Section 4.7 1. Ensure timely delivery of such data. "Timely" might be subjective. What do you really mean? --- Section 4.8 An example of decentralized algorithm is provided in [tinka10decentralized]. This mechanism can be used to establish multi-hop paths in a fashion similar to RSVP. I'm afraid I didn't hunt down the referenced paper. I wonder whether you mean RSVP or RSVP-TE. Probably you *do* mean RSVP in that the decentralised approach allows the reservations to form along the routes the packets happen to follow. Perhaps including a reference (probably RFC 2205 if you do man RSVP) and some explanation of what you mean by "decentralised" would help. I can see "decentralised" as meaning classic RSVP or just a signaling plane like RSVP-TE allowing the hops to select cells. --- Section 4.8 1. Provide a mechanism for two 6TiSCH devices to negotiate the allocation and deallocation of cells between them. This is the first mention of 6TiSCH in a 6TiSCH document! Don't you think it would be good to define the term? --- Section 4.9 3. Define a mechanism to allow for the secure transfer of signaling data between nodes and the LLC. This reads as though the LLC is now being treated as the centralised control entity not a "layer" as previously defined. Certainly, the transfer of data between a node and a "layer" is probably achieved within the node so security is not an issue. Fix this with s/and/within/ ? --- I'm not convinced by your choice to put all but one reference as non- normative. [I-D.ietf-6tisch-terminology] seems to be required reading to understand the terms used in this document. [IEEE802154e] might reasonably be assumed to be fundamental to understanding what TSCH is. Equally, some of the references seemed a little gratuitous. For example: To map the services required by the IP layer to the services provided by the link layer, an adaptation layer is used [palattella12standardized]. I'm sure there are other issues with references, but I lacked the energy to go through them. Could you please work this issue with your AD. --- It would have been good to have included proper forward references to the two Appendixes from early in the document. --- Why is Appendix B titled "TSCH Gotchas" when many of the features described are positive attributes of TSCH?
The reference to 2119 appears to be unnecessary.
The following commments about the content of the document may be useful to the authors and the ISE. === Section 2.1 The header of a Babel packet contains an eight-bit protocol version. The currently deployed version of Babel is version 2; To be consistent with the statement at the end of Section 1, I think you need "The original protocol is version 2." Versions 0 and 1 were experimental versions of the Babel protocol This is true, but gives the impression that version 2 is not experimental. Maybe "Versions 0 and 1 were also experimental..." --- Sections 2.2 and 2.3 could use forward references to Section 5 --- Section 2.4 Bits with values 80 and 40 hexadecimal are defined by the original protocol, and MUST be recognised and used by every implementation. It is clear what you mean, but a bit will not have value x80 or x40. Maybe you can find a way to reword. Due to the small size of the Flags field, extensions to the Babel protocol SHOULD NOT use the six unused bits of the Flags field, and no registry of flag assignments is currently being defined. This is a little odd, IMHO. Of course, you are within your rights to make this rule, but you seem to be saying that, because there are so few bits available you might run out, and in order to make sure you don't run out you won't ever use any of the spare bits. On the other hand "SHOULD NOT" allows that they *are* allowed to be used. The absence of a registry then allows for conflicts. So perhaps you are trying for ...other bits are reserved for use in future versions of the Babel protocol and MUST NOT be used in extensions to version 2 of the Babel protocol. But Section 4 has... Using a new bit in the Flags field is equivalent to defining a new sub-TLV while using less space in the Babel packet. Due to the high risk of collision in the limited Flags space, and the doubtful space savings, we do not recommend the use of the Flags field. You are now giving a different reason (and a different strength of advice) for not allocating new bits: there would be no risk of collision if you had a registry. --- Section 3 Length The length of the body, exclusive of the Type and Length fields. In what units? Ditto 3.1.2 --- 3.1. Standard sub-TLVs Given this is an Experimental RFC on the Independent Stream, I think this choice of title is poor. I'd suggest... 3.1. Pad sub-TLVs Or... 3.1. Sub-TLVs Specified in this Document --- I presume that ISE RFCs still need to conform to the rules that you split your references into Normative and Informative.