IESG Narrative Minutes
Narrative Minutes of the IESG Teleconference on 2017-06-08. These are not an official record of the meeting.
Narrative scribe: John Leslie, Susan Hares, and Ignas Bagdonas (The scribe was sometimes uncertain who was speaking.)
Corrections from: (none)
1 Administrivia
2. Protocol actions
2.1 WG submissions
2.1.1 New items
Telechat:
Telechat:
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
Telechat:
Telechat:
Telechat:
Telechat:
3.1.2 Returning items
3.2 Individual submissions via AD
3.2.1 New items
Telechat:
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
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
Telechat::
5. IAB News We can use
6. Management Issues
Telechat::
Telechat::
Telechat::
Telechat::
7. Working Group News
7a. Other Business
1048 EDT Adjourned
(at 2017-06-08 06:00:03 PDT)
draft-ietf-grow-bgp-reject
I echo Adam's appreciation for Appendix A.
The Appendix A is typically what the OPS directorate would look for.
I am having a little trouble reading Appendix A. If I understand correctly, the idea is: - In version N, you have a behavior X - In version N+1, you introduce a setting S with default value S=X - In version N+2 you change the default to S=!X However, the text says that "installations upgraded from release N+1 will adhere to the previous insecure behavior" Do you need to say that in N+1, you save the value S=X so that in N+1, it continues to apply?
Thank you for Appendix A; I think it is very helpful. Dale Worley's name appears twice in the Acknowledgements section.
draft-ietf-sipcore-name-addr-guidance
draft-ietf-pals-vpls-pim-snooping
Thank you for a useful document -- I have a few editorial comments which I think will make the document more readable, and so even more useful... Please also see the OpsDir comments (which also have some minor editorial nits): https://datatracker.ietf.org/doc/review-ietf-pals-vpls-pim-snooping-05-opsdir-lc-pignataro-2017-05-10/ My comments: S 1. Introduction O: . Forwarding Information Base for a VPLS instance is populated dynamically by MAC address learning. P: . The Forwarding Information Base (FIB) for a VPLS instance is populated dynamically by MAC address learning. C: Was missing a "The". Also, might be worth unexpanding "Forwarding Information Base" (sorry, so used to asking people to expand acronyms, feels odd to suggest the you also include the acronym, but might be helpful for people who know the term FIB, but not the expansion :-)). O: "While this document is in the context of VPLS, the procedures apply to regular layer-2 switches interconnected by physical connections as well, albeit this is outside of the scope of this document. In that case, the PW related concept/procedures are not applicable and that’s all." P: "These procedures also apply to regular layer-2 switches interconnected by physical connections, but further discussion is out of scope for this document. C: The original sentence was clunky. I think that the proposed still covers the salient points, but is easier to read. The "and that's all" in the original also seemed weird. O: "Notice that traffic is always sent on ports that have point-to-point connections to routers that are attached to a LAN on which there is a router." C: Err... "... routers that are attached to a LAN on which there is a router." If the router is attached to a LAN, then there is a router on the LAN. I'm presuming that you mean "routers that are attached to a LAN on which there is a another router." or "at least one other router"? "If we had some eggs, we could have eggs and bacon, if we had some bacon..." :-) O: "Unless explicitly noted, the procedures in this document are used for either PIM snooping or PIM proxying, and we will largely refer to PIM snooping in this document." P: "We will use the term PIM snooping in this document; but, unless explicitly noted, the procedures in this document apply equally to PIM snooping and PIM proxying". C: I had to read the original a few times, I *think* that my proposed is clearer, but might be wrong...
[This was deferred from the May 24 telechat while I was in the act of reviewing
it :-) I'm not sure if my comments will be relevant, but I will enter them
anyway since I have them.]
- The shepherd report describes why this is not PS. Was BCP considered? If
people don't think this is appropriate as a BCP, it would be good to include
comments about whether we expect people to adopt these practices. (Keeping in
mind that an informational draft explicitly does not comprise such a
recommendation.)
-4: I think the security considerations need more, well, consideration. For
example, could an attacker use this method to deny service, or to force traffic
to follow a compromised path?
Editorial:
-1.1: " Notice that traffic is always sent on ports that have point-to-point
connections to routers that are attached to a LAN on which there is a
router."
That seems like a circular statement. ("... connected to routers that are
attached to a LAN on which there is a router.")
Can I see the version that addresses the SecDir review comments? The mail thread showed agreement that they were all legitimate concerns, but the draft was not updated yet to fix these concerns with the text. https://datatracker.ietf.org/doc/review-ietf-pals-vpls-pim-snooping-05-secdir-lc-housley-2017-05-11/ Thanks.
My understanding is that the upcoming change to move from RFC 4601 to RFC 7761 makes section 2.3.3 no longer relevant. I presume it will be removed? Editorial nit: section 2.4.1 uses the abbreviation "J/P" without defining it. Suggest expanding.
[Thanks for the extra time to look at this document.] Please address the point about conflict resolution with respect to the RPF Vector/Join Attributes from Stig Venaas' review [1]. [1] https://mailarchive.ietf.org/arch/msg/pim/fpBjO5ii3IHWWc3923S3jXkT7IY/?qid=5b6c7062767cb7bec8ecdd8bce20a729
draft-ietf-bmwg-ipv6-tran-tech-benchmarking
I note that this document discusses using jumbo Ethernet frames up. The IEEE has a standard now for baby giant Ethernet frames - though there is still concern about the EtherType value used. An informative reference might be helpful.
-7.2, Reporting Format: Is it conventional to use 2119 keywords to describe report formatting? (Or is this paragraph really about content, rather than format?) (Comment repeats for other "format" related paragraphs.)
Section 4. (Test Setup): In terms of route setup, the recommendations of [RFC2544] Section 13 are valid for this document assuming that an IPv6 version of the routing packets shown in appendix C.2.6.2 is used. However, rfc2544 says in several places that the packets in the appendix are just examples. The frame in C.2.6.2 is a RIP update -- but Section 11.3 references the rate at which "frames SHOULD be sent" (also in the appendix) which include OSPF and IGRP, so I'm assuming that any routing protocol used should work (if the recommendations are followed in terms of frequency, etc.). I note that rfc5180 doesn't really say anything about routing setup for IPv6 either. :-( I know this is not the document to define a complete set of (or even update) recommendations for routing setup, so my suggestion is to simply take off the reference to the appendix: In terms of route setup, the recommendations of [RFC2544] Section 13 are valid for this document assuming that IPv6 capable routing protocols are used.
* I am surprised that this document does not use (and does not even mention) the Well Known Prefix (64:ff9b::/96) for the algorithmic mapping between IPv4 and IPv6 on translators as specified by RFC6052. Is there a reason why this is omitted? * It is not clear from the document whether the time taken by the DNS64 resolution procedure is included in the latency measurements. It might be useful to note this.
I was surprised not to find any mention of RFC 4380 (Teredo) in this document. If its omission was intentional, a statement to that effect (say, in the introduction) is probably warranted.
draft-ietf-bmwg-vswitch-opnfv
One minor question: sec 3.4: "The recommended flow classification parameters for any vswitch performance tests are: the input port (physical or logical), the source IP address, the destination IP address and the Ethernet protocol type field." Why does this not include the transport ports? Is it assumed that there is always only one flow between two IP addresses during a test? Minor editorial comment: Not sure why it is so important to mention several times that this work is done "by referencing existing literature" (without referencing any additional work beside opnfv)...?
I don't see the value of publishing this document as an RFC, specially because it reflects the progress of the VSPERF project "through the Brahmaputra (second) release" -- which would make this document obsolete instantly since the project is already working on their Danube (fourth) release. I appreciate the fact that the WG has found the discussions around this document useful and that the methodologies created are being referenced elsewhere. Because the WG/Chairs/Responsible AD find value in publication I am not going to stand in the way; I am then ABSTAINing.
-General: It seems a bit odd to me to use an IETF stream RFC to describe the status of an open source project, even when that project is closely related to IETF work. But I do not object strongly enough to get in the way of publication. -3.4: "It is essential to increase the flow timeout time on a vswitch before conducting any performance tests that do not intend to measure the flow setup time." Does this mean to make allowances for the startup characteristics of virtual network elements, when physical elements might not have such limitations? That seems sort of like optimizing for the test. -4, figures: Figure numbers and cross references would be very helpful for this section.
For sure, the topic of benchmarking of benchmarking virtual switches is
important in the industry today.
Technical Summary: This draft summarizes the progress of the OPNFV project on
virtual switch performance characterization, and notes that the OPNFV work
builds upon the IETF work, particularly the BMWG work within IETF, with an
emphasis on RFC2544.
I like the cross SDO aspects of this draft, as mentioned in the shepherd
writeup: The document itself was reviewed in ETSI NFV, and used as a reference
by at least one of the TST WG and IFA WF specifications (2 references in
total). The document has also been reviewed by several individuals from the
OPNFV community, and NFVRG (IRTF) is aware of the draft.
I would have preferred to see a document that specifies "benchmarking virtual
switches" instead of "benchmarking virtual switches in OPNFV". In other words,
just looking at the abstract, this is completely different to write:
This memo describes the way to benchmark virtual switch performance.
The specifications are based on the Open Platform for NFV (OPNFV) project on
virtual switch performance "VSPERF".
As opposed to:
This memo describes the progress of the Open Platform for NFV (OPNFV)
project on virtual switch performance "VSPERF".
Regarding the "describes the progress of", sentences such as ...
- This project intends to build ...
- Therefore, this memo begins to describe the additional considerations ...
- This memo summarizes the progress of the Open Platform for NFV (OPNFV)
project on virtual switch performance characterization, "VSPERF", through
the Brahmaputra (second) release [BrahRel].
... lead me to think that this is unfinished work, or that work will anyway
have to be updated.
Again, looking at the scope:
The primary purpose and scope of the memo is to inform the industry
of work-in-progress that builds on the body of extensive BMWG
literature and experience, and describe the extensions needed for
benchmarking virtual switches.
I was hoping that the primary purpose and scope of the memo would be the
specifications of the virtual switch benchmarking, not to inform about the
work-in-progress.
Reading further, I see text such as:
Specifications to be included in future updates of the LTD include:
o [RFC3918] Methodology for IP Multicast Benchmarking
o [RFC4737] Packet Reordering Metrics
or
When considering characteristics important to "telco" network
functions, we must begin to consider additional performance metrics.
or
Tests have been (or will be) designed to collect the metrics below:
On one side, I appreciate that you're publishing what you learned, which should
lead up to revisions in the future. On the other side, I've not been used to
that approach in BMWG. I'll trust the responsible AD regarding the publication
of this document as a kind of intermediary document.
I believe the document would be a better flow (and that some concerns would
disappear) if it would have the following structure
- benchmarking virtual switches is key in the industry today
- there are the virtual switches benchmarking specification today
- we worked on this with OPNFV (VSPERF). Great collaboration.
- this is a complex and evolving field:
compared to RFC 2544, we learn that ...
we realize that this is work in progress ...
- future plan: we will need to integrate more "stuff" in the benchmark,
such as RFC3918, RFC4737, additional perf metrics, you-name-it - we'll work
with OPNFV (and other groups) on this future plan.
Editorial
- Section 3.4. Flow timeout.
You mean the active timeout, section 2.2.23 in RFC 6645?
Should this section refer to RFC6645, or RFC 5470 (section 5.1.1)?
-
In addition to this, the LTD also re-uses the terminology defined by:
o [RFC2285] Benchmarking Terminology for LAN Switching Devices
o [RFC5481] Packet Delay Variation Applicability Statement
RFC5481 is already mentioned in the previous bullet list (The base performance
tests in the LTD are based on the pre-existing specifications developed by BMWG
to test the performance of physical switches. These specifications include). So
hopefully, it re-uses the terminology, right?
I'm not comfortable using the RFC series to describe the _progress_ of the Open Platform for NFV. This is orthogonal to the immutable nature of the RFC series as in a very short period the progress on the Open Platform for NFV will be different, and requiring a BIS or other revisions. Thus to "inform the industry of work-in-progress" (to quote the draft) is not something that I see as a part of the RFC series. I shall not stand in the way of publication and have balloted ABSTAIN. However, my advice is to seek other avenues for publication more in line with the white-paper that is draft-ietf-bmwg-vswitch-opnfv. ==-=-=-=-=- added comment I should also add that I have seen the response in relation to Alvaro's ABSTAIN, and that does not sway me. If you are interested in documenting the the test specifications that ARE implemented and any associated metrics, then that I think is a different document, especially when this document has such words as "Future/planned test specs include"...
I think this is a variation on the issue that Alissa calls out, but I'm having a hard time reconciling: It's unlikely that the virtual switch will be the only application running on the System Under Test (SUT), so CPU utilization, Cache utilization, and Memory footprint should also be recorded for the virtual implementations of internetworking functions. ...with... Further, benchmarking is performed on a "black-box" basis, relying solely on measurements observable external to the DUT/SUT. Please add text that clarifies how the metrics that 3.1 says should be recorded in section 3.1 relate to benchmarking.
Picking up on the thread that started with the Gen-ART review, I'm not clear on the position of this document when it comes to repeatability. If all of the parameters listed in Section 3.3 (assuming they apply) are configured and documented, is it assumed that the benchmarks will be repeatable and comparable with hardware implementation benchmarks? Or is the position of the document that the benchmarks are not likely to be repeatable/comparable in some (many?) cases, given the increase in complexity? Or that more work needs to be done (outside the specification process) to achieve repeatability? I think this needs to be more clear in the document.
I understand the debate about the publication of this document as an IETF consensus RFC. To me it seems valuable to publish and that this item is within the WG's charter. I think adding the updates necessary to make the document up-to-date with the Danube 3.0 release as suggested in the thread with Alvaro would be valuable.
draft-ietf-netmod-yang-model-classification
If there is a desire to change from "module types", which I agree is likely to be overused, an alternate term might be "module pedigree". Thank you for an excellent, clear, and useful document; I remember the confusion that generated this.
[Added comment on definition of SDO] My 2cents on the "type" discussion: The sentence in Section 1 Introduction does cause confusion "A number of module types have created substantial discussion" as it's describing the possible name duplication of a module in two different "layers", not types. Will read better if remove "types". I'm very surprised that Adrian on his reading did not question the use of "layers" to distinguish between services and network element modules. To me, with my layer hat on, this is very confusing. My suggestion would be to use the generic word "types" for "layers" and use "class" to distinguish modules which are standard, vendor, user. Vendor/user modules may/may not overlap with standard modules functionality-wise, they also may be modules with no interest to be standardized, so they are not necessarily associated with maturity/finer aging:-) I find the definition of SDO and vendor confusing. In the draft, it defines an SDO as published by a standards development organization. It provides the example of IETF, IEEE, MEF. It defines a vendor-specific module as "..industry consortia and opensource projects".."openly published". This is blurring the lines of SDO and industry consortia, e.g. MEF is a forum (industry consortia) whereas IETF and IEEE (and ITU) are SDOs. It's based on organizational criteria, and it's in the organization's description of their product e.g. standards, specifications. Some users don't care, others do. To prevent IETF from being pulled into the hornet's nest, suggest SDO be defined as only IETF, and separate labels for vendor and industry consortia (includes opensource/openly published).
Substantive: -4: That seems almost a challenge :-) But seriously, I dont know if it makes sense to discuss this sort of thing in this document-- but it seems like sensitivity of content might be a consideration when "typing" models. For example, models that include security credentials or keys. (An answer of "that's not what we are talking about" would be perfectly sensible.) Editorial: -1, " A number of module types have created substantial discussion during the development of this document including those concerned with topologies." I'm not sure I understand that sentence. Is the antecedent of "those" "module types", or "discussions"? Are we talking about network topologies? The section ends with "See figure 1". But that figure seems more related to section 2. Is the reference out of place?
I wonder if we can find a better word than "module types" because really both axes are types. Perhaps "module scope" or "module maturity"?
I'm not going to pick out a bike shed color, but I do support the assertions that "module type" is a bit too ambiguous. When I got to section 3, I had to go back to see what section 2 called its things, because "type" is so generic. There are some places where the unexpanded acronyms lost me (VRF, MEF, UNI) -- consider expanding these on first use.
draft-freytag-lager-variant-rules
Having somewhat followed the variants discussions in the IETF and ICANN, I have primarily learnt 2 things: 1: variants are subtle, complex, controversial and deeply political; and 2: John Klensin, Vint, Patrik and Andrew know way more about them than me, have thought deeply about both the problem space, and the political / long term implications; their opinion in this space should be respected. I have read the document, and, *as far as I understand it*, the technique / methodology in it seems reasonable and sane; however, the LC comments from John and Vint concern me, and I think that they really should be properly addressed - I'm hoping that there has been (possibly off-list) discussion regarding John's concerns? From my reading, the updates to the Introduction do not really address his issue. The response to the IETF LC was primarily John's (and some support of his position). Unless my search foo failed, I have not found much discussion on prior versions - this makes me concerned that this will be used to justify that variants are safe without much review or consensus from those schooled in the art. I do not feel technically qualified to be hold a DISCUSS on the document, and so I'm balloting ABSTAIN - *I* do not see support for advancing the document in the IETF, but understand that others may differ.
John's comment are partially based on misreading of the document. Various clarifications were done to the Introduction, so I believe this version addresses John's concerns. I am open to suggestions about whether 1) IESG should re-open the LAGER WG to process this document. (I closed LAGER last year because its done all work and this document wasn't on my radar.) or 2) Send this document to Nevil for processing in ISE.
I agree with Adam's top level comments. I also agree with Andrew's comments [1] and hope the authors adopt his suggested edits. [1] https://mailarchive.ietf.org/arch/msg/ietf/po47ZJR1xWuxFx_h-8IRTvYBTwo/?qid=42e9c225ee22ddb75ab2a412b597afce Some specific comments: Substantive: - Section 1: Is the term "applied for label" defined somewhere? I can infer the meaning from context, but it would be better to be explicit. -3: I'm confused by this section. Section 2 says that variant relationships are effectively symmetric and transitive, but then this section says some are not. Or more to the point, section 2 says that variant relationships are effectively equivilancies, and this section talks about relationships where that is not true. That seems like a contradiction. I note Andrew's comment that the sort of relationships contemplated in section 3 should be avoided, and the authors indication they would consider stronger language. Please count this as a vote in favor of that. -7, "In the former case we would like to allocate only the label OOO, but in the latter case, we would like to also allow the allocation of either the original label OOO ..." I assume that is an "example" policy for the sake of discussion. As written, it could be taken as general guidance. -11: The section starts out with " But what if we started from AOA", but then later says "O is the original scode point". Is the difference between "starting from" and "original" well defined somewhere? Editorial: General: I gather after quite a bit of reading that the authors intend the label placeholders herein have certain meanings, e.g. "O" for "original". At least, there are sections that seem to operate from that assumption. But I cannot find any text saying that explicitly. Along those lines, ar the mappings towards the end of section 7 intended to apply throughout the document? Again, some sections seem to assume that, but I don't see it stated explicitly. -1, "It tacitly assumes that any LGR will be expressed using the XML representation defined in [RFC7940] and therefore conform to any requirements stated therein." It's not tacit anymore once you say it :-) "However, the reader is expected to have some familiarity with the concepts described in that RFC (see Section 4)." Section 4 of that RFC, or of this document? -9: Does this section assume the mappings from section 7? (See general editorial comment above.)
- I found this in the shepherd write-up: "John Klensin's comments should be reviewed thoroughly since his conclusion is that the document should not be published in the IETF stream." Was this discussed? If there are actual concerns about the amount of review performed and limited attention to reach IETF consensus, maybe this document should go to the ISE instead? - I think the title could be extended e.g. Guidance on designing Label Generation Rulesets (LGR) supporting variant lables
I wouldn't be opposed to reopening LAGER to deal with the questions raised, per Alexey's comment.
I know enough about Unicode, IDN, and ICANN politics to know that I *don't*
know enough to usefully weigh in on John Klensin's suggestions to reconstitute
LAGER or send this document through the ISE.
That said, this document appears to describe a system for defining and
evaluating rules. I can see how the rules themselves might be problematic (this
document does not define any such rules), but I can't see how describing the
tools for creating and evaluating such rules would itself give rise to issues
directly. If the notion here is that we don't want to give people a language on
the premise that they might use that language to say problematic things, I
don't think I agree. If the objections being raised are more subtle than that,
then I'm afraid they're lost on me. I can't find ground to object.
Editorial comments:
This document seems to have the short version of the title ("Using Variants in
Label Generation Rulesets"), which appears on every page, swapped with the long
version of the title ("Variant Rules"), which appears on the front page (and
typically in external citations).
The introduction says "Section Section 7" (with a duplicated "Section").
I'm fine with this document advancing, but I think it would be better if folks who have commented on the document off-list would express their support for it on ietf@ietf (or another public list), assuming they do support its publication. The question of re-opening the LAGER working group seems like the wrong question to me; I think the real question is whether the document has undergone sufficient review and whether, among those who have reviewed it, IETF consensus to advance the document could be claimed. It sounds from the shepherd write-up as though a number of folks who were involved in the LAGER WG have reviewed the document, but if more review is needed then those reviews can be solicited without the need to re-open the WG. It's not as if the LAGER WG had a ton of participants when it was open anyway. So, I would say that more review, or notes to a public list about reviews already conducted, would be advisable to make a stronger case for publishing this as an IETF consensus document.