IESG Narrative Minutes
Narrative Minutes of the IESG Teleconference on 2014-04-10. 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
1215 EDT break
1221 EDT back
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
1301 EDT Adjourned
(at 2014-04-10 07:30:25 PDT)
Sorry to raise a Discuss on what is primarily an editorial issue, but it would impact interop, I think. At least it will be simple to address. The figure in 3.1 has block length = 5 And the text in 3.2 has block length: 16 bits The length of this report block in 32-bit words, minus one. For the Loss Concealment Block, the block length is equal to 5. RFC 3611 has block length: 16 bits The length of this report block, including the header, in 32- bit words minus one. Looks like the figure has 7 32-bit words, so block length should be 6.
- section 2.2 confused me a bit, you said these new values are in seconds, but then present the binary fraction encoding. Is that latter really needed for this one? (Just checking, I assume it is used in some field.)
Just editorial stuff: In 3.2 and 4.2, you say things like: If the measured value exceeds 0xFFFFFFFD, the value 0xFFFFFFFE MUST be reported to indicate an over-range measurement. If the measurement is unavailable, the value 0xFFFFFFFF MUST be reported. You should instead use the style that appears in draft-ietf-xrblock-rtcp-xr-qoe: Two values are reserved: A value of 0xFFFE indicates out of range and a value of 0xFFFF indicates that the measurement is unavailable. If you wanted to clarify even more, you could say: Two values are reserved: A value of 0xFFFFFFFE indicates out of range (that is, a measured value exceeding 0xFFFFFFFD) and a value of 0xFFFFFFFF indicates that the measurement is unavailable. The MUSTs are unnecessary. These are definitions, not protocol requirements. 4.2: I would strike the words "For clarification". While reading this, it declarified things for me for a moment. :-) 5.1: No need to redefine DIGIT. Just put a reference to RFC 5234 in section 2.
Adrian's right, and the block in Section 4 gets it correct -- only Section 3 is wrong (in two places).
I support Adrian's DISCUSS point. I followed the chain of related RFCs back to 3550 as far as the definition of an RTP Extension Header goes. Section 5.3.1 of 3550 says the following: The header extension contains a 16-bit length field that counts the number of 32-bit words in the extension, excluding the four-octet extension header (therefore zero is a valid length). So, 6 appears to be the correct length for the report structure in 3.1.
The first para of the Introduction says This document defines DHCPv4 [RFC2131] and DHCPv6 [RFC3315] options that can be used to provision PCP server [RFC6887] IP addresses. Of course, you mean that the addresses are stable and are provided as information to the clients. You don't mean that the addresses are provisioned into the server. The Abstract has this a bit better, and I suggest you say something like... This document defines DHCPv4 [RFC2131] and DHCPv6 [RFC3315] options that can be used to inform PCP clients of PCP server [RFC6887] IP addresses.
I agree with Pete's DISCUSS. Either the servers are functionally equivalent, in which case you don't need to distinguish between their addresses, or they're not, in which case you need to provide the client some way to tell which to use. The document currently distinguishes between servers without telling the client how to pick one.
(1) Which RFC 6887 threat models apply when this is used? Don't you need to say and might that not affect where this can be deployed securely? (2) How can PCP authentication (based on the WG draft, draft-ietf-pcp-authentication I assume?) make sense with this use of DHCP? I guess that that can make sense but I'm not getting it right now sorry. Can you explain? (Note: its quite possible no change is needed, just to explain the plan to a semi-ignorant AD:-) (3) How does a client know that the security identity of one, some of all of the PCP server addresses returned are the same or not? (You might cover this as part of discuss point 2 above, not sure.)
- I agree with Brian's discuss point #2 about the normative reference. - section 1: I didn't get the meaning of the last sentence here. - section 3: The multiple lists thing seems over complex to me but I guess the WG discussed that and the DHC folks are presumably ok with it too. - 3.2: Extracting an IPv4 address from an IPv4-mapped (doesn't that need a ref?) IPv6 address seems quite hacky. Might be good to a) say more about how to do that in general and b) say why you need to do it.
I've got issues with section 5 in general. On a particular point to explain: However, DHCP servers MUST NOT treat IP addresses returned from a single Fully Qualified Domain Name (FQDN) lookup as belonging to more than one PCP server. That seems like completely bogus to me. It is *perfectly* reasonable for me to make a DNS record containing all of the A or AAAA records for all of my PCP servers, and then write my DHCP server to divide them up on the basis of subnet mask, where it will consider all addresses part of the same subnet as a single server, and each set of addresses from different subnets as different servers. You are making a protocol requirement that I set up my DNS configuration and DHCP configuration in a particular way, and that's not appropriate. If this were a non-normative section, describing possible configuration choices, e.g., "A site could make different FQDNs for each PCP server, have the DHCP server configured with FQDNs, and treat the A or AAAA results from each FQDN as a separate server", I'd have no complaint. But this entire section presumes a bunch of undocumented out-of-band information (like, "The configuration for PCP servers in a DHCP server is done by FQDNs"), and then sticks requirements language next to the result of those presumptions.
At the end of 3.1, add: To return more than one PCP server to the DHCPv6 client (as opposed to more than one address for a single PCP server), the DHCPv6 server returns multiple instances of OPTION_V6_PCP_SERVER. The document seems to be defining a semantic difference between "one PCP server with multiple addresses" and "multiple PCP servers". I guess that's OK, but you never give an explanation of why a client would care about that distinction. What's the use case?
I support Stephen's position
I have no objection to the publication of this document, but I have two points I would like to discuss. 1. Sections 3 & 4 do not have any guidance on error checking that should be done on the provided addresses. RFC 6887 does not explicitly state it, but it infers that the PCP server address is not a multicast address. If that is true, this document should provide that error checking guidance. 2. Sections 6 & 7 don't seem to fit with the goal of this document (defining the DHCP option formats). Those sections simply point to pcp-server-selection, which would need to be read anyways when building a PCP client. Can you point me to the discussion where those sections were deemed necessary for this document? And if these sections remain, it would appear that pcp-server-selection would need to be a normative reference.
Good document, looking forward to the resolution of Stephen's questions and Brian's question about the normative reference.
ipv6 mapped ipv4 addresses are a serious liability and I would vastly prefer to see those dropped as the mechanism for employing them is elided anyway. that said iwill not block publication on that basis.
This DISCUSS is just because I am not clear on what is being done, so to address the DISCUSS all that's necessary is to answer the question and possibly engage in further discussion. It may be that there's an issue here, in which case that would need to be corrected, but that's not clear to me at the moment. In 3.4: The Request Router returns a DNS CNAME response by "stacking" the distinguished identifier for Operator B onto the original CDN- Domain (e.g., b.cdn.csp.example), plus an NS record that maps b.cdn.csp.example to B's Request Router. 2. The end-user does a DNS lookup using the modified CDN-Domain (i.e., b.cdn.csp.example). This causes B's Request Router to respond with a suitable delivery node. What's up with the NS record here? Are you relying on glue to make sure that the query goes to the right nameserver?
Some non-binding suggestions: In section 1.1, this is really unclear: Recursive CDNI Request Redirection: When an upstream CDN elects to redirect a request towards a downstream CDN, the upstream CDN can query the downstream CDN Request Routing system via the CDNI Request Routing Redirection Interface (or use information cached from earlier similar queries) to find out how the downstream CDN wants the request to be redirected, which allows the upstream CDN to factor in the downstream CDN response when redirecting the user agent. This approach is referred to as "Recursive" CDNI Request Redirection. Note that the downstream CDN may elect to have the request redirected directly to a Surrogate inside the downstream CDN, to the Request Routing System of the downstream CDN, to another CDN, or to whatever system is necessary to handle the redirected request appropriately. I think this means that the uCDN gets a query from a user agent, queries the dCDN to find out what URL will reach the desired delivery node, and then sends a redirect to the UA with that URL. But it might mean something else. Maybe I will learn what it means later on in the document, but if this is to be helpful, it needs to make sense _before_ I've read the document! :) So it would be good if it could be rephrased, and I would be happy to help iterate on that if it's useful. Ah. In fact, there's some much clearer text about this at the end of section 3.2. I suggest adapting that text for the terminology section. It might be better to explain iterative request redirection first and then explain recursive redirection in terms of how it differs, which I guess is why I like the text at the end of 3.2 so much... Also in section 1.1, CSP is never expanded, and probably should be: OLD: Trigger Interface: a subset of the CDNI Control interface that includes operations to pre-position, revalidate, and purge both metadata and content. These operations are typically called in response to some action (Trigger) by the CSP on the upstream CDN. NEW: Trigger Interface: a subset of the CDNI Control interface that includes operations to pre-position, revalidate, and purge both metadata and content. These operations are typically called in response to some action (Trigger) by the Content Service Provider (CSP) on the upstream CDN. Or just add an entry in this section for Content Service Provider. This would be a win for me, but possibly not for a reader with more knowledge of the subject matter. Also: OLD: We also sometimes use uCDN and dCDN as shorthand for upstream CDN and downstream CDN, respectively. NEW: uCDN: Upstream Content Delivery Network dCDN: Downstream Content Delivery Network I think this is useful additional emphasis, but won't be offended if you ignore this suggestion. :) Section 3.4, paragraph 2: As before, Operator A has to learn the set of requests that dCDN is willing or able to serve (e.g. which client IP address prefixes or geographic regions are part of the dCDN footprint). We assume Operator has and makes known to operator A some unique identifier ^ You are missing (I suspect) a B here. In section 3.5: This example differs from the one in Figure 5 only in the addition of a FCI request (step 2) and corresponding response (step 3). The diagram shows an RI request and response, not an FCI request and response. Is there a disagreement between the text and the diagram, or am I just misunderstanding something? In 3.6, has the uCDN remembered that the dCDN might have cached a particular bit of content? This seems like a really heavyweight solution. What happens if this information is lost?
For discuss points 1-3, it could be fine for this document to just note that there are tricky issues around these topics, but I'm a little concerned that we not punt on them for too long, or even worse, forget about them, in case we hit late problems. (1) section 3: I would like to have seen some examples with discussion of DNSSEC and where the URL the client starts with is an HTTPS URL and/or where HTTPS URLs are used between CDNs. I'm not trying to insist on that though but have those (3) issues been considered by the WG? If not, when will they? (2) There is no mention of privacy in this document at all, nor is the CDNi requirement LI-17 mentioned. Isn't there simply missing text on that? If not, why not? For example in 4.4 I was surprised not to see any mention of privacy issues or jurisdiction issues. Why does that not need a mention? Are there really no open issues associated with the LI and privacy? Just to pick on one of the possibly many juicy issues: what if the browser request has DNT set? (I don't expect this doc to resolve that issue btw.) (3) section 6: Am I right in thinking that this is the first time we're standardising protocols related to CDNs? (That is, we have not prevously standardised any CDNi or CSP/CDN protocols.) If so, then I question whether the "main trust issue" is transitive trust. That is an issue certainly, but we are also here standardising the logging that has until now been handled in proprietary ways by CSPs and CDNs, which arguably means that the associated privacy issues for the end user need to be considered as in scope and it is not sufficient to simply say "do what CDNs do." If those are in scope, then I would further argue that that is also a significant trust issue. If we figure out how to handle discuss point 2 above, then this might just amount to a simple reference to whatever text results (or maybe that text would just go in this section.) (4) 4.7: Just checking: This made me wonder about how CDNI and HTTP/2.0 are intended to play together. I think there's been relevant discussion on httpbis about similar issues but haven't followed that. Is someone tracking how CDNI and HTTP/2.0 will interact? If not then wouldn't that be a good idea since both are likely to arrive as RFCs about the same time? (To be clear: I've no strong opinion on the details here, nor on sequencing of outputs, but would just like to know we don't have two WGs ignoring one another when they shouldn't. And I'll happily hand this discuss point over to someone who knows more about both topics.)
- 1.1: Does the CDN-Domain include or exclude a default or non-default port number? Saying exactly which part of the RFC 3986 ABNF you mean might help here. Or if that's for later, maybe say that now here so folks don't get confused. - 1.1: Also on CDN-Domain - how does this play with the SOP and/or CORS or does it and what if the URL is not an HTTP URL? I'd be fine if you want to punt until later on other URI schemes btw, not asking that you boil an ocean now, but better to be a bit more precise on this I think. - 1.1: I think it might help to define (or reference a definition for) "footprint" - for me at least its not clear what combination(s) of topological, geographic or other information is intended here. I'm not asking that you provide the data model in 1.1 though but I think a definition could help. - 2.1.1: You don't say why DNAME might be preferable to CNAME. I wondered:-) And btw, I assume mention of wildcards in DNS zone files isn't needed here as relevant DNS servers maybe don't tend to do that? - 2.1.2: The client IP will only be known if there's no proxy or the proxy passes on the client IP via XFF or similar though. Worth noting? - 4.8: I could imagine CDNs serving up frequently loaded static content that's not tiny, like maybe JS libraries that are widely used. W3C have an early piece of work that's related  so just noting that and wondering if it might be wise to take it into account here at some stage. (It *might* be a problem if that's not considered, but that might be ok for now since the W3C stuff is drafty. Maybe worth a look if the WG didn't already.)  http://www.w3.org/TR/SRI/ - section 8: As with section 6, I think the "just consider the delta between CDN and CDNi" is not the right approach here as that could result in CDNi making e.g. HTTPS less easy to deploy. There is a significiant enough history of that approach to security going wrong, e.g. when IEEE did Wired *Equivalent* Privacy (WEP) they ended up addressing the wrong target and had to go back and substantially re-do stuff a number of times. I would suggest that simply referring to  here would be a better approach. This is not a discuss because I assume that CDNi protocol documents will in any case have to deal with how they meet those requirements and will not be able to point here and say "same as CDN, nothing to see here." If that last was the WG's plan, then maybe we should chat more about that now too. (Since we will later otherwise:-)  https://tools.ietf.org/html/draft-ietf-cdni-requirements-17#section-9 - Section 8: Requirement SEC-2 (DoS resistance) is not mentioned at all. Did the WG consider whether or not that requirement ought result in text here? I could buy an argument that this requirement won't really be discussed in any detail until later, but wanted to check.
I just have a few comments/questions, but otherwise the document looks good. Section 6. Trust Model: In practice, do the trust relationships described rely on contracts or other agreements that are enforceable? I would think so and if that's the case, should they be mentioned (Security Levels of Service, etc.)? In either the Trust Model or Security Considerations sections, I expected to see a discussion on fraud concerns in CDNI. Could you add in mention of fraud and some of the explicit concerns/risks? Additionally, I support Stephen's positions. For the privacy concerns he raises, there are several points in the draft that discuss which of the parties have access to what types of data (what users access, just metrics, monitoring capabilities, etc.). It would be very helpful to call this out in a privacy section and enumerate on the limits/restrictions to assist with privacy concerns. The draft does have some of this detailed, but it does not call out privacy as a concern and is not organized around privacy in a section of the document.
As noted in my discussion response, I'm moving this to a non-blocking comment, and I'm happy to accept what Spencer and the authors think is best. Thanks for the discussion. ------------------------------------------------- This is a fine document, and I quite approve of its publication. I'd like to discuss a small point on the obsolescence of 3466: It's my sense that it isn't this document alone that obsoletes 3466, but the combination of this document and RFC 6707. 6707 replaced the problem statement part, and this nukes the rest. Is that correct? If not, whack me in the snout with a rolled-up newspaper and I'll clear this DISCUSS forthwith. But if so, I suggest a tweak that will make that clear: OLD (Abstract) It obsoletes RFC 3466. NEW This document, in combination with RFC 6707, obsoletes RFC 3466. END OLD (Introduction) To avoid confusion, this document obsoletes [RFC3466]. NEW To avoid confusion, this document and [RFC6707] together obsolete [RFC3466]. END
1. Section 1.2 references the CDNI WG, but that reference could be re-worded to point at this document. 2. Should the discussion of HTTP redirection in section 2.1.2 mention as a limitation that this approach won't work for non-HTTP traffic? It is obvious, but if DNS redirection is not feasible, what other option would a CDN operator use?
I support Stephen's DISCUSS and COMMENT, especially his point (2) and the comment about only discussing the security/privacy considerations relevant to the delta between CDN and CDNI. This security considerations text seems particularly inadequate to me: Another concern that arises in any CDN is that information about the behavior of users (what content they access, how much content they consume, etc.) may be gathered by the CDN. This risk certainly exists in inter-connected CDNs, but it should be possible to apply the same techniques to mitigate it as in the single CDN case. Perhaps this is true, but without further discussion of what the existing techniques are, this seems like a weak claim. Furthermore, there are many aspects of the framework described in this document that implicitly promote better identification of clients to more nodes (interconnected CDNs, recursive DNS resolvers, etc.), so it would be helpful to understand how to square that with the claim made above.
(1) Section 3.2 says: "These problems are generally soluble, but the solutions complicate the example, so we do not discuss them further in this version of the draft." Was there an intention to discuss these solutions in this draft (assuming at some point soon we will hit its final version)? (2) During IETF LC, Ray said that the reference to the (expired) draft-vandergaast-edns-client-subnet would be removed. Is that still the plan? I think removing it is appropriate. (3) I'm confused about this text in Section 4.6: "Fine-grain control over how the downstream CDN delivers content on behalf of the upstream CDN is also possible. For example, by including the Forwarded HTTP header [I-D.ietf-appsawg-http-forwarded] with the conditional GET request, the downstream CDN can report the end-user's IP address to the upstream CDN, giving it an opportunity to control whether the downstream CDN should serve the content to this particular end-user. The upstream CDN would communicate its directive through its response to the conditional GET." This is characterized as an in-band mechanism. But how does the dCDN know whether to include the Forwarded header, other than by some out-of-band arrangement with the uCDN? Or is the assumption that the dCDN includes it with every conditional GET request?
Thanks for writing this draft. I am ready to recommend the approval of the draft, but before that the discussion raised after Martin Thomsons'sGen-ART review needs to finish, so that we agree on what changes (if any) are necessary.
Some comments to consider: Section 4.3.2 should cover privacy issues related to the content (DNS names) of the P-Visited-Network-ID header field. Section 4.6: The letter 't' is missing in the second to last paragraph at the end of the word present. When presen only one instance of the header MUST be present in a particular request or response. Section 5.5 and 5.6 cover P-Charging-Function-Addresses header field syntax and P-Charging-Vector header syntax respectively. The section does not include a discussion on fraud and it seems like this would be important? Several of the other sections do include security implications prior to the Security Considerations section. This is a non-blocking comment since trust and integrity are listed as important to prevent modifications, but it would be good to see mention of fraud as the motivation for an attack either in these sections or in the Security Considerations section.
In this text: 188.8.131.52. Procedures at the registrar and proxy Note that a received P-Visited-Network-ID from a UA is a failure case and MUST be deleted when the request is forwarded. is "a failure case" the right description?
In side discussion with Richard, we came up with the following text to be added to 4.3: Note that P-Visited-Network information reveals the location of the user, to the level of the coverage area of the visited network. For a national network, for example, P-Visited-Network would reveal that the user is in the country in question. It would be helpful to state the hop-by-hop integrity protection requirement from 6.3 in 4.3.1 as well.
I've just a bunch of nits. My guess about Specer's non-post-Snowden question is that probably loads of IMS stuff assumes physical security, which may well be questionable. I'd love to be shown that I'm wrong. I doubt fixing that here is doable though. I also think Kathleen's discuss is right - calling out that anyone can spoof the header field values that are allowed on their n/w would be good. - 1.2: Is "closed" accurate there really? Just wondering. - 1.2: RFC 3427 is obsoleted. Does that make any difference to the applicability statement? (Funny that the shepherd write up says this passes the nit checker but the nit checker in the tracker spots this and the ESP one below.) - 1.3: Should the section title be "Background"? - 3.6: I didn't know what Spec(T) meant. Maybe add a reference to 3324 section 2.4? - section 5: By "domain name" do you mean it has to be, or just often is, a real DNS name? - section 7: Does that syntax allow for i18n? - section 8: RFC 2406 is obsoleted. That should be fixed. - section 8: Don't you want to allow SIP/TLS too? - section 8, para 1: Using "ensures the ..." is somewhat optimistic isn't it? "needs to ensure the ..." would be better I think. - section 8: Also just wondering. Given that this header field name is quite long and assuming for a moment that it might be the only difference between private and public SIP messages, might not the message sizes allow someone to distinguish such SIP messages even if they are encrypted? Worth noting? I'm not sure, but the example you give is 42 bytes long which could be a nice distinguisher if one cared.
Please do address Spencer's comments and update the applicability section. It not entirely clear to me why we need to be publishing this document, but still, making it clear why we're publishing another P-header would be good.
Thank you for addressing the SecDir review comments. I would like to understand what prevents spoofing the domain name used in this extension? The rules included for setting and removing this use of this extension may be enough, but does rely on the security of the devices (proxies) and the network. As such, it would be helpful to call spoofing out specifically and the mitigations for it in the security considerations section. It would be helpful to see the set of mitigation described in one spot (Security Considerations).
And I found a couple of nits that would be helpful to correct: Section 6.1.1 I recommend breaking the first sentence into multiple as it is a bit tough to read. Security Considerations Section: Can you add network before "elements" in the first sentence? In other areas, elements typically refers to data. Also, traffic should not have an "s" at the end. New: The private network indication defined in this document MUST only be used in the traffic transported between the network elements which are mutually trusted
I can't quite make myself ballot Discuss on this, but I've been through the Discuss criteria twice looking for justification for a Discuss. Please make good choices. In this text: 1.2. Applicability According to RFC 3427 [RFC3427], P-headers have a limited applicability. Specifications of P-headers such as this RFC need to clearly document the useful scope of the proposal, and explain its limitations and why it is not suitable for the general use of SIP on the Internet. RFC 3427 was obsoleted by RFC 5727, and since then we've also published RFC 6648 (as a BCP) that explicitly deprecated the use of P-headers in SIP. So, this paragraph would have been about right in 2008, but it doesn't describe reality today. I'm fine with publishing this specification for a P-header because it's documenting established practice, and section 1.3 of the draft explains that, but I'd prefer that we not publish an RFC in 2014 that seems to say the draft authors were bound by RFC 3427 requirements that no longer apply. There are, of course, other ways to address this comment, but chopping the first paragraph in 1.2 would work for me. In this text: 8. Security considerations The private network indication defined in this document MUST only be used in the traffics transported between the elements which are mutually trusted. Traffic protection between network elements can be achieved by using the security protocols such as IPsec ESP [RFC2406] or sometimes by physical protection of the network. (I swear this isn't a post-Snowden question) This draft was Publication-Requested in its current form because it matches existing deployments, if I'm understanding correctly. Do those existing deployments rely on physical protection of the network for traffic protection? I'd feel better about allowing this loophole in 2014 if I knew it applied in target deployments.
These comments are provided for information of the ISE in the hope that they can be used to benefit the document. --- This document as introduced to the MANET mailing list on 25th Feb 2014 at http://www.ietf.org/mail-archive/web/manet/current/msg15943.html. This responded in a short thread discussing the document. it is worth reading the whole thread since it raises some questions about the content of the document, and other questions about whether the material should be discussed in the IEEE. --- Approaching my 5742 conflict review I commissioned a Routing Directorate review from Thomas Clausen. Thomas is an expert in this type of protocol although he does most of his work within the IETF not the IEEE. You can see Thomas's review at http://www.ietf.org/mail-archive/web/rtg-dir/current/msg02130.html. The review concludes that there is no conflict with IETF work (see my 5742 conflict review), but also warns of potential conflict with work done in the IEEE. Additionally, the review makes a number of comments on the style, content, and technical matter of the document.
From a quick read, I'd be shocked if independent implementations could interop. It seems very underspecified, definitely in terms of the crypto but also in e.g. protocol terms where you need a PKG and KDC and afaik those aren't part of the underlying IEEE stuff and nor are they documented here at all that I can see. One suggestion for the author and ISE might be to see if the CFRG are interested in the crypto parts of this. I could imagine a world where this'd be a fine -00 draft for CFRG to work from, if they were interested in the topic. I didn't try figure out if the security claims made are justified either btw. I think it'd be a fine thing if the ISE did want to (or has already) gotten someone to check those. I don't think those claims are entirely obvious nor would checking them be trivial, espcially with the level of underspecification here.
I agree with Stephen.
Definitely support suggesting that the ISE discuss this with the IEEE.
Agree with Adrian and Brian.
I'll be interested to see where this goes, and whether there's future work for the IETF relating to this work.
Comments for the ISE and authors from Stewart Bryant, who was kind enough to review the draft: This is a useful and well written document and could be published as is. However I do have some comments that you may wish to consider. In terms of connectivity you have characterized an IP unicast service, but in the general case there is multicast and there are a variety of LAN and pseudowire connectivity services that require a connectivity provisioning profile. There is considerable overlap between the IP and non-IP profiles, so you may wish to extend the work here to cover that case, or you could reasonably leave it for the future. If you omit non-IP services you might wish to amend the title accordingly. The various multipoint service needs a specialist review and I suspect will increase the complexity of the profile. Again you might wish to reflect a limited scope in the title and introductory material. This is fine as an independent stream document, but I wonder if it (or a development of this text) needs to be considered for publication in one of the OPS WGs or as input to I2RS. In terms of the various performance parameters delay, loss, availability it occurs to me that you need to be specifying a mask rather than point parameters. Now the state of the art in technical metrics may not be sufficiently developed buy I would be surprised if contracts were no written in those terms. === Minor typo: The CPP reference architectures are depicted in Figure 3Figure 4Figure 5. === These nodes should be unambiguously identified (e.g., using a unique Service_identifier). For each Customer Node, a border link or a node that belongs to the domain that connects the Customer Nodes should be identified. Is the above sufficient? I can imagine that you will need to consider other parameters such as VLANs, MAC addresses etc. === 3.4. Availability Guarantees o Enable IP Fast Reroute features (e.g., [RFC5286]). It occurs to me that there are no well developed metrics for FRR in the IETF an perhaps there need to be for these types a specification. === In view of recent global events, at some stage this work will need to be extended to consider privacy requirements and geographic routing restrictions. === 3.9. Flow Identification This is a section that could certainly do with some privacy considerations. === 3.10. Routing & Forwarding I would expect that the profile needed to contain some indication of how reachability/topology information was exchanged between the provider network and the client network. In a pure OTT network this is not needed, but where the provider network is providing an IP service BGP is a consideration. === 3.13. Notifications Does NETCONF/YANG need to be called up? === 6. Security Considerations You probably need to consider privacy in this section. === Two typos in the following "CPP documents should be protected againts illegitame modifications" ===============
I am curious if there is any concerns with a potential relationship in the OAM side of the IETF. This document reads like the start of a data model (i.e., YANG).
This comment for the ISE and the authors to consider as a way to improve the document. In reading this document I was disappointed to not find a neat summary of "recommendations to the IETF". If the document is open for editing at some future point, it would be nice to draw out a set of bullet points in their own sub-section.
Note that these comments are just my review and are intended for the authors and ISE to consider however they wish. Happy to chat about them if someone wants to though. - p4, 2nd para: this seems to end abruptl - 2.1, RIPEMD-160 and SHA-1 are odd choices for MTI these days. One would expect that SHA-256 perhaps plus a SHA-3 finalist would be more likely as a modern MTI HMAC choice for an experimental RFC, or if there are reasons to prefer a shorter output that those might be stated. - 2.1, which of the combinations mentioned have known weak keys? Could that be a hangover from old DES based stuff? - 2.2, I'm not clear why you need padding before doing HMAC. Ah - I got it at the end of 2.2 - you don't mean what a cryptographer would call padding but rather you mean preparing a canonical input for HMAC. - 2.4, why oh why do routing people feel the need to replicate text from RFC 2104 ;-) I think just referring to the HMAC RFC would be better here. - 4.3, the length field is in octets and not bits I assume? Might be a (tiny bit;-) better to say that explicitly. - 4.3, "Digest" isn't a great name, since those bits are not actually a digest but an HMAC output. (Authenticator would be a more common term maybe.) - 4.3, While this is just about HMAC, with an eight bit length field and 2 octet KeyID that would only allow a max of 2038 bits of "Digest" which is not enough for an RSA 2048 signature. Up to you if you think that's important or not. If you did, using another Type for signatures would be fine, or a 16 bit Length. Maybe another Type would be better in this case. - Section 8: Nice! Thanks for that. - Section 9: It wasn't clear to me whether or not any reflection attacks might be possible, nor if use of private addresses (e.g. Net10) might mean that some odd form of replay might be doable.