IESG Narrative Minutes
Narrative Minutes of the IESG Teleconference on 2016-05-19. 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: (none)
1 Administrivia
2. Protocol actions
2.1 WG submissions
2.1.1 New items
Telechat:
Telechat:
Telechat:
Telechat:
2.1.2 Returning items
Telechat:
Telechat:
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:
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
Telechat:
3.3.2 Returning items
3.4 IRTF and Independent Submission stream documents
3.4.1 New items
Telechat:
3.4.2 Returning items
1032 EDT 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. Working Group News
1034 EDT Adjourned
(at 2016-05-19 06:00:03 PDT)
draft-ietf-netmod-rfc6020bis
- I'm not sure I properly understand what the rpc and action statements really do, but can an action statement result in sensitive information being in a place in the model that previously only contained non-sensitive information? If so, does that warrant a mention in the security considerations, like the existing one about RPCs? (I mean the 3rd para of section 17.) - anydata (section 7.10) is new, right? Doesn't that mean that new kinds of stuff (that might be dangerous) can be found in a module? So if it's true that before yang 1.1 a parser only had to be careful to parse XML correctly, and if the addition of anydata means that a parser (via some extension mechanism) might now be parsing say images, (say via ImageMagick:-) then that'd likely create new potential vulnerabilities and might be worth a mention in section 17.
I reviewed YANG 1.0 in 2010. I am glad to see YANG 1.1 in IESG review! I think
this version is an improvement.
Nit:
9.12.4. Usage Example
The following is a union of an int32 an enumeration:
Typo: int32 *and* enumeration
In response to Suresh:
Section 9.4.7:
It is not clear why the following refinement is illegal. Can you clarify?
type my-base-str-type {
// illegal length refinement
length "1..999";
}
refinements must be more restrictive, 999 > 255 (the original length limit).
Meta comment:
Shouldn't this document obsolete RFC6020. There is no Obsoletes: tag in the
draft
Section 4.2.4:
s/A reference a data tree node/A reference to a data tree node
Section 9.4.7:
It is not clear why the following refinement is illegal. Can you clarify?
type my-base-str-type {
// illegal length refinement
length "1..999";
}
IANA considerations:
Not sure what is the correct method for doing this in -bis documents, but I
would have expected a note that instructs IANA to switch references to RFC6020
in IANA registries over to this one.
Dale's Gen-ART review warrants a response.
Following the discussion from Stephen's comments.
draft-ietf-sidr-rpsl-sig
one nit: "MUST reject the signature and threat the object as a regular" I think you mean `s/threat/treat` Misc comments: * Thank you for the very clear canonicalisation requirements! * For route6 objects, where two resource holder's signatures considered such that it might address the inability to properly sign the RPSL when one holder possesses the ASN and another possesses the prefix? (just a comment, nothing more)
Thanks all for chatting about my discuss, I think the outcome is good. --- OLD COMMENTS below, I didn't check 'em, feel free to chat more or not, as you think best. - If you keep the potential for http(s) URIs then I think more text is needed in the security considerations but it looks like you're taking that out for now so I guess that's ok. - 2.1, I don't see why it's useful to allow variation in the fields of the signature attribute e.g. why "MAY" the version not be 1st? - 2.1, "t=" and "x=" any limits on precision here? (Non-)support for fractional seconds can be a source for non-interop if not. The "All times MUST be converted to" is also actually a little ambiguous as you don't say to do that before signing;-) - 2.1, "a=" did you want a lowercase "must" there? - Are steps 2 and 3 in 3.1 order-sensitive? I think you might sometimes need to do 2 after 3, or re-do 2 maybe or else leading whitspace could be an issue. Maybe say that sometimes you need to do step 2 >1 time? - 3.1, oops, an ambiguity - in "The following steps MUST be applied in order..." does "in order" mean "in the order below" or "so as to"? I assume the latter. - 3.1: In general I think you'd be better if you pointed at specific bits of text in all the RFCs mentioned in 3.1 - it's maybe easy to get wrong otherwise, esp. if we don't yet have >1 implementation. - 3.1, step 6: names are all ASCII right? just checking - 3.2, step 1 - given 3.3 step 2, you're missing a step to "publish the cert" at the c= location as well.
Thank you for addressing my DISCUSS points.
I am also curious about the point in Stephen's discuss.
Thanks for a well-written document and addressing the SecDir review: https://www.ietf.org/mail-archive/web/secdir/current/msg06567.html
Al morton performed the opsdir review
draft-ietf-tsvwg-rtcweb-qos
A very well-written document! Thanks for all the work! One question: the doc says: "This specification [...] does not change any advice or requirements in other IETF RFCs. The contents of this specification are intended to be a simple set of implementation recommendations based on the previous RFCs." This sounds like an information doc for me. However, I'm okay with standards track as this should be consistently applied by WebRTC browsers. Just wondering if this was discussed (because it also reads like this change in scope was applied in a later phase of the live-time of this doc)?
I was a little surprised that there's no additional security considerations due to the fact that JS can set the application priority - isn't that different enough (from earlier uses of DSCP) that a browser might want to be a little suspicious if some JS wants to try send too much stuff as high priority, given that that same JS code might be running on many many browsers all at once for a while after some WebRTC server has been hacked? Or do we conclude that that won't make any real difference or make it easier for such JS malware to cause some kind of DoS somewhere?
Section 5: The draft claims that "Currently, all WebRTC video is assumed to be interactive" and makes a reference to [I-D.ietf-rtcweb-transports], but the referred draft does not contain any explanation regarding this. Is this some kind of well known fact in WebRTC circles? If so, is it documented somewhere? Section 8: Is this really required to be in the document? The shepherd writeup does explain the rationale for the downrefs.
I had the same comment as Alissa.
I agree with Stephen's comment.
I would suggest doing a pass through the document to check for uses of the term "browser" and "non-browser" to see if they could or should align with the terms defined in RFC 7742. It's not obvious to me why this document is using a different definition of "browser" than is used in that document.
still ok with it
draft-ietf-teas-interconnected-te-info-exchange
This document is terrifically helpful. Thanks for producing it.
I fully support Alvaro's Discuss and I was just in the process of deciding if I want to raise a Discuss or not when his ballot position came in. Even though this document is well written and provides a lot of interesting information, to be honest, I could not find any recommendation on a best current pratice as this document mainly takes about requirements for future work. For me this document provides a problem statement, use cases, and requirements as well as some survery about the applicability of existing protocols and therefore should be an Informational document.
I too share the confusion over the intended status. (And I agree with Alissa that this seems like an informational)
I believe this document would greatly benefit from clarifying the role of describing the "abstracting" from existing solutions, as discussed in Brian Carpenter's Gen-ART review thread. This will help explain why the document is a BCP rather than Inf.
Thanks for addressing the SecDir review: https://www.ietf.org/mail-archive/web/secdir/current/msg06560.html
First off, let me say that this is a very well written and informative document. I went back and forth when considering my ballot for this document. I decided to put in a DISCUSS for the IESG to talk about the Intended Status and whether anything needs to be done in the current document. My intent is to attract the attention of the IESG towards the Gen-art review (where the topic of the Intended Status first came up [2]) and the longer than expected thread [3] in the teas WG, where a couple of the authors have said that they don't know why BCP is the right answer [4] and [5]. By the time we get to the Telechat (tomorrow!) my comments may have already been taken over by events; if so, I will clear. If asked to decide I would have leaned towards Informational — there is lot of content describing the problem and an architecture (not a solution). I think Adrian made more persuasive points towards Informational (probably not his intent) in one of his messages to the teas WG [1]. The document does present the best thinking of the WG at this point, but I think it falls short of explicitly documenting the "the best way to perform some operations" [rfc2026]. In fact, the current way to implement the architecture is left to an Appendix. If the resulting Status remains as BCP (or even Standards Track), then I would like to support Brian Carpenter (Gen-art reviewer) in his request for the document to call out which sections are not normative (5 – Building on Existing Protocols and 9 – Scoping Future Work, are high on my list). This action shouldn't require more than a couple of sentences. Just to recap. This DISCUSS is for the IESG to talk… I don't expect any action from the authors at this point — maybe just help the IESG in the discussion… [1] https://mailarchive.ietf.org/arch/msg/teas/ql2RDMcvMZZU9KPKTdKijIqMtBA [2] https://mailarchive.ietf.org/arch/msg/gen-art/yDlSiKhKzkEhrXbuXSJtdYivhbc [3] https://mailarchive.ietf.org/arch/msg/teas/qMbaZkMi4iJMAzZPq8SYrxMmtPg [4] https://mailarchive.ietf.org/arch/msg/teas/aq8YSEDr6BP6V1MdN4ZNTJUQd4k [5] https://mailarchive.ietf.org/arch/msg/gen-art/kMwMDZ8nU8t4dKKI1ImN3l6YdbY
A couple of nits: s/one or more network/one or more networks "…the source domain does not know in which domain the destination node is located…this issue is obviously mitigated in IP networks by inter-domain routing [RFC4271]." For the definition of "domain" used in this document BGP is not the only inter-domain routing solution — and others may not mitigate the issue in the same way (but may of course use aggregation/abstraction to compensate). s/requested to to follow same path/requested to follow the same path
I too was wondering why this is listed as BCP rather than Informational.
watching the outcome of the state discussion, but I won't belabor the point. I think a clear case can be made of state other than informational on the basis that this is providing guidance to the rest of the teas effort.
draft-ietf-cdni-logging
While the security and privacy bits are much improved from earlier versions, I think I have found some holes. I assume these are not intentional, and it's entirely possible I have misread some things. But I would like to make sure they are considered prior to progressing. - 3.4.1, c-groupid: The privacy-related guidance about c-groupids indentifying individual clients (in the several bullet list entries with "-" bullets) seems contingent on the MAY in the parent (with the "+" bullet.) The parent says that you MAY structure the field so that parts identify the aggregate and one part aggregates the individual, with the sub-bullets following an "In this case..." clause. I assume the guidance is intended to apply even when an implementation doesn't structure c-groupid that way (or at all.) - 7.1: This section seems to effectively say that various protections are required when they are required. But it doesn't give advice on when they may be required. (For example, when c-groupid can be mapped to individual client addresses.) - 7.3: "Making detailed CDNI logging information known to the uCDN does not represent a particular privacy concern because the uCDN is already exposed at request redirection time to most of the information that shows up as CDNI logging information (e.g., enduser IP@, URL, HTTP headers - at least when HTTP redirection is used between uCDN and dCDN)." I agree this is mostly true for HTTP redirection. But as you mention, the assertion seems to fall down for DNS redirection, where the uCDN may have considerably less information. I think some different guidance for that case may be needed. -- "Transporting detailed CDNI logging information over the HTTP based CDNI Logging Interface does not represent a particular privacy concern because it is protected by usual IETF privacy-protection mechanism (e.g.,TLS)." I don't find normative text that says privacy-sensitive information MUST be protected. Just that information that needs to be protected MUST be protected. The reader is left to infer that privacy-sensitive information is covered by that. (See previous comment about 7.1). Without something explicit there, I think it highly likely that some people will rationalize that their deployments don't need protection for one reason or another.
- 3.3, 2nd to last paragraph: What does it mean to reject a logging file? Does
it mean to simply ignore it, or does it imply some notice back the source of
the file that there's a problem? (I tend to think of "reject" as implying the
latter in a protocol, in contrast to words like "drop" or "ignore".)
- 3.4.1, 3rd "-" bullet: "The algorithmic mapping and variation over time MAY
allow
the uCDN ... to reconstruct the actual client IPv4 or IPv6
address"
Is that intended to be a 2119 MAY or a statement of fact? If the former, it
seems to directly contradict the NOT RECOMMENDED in the next "-" bullet..
I still agree to the privacy concerns that have been raised earlier by Richard Barnes but don't see a solution that would justify a "DISCUSS" to hold up the document. Further I think it's important that TLS is mandatory and it could be useful to already state this earlier in the doc and not only Section 7.
Thanks for resolving my DISCUSS points. I will note that I don't think the issue with partial-time has been completely resolved, because the document still says it uses partial-time as defined in RFC 3339, and partial-time by definition does not have a time zone associated with it, whereas the document text now says all times are reported in UTC. Bit of a detail, but it might make sense to use full-time since you are specifying the time zone offset. There are probably other folks who know better than I do what standard practice is here.
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.
Thanks for your work on this draft. I've cleared my prior discusses. Although for the first one I would have preferred my suggested text over what you wound up with from the SecDir review after I had provided the suggestions just because I think it covers the points a bit more cleanly.
I know this document has long history and I want to get it done as well. Below is a list of small issues that I think need to be addressed: Is version directive value case-insensitive? The IANA registration is in lowercase, but all examples show uppercase. On page 28: SHA-3, AES-GCM and base64 all need normative references. (Use "Section 4 of [RFC4648]" for base64, as RFC 4648 defines 2 base54 encodings). On page 33: where does the "missing field value is denoted by -" specified in ABNF? If this is not defined in ABNF, it would be good to have an example record with a field missing.
In 7.1, last sentence: TLS only provides for protection from tampering when in transit, not when a log file being stored.
Thanks for the additional text in -22, which clears up the last of my discuss points. old comments below, I didn't check 'em - in the description of c-groupid, "the address with a shared secret that is pre-synchronised and rotated at a predefined time interval" isn't very clear. I know what you mean but I don't think you state it very clearly. Could be that a bit of text earlier in the document that describes the basic idea would be better than doing it all inline as you have in -21. OLD COMMENTS Below, not updated for -21, I didn't check if you took 'em on board, feel free to chat about 'em if that's useful - I'm happy to do so anyway. - 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? - 2.2.5.3: what's "track audience" mean? - 2.2.5.4: there are more security goals in the universe - 2.2.5.4: seems like the user is the enemy, that's odd - 2.2.5.6.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?
draft-ietf-cdni-footprint-capabilities-semantics
I agree with Alissa's discuss and comments (and transitively, Mirja's comments). Specifically, I agree that the object definitions seem like they should be PS, and that much of the motivational text seems like input to the working group process, not output from it. Additionally, I find the mix of using 2119 language for implementation requirements and requirements on protocol work confusing--especially in those sections where 2119 keywords are intermixed with the aforementioned motivational text.
I did enter enter 'No Objection' because non of my comments should hold up publication, however, I really would like to see another revision of this doc to make it easier to read and understand. 1) Intended status This documents contains two things a) Requirements (or here called Design Decision) for a FCI protocol b) Definition of the mandatory base object as well as needed registries While a) would clearly be an informational document, I would see b) rather as being a Standards track document. Further, the document reads as if b) was added late in the process. So my question is: was the intended status discussed in the working group and why was it decided to go for information? 2) footprint vs. capabilities I'm sure (I hope) these terms are well understood in the wg, however, for me it is still not clear why a footprint is not just a capability but something special. I understood that other capabilities can be bounded to a footprint, however, can this not also be true for other capabilities? E.g. a certain protocol is only supported for a certain content type... or something like this? Further, I still don't understand why you need a new term called footprint. In 2.2 you only talk about coverage which would be the better (more easy to understand) term for me. Also if you don't support something because of resource restrictions, this would still simple mean that you don't cover something. If those terms are well understand and use in the wg, I do understand if you don't want to apply any changes anymore here. However, for the readability it might be helpful to at least add a terminology section at the very beginning of the doc. 3) Reduce Redundancy I think it would help the readability if the requirements and the specification bits would be more clearly separated. I guess all requirements are listed and explained well in section 2. Therefore all reasoning given in the later section can simply be removed (and if needed replaced by a reference to the respective subsection in 2). Further, it's a little confusion that the requirements are phrased as if they should be addressesd in a future doc, while some of the requirements are already addressed in this doc by the given definitions. 4) Requirements a) It is mentioned a few times that the additional network load by sending these information must be limited to a reasonable amount, however, there is no explicit requirement in section 2 that is saying this. Would it make sense to add one more requirement here? b) Not sure if Focusing on Main Use Cases can/should actually be a requirement. The question might be rather but are the restrictions you will have by only focusing on the main use case/what cannot/does not have to be supported (overlapping coverage?)... however, that might only be a wording thing. 5) References: [RFC2818], [RFC5226], [RFC7230], and [RFC7525] should be informative, while potentially some of the innformative refernces, e.g. RFC6770, should be normative.
- I wonder if IETF participants know if the phrase "included in a standard adopted by IETF" used in the IPR declaration does or does not apply to this informational document? FWIW, I do not know. (We see this from time to time and mostly I think it's just a case of using company-standard IPR boilerplate and not considering informational and experimental RFCs, but who knows. I think I do recall one company modifying their IPR boilerplate before when this ambiguity was pointed out to them, so maybe if someone knows someone here, that'd be good info to pass on...:-) - section 4: I don't get why a full IP address is needed here, i.e. the v4 /32 or v6 /128. Why is that? And if it is needed, will it cause the usual CDNI privacy issue for a standards track document? - 7.5: the value "https1.1" is odd - would that really be used?
Note to IESG: This is now returning to IESG as PS (instead of Informational), please make sure that you are happy with that. As Stephen pointed out: is "http1.1" correct or should this be "http/1.1"? Similarly for "https1.1".
I agree with Alissa and Mirja's positions.
I also support Alissa & Mirja's discuss & comment points.
Thanks for updating the document status. Will re-review when it comes back to the IESG. Leaving my comment below since I haven't re-reviewed yet. (2) Section 4: "For all of these mandatory-to-implement footprint types ..." seems like a misuse of the term "mandatory-to-implement." I thought this section was specifying requirements for the FCI which is to be specified, but this implies that all conforming implementations would also have to implement all of the footprint types (country code, AS, and IP prefix). Has that already been decided as well? If so, it could be explained more clearly in the text.
Rick Ceasarez reviewed for opsdir
draft-ietf-aqm-eval-guidelines
I'm pretty sure I know what "steady state" means in this text The transmission of the non application-limited flow must start before the transmission of the application-limited flow and only after the steady state has been reached by non application-limited flow. but I'm not sure how someone using this specification knows what it means, and it's asking the user to do something specific during evaluation. Is there a reference or definition you could provide? (There are other uses of the phrase "steady state" in the document, and they would also benefit, but this is the use that needs the precision)
Too bad there are no implementations... :-(
Several issues from the Gen-ART review by Ralph Droms need to be addressed, in my opinion. In particular, Figure 1 or text under needs clarification, the advise on ECN seems superfluous, and section 10 example needs to be labeled as an example.
Has a RFC6390 performance directorate review done for the 2.X metrics? It should. See http://www.ietf.org/iesg/directorate/performance-metrics.html I guess that the metrics will be recorded in the future (See draft-ietf-ippm-metric-registry-06 ), right? For example, Flow Completion Time and Packet Loss Synchronization are new, I believe. And some other metrics are already documented in RFC6390 compliant documents. Pointers should be provided. See https://tools.ietf.org/html/draft-ietf-xrblock-independent-burst-gap-discard-01#appendix-A for an example
- Random Early Detection (RED), BLUE, and Proportional Integral controller (PI) Would you have references? - BDP is mentioned a few times. Please expand. - Glossary section = terminology section, right? If we want to be consistent across documents - section 12.2. Why not a MUST below? In order to understand an AQM's deployment considerations and performance under a specific environment, AQM proposals SHOULD describe the parameters that control the macroscopic AQM behavior, and identify any parameters that require tuning to operational conditions.
(1) In the abstract, I'm not sure "precautionary" is really the right adjective.
(2) Sec. 4.2 says: "However, the evaluation MUST be primarily based on
externally observed end-to-end metrics." This seems like a bit of a weird use
of normative language. It makes sense to me that you would normatively
recommend how to setup an evaluation environment to be able to compare AQMs,
but if people want to weigh their evaluations in the wrong the direction, there
is not much to be done about it. It seems like this would be more useful if it
focused on explaining why primarily focusing on e2e measurements is preferable.
(3) Overall I would recommend a pass through the whole document to check for
the consistency with which normative language is used -- it seems like in some
cases it isn't really necessary but it's there anyway, or its use is uneven
(e.g., 4.3.2, 5.2, 6.1, 6.2, 6.3, 7.2 to name a few). There also seems to be a
mix of normative statements about what proposals should say and how evaluation
environments should be setup. It would help if each time a normative statement
was made it clearly distinguished who the recommendation is directed towards.
This became especially confusing in Sec. 13, where it is unclear whether
"Scenario MUST be considered" means that an AQM spec needs to discuss this, or
an AQM evaluation environment needs to test for this.
(4) Since this document provides guidelines for how to characterize AQM
proposals, it seems inappropriate for it to be making normative recommendations
about how AQM proposals should work, even if they are just re-statements of
things from RFC 7567. In particular, these statements seem out of place:
- Sec. 4.4: "An AQM scheme SHOULD adhere to the recommendations
outlined in
[RFC7141], and SHOULD NOT provide undue advantage to flows with
smaller packets [RFC7567].
- Sec. 4.5: "Deployed AQM algorithms SHOULD implement Explicit Congestion
Notification (ECN) as well as loss to signal congestion to endpoints
[RFC7567]."
- Sec. 13: "Tuning SHOULD NOT be required"
(5) Sec. 4.6 says: "This discussion as an instance, MAY explain whether the
dropping policy is applied when packets are being enqueued or dequeued." I
don't understand what "this discussion as an instance" means.
(6) In Sec. 7.2, is there some justification that could be provided for
choosing the particular parameters listed to simulate web traffic? E.g., are
these parameters considered typical or is there a reference to some standard
way of simulating web traffic that could be referenced?
(7) Also in Sec. 7.2, why is the detail for the web flow given but the detail
for bursty video is not? Surely there is more than one way to generate or
simulate bursty video -- does it not matter what the bursts look like or how
they are timed for this measurement purpose?
(8) In 9.1, I would suggest that bi-directional video is prevalent and
important enough to be listed in the traffic mix analysis as well.
(9) I think the statement in Sec. 17 assumes that the tests envisioned by this
document will be based on active measurements of simulated traffic. If that is
a real scope limitation, and evaluation of AQMs based on passive measurement of
traffic is out of scope, I think that should be stated somewhere in the
document.
(10) Just curious: has anyone thought about using LMAP, or the LMAP information
model at least, to configure the kinds of tests envisioned in this document?
draft-ietf-aqm-pie
In section 5 and its children: Please keep in mind that "SHOULD" does not mean quite the same thing as "optional". It would be nice to see some text about the nature of the "experiment". That is, why is this experimental? Do you expect to promote this to a standard in the future? (The shepherd's report speaks of this; the draft should, too.)
Section 4.1:
QDELAY_REF is used here without definition. Suggest something like:
s/is smaller than half of QDELAY_REF/is smaller than half of the
target delay value (QDELAY_REF)/
Section 4.2:
Not sure what this piece of pseudo-code intends to achieve. Isn't this a no-op?
} else {
p = p;
}
Section 5.3:
What does the following text intend to say? Do you mean when it is turned off?
"When PIE is optionally turned on and off, ..."
Section 5.4:
The forced drop at 8.5/PIE->drop_prob_ packets is not consistent
with the pseudo-code in page 24. The drop_early() does not the
drop packets if the queue is not congested. Either the
pseudo-code or text in this section needs to be adjusted.
- Support Ben's comment:
It would be nice to see some text about the nature of the "experiment".
That is, why is this experimental? Do you expect to promote this to a
standard in the future? (The shepherd's report speaks of this; the draft
should, too)
ex: https://tools.ietf.org/html/rfc6614#section-1.3
- Minor personal preference: delay variation instead of jitter.
See https://tools.ietf.org/html/rfc5481#section-1 for a justification.
Btw, same comment for draft-ietf-aqm-eval-guidelines-11, which I forgot to
mention.
- Section 1
RFC2309 is obsolete:
RFC 2309[RFC2309]
strongly recommends the adoption of AQM schemes in the network to
improve the performance of the Internet.
Not sure why [RFC2309] is different than [IETF-AQM], which is now RFC7567. So
maybe using [RFC2309] was used on purpose.
- it seems that you sometimes interchange queueing latency, latency, delay,
queue delay For an example, review section 3 and section 4 first paragraph. You
should really use consistent terms, for example queueing latency, throughout
the document.
OLD:
As illustrated in Fig. 1, PIE conceptually comprises three simple MUST
components: a) random dropping at enqueueing; b) periodic drop
probability update; c) latency calculation. When a packet arrives, a
random decision is made regarding whether to drop the packet. The drop
probability is updated periodically based on how far the current delay
is away from the target and whether the queueing delay is currently
trending up or down. The queueing delay can be obtained using direct
measurements or using estimations calculated from the queue length and
the dequeue rate.
NEW:
As illustrated in Fig. 1, PIE conceptually comprises three simple MUST
components: a) random dropping at enqueueing; b) periodic drop
probability update; c) queueing latency calculation. When a packet arrives, a
random decision is made regarding whether to drop the packet. The drop
probability is updated periodically based on how far the current queueing
latency is away from the target and whether the queueing latency is currently
trending up or down. The queueing latency can be obtained using direct
measurements or using estimations calculated from the queue length and the
dequeue rate.
NEW:
Random Drop
/ --------------
-------/ --------------> | | | | | -------------->
/|\ | | | | |
| --------------
| Queue Buffer \
| | \
| |queue \
| |length \
| | \
| \|/ \/
| ----------------- -------------------
| | Drop | | Queueing |
-----<-----| Probability |<---| Latency |
| Calculation | | Calculation |
----------------- -------------------
- terminology: dequeue_rate or departure?
Section 4.2 =>"dequeue rate"
Section 4.3
current_qdelay = queue_.byte_length()/dequeue_rate;
Section 5.2 Departure Rate Estimation
Section 5.2 typo "Upon a packet deque:" (this one could fine if you speak
about the
deque(Packet packet) function, but that's not clear)
Again, be consistent across the entire doc.
- editorial: missing reference links
CBQ has been a standard feature in most network devices today[CBQ].
The controller parameters, alpha and beta(in the unit of hz) are
designed using feedback loop analysis where TCP's behaviors are modeled
using the results from well-studied prior art[TCP-Models].
- editorial:
This draft separates the PIE design into the basic elements that are
MUST to be implemented and optional SHOULD/MAY enhancement elements.
NEW:
This draft separates the PIE design into the basic elements that
MUST to be implemented and optional SHOULD/MAY enhancement elements.
Below is Mahesh's OPS DIR review:
I have reviewed the following 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.
Document reviewed: draft-ietf-aqm-pie-06
Summary: Ready with nits.
The document is on an Experimental Track. Perhaps because of it there is
little discussion of either operational or management considerations. If
the document progresses towards a standardization effort, the following are
(only a partial list of) suggestions or areas that can be explored. From a
deployment consideration perspective
The document could talk about how the technology is going to be
deployed or managed. It would help if the authors documented any
scaling issues that they have run into. How would this AQM co-exist
with other methods?
From an installation and initial setup perspective
The document could talk about how PIE would be configured. For the
parameters that are configurable, what are the ranges and what is the
default value. Are the parameters going to be configured by
configuration manager, or will the device pull the configuration from a
configuration server?
From a network operations perspective
The document could talk about the impact of PIE on existing networks,
with or without other AQM. While PIE attempts to reduce latency and
jitter, what is the impact on throughput when it is deployed, specially
for non-real time traffic?
From a verifying correct operations perspective
How does one verify that the network is behaving as expected once PIE
is applied? Other than latency and jitter, are there any other
parameters of interest? Will the test in itself have an impact on the
network or the protocol?
From a management interoperability perspective
The document can talk about any standard YANG models that might need to
be enhanced or developed for manageability across vendors.
From a fault or threshold conditions perspective
The document could talk about any notifications that need to be
reported for any events generated because of the algorithm. Should the
events be polled or could they be pushed? Would notifications have to
be throttled?
A run of idnits has revealed a few issues that will need to addressed.
tmp/draft-ietf-aqm-pie-06.txt:
tmp/draft-ietf-aqm-pie-06.txt(17): Found control character TAB in position 1.
tmp/draft-ietf-aqm-pie-06.txt(383): Found control character TAB in position 4.
tmp/draft-ietf-aqm-pie-06.txt(469): Found control character TAB in position 9.
tmp/draft-ietf-aqm-pie-06.txt(471): Found control character TAB in position 9.
tmp/draft-ietf-aqm-pie-06.txt(941): Line is too long: the offending characters
are '.' tmp/draft-ietf-aqm-pie-06.txt(978): Found control character TAB in
position 8. tmp/draft-ietf-aqm-pie-06.txt(982): Found control character TAB in
position 9. tmp/draft-ietf-aqm-pie-06.txt(1099): Found control character TAB in
position 7. tmp/draft-ietf-aqm-pie-06.txt(1101): Found control character TAB in
position 7. tmp/draft-ietf-aqm-pie-06.txt(1112): Found control character TAB in
position 4. tmp/draft-ietf-aqm-pie-06.txt(1126): Found control character TAB in
position 4. tmp/draft-ietf-aqm-pie-06.txt(1128): Found control character TAB in
position 4. tmp/draft-ietf-aqm-pie-06.txt(1182): Found control character TAB in
position 9. tmp/draft-ietf-aqm-pie-06.txt(1187): Found control character TAB in
position 9. tmp/draft-ietf-aqm-pie-06.txt(1189): Found control character TAB in
position 9. tmp/draft-ietf-aqm-pie-06.txt(1253): Found control character TAB in
position 7. tmp/draft-ietf-aqm-pie-06.txt(1254): Found control character TAB in
position 7. tmp/draft-ietf-aqm-pie-06.txt(1257): Found control character TAB in
position 7. tmp/draft-ietf-aqm-pie-06.txt(1258): Found control character TAB in
position 13. tmp/draft-ietf-aqm-pie-06.txt(1259): Found control character TAB
in position 7. tmp/draft-ietf-aqm-pie-06.txt(1260): Found control character TAB
in position 13. tmp/draft-ietf-aqm-pie-06.txt(1261): Found control character
TAB in position 13. tmp/draft-ietf-aqm-pie-06.txt(1263): Found control
character TAB in position 7. tmp/draft-ietf-aqm-pie-06.txt(1306): Found control
character TAB in position 4. tmp/draft-ietf-aqm-pie-06.txt(1325): Found control
character TAB in position 7. tmp/draft-ietf-aqm-pie-06.txt(1327): Found control
character TAB in position 4. tmp/draft-ietf-aqm-pie-06.txt(1328): Found control
character TAB in position 4. tmp/draft-ietf-aqm-pie-06.txt(1330): Found control
character TAB in position 4. tmp/draft-ietf-aqm-pie-06.txt(1352): Found control
character TAB in position 4. tmp/draft-ietf-aqm-pie-06.txt(1386): Found control
character TAB in position 9. tmp/draft-ietf-aqm-pie-06.txt(1391): Found control
character TAB in position 9. tmp/draft-ietf-aqm-pie-06.txt(1393): Found control
character TAB in position 9.
[Stuff deleted]
Checking boilerplate required by RFC 5378 and the IETF Trust (see
http://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
No issues found here.
Checking nits according to http://www.ietf.org/id-info/1id-guidelines.txt:
----------------------------------------------------------------------------
No issues found here.
Checking nits according to http://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
** There is 1 instance of too long lines in the document, the longest one
being 1 character in excess of 72.
** There are 31 instances of lines with control characters in the document.
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the IETF Trust and authors Copyright Line does not
match the current year
Checking references for intended status: Experimental
----------------------------------------------------------------------------
== Missing Reference: 'IETF-AQM' is mentioned on line 748, but not
defined
'[IETF-AQM] Baker, F. and Fairhurst, G., "IETF Recommendations...'
== Missing Reference: 'CoDel' is mentioned on line 730, but not
defined
'[CoDel] Nichols, K., Jacobson, V., "Controlling Queue Dela...'
== Missing Reference: 'CBQ' is mentioned on line 727, but not
defined
'[CBQ] Cisco White Paper,...'
== Missing Reference: 'FQ-Implement' is mentioned on line 739, but not
defined
'[FQ-Implement] Baker, F. and Pan, R. "On Queueing, Marking and...'
== Missing Reference: 'DOCSIS-PIE' is mentioned on line 736, but not
defined
'[DOCSIS-PIE] White, G. and Pan, R., "A PIE-Based AQM for DOCSIS...'
== Missing Reference: 'HPSR-PIE' is mentioned on line 742, but not
defined
'[HPSR-PIE] Pan, R., Natarajan, P. Piglione, C., Prabhu, M.S.,...'
== Missing Reference: 'PI' is mentioned on line 755, but not defined
'[PI] Hollot, C.V., Misra, V., Towsley, D. and Gong, W.,...'
== Missing Reference: 'QCN' is mentioned on line 759, but not
defined
'[QCN] "Data Center Bridging - Congestion Notification",...'
== Missing Reference: 'TCP-Models' is mentioned on line 762, but not
defined
'[TCP-Models] Misra, V., Gong, W., and Towsley, D., "Fluid-base...'
== Missing Reference: 'IETF-ECN' is mentioned on line 751, but not
defined
'[IETF-ECN] Briscoe, B. Kaippallimalil, J and Phaler, P.,...'
-- Obsolete informational reference (is this intentional?): RFC 2309
(Obsoleted by RFC 7567)
Summary: 2 errors (**), 0 flaws (~~), 11 warnings (==), 2 comments (--).
- Thanks to the IPR declaring folks for not using the term "standard" in their declaration. (I first looked at one of the earlier ones [1] that did say that, and I was about to start my usual whine when I noticed the most recent one [2] doesn't have that problem:-) [1] https://datatracker.ietf.org/ipr/2123/ [2] https://datatracker.ietf.org/ipr/2540/ - Seems odd to mention one specific vendor in the security considerations section. Why is that important to include?
Thanks for doing this work. In 4.2 and 4.4, it might help to explain how the default values were chosen, or point to where those are explained elsewhere.
Mahesh Jethanandani performed the opsdir review
draft-ietf-tls-falsestart
I concur with the "what is the experiment?" comments.
I'm a little confused by the experimental status given the shepherd write up. This is just a comment though...
For Stephen, yes, I noticed :-) In support of Kathleen's comment and based on the shepherd's write-up, why is this experimental and what is the experiment?
status-change-ip-versions-5-8-9-to-historic
conflict-review-gont-dhcpv6-stable-privacy-addresses
I'd like to chat about whether or not the IESG note ought say something about the fact that this (presumably?) used to be a DHC WG document. [1] Were the WG ok with this being sent to the ISE or were they asked if they were ok? If the WG were asked and don't care or are happy for it to be an ISE document, then that's fine, but in some other cases, maybe we ought ask the ISE to say something more in the IESG note. I see there is an "ISE writeup" [2] in the tracker, which is great (thanks Nevil) but that text doesn't answer the above. If there were a good answer that didn't need to be reflected in an IESG note then perhaps that'd be a fine place to record that for posterity. I suspect it'd also be good (for IPR reasons, if not IETF process reasons) if the "replaced-by" had been set to show that this submission used once be a WG document. [1] https://tools.ietf.org/html/draft-ietf-dhc-stable-privacy-addresses [2] https://datatracker.ietf.org/doc/draft-gont-dhcpv6-stable-privacy-addresses/shepherdwriteup/
General: The document contains instances of normative language such as "A DHCPv6 server implementing this specification must select the IPv6 addresses to be leased with the following algorithm" Suggest rewording to something like "A DHCPv6 server implementing this specification selects the IPv6 addresses to be leased with the following algorithm" Section 5: Security considerations Suggest adding the privacy assessment RFC as a reference in addition to the anonymity profile RFC. OLD: Please read [I-D.ietf-dhc-anonymity-profile] for a comprehensive assessment of the privacy implications of DHCPv6. NEW: Please read [RFC7824] and [RFC7844] for a comprehensive assessment of the privacy implications of DHCPv6.
I am interested in the results of Stephen's DISCUSS/