IESG Narrative Minutes
Narrative Minutes of the IESG Teleconference on 2016-06-30. These are not an official record of the meeting.
Narrative scribe: John Leslie (The scribe was sometimes uncertain who was speaking.)
Corrections from:
1 Administrivia
2. Protocol actions
2.1 WG submissions
2.1.1 New items
Telechat:
Telechat:
Telechat:
2.1.2 Returning items
2.2 Individual submissions
2.2.1 New items
Telechat:
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
Telechat:
Telechat:
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
Telechat:
3.4.2 Returning items
1026 EDT no break
4 Working Group Actions
4.1 WG Creation
4.1.1 Proposed for IETF Review
4.1.2 Proposed for Approval
Telechat::
Telechat::
Telechat::
4.2 WG Rechartering
4.2.1 Under evaluation for IETF Review
4.2.2 Proposed for Approval
Telechat::
5. IAB News We can use
6. Management Issues
Telechat::
Telechat::
7. Working Group News
Amy: next telechat July 7th; US holiday July 4th
Jari: add sentence saying "not chartered to..."; anybody have comment
Benoit: you will also mention ??? -- (not in charter)
1130 EDT Entered Executive Session (for Jari's IESG statement on IPR declarations)
(at 2016-06-30 06:00:03 PDT)
draft-ietf-trill-irb
Just a couple of nits: - Please expand TRILL in the abstract. - Figure 1: I see what ToR means, but what about AGG and COR? (I can guess, but a definition would be helpful.)
- section 5: The tenant ID is sometimes described as "globally unique" and sometimes (in 5.2) as "throughout the campus." The latter seems likely correct to me. (As an aside, is this document the first to introduce that concept to TRILL?) - section 8: If IS-IS security is not actually used, (is that the current deployment reality btw?) and if I can guess a tenant ID then what new mischief can happen? If there is some, then perhaps you ought recommend that tenant ID's be randomly selected within the campus? (I see you use "1" in the example, which is pretty easy to guess:-) I think one could argue that that (and maybe more) ought be covered in section 8, if the current deployment reality is that no crypto is actually used to protect most IS-IS traffic. Is it?
* Section 6 has a few errors that need to get fixed before this document goes forward. e.g. It is not clear what a "192.0.2.0/32" subnet means especially since the only host shown to be on the subnet 192.0.2.2 cannot obviously fall inside the subnet range. The /32 needs to be replaced with something shorter depending on what the authors/WG intended (say a /24). * RB2 seems to be advertising ES2s IPv4 address 198.51.100.2/32 instead of the prefix of the subnet while RB1 seems to be advertising the the IPv4 prefix of the ES1 subnet. One of these is wrong. Not sure which one is intended. * What is the rationale for using a /112 IPv6 prefix for numbering an IPv6 link with hosts? Things like SLAAC (RFC4862) will not work in such links. Is there a reason the authors want to use a longer than /64? Please read RFC7421 for advantages of using a /64 instead and to find out what things break if you do not use a /64.
Section 5: What does "Layer 2 routing" mean in this context? Sections 7.3 & 7.4: What is the point of including these sub-TLVs if no prefix is being advertised? (The Total Length=0 case specified in the document)
Here is Scott Bradners' OPS directorate review: I performed an OPS-DIR review of draft-ietf-trill-irb-13.txt. Summary: the technical specification seems ready to be published but management considerations are not mentioned. I found the document to be a confusing read, likely because it is not easy to explain the forwarding behavior but I expect that the document is clear enough to implement from. What I did not find was any discussion of management - maybe that is covered in the MIB or OAM documents listed in the TRILL charter. If so, it might be good to reference the right documents. If not, then it would be good to have some suggestions about what to instrument for management. Balloting no objection based on the interaction with Donald Eastlake, assuming some text will be provided: The configuration information is visible in the link state database. A reference to the appropriate OAM documents could be added. Regards, Benoit
In reading the draft and security considerations, I had the same concern as Stephen's second point. Are there any security issues if the session is not encrypted? I see the concern for sensitive data and that is good, but are any exploits possible if the session is not encrypted (like on the tenantID as Stephen asked).
Two minor comments: 1) There are only few SHOULDs and MUSTs in this whole document and where they are used it is often not very clear what the action is that should follow and how it should be implemented (e.g. "The network operator MUST ensure the consistency of the tenant ID on each edge RBridge for each routing domain."). And maybe there are actually more case where normative language should be used? Please double-check the use of normative langauge in this document! 2) A similar question on the following part: „If a tenant is deleted on an edge RBridge RB1, RB1 SHOULD re- advertise the local tenant Data Label, tenant gateway MAC, and related IP prefixes information of the rest tenants to other edge RBridges. […] Therefore the transient routes consistency won't cause issues other than wasting some network bandwidth.“ Wasting network resources actually can be an issue. So why is this not an MUST?
Scott Bradner performed the opsdir review.
draft-ietf-ospf-transition-to-ospfv3
section 4: Just checking that I've gotten this right. Is the following correct? If RFC7166 is being used then there is never a need to modify packets in a way that would break the authentication. In other words, am I correct that this draft doesn't envisage any middlebox changing an OSPF packet in between the source (of authentication) and destination(s)? If that is correct, then we're good. If that is not correct, then I think more needs to be said in section 4, as it is not at all clear to me how a source could emit a packet that a middlebox could modify, without having to share the symmetric secret used for RFC7166 authentication with that middlebox, which would be fairly clearly undesirable.
Nit: „Further work such as [ipsecospf] would be required to support IPsec protection for OSPFv3 over IPv4 transport.“ -> I guess that should mean OSPFv2 here...?
I do think this is a good mechanism to transition from IPv4-only OSPFv2 to dual-stack capable OSPFv3. Thanks for quickly addressing the issues in my DISCUSS.
I support this document going forward. However, in Section 4 it says: Consequently, an OSPFv3 packet transported within an IPv4 packet requires IPsec to provide authentication and confidentiality. Further work such as [ipsecospf] would be required to support IPsec protection for OSPFv3 over IPv4 transport. And I had trouble understanding what you meant by this, exactly. IPsec is required, but is not currently completely enough defined for OSPF to make this possible? If so, I'd suggest using the words: Consequently, an OSPFv3 packet transported within an IPv4 packet requires IPsec to provide authentication and confidentiality. However, further work such as [ipsecospf] would be required to support IPsec protection for OSPFv3 over IPv4 transport. But maybe I am misunderstanding what was meant here.
This was nice work. I did have one question - I don't think it would be a likely problem, but is it worth pointing out that you're taking OSPFv3 payloads that might have been sized for IPv6, and encapsulating them as IPv4 payloads that might have a smaller MTU? If you tell me this isn't a problem, I'll believe you, of course, but I needed to ask :-)
I have a couple of comments that I want to see addressed before publication; I don't think they raise to a DISCUSS, but are not minor. …and a couple of nits… Comments: 1. I think there's an rfc2119 conflict in Section 3.1. (Source Address); the text says: "All OSPFv3 routers on the link SHOULD share the same IPv4 subnet for IPv4 transport to function correctly…Accordingly, an OSPFv3 router implementation MAY support adjacencies with OSPFv3 neighbors on different IPv4 subnets." I think this text presents a conflict because the support of adjacencies in different IPv4 subnets is optional (MAY), while the "SHOULD" implies a much stronger requirement. Suggestion: s/SHOULD/should 2. Section 3.3. (Operation over Virtual Links): "…it is RECOMMENDED to use the IP transport matching the address family in OSPF routing domains requiring virtual links." This sentence is wrong because (as you said in the previous one) "If IPv4 transport, as specified herein, is used for IPv6 address families, virtual links cannot be supported." IOW, the IP transport for IPv6 AFs MUST be IPv6. "RECOMMENDED" implies that there may be a case where it is ok not to do it, that that is not the case here. Nits: n1. In the Introduction, "…because both IPv4 and IPv6 address families can be advertised using either IPv4 or IPv6", I think you meant "IPv4 or IPv6 transport". n2. This statement is superfluous because (to me) you're comparing apples and oranges: " Unlike 6to4 encapsulation [RFC3056] that tunnels IPv6 traffic through an IPv4 network". n2. Section 4. (IPv4-only Use Case) is ok, but it seems out of place. Maybe put it right after the Introduction, or make it a subsection of it.
draft-ietf-calext-extensions
I think it'd be a fine thing if the calext WG were to consider privacy issues with caldav in general. As it'd probably be wrong to try get all of that done in this one document, perhaps we could try and see if the WG have sufficient interest and cycles to take that on? My previous discuss text (plus an additional point about images is below. - I think adding some privacy considerations to this would be good, either as new text or via references. Did the WG consider privacy issues? Some that occur to me are: - names, descriptions and identifiers here are all ones that might allow (re)identification in unexpected ways - the UID property in particular probably ought be random and probably ought not be re-used for anything else, some RFC2119 SHOULD statements about that would seem like they'd be good. - doing a refresh against a calendar at the expected frequency could be a good way to re-identify someone - if I can read the expected frequency and some IP address connects (even all over TLS) at about that regularity then I can be reasonably sure that the client is someone subscribed to that address, and maybe use that to track a person's movement across various networks. (That's different from the text in section 7 which assumes that the URL is what's tracked, but the connection can be just as revealing, for some calendars.) I'm not trying to insist all that analysis be documented in this draft but I would hope that the WG have considered the issues and how best to document those and have a plan to do that. (If I'm told such a plan exists and what it is, I'll clear.) This is related to, but a little different from, Kathleen's discuss, depending on the added privacy considerations text which I've not managed to find in the secdir review thread. But this should be as easily cleared I'd guess. And another possible issue now occurs to me: I remember that one social network had an issue where all the avatar image sizes were nearly unique, so that even though those were all accessed over TLS, one could identify users and their buddies by watching those be downloaded. (That depended on how the social network in question made avatar images available, which'll likely be different here.) But there may be a reason to recommend normalising image sizes here as well and to encourage only offering those over https and not http.
The author has addressed all my DISCUSS points and comments in email. (Thanks!). I've cleared on the assumption the proposed text will make it into a revision.
Dan Romacanu did the OPS DIR review. The RFC5706 does not apply.
Thanks for the updated text to address the SecDir review and Stephen's additional comments (I followed that discussion as well).
draft-ietf-forces-interfelfb
I have two things I'd like to discuss: (1) Section 10 says: " This document does not alter [RFC5812] or the ForCES Protocol[RFC5810]. As such, it has no impact on these documents security considerations. This document simply defines the operational parameters and capabilities of an LFB that performs LFB class instance extensions across nodes under a single administrative control. This document does not attempt to analyze the presence or possibility of security interactions created by allowing LFB graph extension on packets. Any such issues, if they exist should be resolved by the designers of the particular data path i.e they are not the responsibility of general mechanism outlined in this document; one such option for protecting Ethernet is the use of IEEE 802.1AE Media Access Control Security [ieee8021ae] which provides encryption and authentication. " I'm not sure I buy that explanation. While you may not be changing the protocol much, you are sending PDUs over a network where they previously were processed within one machine. IIRC, earlier ForCES documents called for IPSec or TLS as mandatory-to-implement (MTI) for anything where ForCES stuff was being sent "off the box." That is clearly being done here, so I don't get how MACsec is now regarded as optional to implement. Can you explain? That may be me recalling incorrectly, or perhaps there is a good reason, but if the above logic were correct there would have been no reason to have said earlier that security was MTI so I'm confused. (2) I'm also unsure that just saying "use MACsec" is enough to get interop and security for this. For example, is it likely that separate keys would be setup just for ForCES use here? If so, saying that's needed would be good. If not, I wonder what threats might arise with spoofing ForCES traffic from a box that has the right MACsec keys. Has someone implemented/tested with MACsec and considered those issues?
There are three places where there still seem to be comments in the draft (marked by "XXX"), at least one of those looks like it ought to have been sorted before now. I'm also not sure the others are clear enough for the RFC editor. (Or perhaps for IANA, at whom they may really be directed?)
"The Ethernet type is used to identify the frame as inter-FE LFB type. Ethertype TBA1 is to be used (XXX: Note to RFC editor, likely we wont get that value - update when available)." What is the status of the Ethertype registration with IEEE? Obviously this document shouldn't be published without it.
* I am not sure what the point of Section 9 is. There is not much IETF/IESG/IANA can do about this, can we? I think the authors/WG should take this up with the IEEE to get the required ethertype assigned before publication. * It would have been nice to include a basic IPv6 router example in addition to (or even instead of) the basic IPv4 router example. * I simply cannot visualize how the TLV encoded metadata format looks like inside the packet and how it saves 4 bytes per metadatum transferred. Specifically how does this differ from the encoding specified in section 6.2 of RFC5810 . Can you please clarify?
I support Stephen's discuss points.
Thanks for addressing all transport comments!
Liushucheng performed the opsdir review
draft-ietf-mile-implementreport
I concur with Alvaro and Ben on this one. There is too much that is too close to marketing text and that would not really help an implementer or someone investigating these RFCs, or someone further developing those RFCs. It seems to me that only sections 7.1 and 7.4 contain the kind of information that I'd expect to find in an RFC like this. As far as I can see only those two sections actually refer to sections of, or content from, the RFCs concerned in a way that is useful to document in an RFC. I also could not access the URL in section 1. That seems like it really would need fixing. (I will admit that I may be somewhat biased here - IMO any document with 26+ occurrences of the string "cyber" is likely not a good candidate for an RFC;-)
I think that this document is already outdated and that it doesn't have any archival value — I am then ABSTAINing. I like the fact that the authors provide a link to a "more complete list of implementations", which (in my opinion) results in the archival value of this document to be lowered even more. [However, the link didn't load for me. :-(] The information in Section 5.1. (Threat Central, HP -- picking on this section just because it is the first one) reads like a marketing brochure ("…a security intelligence platform that enables automated, real-time collaboration between organizations to combat today's increasingly sophisticated cyber attacks…"), and it provides information that is obviously not current: "General availability of Threat Central will be in 2014".
I do agree with Alvaro's position that this document does not have much archival value.
I'm going to have to agree with Alvaro on this one. I do not understand the purpose of publishing this, since it seems to be a snapshot of an moving target. It will be out of date very quickly. I don't see how that is helpful, and can imagine it might be harmful if future readers treat this as current information. A paragraph or two about why is valuable as an RFC might help. This is reminiscent of an RFC 6982 "implementation status section", but that RFC explicitly recommends such sections be removed before publication. In any case, I also cannot load the page referenced at the end of section 1. Hopefully that's a transient problem, but please make sure at the end of section 1 works prior to publication. (And hopefully forever if the resulting RFC continues to reference it.)
Nevil Brownlee performed the OPS DIR review. Here is his feedback. I have performed an Operations Directorate review of draft-ietf-mile-implementreport-09 "This document is a collection of implementation reports from vendors, consortiums, and researchers who have implemented one or more of the standards published from the IETF INCident Handling (INCH) and Management Incident Lightweight Exchange (MILE) working groups." This draft is a collection of information about Security Incident reporting protocols, and the implementation of systems that use them to share such information. It is simply a collection of information, it makes no attempt to compare the various standards or implementations. As such, it will be of interest to Network Operators who wish to collect and share such data. Operationally, Operators would need to decide which incident data collection group they want to be part of, that choice will strongly influence their choice of reporting protocol and applications to gather and distribute the data. The draft seems (to me) to need quite a bit of copy-editing, I list a few changes and suggestions below ... S1 RFC5070-bis. Is there an Internet Draft about this, or some other document you could reference? It's mentioned again in section 3.1, but there's nothing about it in the References section. S2.1 s/provides a solutions/provides solutions/ S2.3 s/IODEF formatted-message to/IODEF formatted-messages to/ s/by REN-ISAC are designed/by REN-ISAC is designed/ S3.2 "IODEF-SCI is the IETF draft" there's no reference to such a draft, there should be. "It also equips the interface ..." Exactly what does this mean? S4.2.2 s/prevents from accidentally/prevents accidentally/ s/ensure it is a well formed format/ ensure it is well formed/ S5.1 "General availability of Threat Central will be in 2014." It's now well into 2016 - this needs updating! Overall, I think the material in this draft is interesting, but it needs quite a bit of tidying/updating to get it ready for publishing.
Having an implementation report that actually provides references to available code is useful - as long as there is some permanence to the links.
One high level comment: I personally would rather see this as an appendix of RFC5070bis than an own document. Minor comments: - Please add a refernce to RFC5070-bis - http://siis.realmv6.org/implementations/ - this link did not work for me. Should this information be hosted somewhere, were long-time hosting is guaranteed? - I don't understand the following sentence; is there a reference missing? "IODEF-SCI is the IETF draft that extends IODEF so that IODEF document can embed structured cybersecurity information (SCI)" - What is the following sentence suposed to tell me? "Note that users can enjoy this software with their own responsibility." - draft-field-mile-rolie-02 should also be a real reference; and maybe "XEP-0268 (http://xmpp.org/extensions/xep-0268.html)" as well? In general check references where needed. - This is in the past: "General availability of Threat Central will be in 2014" - There are also a couple of other nits (e.g. missing articles) that probably will be fixed by the RFC editor, but maybe double-check if you do an update.
Nevile Brownlee performed the opsdir review. I don't think the draft is entirely ready to publish and I hope some editing will ensue but I that in the hands of shepherd, and responsible AD. Hi all: I have performed an Operations Directorate review of draft-ietf-mile-implementreport-09 "This document is a collection of implementation reports from vendors, consortiums, and researchers who have implemented one or more of the standards published from the IETF INCident Handling (INCH) and Management Incident Lightweight Exchange (MILE) working groups." This draft is a collection of information about Security Incident reporting protocols, and the implementation of systems that use them to share such information. It is simply a collection of information, it makes no attempt to compare the various standards or implementations. As such, it will be of interest to Network Operators who wish to collect and share such data. Operationally, Operators would need to decide which incident data collection group they want to be part of, that choice will strongly influence their choice of reporting protocol and applications to gather and distribute the data. The draft seems (to me) to need quite a bit of copy-editing, I list a few changes and suggestions below ... S1 RFC5070-bis. Is there an Internet Draft about this, or some other document you could reference? It's mentioned again in section 3.1, but there's nothing about it in the References section. S2.1 s/provides a solutions/provides solutions/ S2.3 s/IODEF formatted-message to/IODEF formatted-messages to/ s/by REN-ISAC are designed/by REN-ISAC is designed/ S3.2 "IODEF-SCI is the IETF draft" there's no reference to such a draft, there should be. "It also equips the interface ..." Exactly what does this mean? S4.2.2 s/prevents from accidentally/prevents accidentally/ s/ensure it is a well formed format/ ensure it is well formed/ S5.1 "General availability of Threat Central will be in 2014." It's now well into 2016 - this needs updating! Overall, I think the material in this draft is interesting, but it needs quite a bit of tidying/updating to get it ready for publishing. Cheers, Nevil -- --------------------------------------------------------------------- Nevil Brownlee Computer Science Department Phone: +64 9 373 7599 x88941 The University of Auckland FAX: +64 9 373 7453 Private Bag 92019, Auckland 1142, New Zealand _______________________________________________ OPS-DIR mailing list OPS-DIR@ietf.org https://www.ietf.org/mailman/listinfo/ops-dir
draft-ietf-alto-deployments
There's a 2 day old (at the time of this writing) IPR disclosure. It seems rather unusual, and I am not sure of the intent.
Brian Carpenter's Gen-ART review comments may be worth observing (though are minor; do not prevent approval).
Carlos pignataros 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. Summary: Ready with issues This is a very comprehensive (verbose) document, very well written. It considers operational issues throughout, and expires them in detail. Major: 1. I came across two patent applications in which the examiners add this document as a non-patent citation. The document has no IPR disclosures, and authors seem to have responded to IPR calls. I will submit 3rd party disclosures for these now, there may be more: http://www.google.com/patents/EP2913979A1#npl-citations http://www.google.com/patents/WO2016039798A1#npl-citations Minor: Section 3.2.2 1. Should PCE be a clear data source here? 2. Figure 8 — This figure lists the data sources, and where to retrieve data (the “how” via BGP/I2RS/NETCONF), but not too much about the “what data”. Is it only Topology? The BGP and I2RS sources are clear in terms of what information can provide, but SNMP/NETCONF can be pretty much anything, and then there’s IPFIX for flow info. Making explicit that this is Topology would help. 3. Figure 8 — NMS/OSS —> RESTCONF? 4. Page 23, first bullet — From an Operational standpoint, in the context of I2RS as a data source, it would be useful to reference draft-ietf-i2rs-traceability. Additionally, in terms of collecting topological data, I wonder if it would help to reference draft-ietf-i2rs-yang-network-topo. 5. Page 23, second bullet — says: Information Export (IPFIX), as well as other Operations, Administration, and Maintenance (OAM) information (e.g., syslog). But syslog (and traceability in general) is not OAM. Would ALTO benefit from reading information from or using actions from OAMs (BFD, performance management, etc)? Section 3.2.4 6. “Performance-related criteria” — it would be beneficial, from an Operational standpoint, to show or list IPPM specifics or other PM as OAMs which can be used. Section 3.4.4 7. The first “poet nail source” says “OAM”, but it really is referring to OSS which in turn can use OAM. Interestingly, the monitoring only reads data; however, a missed opportunity here is to actually trigger OAM and generate actions to generate OAM to test topology or traffic. I do not know enough about ALTO to conclusively know if this is a gap or not. 8. Section 10, Acknowledgements. Some Authors are Acknowledged in the Acknowledgements section. Others are not. It is not clear the contribution scope. Nits: 1. Acronyms — the document contains an immense amount of acronyms. They are all, it appears, very well expanded on first use. It would help, however, to have an Acronyms section. 2. Section 6.1. Thank you *very* much for explaining clearly what is meant by “VPN”! I hope these are clear and useful. Best, Carlos Pignataro. _______________________________________________ OPS-DIR mailing list OPS-DIR@ietf.org https://www.ietf.org/mailman/listinfo/ops-dir
conflict-review-irtf-icnrg-evaluation-methodology
I had a quick read (my first for this one) and especially thank the authors for section 3 which I think is very fair in its presentation.
I saw Stephen's comment and decided to skim the draft. Interesting read and thank you for section 3!