IESG Narrative Minutes
Narrative Minutes of the IESG Teleconference on 2016-03-17. 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: Alvaro
1 Administrivia
2. Protocol actions
2.1 WG submissions
2.1.1 New items
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
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:
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
Telechat:
Telechat:
3.4.2 Returning items
1032 EDT no break
4 Working Group Actions
4.1 WG Creation
4.1.1 Proposed for IETF Review
4.1.2 Proposed for Approval
4.2 WG Rechartering
4.2.1 Under evaluation for IETF Review
4.2.2 Proposed for Approval
5. IAB News We can use
6. Management Issues
Telechat::
Telechat::
Telechat::
7. Working Group News
1138 EDT Adjourned
(at 2016-03-17 06:00:02 PDT)
draft-ietf-tsvwg-circuit-breaker
Agree with Ben's Discuss point. Also Requirement 18 says for in-band "SHOULD" and "ought to" vs. Requirement 1's "MUST". Would prefer Requirement 1 be clarified by combining with Requirement 18. Prefer 18's requirement that an out-of-band control channel failure does not trigger the CB and disrupting traffic. May want to consider adding the ability to configure if a loss of the control channel should trigger the CB. Other technologies consider the loss of control protocol as a freeze on the bridge selector state. Also may want to consider adding the ability to configure a freeze of the CB for maintenance/operations.
- I agree with Ben's discuss. - Do the MPLS folks and similar agree with 6.1? If so, great. (And how did you figure that out?) If not, doesn't that make a big part of this BCP mythical? (Which would seem undesirable.) - 6.2, 2nd para: what question? - Section 7 (and earlier): You RECOMMEND a crypto mechanism to mitigate possible DoS. In both cases however, the statement is ambiguous. Are you RECOMMENDing a mechanism be defined or that one be used? (And of course if you asked me, I'd say that it'd be better to a crypto mechanism MUST be used, even when off-path attacks seem unlikely to work.)
= Substantive: =
- General:
-- [I moved the following here from my original DISCUSS position. I've cleared
the DISCUSS, since "discussion" has started and looks promising.] The rule 18
"out of band" section says loss of control messages SHOULD NOT trigger the CB.
But rule 1 said "The CB MUST trigger if there is a failure of the
communication path used for the control messages." These seem to be
contradictory normative requirements.
-- I'm surprised not to see much, if any, commentary about how endpoints are
expected to learn of and react to triggered CBs. Flows that just stop working
for no apparent reason will violate the principle of least surprise for users.
Users are likely to do exactly the wrong things (e.g. restart flows), unless
they are informed of why.
- 1, last paragraph:
-4, req 10:
What is meant be default here? Does this suggest that an implementation must
disable all traffic unless a user explicitly configures it to behave
differently?
- req 12: "... MUST be much more severe"
How do you measure that sort of requirement? Isn’t this already covered by 10
and 11 and 13?
- 5.1, last paragraph, last sentence:
Does this imply that circuit breakers can/will be stacked? If so, an explicit
mention of that fact early in the document would be helpful.
- 5.1.1:
Why not reference draft-ietf-avtcore-rtp-circuit-breakers ? (Informational
should be fine.)
= Editorial: =
-1, third paragraph: "Avoiding persistent excessive prevention ..."
Should that be "Avoiding persistent excessive _congestion_ ..."?
-- 5th paragraph, first sentence:
Is there a such thing as “normal excessive congestion?”
-- 8th paragraph: "This is to
ensure that a Circuit Breaker does not accidentally trigger following
a single (or even successive) congestion events (congestion events
trigger transport congestion control, and are to be regarded as
normal on a network link operating near capacity). "
I’m confused by this sentence. What is the subject of “are to be regarded as
normal”?
-- 10th paragraph, first sentence: Is this the same as saying that circuit
breakers should not trigger under normal conditions?
- 2nd to last paragraph, 2nd sentence:
In contrast to what? Not knowing the cause of congestion? (Are
contestion-controlled protocols expected to know the cause?)
-4, req 3: It would have been helpful to mention ECN (or forward reference it)
prior to the first mention of "lost/marked packets".
-- req 9: Isn’t this the point behind the last 3 (or more) requirements? That
is, it seems like this is the real requirement and those were more
implementation details.
- 5.1, first paragraph, 2nd sentence:
The sentence structure makes it look like you are using (TCP, SCTP, DCCP) as
examples of "applications that do not use a full-fledged transport", which is
obviously not the intent.
I agree with Ben's DISCUSS point.
linda.dunbar@huawei.com performed the opsdir review Simple protection can be provided by using a randomized source port, or equivalent field in the packet header (such as the RTP SSRC value and the RTP sequence number) expected not to be known to an off-path attacker. Stronger protection can be achieved using a secure authentication protocol. This attack is relatively easy for an on- path attacker when the messages are neither encrypted nor authenticated. When there is a risk of on-path attack, a cryptographic authentication mechanism for all control/measurement messages is RECOMMENDED to mitigate this concern. By on-path attacker we mean service provider. As with for example HLS (which is congestion controlled), and which ISPs particularly wireless carriers then deliberately degrade; Providing a protocol with a well understood mechanism for shutting it down can be used to do so maliciously without imposing a strict firewall policy. that's convenient for plausible deniability. I wonder if the technical response from implementors isn't to wrap the flow in something harder to inspect. The discussion of a multicast circuit breaker seems largely anchored in SSM with respect to there being one (reliable) sender. In the ASM case it seems trivial for a malicious sender to cause all the other parties to leave the group by misreporting it's own sending properties (and do so with very few packets).
draft-ietf-opsawg-hmac-sha-2-usm-snmp-new
While it certainly passes compilation, the MIB module doesn't display nicely.
Ex:
usmHMAC128SHA224AuthProtocol OBJECT-IDENTITY STATUS current DESCRIPTION
"The Authentication Protocol usmHMAC128SHA224AuthProtocol uses
HMAC-SHA-224 and truncates output to 128 bits." REFERENCE "- Krawczyk,
H., Bellare, M., and R. Canetti, HMAC: Keyed-Hashing for Message
Authentication, RFC 2104. - National Institute of Standards and
Technology, Secure Hash Standard (SHS), FIPS PUB 180-4, 2012." ::= {
snmpAuthProtocols 4 }
Please fix this before submitting.
draft-ietf-ccamp-otn-signal-type-subregistry
Updated from Last Call version for Secdir review.
The Shepherd's writeup should be updated. The document doesn't register any new types, it just updates the registration policy. I find the description of the updated registration policies confusing. The text reads: "…updated with the following registration policies: "Standards Action" and "Specification Required"…" What does the "and" of these two policies mean? I see [1] that the WG Chair had proposed: "IANA section needs to be updated indicating the registry and the following registration policies: "Standards Action" (for Standards Track documents) and "Specification Required" (for other documents). ", but even though there were only positive comments in reply, the document did not adopt that text. It might be just me who finds the current text not obvious as IANA seems to not have a problem with it either [2]. [1] https://mailarchive.ietf.org/arch/msg/ccamp/4PRR2n5zqABNrDMhJje_raPE6Qw [2] Message sent to the authors and IESG only.
I had a DISCUSS on the registration policy, but Lou has put forth this alternative, which comes from earlier discussions: "Standards Action" for Standards Track documents, and "Specification Required" for other documents. The designated expert is any current CCAMP WG chair or, in the case the group is no longer active, designated by the IESG. Happily clearing the DISCUSS with that text on the table. Thanks.
draft-ietf-mmusic-proto-iana-registration
Some editorial comments from Meral's Gen-ART review might be useful to address. Have the authors seen those?
Sarah Banks performed the opsdir review.
draft-ietf-dprive-dns-over-tls
Many thanks for doing this work. I look forward to using DNS in this way. I had a discuss but the changes indicated at [1] are plenty good. [1] https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-dprive-dns-over-tls-07.txt&url2=https://raw.githubusercontent.com/paulehoffman/draft-hzhwm-dprive-start-tls-for-dns/master/draft-ietf-dprive-dns-over-tls.txt
I'm balloting yes, but I do have a few comments/questions: - 3.1, third paragraph: This seems to put normative requirements on clients and servers that do not implement this draft. If that is really needed, then perhaps this needs to update the appropriate base spec(s)? - 3.2, last paragraph: That's a bit of an odd use of SHOULD. I suggest s/SHOULD/can - 3.3: This section seems more about DNS over TCP in general. Is it specific to TLS? Are the 2119 keywords in this section new requirements, or do they describe existing requirements from 5966/7766? (If the latter, please consider stating them with descriptive language rather than normative language.) - 4 and subsections: There seems to be a notable absence of a profile that requires server authentication but does not require pinning. I assume there's a good reason for that which is obvious to people with stronger TLS and/or DNS backgrounds than mine. But it might be helpful to say why. Do (or should) the profiles have anything to say about clear-text fallback if a client cannot connect to the server's DNS-over-TLS port, or the TLS handshake fails? I infer that such fallback should not occur with the pinned profile, but what about the opportunistic profile?
-- Section 3.1 -- A DNS server that supports DNS-over-TLS MUST listen for and accept TCP connections on port 853. By mutual agreement with its clients, the server MAY, instead, use a port other than 853 for DNS-over-TLS. Is it really "instead" (in which case the previous sentence isn't unqualified "MUST"), or is it "in addition? That is, which of these is correct?: NEW-1 A DNS server that supports DNS-over-TLS MUST listen for and accept TCP connections on port 853. By mutual agreement with its clients, the server MAY, in addition, use a port other than 853 for DNS-over-TLS. END NEW-2 A DNS server that supports DNS-over-TLS MUST listen for and accept TCP connections on port 853, unless it has mutual agreement with its clients to use a port other than 853 for DNS-over-TLS. END (And similarly for the client side in the following paragraph.)
I am a definite Yes on this work, but just have a couple of comments... * Section 3.1 says "By mutual agreement with its server, the client MAY, instead, use a port other than port 853 for DNS-over-TLS. Such an other port MUST NOT be port 53..." It would be useful to *briefly* explain the MUST NOT. If it is by mutual agreement, what's the harm? * Section 3.2 uses the SPKI acronym before it is expanded in section 4.2. * I do not understand the last sentence of section 3.2, especially the "SHOULD".
draft-ietf-cdni-redirection
The basic idea of the uCDN sending everything to the dCDN so that the dCDN can reply with all the details of a request that'll work (i.e. the sc-* stuff) seems broken as it requires that the uCDN expose all security and privacy sensitive data to the dCDN in pretty much all cases. I fail to see why that is an acceptable approach. Can you point me at where the WG disucssed the issues with that approach and considered less security/privacy unfriendly potential alternatives? Some examples: - section 4.1 says "SHOULD convey as much information as possible" that is surely wrong - there is no reason to encourage sending cookies and other security/privacy sensitive information and in fact sending such should be discouraged (SHOULD NOT) or even, if possible, prohibited (MUST NOT). - The cs-(cookie) in 4.5.1 is one specific case of sending too much. - 4.4.1 Resolver IP addr is liable to be that of an end user's machine (if they operate a recursive). But the examples are just that, I'd like to DISCUSS the WG's consideration of the overall design first before we dive into those.
- I support Alissa's discuss points. - section 3: false-negative? don't you mean false-positive? And in any case, those warnings are not false from the browser perspective. I'd suggest s/false-negative// - section 3: phrases like "trusted re-direction" are a bad idea - you need to say who is trusting whom for what for this to be meaningful and not misleading (people get misled by such phrases all the time). I'd just delete the sentence or s/trusted// - 4.4.2: a JSON "string" is not the same as a DNS name is it? What about i18n? (ULABEL or ALABEL?) what about odd characters allowed in JSON but not in DNS names? In general the fields in this dictionary (and others) seem underspecified to me.
I have a few comments and questions:
# Substantive: #
- 3, last paragraph: "Any operational
mechanisms this requires, e.g., private key distribution to
surrogates and request routers in dCDNs, are outside the scope of
this document. Further mechanisms to notify User Agents of trusted
redirection are also outside the scope of this document."
Is it in scope _somewhere_? As it is, this seems like an excuse to avoid HTTPS,
which is not optimal.
-4, first paragraph:
Was any thought given to using or supporting HTTP/2?
-- step 1 after figure 1:
I am I correct to infer an assumption that CDN A acts as the UAs DNS server? Is
that assumption documented somewhere?
- 4.2, last paragraph (note)
This explicitly makes an IPv6 only CDN non-compliant. Is that the intent?
- 4.4.1, table, entry for dns-only:
The description says "MUST include RTs". That doesn't seem to consider error
cases.
- 4.8, 3rd and 4th paragraph:
I'm curious why they SHOULDs are not MUSTs. Are there times it might be
reasonable to do something different; maybe even choosing not to send an error
at all? I wonder if these should be of the form of "MUST send an error which
SHOULD be XXX"
-5.1, 2nd to last paragraph:
" In an environment where any such protection is required...," is a pretty weak
recommendation. Would you consider making the default behavior secure? Or at
least saying something to the effect of "Except in networks where similar
protections are provided by some other means,..."?
-5.2, First paragraph:
I have trouble imagining situations where information passed over the RI might
not be sensitive. -- third paragraph: I wish the text wasn't so dismissive of
attempts to anonymize some RI request data. I agree doing so may reduce RI
effectiveness in some cases. But that needs to be balanced with privacy needs,
and that balance may not always land on the side of RI effectiveness. And the
inability to correlate UAs between requests can be a feature in some
circumstances.
# Editorial: #
- General:
There's quite a bit of repetition and redundant text, including redundant
normative text.
- abstract:
s/"The Request Routing Interface..."/ "The Content Delivery Network Interface
(CDNI) Request Routing Interface..." s/"comprises of"/"comprises"
- 4, 2nd paragraph: "The same HTTP interface is used for both DNS and HTTP
redirection of User Agent requests,..." From the rest of the sentence, I assume
this means the RI uses the same interface to communicate information about DNS
and HTTP redirects—but the first part sounds like it is saying that the actual
redirection (i.e. interacting with the UA) occurs over the same interface.
-- 4th paragraph:
s/"try and"/"try to"
- 4.1, 2nd to last paragraph: "... signaled the HTTP response body
of the RI response ..."
Missing word? (perhaps "... signaled in the HTTP response body ..."
-4.2, paragraph 4:
This paragraph is redundant to section 4.8.
-4.5.1, last paragraph before example: "For example, it MAY only
send the contents of the first occurrence of the HTTP Headers
instead."
s/MAY/might.
(1) There is some ambiguity in the document about whether the uCDN passes the IP address of the UA or its prefix to the dCDN. Sec 4.4.1 says that for DNS redirection, the uCDN passes "IP address or prefix" of the UA, but then in the definition of resolver-ip specifies it only as the IP address of the UA. Then in Sec 4.5.1 for HTTP redirection the equivalent field is specified as the IP address of the UA and the possibility of sending only a prefix is not mentioned. Then 5.2 has the para that begins "While it is technically possible to mask some information in the RI Request, such as the last bits of the UA IP address ..." which makes it seem like prefixes really shouldn't be sent. I think the document needs some consistency and clarity here about whether prefixes are expected to be used for either redirection method. It's also not obvious to me why the document shouldn't recommend to uCDNs that if they are polling multiple candidate dCDNs as described in Sec 5.2, they should use only a prefix for such requests. The arguments given against this seem pretty thin -- isn't preventing correlation of multiple requests to a single UA a good thing, especially when it's being done by a bunch of dCDNs? And I don't understand the CGN example -- isn't the root of the problem here that topologically dispersed UAs are sharing the same public-facing IP address, in which case the dCDN may have the same problem when passed a full IP address as it does a prefix? (2) Ben noted the weakness of the recommendation in 5.1 regarding TLS. I see that the language here is the same as it is in draft-ietf-cdni-logging-22. But I thought the agreement on that document was MUST use TLS, full stop. So there is ambiguity in both documents I think. "In an environment where ..." and "When TLS is used ..." seem inconsistent with "TLS MUST be used ...." I'm happy to clear on this if I'm missing something from the previous discussion, which I think happened when I was on leave and resulted from one of Stephen's ballots.
draft-ietf-netext-pmipv6-flowmob
The shepherd write-up says: "Have a significant number of vendors indicated their plan to implement the specification? No. The relevance of flow mobility at the present time is suspect. While there is some adoption of Proxy Mobile IPv6 by the industry, there is no real demand for flow based mobility." I wondered why this is then being frozen into an RFC? That can be the right thing to do sometimes, but the above does make it seem questionable. So I'm asking:-) And did you consider if an experimental RFC would send the right signal?
draft-ietf-netmod-yang-json
- I would have thought that it'd be useful to point out any issues with round-tripping, e.g. going from XML to JSON and back to XML or vice-versa. But I didn't see any mention of that. How come? - I'm not sure if anyone has considered XMLDSIG or use of JOSE with YANG. If one did, then this kind of mapping would not allow one to preserve digital signatures without a lot of work. I assume that that's considered ok. (Which it can be, depending on how one does object level security, if one does object level security.) - It's not clear to me if the discussion of the secdir review [1] concluded. It seemed to just stall. Is there more to be said? (If so, be great if the shepherd would kick that discussion.) [1] https://www.ietf.org/mail-archive/web/secdir/current/msg06408.html
draft-ietf-netmod-yang-metadata
Section 9: You could maybe add a sentence recommending to not store security or privacy sensitive information in annotations (unless it's really needed).
draft-wallace-est-alt-challenge
Thank you for a concise and clearly written document as a individual submission.
There are 3 DownRefs that were not called out in the Last Call (only one of them appears in the registry).
Elwyn's Gen-ART review brought up a downref issue which Stephen suggest we handle as follows: > 2985 is a normative reference in 5750 which is standards track > so I think we can safely claim precedent and I can put 2985 in the > downref registry if nobody objects. Which I think is fine.
draft-ietf-i2rs-architecture
Hi there, Firstly, I support Alvaro's two significant comments, especially with regards to the outcomes of the I2RS initiated change. My reading of the draft is that the resulting architecture espouses to judge intent, or the very least the outcome of the intent, as safe. How? Apologies if I read more into this than intended, please help clarify. I only saw one nit that hadn't been noticed in other comments. Section 3: para, last sentence. "may may" Thanks
- If i2rs were used to control home networks, then that would raise more privacy issues, e.g. the agent's IP address can be privacy sensitive. Would it be useful to rule that out of scope? E.g. to say that i2rs SHOULD NOT be used where the agent/router in question is specific to one person or home? - section 2: security role, hmm..... Do netconf/restconf have the concept of mapping identifiers to roles? If not, that might be tricky to graft on. Not sure. - section 4: "Mutual authentication between the I2RS Client and I2RS Agent is required. " yay! thanks:-) Even better if you did s/Mutual/Strong mutual/ to prevent someone saying that TCP-MD5 is good enough. - section 4: "The primary communication channel that is used for client authentication and then used by the client to write data requires integrity, confidentiality and replay protection." yay! again! :-) - section 4: "Other communications via I2RS may not require integrity, confidentiality, and replay protection. For instance, if an I2RS Client subscribes to an information stream of prefix announcements from OSPF, those may require integrity but probably not confidentiality or replay protection." sorry, boo! :-) It's often unsafe to mix and match differently protected sets of data between the same sets of entities. I think you'd be better off there saying that the requirements may *exceptionnally* differ but usually only because of e.g. some level of broadcast or multicast being part of the story, where we don't have good usable security solutions today. (This is not a DISCUSS because I think the protocol work will end up saying "just use TLS always" as that'll be simpler and better, so I hope this'll be a non-issue. If you know already that there's some other plan in place, then please say so we can chat now and avoid a trickier discussion later.) - section 4: I think you're heading here towards use of TLS and not object level security. Is that right? If so, would it be useful to say so? (Just so as to correctly set expectations for later.) - 7.7: Would it be useful to say that the relevant information here is only about network state and stastics and not about connections (e.g. who spoke to whom) or payloads? That might save some discussions about RFC2804 later on.
I have some comments; I would consider the first two as significant/major, while the others are minor comments and nits that came up as I was reading (not always linearly). A. There are a couple of places where operations are characterized as "safe" (1.1 and 6.4.1 — see below), but no explanation as to what "safe" means. It seems to me that these mentions of "safe" go beyond authentication and even authorization to perform a specific operation, to the content of the operation itself. I would like to see some discussion about how to achieve it, and/or (at least) what the impact may be. - 1.1: "I2RS will only permit modification of state that would be safe, conceptually, to modify via local configuration; no direct manipulation of protocol-internal dynamically determined data is envisioned." - 6.4.1: "Routing elements may maintain one or more Information Bases. Examples include Routing Information Bases such as IPv4/IPv6 Unicast or IPv4/IPv6 Multicast. Another such example includes the MPLS Label Information Bases, per-platform or per-interface or per-context. This functionality, exposed via an I2RS Service, must interact smoothly with the same mechanisms that the routing element already uses to handle RIB input from multiple sources, so as to safely change the system state. Conceptually, this can be handled by having the I2RS Agent communicate with a RIB Manager as a separate routing source." B. Section 3. (Key Architectural Properties) says that "some architecture properties such as performance and scaling are not described below because they are discussed in [I-D.ietf-i2rs-problem-statement]". However, as I mentioned in my review of I-D.ietf-i2rs-problem-statement [1], that document has a very, very sparse treatment of performance and scalability to even attempt to call it a "Key Architectural Property". C. Section 1.1. (Drivers for the I2RS Architecture) says: "I2RS is described as an asynchronous programmatic interface, the key properties of which are described in Section 5 of [I-D.ietf-i2rs-problem-statement]." Why isn't I-D.ietf-i2rs-problem-statement a Normative Reference? It is considered to define the properties of the I2RS which are used in building the architecture. D. Section 4 (Security Considerations) mentions the "I2RS security requirements", but there is no reference to draft-ietf-i2rs-protocol-security-requirements. E. s/I2RSS/I2RS F. There's a orphan "In addition, the" in 1.2. G. Systems and sub-systems. The text mentions "routing system", "Internet routing system" and "routing subsystem" many times (obviously!), but there is no description of what these terms mean — I'm sure many/most of the readers have an opinion of what these are, but I think it might be good to add something to the terminology section specially because statements like this are made: "state on a routing element beyond what is contained in the routing subsystem"; that way there is no questions as to what is in the routing system, or sub-system and what is not (at least for this document). H. 3.2. (Extensibility) talks about the initial scope of I2RS (without references). To extend the usability of this document, I would suggest that the statements of this section be made independent of the fact that the initial scope may be narrow. IOW, I think you may want the protocol/data model to be extensible regardless of the size of the initial scope (even if boiling the ocean to start with, there will always be opportunities for extensions later). I. s/an definition/a definition J. If out of scope, I don't really see the value of 5.1. (Example Network Application: Topology Manager). However, Section 5 does say that these types of "models are, at least initially, out of scope for I2RS" -- as I mentioned above, if this architecture is meant for the long run (not just the initial scope of the i2rs WG), then the 3rd architecture is valuable to illustrate. IOW, the WG charter can control the scope, the architecture should be thought out for the long term. K. s/to be to be/to be L. Many protocols (routing-related and otherwise) are mentioned without references. M. I don't think you need both of these references: "Yang 1.1 ([RFC6020]), Yang 1.1 ([I-D.ietf-netmod-rfc6020bis])". [1] https://datatracker.ietf.org/doc/draft-ietf-i2rs-problem-statement/ballot/#alvaro-retana
Russ Housley's Gen-ART review raised the following question and editorial comments. I believe it would be useful for the authors to think about the question at least, but I have not seen a response yet: --- Minor Concerns: Section 4.2 talks about authorization. I would expect policy to dictate that some writes come from a specific source, but it is unclear to me whether I2RS can require that a particular write request arrive on a particular channel. Is this desirable? If so, please expand the discussion of authorization to cover this point. Nits: Sometimes you say "i2rs architecture", but it should say "I2RS architecture" to be consistent throughout the document. Sometimes you say "I2RS Agent" and other times you say "I2RS agent". Please pick one and use it consistently. Sometimes you say "I2RS Client" and other times you say "I2RS client". Please pick one and use it consistently. Section 3: s/ may may vary based / may vary based / Section 6.3: s/ the yang data model / the YANG data model / Section 6.4.2: some bullets have periods, but others do not. Section 7.1: s/ Yang / YANG / (more than one place)
A couple of points, not all of them are minor (I've been wondering: COMMENT or
DISCUSS. Let's go for a COMMENT)
- "Second is the access to structured information and state that is frequently
not directly configurable". I have a hard time reconciling the NETMOD state
definition, for example from
https://tools.ietf.org/html/draft-ietf-netmod-opstate-reqs-04 It would be good
if the terminology were aligned.
-
This I2RS architecture assumes a data-model driven protocol where the
data-models are defined in Yang 1.1 ([RFC6020]), Yang 1.1
([I-D.ietf-netmod-rfc6020bis]), and associated Yang based model
drafts ([RFC6991], [RFC7223], [RFC7224], [RFC7277], [RFC7317]). "
RFC 6020 is YANG 1.0, not YANG 1.1
I2RS is YANG 1.0 or YANG 1.1? I hope YANG 1.1
btw, this "YANG" not "Yang"
- Are the two sentences redundant?
As can be seen in Figure 1, an I2RS client can communicate with
multiple I2RS agents. An I2RS client may connect to one or more I2RS
agents based upon its needs.
-
There are several key benefits for I2RS in using model-driven
architecture and protocol(s). First, it allows for transferring
data-models whose content is not explicitly implemented or understood.
Reading that second sentence multiple times, I still fail to understand.
Model-driven on one side, but you want data-models whose content is not
explicitly implemented or understood. Really confused.
-
Two of the existing protocols which the
which may be re-used are NETCONF [RFC6241] and RESTCONF
[I-D.ietf-netconf-restconf].
"may be reused". What does it mean? I was hoping that an architecture documents
would at least tell me which protocols are used. On my side this architecture
is flexible (NETCONF or RESTCONF), on the other side unclear (YANG 1.0 or
YANG1.1), and in some cases, a complete specification (for example the
notification)
To handle I2RS Agent failure, the I2RS Agent must
use two different notifications.
NOTIFICATION_I2RS_AGENT_STARTING: This notification signals to the
I2RS Client(s) that the associated I2RS Agent has started. It
includes an agent-boot-count that indicates how many times the
I2RS Agent has restarted since the associated routing element
restarted. The agent-boot-count allows an I2RS Client to
determine if the I2RS Agent has restarted. (Note: This
notification will be only transmitted to I2RS clients which are
know in some way after a reboot.)
- editorial:
Optionally, a routing element may permit a priority to be to be
-
For the case when the I2RS ephemeral state always wins for a data
model, if there is an I2RS ephemeral state value it is installed
instead of the local configuration state.
Again, I read that sentence multiple times, and could not understand it
- figure 2. "The initial services included in the I2RS architecture are as
follows." Are these really the initial services for I2RS. I2RS is really
dealing with all these: interfaces, policy, QoS, ... Maybe I should review the
I2RS charter?
-
The I2RS
protocol may need to use several underlying transports (TCP, SCTP
(stream control transport protocol), DCCP (Datagram Congestion
Control Protocol)), with suitable authentication and integrity
protection mechanisms
Do you really want to have define transports?
And below is Fred Baker's OPS DIR review:
The first nit is a statement in section 1.1:
Such an interface also facilitates the injection of ephemeral state
into the routing system. Ephemeral state on a router is the state
which does not survive a the reboot of a routing device or the reboot
of the software handling the I2RS software on a routing device.
Ephemeral state is state that is "ephemeral", which my dictionary tells me
means that it is "short-lived, transitory, lasting a short time". This comes to
mind because of a paper I discovered I was a co-author on (story in the
presence of adult beverages) last year, which suggested that congested links in
a network could be offloaded by directing a subset of the routes, or a subset
of the traffic using those routes, using them to other links that a routing
protocol might contend were below par but which provided a non-looping path and
had available capacity. The issue was that when routing changed for any reason,
these SDN changes had to be undone and redone, a process that could take (in
the network of interest) on the order of 40 minutes. My suggestion to my
"co-authors" was that they simply change the FIB (which is by definition
ephemeral), so that should routing change the FIB would became predictably
correct (e.g., with no such optimizations added to it) after having
re-converged, and they could now re-optimize the FIB as they saw fit without
incurring a potential outage.
I would suggest that the above reference to a reboot be changed to "Ephemeral
state on a router is state that changes from time to time". A reboot is only
one of those times.
At the top of page 6, the first paragraph reads:
The I2RS agent provides read and write access to selected data on the
routing element that are organized into I2RS Services. Section 4
describes how access is mediated by authentication and access control
mechanisms. Figure 1 shows I2RS agents being able to write ephemeral
static state (e.g. RIB entries), and to read from dynamic static
(e.g. MPLS LSP-ID or number of active BGP peers). In addition, the
I have a hunch the authors intended to complete the final sentence.
In section 3.1, which comments on "simplicity", I am very much in favor of
simplicity in the sense described by RFC 3439. That said, I think the paper
misses the mark by a few millimeters. It says
Thus, one of the key aims for I2RS is the keep the protocol and
modeling architecture simple. So for each architectural component or
aspect, we ask ourselves "do we need this complexity, or is the
behavior merely nice to have?"
Often, simplicity is not about whether a feature is itself complex, but about
whether what is externalized is complex. Theorists dealing with complexity use
a swimming duck as an example: viewed from above the water line, the duck is a
picture of placidity in motion, while when viewed from below its paddle feet
are madly beating the water. A communication example is in TCP; heaven only
knows what is really happening in the network, but TCP narrows the entire
discussion into two signal classes - in this RTT, it has received a congestion
signal, or it has not, and it has either received acknowledgements indicating
forward progress in the session, or it has not. From the application's
perspective, there is sufficient forward progress to merit continuing the
session at whatever rate it is able to proceed, or progress is inadequate.
Within TCP, there is actually a fair bit of complexity. However, what it
externalizes to a client application is dead simple.
So I would go beyond "do I need this complexity" to "do I need for this
complexity to be externalized, do I need it at all, and if I need it, is there
a way to meet the need with a simpler external API?"
In section 4 and 4.2, I'm concerned about the issues of authorization "for
classes of statements", which are mentioned obliquely but not really gone into.
My personal bugaboo in this context is the router I use at my home, which is
functionally equivalent to two separate routers coexisting in a single chassis.
One router connects my home office to my employer using a VPN, and the other is
a very typical residential CPE. We have similar issues whenever a router has
multiple routing tables or contains multiple virtual routers. When I read
An I2RS Client is not automatically trustworthy. Each I2RS Client is
associated with identity with a set of scope limitations.
I read "scope limitations" as a reference to "authorization", but I think this
concept needs to be fleshed out more. An I2RS client (or the server it serves),
perhaps on an interface, has a set of information, which may be complete, null,
or anywhere in between, for which it is trustworthy, and it is not trustworthy
for anything else. In a network like my home, I could imagine a route
controller operated by my employer's IT organization and another operated by me
or by my ISP on my behalf. If a single system contains multiple clients or
serves multiple servers, that difference of authorization can be important. We
understand that in some detail in BGP; it needs to be handled in I2RS as well.
I'm happy to leave this to the INT and RTG ADs. I have no objection after a quick run-through.
In this text: 7.1. One Control and Data Exchange Protocol The I2RS protocol may need to use several underlying transports (TCP, SCTP (stream control transport protocol), DCCP (Datagram Congestion Control Protocol)), with suitable authentication and integrity protection mechanisms. These different transports can support different types of communication (e.g. control, reading, notifications, and information collection) and different sets of data. Whatever transport is used for the data exchange, it must also support suitable congestion control mechanisms. The transports chosen should be operator and implementor friendly to ease adoption. I echo Benoit's question about defining multiple underlying transports. I suspect you'll need to pick one mandatory-to-implement transport protocol, and when everyone has to support that one, I'd be surprised to see implementations that support more than one transport protocol unless the mandatory-to-implement transport protocol is seriously broken in some scenarios.
fred and benoit did quite a good job on this one.
draft-ietf-p2psip-concepts
Thanks for sticking with it! A document such as this could be useful, given the complexity of RELOAD.
Thanks for doing this. I wish more of our protocols had high-level concept descriptions like this. - 1, first paragraph: I was slightly surprised not to see the word "rendezvous" turn up here. It's not critical, but it's a term that has meaning to a lot of "conventional SIP " people. - 2.2, last paragraph: While I assume the client in the first sentence is the conventional SIP client mentioned further down the paragraph, the initial paragraph structure led me to expect you to call the special peer offering the SIP registrar service a "client". - 2.5, first paragraph: consider expanding "zeroconf" to "zero configuration" -6: I’m not going to push the matter this late in the process, but there might have been an opportunity to describe the security concepts of p2psip at a similar level of detail.
draft-ietf-v6ops-ipv6-ehs-in-real-world
- The tables in section 2 would be more useful if they said how many addresses correspond to each row after filtering the 1M. - Appendix A: The URL [1] results in a 404 for me after a re-direct to port 443. I like the 301, but not the 404:-) [1] http://www.si6networks.com/datasets/wipv6day-domains.txt
This document provides two pieces of valuable information: the confirmation that IPv6 packets with extension headers are dropped in the Internet, and the description of the methodology used to collect the data. However, I don't think that either of these have RFC-archival value without offering guidance on what could be done about it, or even raising awareness to operational issues (beyond the obvious drops). [The Shepherd write up mentions that "the WG is considering another document" which may make recommendations. It might have been better to wait and package both together.] I won't stand in the way of publication, so I'm ABSTAINing.
While reading the document, I was wondering under which circumstances dropping IPv6 Extension Headers is the right behavior? Or, if dropping IPv6 Extension Headers is always just wrong? The only related sentences I found are: The aforementioned results serve as a problem statement that is expected to trigger operational advice on the filtering of IPv6 packets carrying IPv6 Extension Headers, so that the situation improves over time. ... In any case, we note that it is impossible to tell whether, in those cases where IPv6 packets with extension headers get dropped, the packet drops are the result of an explicit and intended policy, or the result of improper device configuration defaults, buggy devices, etc. What does it mean "so that the situation improves overtime"? A disclaimer that this study is formulated in a neutral way, as a precursor document for some further advice + a pointer to https://tools.ietf.org/html/draft-gont-v6ops-ipv6-ehs-in-real-world-00 would be a plus IMO.
I'm going with Álvaro here: it would be better to merge this into whatever other document the working group is considering, and to have this as a draft or in the working group wiki in the meantime.
I agree with Alvaro that this document is valuable as far as providing data that serves as input to other work, but does not by itself warrant publication as an RFC.
draft-ietf-aqm-fq-codel
Good stuff. Thanks.
- Is the following really necessary: In this document, these words will appear with that interpretation only when in ALL CAPS. Lower case uses of these words are not to be interpreted as carrying [RFC2119] significance. - section 6 While FQ-CoDel has been shown in many scenarios to offer significant performance gains, there are some scenarios where the scheduling algorithm in particular is not a good fit. Gains compared to? - From Jürgen's OPS DIR review: The working draft still says this: and we encourage such implementations be widely deployed It is unclear what 'we' is. This is something I think that needs to be fixed since people will come up with different interpretation of such a recommendation. (In a scientific paper, it would be clear that 'we' refers to the authors but in documents coming out of IETF WGs, the notion of what is 'we' is not so clear anymore.
Very nice work. I have some nit-ish questions I hope you'll consider, but
nothing blocking.
This text in the Introduction,
The FQ-CoDel algorithm is a combined packet scheduler and AQM
developed as part of the bufferbloat-fighting community effort. It
is based on a modified Deficit Round Robin (DRR) queue scheduler,
with the CoDel AQM algorithm operating on each queue.
introduces both CoDel and DDR, but they don't have references until Section
1.3. Maybe move that forward in the doc?
Perhaps this text:
FQ-CoDel stochastically classifies incoming packets into different
queues by hashing the 5-tuple of IP protocol number and source and
destination IP and port numbers, perturbed with a random number
selected at initiation time (although other flow classification
schemes can optionally be configured instead).
would benefit from a forward reference to Section 4.1.1?
Just as a nit, you have an "is is" in Section 3.
In this text:
After having selected a queue from which to dequeue a packet, the
CoDel algorithm is invoked on that queue. This applies the CoDel
control law,
"CoDel control law" hasn't been introduced, and isn't included in Section 1.2.
Could you provide a reference or pointer?
In this text:
This parameter can be set only at load time since memory has to be
allocated for the hash table in the current implementation.
if "in the current implementation" refers to "can be set only at load time",
This parameter can be set only at load time in the current implementation,
since memory has to be allocated for the hash table.
might be clearer.
I wonder if
while CoDel itself can take a while
to respond, fq_codel doesn't miss a beat.
is clear to non-native English language readers?
In this text:
In the presence of queue management schemes that contain latency
under load,
"contain" means something like "limit" right? That wasn't what I understood in
my first parsing attempt.
I'm confused by this text:
o Packet fragments without a layer 4 header can be hashed into
different bins than the first fragment with the header intact.
This can cause reordering and/or adversely affect the performance
of the flow. Keeping state to match the fragments to the
beginning of the packet, or simply putting all fragmented packets
into the same queue, are two ways to alleviate this.
Is this "all fragmented packets", or "all packet fragments"?
If it's "all fragmented packets", don't you have to reassemble the fragments?
If it's "all packet fragments", the packet fragments would all be transmitted
in order, but could the fragments with headers and without headers of a single
packet be reordered?
But either way, I have a question :-) ...
Do we say things like
In this document we have documented the Linux
implementation in sufficient detail for an independent
implementation, and we encourage such implementations be widely
deployed.
in Experimental RFCs?
draft-ietf-aqm-docsis-pie
For my own edification I assume that the latency target is expected to fall within o LATENCY_LOW = 5 ms o LATENCY_HIGH = 200 ms. but presumably it's most usable at the bottom end of that range? why is the lower bound at 5ms? is it simply unreasonable to target below that or is it bounded by the resource contention of the subscribers.
draft-martin-urn-globus
The secdir-review [1] raised a nit you may want to consider, but I didn't see a response. (Apologies if I just missed it.) [1] https://www.ietf.org/mail-archive/web/secdir/current/msg06382.html
Section 3, title: "Examples (Informative)" The whole draft is informational :-)
Thanks for writing this document. Before recommending its approval, I need to have a discussion with you about one aspect. Joel Halpern raised a question in his Gen-ART review: As per the pointer in this document to RFC 3406 section 4.3, this document is required to have a Namespace Considerations section which "outlines the perceived need for a new namespace (i.e., where existing namespaces fall short of the proposer's requirements)." While there is a section called Namespace Considerations, what it lists is the envisioned usages, not the reasons existing name spaces are insufficient. Is there an answer, or an update? I cannot imagine adding the requested rationale is difficult to add in this case, but it probably should be added. Thoughts?
conflict-review-melnikov-mmhs-authorizing-users
I had a quick read and have one question. Otherwise it seems fine, if very specialised. (But hey, it's MMHS:-) - 3.3 says: "one example is by verifying the S/MIME signature, making sure that the signature protects all header fields" huh? When do smime signatures cover header fields?
conflict-review-seantek-windows-image
For Standards-Tree registration in the Independent Stream, the IESG has to explicitly approve the registration requests. In this case, I would like to make that approval contingent upon approval by the media-types experts, which I have not yet seen. I (or my successor) will put a management item on a telechat to make that approval only after the ISE or IANA gets the OK from the DEs. I don't imagine that that will be much of a problem, though it might entail some document revisions. Sean did start some discussion of this on the media-types list, but it was a long time ago (October 2014), and did not end in resolution.