IESG Narrative Minutes
Narrative Minutes of the IESG Teleconference on 2015-10-15. These are not an official record of the meeting.
Narrative scribe: John Leslie (The scribe was sometimes uncertain who was speaking.)
Corrections from: Sandy
1 Administrivia
2. Protocol actions
2.1 WG submissions
2.1.1 New items
Telechat:
Telechat:
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:
3.4.2 Returning items
1048 EDT no break
4 Working Group Actions
4.1 WG Creation
4.1.1 Proposed for IETF Review
Telechat::
4.1.2 Proposed for Approval
4.2 WG Rechartering
4.2.1 Under evaluation for IETF Review
Telechat::
Telechat::
4.2.2 Proposed for Approval
5. IAB News We can use
6. Management Issues
Telechat::
Telechat::
7. Working Group News
Cindy: is IESG OK with changing wrap-up session to noon Friday of IETF week?
Benoit: brand new RFC has error, MIB doctors tried to correct it... automatic extraction has problems; can we just obsolete it and publish a new one?
Jari: should choose practical way; perhaps one-week LastCall on the diff; and republish... seems to break as little as possible of our code-base
Benoit: could we obsolete it right now
Sandy: we don't have anything to obsolete it with
Benoit: if we ever need to use that number again
Michelle: I though that couldn't happen, the registry is correct, just the RFC is wrong
Jari: LastCall diffs...
Benoit: I have a way forward
Amy: next week our (last) formal telechat before IETF week
1142 EDT Adjourned
(at 2015-10-15 06:00:37 PDT)
draft-ietf-ppsp-base-tracker-protocol
6.2 - can you explain to me how the overall protection against pollution works? I'm not quite following it and am concerned that it may be lacking. But that may just be me forgetting how this ties together with rfc7574.
- I-D nits notes a bunch of missing reference entries, e.g. for RFC6972 as well as 6 others. Probably some xml2rfc issue. - intro: last para (just before 1.1) puzzles me. Not sure why it''s there. - intro: why is there no mention of Bit Torrent? This seems to be the same design for the same purpose, and BT is in widespread use so not explaining the relationship seems a bit odd. 5.1.2 seems to be plain silly in that light, while BT is not a "standard" that is irrelevant - it has been widely deploy and migration from BT to this, or co-existence, would seem critical to the success of this effort. - RFC2616 is obsoleted. - 6.1: I agree with Katheen's discuss, a MUST use TLS is needed here really and just reflects reality and is not an additioanl consideration. It is needed for clarity though. - 6.2: Given the history of spoofing in BT I wondered why there is no object level origin auth defined here. - I also agree with Ben's discuss.
I think this draft needs privacy considerations. The protocol carries sensitive information in the form of IP addresses and location. If I understand correctly it may also identify transferred content, which can be highly sensitive under some circumstances. Encryption is optional. It think it needs stronger guidance on privacy implications and the use of HTTPS.
- 1.1, definitions of "LEECH" and "SEEDER"
These don't seem to match the use of the terms elsewhere in the document. In
particular, these seems to describe transient states, while the protocol
requires the peer to declare itself to be a leech or seed when it joins a
swarm. Additionally, these definitions don't seem to consider a peer that may
have received part but not all of some content, but still makes the chunks it
has available.
- 1.1, LIVE STREAMING:
Is there an expectation of syncing reception between receivers?
- 1.1, VIDEO-ON-DEMAND
Aren't the main points that different audiences can watch the same part at
different times, or different parts at the same time?
- 1.2, 2nd to last paragraph:
Wouldn't a distributed tracker have implications for discover and connection
management? It also seems worth some discussion in the operations section.
- 1.2.2, first paragraph:
Aren't there at least some implied requirements for peer-ids? E.g. uniqueness
requirements? Requirements for elements to treat them as opaque strings?
-2.1: "The messaging model of PPSP-TP aligns with HTTP protocol..."
Is that the same as saying it uses HTTP as a substrate? (If so, the references
to HTTP need to be normative.)
- 2.2, 3rd paragraph: "Requests are sent, and responses returned to these
requests." The use of passive voice obscures the actors. What does each of
these things?
- Figure 5: Is there a matching peer state machine (i.e. that models the
internal state of a peer?)
- 2.3.2, general:
The section is inconsistent in specifying result codes. Also, it's not clear
whether these are HTTP result codes, or PPSP-TP result codes.
-2.3.2: "Peers MUST NOT generate protocol elements that are invalid."
That's an odd use of "MUST NOT".
ability_nat: What's the use case for one peer caring what the NAT status of
other peers might be, as long as it gets addresses that it can reach?
- 3.2.4: "connection":
That list will continuously become obsolete. I suggest some classification that
describes the attributes you care about, rather than the current-as-of-now set
of network technologies.
- table 3:
How is "priority" encoded and interpreted?
-3.3.4:
"Normally, swarm action result
elements SHOULD be set and error_code MUST be set to 0 when
response_type is 0x00."
What does it mean for swarm action results element to be set? Since that's a
structure, I assume you don't mean set as in "true", or set to zero like the
error_code. Do you mean they should be _included_ or _present_?
"A swarm action result element is the result information for a peer to
request the tracker to have some actions towards the swarm."
I'm a bit confused about the causality here. This is the result of a request
that has already happened? An indication that the pier should request
something? A reciprocal request and the result of the previous request?
-4, general:
The protocol specification sections are inconsistent in the way they use 2119
keywords. It seems somewhat random whether any given protocol requirement uses
2119 keywords or not. I suggest the authors re-review this section for 2119
consistency. In general, you don't need 2119 words to describe every detail of
the the basic flow of the protocol; rather they are more useful when there's a
decision to make, or a place where an implementor is likely to get things wrong.
-4, 2nd paragraph:
Can you offer any guidance on when one should actually _use_ HTTPS? (See
DISCUSS comment)
-4, paragraph 4:
This seems to be describing the general working of HTTP. I'm not sure why you
need to restated it here, especially with 2119 words.
-4.1.1, paragraph 4:
Since the mentioned elements are "optional", is there any guidance for the
tracker? For example, can the peer assume that the tracker (or other peers)
will never require these elements to operate properly? Or if they may be
required by the tracker (or other peers), how would the peer know it needed to
include them?
- 4.1.1, paragraph 6:
"... MAY... start by pre-processing the peer authentication information" needs
elaboration. I assume the "MAY" relates to the previously mentioned "preferred"
use of TLS client certificate authentication?
-4.1.1., 3 paragraphs from end:
Can you elaborate on "STUN-like function"? I gather the tracker can reflect
back the observed source address/port of the peer in the response? If so, I'm
not sure readers will understand that from "STUN-like function".
-4.1.1.1:
I'd love to see the example use HTTPS, just to set a good example.
In the example of a peer leaving one swarm and joining another, second
swarm_action:
s/@peer_mode/peer_mode
-4.3, 1st paragraph:
Why would the peer fail to read the response? Because the response is invalid?
Not received? This all runs over TCP right?
-4.3, 3rd paragraph:
Why only a should? What are the consequences of not being prepared?
I assume the errors in this section are PPSP-TP errors, not HTTP result codes.
I think the choice of 4XX codes will confuse people into thinking these match
the HTTP 4XX client-error result codes. Especially since many seem to have
similar meanings--but rearranged.
-6.1:
It would probably be worth mentioning the need for an enrollment service in the
operations section.
The 3rd paragraph would work better in the previous paragraph where you mention
the HTTP security considerations, and perhaps cast in terms of HTTPS. Also,
please consider a reference to RFC 7525.
OAuth might should've been mentioned back when you discussed digest
authentication and HTTPS client certificates
-6.2:
This seems to mean that the peers in a swarm must agree on an integrity
protection mechanism. Can you reference something? On the other hand isn't this
an issue for the actual transport protocol rather than the tracker protocol?
-7:
The 3rd paragraph seems to forbid adding new elements, as described in the next
section.
The 2119 words in the 4th paragraph are questionable. It's hard to put MUST
level requirements on people, and the MAY is a statement of fact.
In the last two paragraphs:
Internet-Drafts are not appropriate places to document things, other than
ephemerally on their ways to become RFCs. I-Ds expire.
Saying extensions MAY be documented in RFCs doesn't add anything; anything may
be documented in RFCs. I assume therefore you mean at least SHOULD. If so, what
kind(s) of RFCs would be appropriate?
The suggestion that private extensions need not be documented in RFCs can be
harmful to long-term interoperability. So-called private extensions have a way
of migrating to public networks.
-7.2:
Wouldn't non-backward compatible extensions require a new version number?
Doesn't this violate the requirements in the parent section?
-8:
I am surprised not to see registries for methods and result codes, especially
with the considerable text about extensibility. Do you expect them to be
extended?
10.2:
The references to 2616, 2818, and 5246 probably need to be normative. Also,
2616 is obsolete.
Editorial and nits:
-------------------
- IDNits points out a number of citations without matching references
-1.1: VIDEO-ON-DEMAND and LIVE-STREAMING
I suggest changing "It refers to" to "VIDEO-ON-DEMAND refers to..." and
"LIVE-STREAMING refers to..."
- 2.2, definition of CONNECT: "... Peer
registers in the Tracker (or if already registered) to notify it..."
What is the antecedent of "it"? (peer or tracker?)
- 2.3.1, 4):
s/"is responded with"/ "is responded to with" (Or even better, "The tracker
responds to the request with...")
- 3.1 : "... turning the definitions for
JSON objects extensible."
I don't understand the phrase. Do you mean "making the
definitions...extensible"?
- 3.2.2, 1st paragraph:
Paragraph seems out of place, and seems redundant with the rest of the section.
The placement here makes it look like NAT status selection is the primary use,
and I don't think that's the intent.
s/"inform the tracker on the preferred type"/"inform the tracker of the
preferred type"
- 3.2.5, first paragraph:
s/can be related with/can be related to
-3.3.4, response element:
s/ppsp_tp_interger_t/ppsp_tp_integer_t
- 4.1.1, 3rd paragraph after table 6
The first sentence is convoluted and hard to parse. I suggest breaking it into
simpler sentences.
-4.1.2, 4th paragraph, "... with regard to the possibility of
connecting with other IETF efforts such as ALTO [RFC7285]."
I don't understand the intent of this phrase.
-4.1.2, 5th paragraph:
The structure of the sentence is confusing. Do you mean to say that included
elements MUST include public addresses?
-4.1.2, 3rd to last paragraph:
The paragraph seems redundant to the previous paragraph.
-6, first paragraph:
s/"impersonating to be another valid participant"/"impersonate a valid
participant"
-7.2, security issues: "Being security an important component of any
protocol..."
I don't understand this phrase.
Thanks for your work on this draft, I have a few things I'd like to discuss that we should be able to resolve quickly. I'll try where possible to offer suggestions, but please do let me know if there is a good reason why they don't make sense. 1. Section 5.2.7 Please make mention and reference to security provisions for SNMP and Syslog. RFC5424 is just for syslog, so a pointer for SNMP security considerations should be added in this section as well. They use a boilerplate for the text and add considerations specific to a draft. Benoit - do you have a good reference for them to use? A more generic SNMP draft might not be up-to-date with the latest boilerplate text. If that's the case, the recent changes are small and could be stated with a pointer to an RFC with the older boilerplate text. 2. Are there any considerations for the statistics collected, can they be used in a malicious way? I would think so and that this would be an important security consideration. Mentioning possible issues would be helpful to the reader. Section 6 Reference to RFC2616 isn't enough for the security considerations of HTTP since that's a really old RFC. If you want authentication options, you could point to the HTTPAuth documents, which include updated versions of HTTP basic (RFC7616) and digest (RFC7617). While there are still lots of security issues with these options, the RFCs spell out what the actual considerations are, which are helpful to the reader. This raises the need for TLS 1.2 as well to provide session protection for the session (passive and active attacks) as well as for the authentication used. Section 6.1 Why isn't TLS a must here to protect the session data? If you are relying on OAuth Bearer tokens, they offer no security protection without TLS, so to rely on this, I'd say TLS really should be a MUST. The authentication types to get a bearer token (at least in RFC documentation and in the registry) are all pretty weak and require TLS protection to have any level of security. With the TLS MUST, we are recommending TLS 1.2 as the minimum in drafts. It would be good to see a mention of TLS 1.2 as a minimum recommendation and a reference to the BCP for TLS 1.2 configurations RFC7525 (it even includes cipher suite recommendations). Privacy I would have expected some discussion on the protection of the 2 ID types and the tracker capabilities and that session encryption (TLS) ought to be used when this is a consideration. Is there a reason this isn't covered? If it's not a concern, I'd like to understand why.
You use RFC 2616 as a reference for HTTP 1.1, but that's obsolete, and the current reference should be RFC 7230 for the general references and RFC 7231, Section 3.1.1.5 for Content-Type (the citation in Section 4 here). The Security Considerations section should cite both 7230 and 7231. -- Section 3.1 -- A JSON object consists of name/value pairs. The JSON names of the pairs are indicated with "". I don't find the meaning of the second sentence to understandable at all. What are you trying to say? -- Subsections of 3.2 -- Where are the semantics of the string values, such as "HIGH", "NORMAL", and "LOW", defined? -- Section 4 -- For deployment scenarios where Peer (Client) authentication is desired at the Tracker, HTTP Digest Authentication MUST be supported, with TLS Client Authentication as the preferred mechanism, if available. You need a normative reference to RFC 7616 for HTTP Digest Authentication, and a citation here. -- Section 4.1.1.1 -- Please re-check your examples carefully, and pass them through a JSON validator. In the first example, for instance, the Content-Length value is wrong and the "transaction_id" member is missing its ":". The third example uses "TransactionID" instead of "transaction_id" for the member name. Be careful during AUTH48 that you re-check this, including making sure that any Content-Length values are still correct after all the editing.
Is the definition give for "LEECH" sufficient?:
LEECH: A Peer that has not yet completed the transfer of all Chunks
of the media content.
I don't think "completed the transfer" is clear enough, and "transfer" can be
outbound or inbound. Would something like "A Peer that has not yet received
all chunks of the media content, and therefore can't be used to share the
content," be better? And isn't it possible for a peer to share the chunks that
it has, even if it doesn't have all of the chunks?
You do seem inconsistent with capitalization of terms ("SEEDER" and "Seeder",
"LEECH" and "Leech", "SWARM and "Swarm" and "swarm"). You should fix that --
readers often find it confusing, and the RFC Editor will ask you about it
during AUTH48.
-- Section 1.2.1 --
I don't understand the meaning of "[Peer Protocol]" in front of list items 3,
4, and 5. Why's it there? And if you're going to leave it there, I think you
might do better to find notation that doesn't look like how we write reference
citations.
-- Section 2.2 --
Requests are sent, and responses returned to these requests. A
single request generates a single response (neglecting fragmentation
of messages in transport).
The word "neglecting" can make this ambiguous -- it can be taken to mean that
fragmentation can't happen. It might be better to say it this way:
NEW
Requests are sent, and responses returned to these requests. A
single request generates a single response (though both requests
and responses can be subject to fragmentation of messages in
transport).
END
-- Section 4.3 --
If the peer fails to read the tracker response, the same Request with
identical content, including the same transaction_id, SHOULD be
repeated, if the condition is transient.
...and...
The tracker SHOULD be prepared to receive a Request with a repeated
transaction_id.
Given the first paragraph, why isn't the SHOULD in the second one a MUST?
In the list of error responses, why are some of them MUST and others SHOULD?
-- Section 4.4 --
There are no JSON things called "fields". Objects have "members" and arrays
have "elements". I think you mean to use "members" in this section.
-- Section 7 --
Additionally, a designer MUST remember that extensions themselves MAY
also be extensible.
The "MAY" shouldn't be a 2119 key word, and should be changed to lower case.
-- Section 8.1 --
This is not defining a registry; it's making a registration in the media types
registry. We no longer use the term "MIME type", so please change the title to
"Media type registration", and change the first paragraph:
OLD
This document defines registry for application/ppsp-tracker+json
media types.
NEW
This document registers the application/ppsp-tracker+json
media type.
END
You also use "MIME type" in the "File extension" information (you can actually
just change that to "n/a"). And you haven't updated the registration template
to the latest one specified in RFC 6838 -- there's a new "Fragment identifier
considerations" item (which can just be "n/a" also, but please add it).
-- Section 10 --
Some of your informative references are for required functions, and should be
normative. In particular, RFC 2616 needs to be changed to 7230 and 7231 (see
above) and needs to be normative. 2818 and 5246 should be normative. 3986 and
5952 tell you how to encode IP addresses, and should be normative.
I support the DISCUSSes raised by Barry, Ben, Kathleen, and Stephen.
Neville Brownlee performed the opsdir review
Hi all:
I have performed an Operations Directorate review of
draft-ietf-ppsp-base-tracker-protocol-10
"This document specifies the base Peer-to-Peer Streaming Protocol-
Tracker Protocol (PPSP-TP/1.0), an application-layer control
(signaling) protocol for the exchange of meta information between
trackers and peers. The specification outlines the architecture of
the protocol and its functionality, and describes message flows,
message processing instructions, message formats, formal syntax and
semantics."
- - - -
This is a long document describing in detail a protocol that can be
used to form a network of co-operating peers, supporting swarms for
particular content streams, and distributing that content to all peers
that are members of the stream.
The formal presentation of the protocol uses a C-style notation, and
encodes its requests and responses using JSON. It seems to me that
there has been at least one implementation to date, therefore the
Object definitions are taken from that implementation's source code.
Reading them, I believe that the protocol is described clearly enough
to allow other independent implementations.
Having said that, there are several items which are not covered, for
example in section 1.2.2 "The specification of the format of the Peer
ID is not in the scope of this document." I'm sure there's a good
reason for leaving that out, but implementors will need to make sure
that Peer IDs are always treated as strings (as specified in section
3.2.4).
Section 5.1, Operational Considerations, seems carefully considered;
it provides a checklist of things a service provider will need to
consider when they deploy PPSP-TP. In particular section 5.2
(Management Considerations) points out that Management Information,
including that for Fault, Configuration, Accounting, Performance and
Security Management all expect to use other existing techniques.
That's reasonable, of course, but providers will need to plan
carefully for all that.
Section 6, Security Consideration, seems thorough, pointing out that
peers will need to cope with various kinds of other - potentially
malicious - peers.
Last, section 7 provides some guidelines for extending PPSP-TP.
This is certainly interesting, clearly the authors view PPSP-TP
as an ongoing development activity!
Overall, this document seems sound, i.e. ready for publication
as an RFC.
A few typos:
s1 s/peers able to communicate/peers that are able to communicate/
s/different order of the/different order to that of the/
s1.2 s/here, as not in the scope/here, as it is not in the scope/
/swarms corresponding each swarm to the group of peers/
what does this mean?
s2.2.3 s/On normal operation/In normal operation/
s2.3.1 s/respectively responded with/respectively responded to with/
s/responded with/responded to with/
s2.3.2 s/transition to TERMINATE/transitions to TERMINATE/
s3.2.5 s/peer is actively involved./peer is actively involved with./
s4 s/The section describes/This section describes/
s4.1.2 s/include peer_group element/include a peer_group element/
s4.1.3 s/concurrent_links and etc./concurrent_links etc./
s4.3 s/due to unexpected/due to an unexpected/
s4.4 s/set a upper/set an upper/
s7.2 s/Being security an important/Because security is an important/
Cheers, Nevil
Co-chair, SUPA WG
draft-ietf-idr-ls-distribution
Note: This may sound like a scary discuss, and who knows but it might lead to us recognising that some significant work is needed in future, but I think this should be easily fixed for this particular document... This document does recognise that there can be confidentiality or privacy issues with exporting information in this way. And it correctly (I think) says that just not sending that sensitive data is a good way to handle this and that mechanisms for e.g. aggregating to ensure privacy are out of scope. (As an aside: strengthening that recommendation would be a good thing I think.) However, noting that e.g. ALTO servers can be handling data that is privacy sensitive for specific users (e.g. see https://tools.ietf.org/html/rfc7285#section-15.3 and https://tools.ietf.org/html/rfc7285#section-15.4), I think there are two more things that need to be noted here, but that are not. (1) First is that this document does change (what I understand, perhaps imperfectly, as) the security model for BGP, in that previously we have assumed that BGP speakers are not exposing user-specific privacy sensitive information. This draft seems to me to change that. (If it does not, then a reference to where that was previously done would be needed, or an explanation of why I'm wrong:-) If you could add a strong recommendation to not do that, I think that'd be good. (I do get that that can't be an easily implemented MUST NOT statement though, so I'm not quite sure what text to suggest, but it oughtn't be too hard to figure something out.) (2) Second, I wonder if the above change means that we need to seriously consider confidentiality for BGP. The RPKI does not, but then neither did DNSSEC for years until we belatedly realised that that was a real issue. I'm not asking that this draft provide a mechanism for confidentiality for BGP, but that at least recognising the issue as real (if it is) seems to be required. (And nor am I asking that a confidentiality system as complex as the rpki be developed, I think that if anything is needed here beyond data minimisation, then transport layer security would be as good as it'd get.) The change here would be to simply recognise this consequence, if it is real, and that could be a simple sentennce in the draft, e.g. saying that these changes to BGP might result in PII being emitted, and hence might cause a real need for confidentiality for BGP.
-section 5: "The SAFI assignment does NOT need to be out of the range 1-63 and MAY come out of the "First Come First Served" range 128-240." I suspect the all-caps terms don't really apply (especially the free-floating NOT). - section 5.1: "available for review by the IDR working group," What if that group concludes?
Thanks for the Manageability Considerations section. Hopefully draft-ietf-idr-bgp-model covers the BGP-LS specifics
Thanks for addressing the SecDir review comments. https://www.ietf.org/mail-archive/web/secdir/current/msg05619.html
Nicely written; thanks. And a particular thanks for the clear guidance to the DEs in Section 5.1. I might want to point to this from 5226bis, which means this might get me off my bum on that. A minor editorial thing in the Introduction: The contents of a Link State Database (LSDB) or a Traffic Engineering Database (TED) has the scope of an IGP area. I don't know what that means. Might it be this (and might this be a clearer way to say it)?: NEW The contents of a Link State Database (LSDB) or a Traffic Engineering Database (TED) are only visible within their IGP area. END
Carlos Pignator did the ops dire review. I think I was ok with version 10.
draft-ietf-trill-cmt
I have a couple of significant concerns — I don't think are at the level of a
DISCUSS and should be easily resolved.
1. What is a "virtual RBridge". Is there a formal definition and a reference?
I think we can all pretty much guess what it is, but this is a standards track
document and we shouldn't be guessing. The Abstract ("Virtual representation
of the non-TRILL network with a single Rbridge…") and Section 1.1 ("…a virtual
Rbridge is used to represent multiple RBridges connected to an edge CE…") seem
to attempt a definition, but one talks about a non-TRILL network and the other
about RBridges which are TRILL constructs.
2. Section 5.6. (Failure scenarios) presents a failure recovery algorithm and
says that "implementations MAY include other failure recover algorithms." My
concern is whether having different algorithms (in the same virtual RBridge
group) can cause inconsistent performance or maybe even loops. If so, then I
think that fact should be called out and maybe a recommendation put forward to
have one algorithm per group.
BTW, these are the same comments put forth in Stig Venaas' RTG-Dir review — but
I didn't see a reply to that
[https://mailarchive.ietf.org/arch/msg/rtg-dir/sdJci3nJ47BjpK4cm9LVWX36WZM].
1.1, 2nd paragraph: I assume the all-caps for "DOES NOT" are for emphasis, and we all know 2119 does not define that phrase. But it looks enough like 2119 language that it may confuse people. Figure 2 is misaligned.
As mentioned by Tina in her OPS DIR review. Section 5.7 After sentence about tunnelling, another sentence could be added as following. “It should be noted that tunneling would require silicon change though CMT itself is software upgrading only.” It can be also added in the introduction or abstract, CMT method doesn’t need hardware upgrade, this is the biggest advantage of CMT.
Thanks for your work on this draft and incorporating the nits found during the SecDir review. https://www.ietf.org/mail-archive/web/secdir/current/msg06083.html
Given the broad waiver written into the Applicability section, I am left to wonder about the more interesting multicast issues like interactions with IP multicast and actual distribution tree construction in TRILL. I guess that is future work.
Tina Tsuo performed the opsdir review
draft-ietf-bess-mvpn-bidir-ingress-replication
I have one less and two more serious comments... - Less seriously, "MP2MP tunnel" seems like a strange use of language, I wondered if it might be better to call these an MP2MP warren (as in rabbit warren, and of course bearing in mind the ops-dir review:-) - More seriously, this is another draft that simply has too many acronyms and uses those too densely. For example, I just find it really hard to believe that "If a PE, say PEx, is connected to a site of a given VPN, and PEx's next hop interface to some C-RPA is a VRF interface, then PEx MUST advertises a (C-*,C-*-BIDIR) S-PMSI A-D route, regardless of whether it has any local Bidir-PIM join states corresponding to the C-RPA learned from its CEs" is a useful sentence to implementers. IMO enough folks have commented on this aspect that the wg would be wise to seriously consider the readibility of their output. I've worked on enough EU-funded projects that had write-only documents to be worried if the IETF starts to produce those. (This is not a discuss since I've been assured that this is not a problem for implementers, and while I do accept that, I also continue to worry about it.) - I am simply not in a position to evaluate section 4. And nor was the assigned secdir reviewer. The same point about density and that making any secdir review hard to impossible was noted by the secdir reviewer for draft-ietf-bess-mvpn-bidir. I don't think it'd be valid for me to put on a discuss on the basis that nothing this complex has "no new security issues" but it was tempting. Overall, I think it would be best if this were returned to the wg asking for significant improvement in clarity for readers.
Here is Warren Kumari's OPS DIR review. Summary: Ready, typo / grammar nits. General: I found this document to be very dense. At some point my brain started dribbling out my ears and I largely gave up on trying to understand the mechanism. This seems to be very much a niche application, and my IP multicast and deep MPLS knowledge isn't up to the level of finding issues with the logic. Nits: Abstract: This document specifiess how [O] specifiess [P] specifies [R] spelling 1: Introduction: With these two methods, all PEs of a particular VPN are separated [O] all PEs [P] all PEs (Provider Edge router) [R] first use of acronym. The document does say it assumed familiarity with terminology from [RFC5015], [RFC6513], [RFC6514], and [RFC7582], but this is before that, and also expanding PE here will help people understand if they want to continue reading...
A very small point, and not a big deal: The abstract says, "This specification updates RFC 6514," presumably to meet the I-D nits question. But it doesn't say what, specifically, is updated, and I don't get that clearly from reading the rest of the document either (I presume that someone who knows 6514 well would understand; I think the explanation is in the paragraph in the introduction that mentions Ingress Replication tunnels, and there's a paragraph in the middle of Section 3.1...). Can the sentence be expanded just a little (keeping it as one sentence) to summarise what the update is? I'm thinking along the line of, "This specification updates RFC 6514 by [changing the procedures with respect to [whatever]]."
This is not an easy document to read. If it gave reasons, examples, and explained what it was accomplishing with the information exchanged, that would probably help.
I have to agree with Alia's comments and Warren's review. Very dense. No clear justification. No examples.
warren kumari did the opsdir review
draft-ietf-grow-bmp
Thank you for a clear and well-written document. This was easy to read and understand. I do have a couple questions. a) In Section 4.2, I see special casing for an "L3VPN Instance Peer". Will the same thing be necessary for an EVPN peer? Are there other future cases to be considered? b) In Sec 4.4, for the type=0 String, it may be useful to specify that the language is unspecified and based on the configuration. A similar description for the other information strings would be useful. I'm sure that Barry could suggest better text.
Apologies in advance for the rant, but this is a new protocol and not something deployed for decades that can't be fixed. (At least so says the write-up.) The state of security here is just sad. It reminds me of the 1980's. And introducing new protocols without improving that goes against very long held IETF consensus that protocols need to have some actually usable strong security mechanism defined. It seems the wg here get that but are choosing to do nothing about it - I mean in their day-jobs, not that writing RFC text is "doing something." The responses to the secdir review seem to make it clear that the claim that IPsec can be used is mythical, so this discuss to ask that the security considerations properly document the utter absence of any modern way to secure this protocol and not pretend that there are ways that can be used to secure this in the real world. I would suggest text that simply says that: "This is an inherently insecure protocol for no particularly good reason and mostly due to the lack of implementation of basic security mechanisms (SSH, TLS) but also due to a lack of customer/operator pressure to ensure those are present, usable and interoperate, despite evidence that attacks on the links over which this data will be sent are ongoing." I'd not be surprised if you preferred some other text:-)
Separate to the discuss, I have some non-blocking points, that I think resonate with Kathleen's discuss: Why is using TLS not a no-brainer for this? Given the likes of the Belgacom and Gemalto reports, I would love to understand why people are still willing to buy and sell equipment without such basic features. The "explanation" that nobody needs it or nobody provides it seems off base here - this is new code and a new interface, and the relevant security protocols (SSH, IPsec and TLS) are all nearly or more than 20 years old. And that is all the more the case for a new protocol like this that is not likely in the critical path and where the monitoring statiion may be off to the side so the traffic flows via BMP in places where BGP doesn't go implying different threat levels, that may need different protection. My best guess as to causes for now is that people are just used to doing nothing and have done that for so long they seem to think that doing nothing is the only possibility. (That's how business models get disrupted isn't it?) Can you educate me some more on this? (And yes, I get that all the stuff as to why AO isn't available for BGP, but this is not BGP. It's our apparent need to keep the security level down at the "crap" marker that I don't get.)
The shepherd write-up says that IPR was declared, but the datatracker shows nothing for this draft or its predecessor. === (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. -- Yes. ===
I support Stephen's and Kathleen's discuss positions concerning the lack of MTI security. I'm balloting no-objection (for now) so that those conversations can happen on their respective threads. 3.2: The says no message is ever sent by the monitoring station, but the last paragraph in the section mentions a monitoring station sending a termination message. Also, does the strategy for retrying failed connection attempts apply to reconnects after the fail or an existing connection? The 3rd paragraph from the end talks about redundant connections happening when both parties are configured as active. But previous paragraphs suggested that only passive endpoints will listen for a connection. How could this result in redundant connections? Is there logic to make sure the endpoints do not terminate both redundant connections? IANA Considerations: Several of the tables reserve an experimental range of 65531 through 65534. Is it really the intent to have experimental ranges with only 4 code-points each?
Comments and questions from the recent Gen-ART review by Vijay Gurbani deserve to be looked at.
This DISCUSS is in line with Mahesh's OPS DIR review.
If BMP (which I consider like a span port feature btw) troubleshooting shows
that the BGP configuration is required, then the standard way to configure BGP
will be https://tools.ietf.org/html/draft-ietf-idr-bgp-model-00. I'm wondering
about the link between BMP and the following draft-ietf-idr-bgp-model-00.txt
YANG models:
bgp-types.yang
bgp-policy.yang
bgp-multiprotocol.yang
bgp.yang
bgp-operational.yang
Specifically: are we able to map the Per-Peer Header (section 4.2) and
Information TLV (section 4.4) to draft-ietf-idr-bgp-model-00.txt. Either
because the field information come from the same reference (ex: both this draft
and the idr one have the same reference for the Peer Distinguisher), or because
specific references to the YANG key information is provided. I believe that the
draft-ietf-grow-bmp and draft-ietf-idr-bgp-model authors should sit down and go
through the exercise of mapping the BMP data model into the YANG data model,
for a couple of troubleshooting scenarios. The OPS world suffers from too many
different data models (MIB, IPFIX, YANG, etc.). With this DISCUSS, I want to
make sure that we won't fall into the trap of defining a new one without at
least providing the necessary mappings. Note: I see that sysName and sysDescr
make the link with the MIB world, that's a step in the right direction.
Below is Mahesh's OPS DIR review:
Summary:
This document defines a protocol, BMP, that can be used to monitor BGP
sessions. BMP is intended to provide a convenient interface for obtaining
route views. Prior to introduction of BMP, screen-scraping was the most
commonly-used approach to obtaining such views. The design goals are to keep
BMP simple, useful, easily implemented, and minimally service-affecting. BMP
is not suitable for use as a routing protocol.
The document is on standards track and defines another monitoring method
specifically for BGP. The original draft is dated 2005, long before NETCONF or
YANG were defined, and when there was probably no way to view routes. With the
advent of NETCONF and specifically the BGP YANG model, which is currently a WG
document, it would be helpful to know how BMP stands apart. The NETCONF
notification structure allows for notifications described in this draft and the
ability to collect stats reports and route monitoring. It would be helpful to
know how BMP compliments that capability.
COMMENT:
- From the write-up:
-- The BMP protocol has been a GROW document for quite sometime. The
-- length of time has allowed the document to have multiple implementations
-- completed, along with incorporating working group feedback into the spec
-- and polishing the document.
Btw, don't forget, for future documents, the experimental RFC 6982 "Improving
Awareness of Running Code: The Implementation Status Section"
- following nits need to be addressed in the document.
Miscellaneous warnings:
----------------------------------------------------------------------------
== The document seems to contain a disclaimer for pre-RFC5378 work, but was
first submitted on or after 10 November 2008. The disclaimer is usually
necessary only for documents that revise or obsolete older RFCs, and that
take significant amounts of text from those RFCs. If you can contact all
authors of the source material and they are willing to grant the BCP78
rights to the IETF Trust, you can and should remove the disclaimer.
Otherwise, the disclaimer is needed and you can ignore this comment.
(See the Legal Provisions document at
http://trustee.ietf.org/license-info for more information.)
Checking references for intended status: Proposed Standard
----------------------------------------------------------------------------
(See RFCs 3967 and 4897 for information about using normative references
to lower-maturity documents in RFCs)
== Outdated reference: draft-ietf-idr-error-handling has been published as
RFC 7606
The statements on authenticated access and confidentiality are helpful, but this is a new protocol and should not start out with the security property levels of the current BGP deployments. Efforts have been made to publish RFCs to fix BGP security and the vulnerabilities have been published - even in the Washington Post. I'd like to see more security required for the properties mentioned to prevent active and passive attacks getting dumps of the BGP data, which was not previously available. If this is not possible per the suggestions below, please explain why. If there is a good reason, it would be helpful to remove the text that says its okay to leave security out because BGP isn't secure and just include the security considerations. Now for specifics: 1. In the Security considerations, it is not only a passive attacker, but also an active one that could gain access to the session if it is not encrypted (protected for confidentiality). An active attacker might change routes causing network disruption. A passive attacker might better understand the possible paths to an AS, assisting with a more effective DDoS attack. The latter point is important to consider in the first paragraph of this section that currently says, "although it's hard to consider the content of BGP routes in the public Internet to be confidential," I think this is a bit of an overstatement as the exact routes and paths are not published for each router and could be used for DoS attacks - for example taking out one or more paths to a network AS. What I am suggesting for #1 is a simple text change to address the fuller set of security considerations. Change from: Unless a transport that provides confidentiality is used, a passive attacker could gain access to BMP data in flight. To: Unless a transport that provides confidentiality is used, a passive or active attacker could gain access to or tamper the BMP data in flight. 2. The last paragraph would be the right place to require session encryption and authentication for sessions (unless there is a good explanation as to why this is not needed). If the transport may vary, then it's okay to leave IPsec as a suggestion. It would be nice if there was an MTI for transport, so the security protections could be consistent and interoperability would be easier between implementations. This also came up in the SecDir review. https://www.ietf.org/mail-archive/web/secdir/current/msg06011.html In any case, it would be good to discuss this and see if there are good reasons to leave it as-is or to change the text to improve security, preventing a few attack types.
I found myself wondering when you can start route mirroring, and whether there was any guidance about what to do when a BGP speaker runs out of buffers so that route mirroring is no longer complete.
draft-ietf-mpls-self-ping
I was looking at o The UDP Destination Port MUST be lsp-self-ping (8503) [IANA.PORTS] and wondering why this is a MUST. Is the answer that this mechanism works within an administrative domain, so you can just tell the other end what the port number needs to be?
Did the WG consider updating RF C3209? OLD: The node SHOULD be prepared to forward packets carrying the assigned label prior to sending the RESV message. NEW: The node SHOULD be prepared to forward packets carrying the assigned label prior to sending the RESV message. When an ingress LSR receives an RESV message, it MAY/SHOULD/MUST invoke the LSP Self-ping procedures [this-RFC-to-be] to verify that forwarding state has been installed on all downstream nodes.
I see that the Security Considerations section says, "operators SHOULD filter LSP Self-ping packets at network ingress points" I think it would be helpful to have the draft explicitly state the scope for this new function - within a single operator's network is my assumption. If that assumption is not correct, I may come back with more questions. There was also a suggestion made int he SecDir review that you may want to consider: https://mailarchive.ietf.org/arch/search/?email_list=secdir
Bert Wijnen did the opsdir review.
draft-ietf-v6ops-siit-eam
This document updates rfc6145, and it looks like the intent (from 3.3.1 and 3.3.2) is to replace whatever rfc6145 says with the outcome described, unless "no matching EAM entry is found". Please be specific about which parts of rfc6145 are being replaced — 1-2 sentences in Section 3.3 should be enough. Having said that, I am a little confused. The Introduction says that "If no matching mapping exists, the [RFC6052] algorithm will be used instead.", but 3.3.1 and 3.3.2 both say that "If no matching EAM entry is found, the EAM algorithm is aborted. The SIIT implementation MUST proceed to translate the address in accordance with [RFC6145]". My confusion may be due to just not being familiar with the relationship between rfc6145 and rfc6052; please clarify.
From Ron Bonica's OPS DIR review:
The Nit Checker says:
== There are 1 instance of lines with non-RFC5735-compliant IPv4 addresses
in the document. If these are example addresses, they should be changed.
== There are 3 instances of lines with non-RFC3849-compliant IPv6 addresses
in the document. If these are example addresses, they should be changed.
I understand why you had to break the rule for 0/0. But could the IPv6
addresses have been taken from documentation space?
I have no issues with the publication of this draft, but want to point out that there an abundance of misuses of 2119 keywords. Section 3.1 provides useful examples: An SIIT implementation MUST include an Explicit Address Mapping Table (EAMT). By default, the EAMT SHOULD be empty. The operator MUST be able to populate the EAMT using the implementation's normal configuration interfaces. The implementation MAY additionally support other ways of populating the EAMT. - How a SIIT implementation manages the mappings has no bearing on the functionality. So, saying "MUST include an EAMT" is not needed. - SHOULD be empty? At what point? During implementation? - Why "MUST be able to populate"?
draft-ietf-ippm-owamp-registry
Thanks for addressing the SecDir review. https://www.ietf.org/mail-archive/web/secdir/current/msg06058.html
Nevil Brownlee did the opsdir review
draft-ietf-bfd-rfc5884-clarifications
Thanks for your work on this draft. I'd just ask that you expand out BFD on first use since it is an acronym used frequently in the draft.
Just a question on this draft... Given its status as clarifying (and updating) RFC 5884, does it also inherit any of the IPR claims levied against RFC 5884?
Scott Bradner did the Opsdir review
I have done a OPS-DIR review of "Clarifications to RFC 5884”
<draft-ietf-bfd-rfc5884-clarifications-03.txt>
summary - ready for publication
This document clarifies how best to operate multiple BFD (Bidirectional
Forwarding Detection) sessions in MPLS environments. Any document that purports
to clarify operational procedures is, by definition, a good thing when it comes
to operational impact, assuming the document is clear and makes sense. This
document is clear and makes sense.
One suggestion though.
The first observation in Section 2.3 says:
The BFD session MAY be removed in the egress LSR if the BFD
session transitions from UP to DOWN. This can be done after the
expiry of a configurable timer started after the BFD session state
transitions from UP to DOWN at the egress LSR.
It might be helpful to specifically say what the aim of using such a timer is.
My guess is that the timer is used to introduce hysteresis to reduce flapping -
but it would nice to say one way or the other
draft-ietf-ospf-node-admin-tag
I share Alvero's Discuss about whether these tags are opaque.
- I think Alavaro and Brian make some good points. I'll be interested in how that discussion turns out. - Good to see that you recognise that even opaque tag values can expose sensitive information (the attacker isn't limited in how they are allowed interpret what they see). However, given that we recognise that confidentiality ought be provided sometimes, isn't there an onus on us to actually provide some usable way to get that service? If so, then who is looking at that problem? If not, then why is that acceptable? (This isn't a discuss as I don't think there is any PII or similar information being transferred, and the confidentiality requirement here really relates to network topology etc. But please do correct me if one of these tags could be PII-like and I'll make this a discuss if that's better.)
Section 3.2. (Elements of procedure) says that the "interpretation of tag values is specific to the administrative domain of a particular network operator", which makes them opaque and obviously locally significant. I then have an issue with the following text, which tries to (using rfc2119 keywords) specify how to interpret the tags, which doesn't make sense to me given the text above: Each tag MUST be treated as an independent identifier that MAY be used in policy to perform a policy action. Tags carried by the administrative tag TLV SHOULD be used to indicate independent characteristics of a node. The administrative tag list within the TLV MUST be considered an unordered list. Whilst policies may be implemented based on the presence of multiple tags (e.g., if tag A AND tag B are present), they MUST NOT be reliant upon the order of the tags (i.e., all policies should be considered commutative operations, such that tag A preceding or following tag B does not change their outcome). To avoid incomplete or inconsistent interpretations of the per-node administrative tags the same tag value MUST NOT be advertised by a router in RI LSAs of different scopes. The same tag MAY be advertised in multiple RI LSAs of the same scope, for example, OSPF Area Border Router (ABR) may advertise the same tag in area-scope RI LSAs in multiple areas connected to the ABR. . . . Being part of the RI LSA, the per-node administrative tag TLV must be reasonably small and stable. In particular, but not limited to, implementations supporting the per-node administrative tags MUST NOT tie advertised tags to changes in the network topology (both within and outside the OSPF domain) or reachability of routes. . . . instances of the RI LSA. The node administrative tags associated with a node that originates tags for the purpose of any computation or processing at a receiving node SHOULD be a superset of node administrative tags from all the TLVs in all the received RI LSA instances originated by that node.When an RI LSA is received that changes the set of tags applicable to any originating node, a receiving node MUST repeat any computation or processing that is based on those administrative tags. If the tags are opaque, I don't think that anything can be mandated as to how they are interpreted or what they're used for. That is the point I want to talk about with this DISCUSS.
Related to the DISCUSS: Section 3.2 says that the "meaning of the Node administrative tags is generally opaque to OSPF", are there cases where the meaning is not opaque? Even if the application is well known there is no indication that the tag is not opaque. Yes, this is a nit with the word "generally". All the references related to rfc4970 should be changed to draft-ietf-ospf-rfc4970bis.
The shepherd write up says that there have been no IPR disclosures, but there has in fact been a disclosure on an earlier version. Wast he working group aware of this disclosure? 3.2, paragraph 4: "Each tag MUST be treated as an independent identifier that MAY be used in policy to perform a policy action." Given the context of the previous MUST, the MAY seems more descriptive than normative.
- "Tags carried by the administrative tag TLV SHOULD be used to indicate independent characteristics of a node." I was initially confused by that sentence. So there are tags carried by a different TLV than the administrative one? Actually, no (I checked with one of the authors). I would simply write: "Administrative tag TLV SHOULD be used to indicate independent characteristics of a node." This would be in line with the definition: An administrative Tag is a 32-bit integer value that can be used to identify a group of nodes in the OSPF domain. - Router information LSA [RFC4970] can have link, area or AS level flooding scope. Choosing the flooding scope to flood the group tags are defined by the policies and is a local matter. "and is a local matter". Hopefully there is some sort of centralized management application that checks consistency.
Thanks for your responsive and helpful feedback to the SecDir review. The suggested and agreed changes look good and I'll continue to watch the thread as the discussion seems to be going very well and is managed very well on both ends. Thank you! https://mailarchive.ietf.org/arch/msg/secdir/FT81G3Iml0J1alWq5wdVaBYXiao
The abstract reads a bit oddly, repeating "This document describes an extension to OSPF protocol". Perhaps while you're making changes to address the other IESG comments, you could re-word the abstract to avoid that repetition.
I support Alvaro's DISCUSS position. I also wonder why we are turning OSPF into a generic container protocol. That approach has caused issues with BGP and I don't see it being any better doing it in OSPF.
David Black did the opsdir / genart review updates were applied to the reviewed version
draft-ietf-ospf-rfc4970bis
I just have a nit: The text immediately under the Section 2 header is only related to OSPFv2 — that would fit better under 2.1. (OSPFv2 Router Information (RI) Opaque LSA). Leave the general header for general information.
draft-kivinen-ipsecme-oob-pubkey
A minimal-value-added comment follows, so I apologize in advance ... Would a better title for this document be "Algorithm-agnostic Raw Public Keys for IKEv2"? At a minimum, "More *Types of* Raw Public Keys for IKEv2" seems more accurate. I'm not a SEC guy, but I'm reading "more keys" as "more key values", and I'm pretty sure that's wrong.
- Good stuff, we must remember to define this for eddsa. - intro and security considerations: "Secure DNS" might be better as DNSSEC (Sorry if this is the reverse of some comment you've previously processed.)
In addition to Spencer's comment, which I agree with, I have some minor editorial comments about the abstract: The Internet Key Exchange Version 2 (IKEv2) protocol only supports RSA for raw public keys. As written, this sounds like it means that the only time IKEv2 supports RSA is when you're using raw public keys. What you actually mean is that when you're using raw public keys, only RSA is supported. You should re-word it, perhaps like this: NEW When using raw public keys in the Internet Key Exchange Version 2 (IKEv2) protocol, only RSA keys are supported. END This document updates RFC 7296 You're missing a "." here, but I suggest that you just roll this into the last sentence of the first paragraph instead: NEW This document updates RFC 7296, adding support for other types of raw public keys to IKEv2. END
draft-ietf-v6ops-pmtud-ecmp-problem
In section 3, "Mitigation", I'm reading this.
Mitigation of the potential for PTB messages to be mis-delivered
involves ensuring that an ICMPv6 error message is distributed to the
same anycast server responsible for the flow for which the error is
generated. Ideally, mitigation could be done by the mechanism hosts
^^^^^^^
use to identify the flow, by looking into the payload of the ICMPv6
message (to determine which TCP flow it was associated with) before
making a forwarding decision. Because the encapsulated IP header
occurs at a fixed offset in the ICMP message it is not outside the
realm of possibility that routers with sufficient header processing
capability could parse that far into the payload. Employing a
mediation device that handles the parsing and distribution of PTB
messages after policy routing or on each load-balancer/server is a
possibility.
Most of the document is about using other mitigations that make this mitigation
unnecessary, but it's still a bit odd to see Deep Packet Inspection
characterised as "ideally", now that RFC 7258 is now BCP 188, and we've
chartered TCPINC to make that DPI fail as often as possible.
Could that one word go away?
I see in email that Fred asked if any reviews were needed before submitting
this draft for publication, and David Black suggested reviews from INT and TSV,
and that made it as far as the shepherd writeup, but I'm not seeing a request
for review popping up in TSV (at least not with "PMTUD" and "V6OPS" in an
e-mail). I don't have concerns about this particular draft, but I wish it
hadn't slipped through that particular crack.
Yes, Fred copied TSVWG and TSVAREA on his note asking for guidance, and yes,
there was an IETF Last Call, so I'm not hitting "Defer" to chase that. Just
something to watch for, in the future.
And yes, Martin and I have a call set up to talk with the TSVdir triage team
next week ...
I agree with Spencer's comment about not using the word "Ideally" when talking about payload inspection.
Thanks for a useful document. I'd probably have expanded ECMP in the abstract, and included a reference to the relevant RFC in Section 1.
The following sentence int he Security Considerations section is hard to read, can you adjust it? The proxy replication results in devices not associated with the flow that generated the PTB being recipients of an ICMPv6 message which contains a fragment of a packet.
Really nice document, Thanks for writing it!
Given the current state of affairs, I think this is a quite useful document. I just have a question for my own knowledge. Is there any data that indicates how many of these PTB messages are due to tunneling?
it's mine, what can I say.
draft-ietf-tcpm-rtorestart
Thanks for producing this. It looks helpful. I had a few comments you might consider. Overall - I'm reading "restart the RTO timer" and its variations as an action that would *increase* the delay before retransmission, but that's backwards - RTOR is an action that can *decrease* the delay before retransmission. I suspect I'm not the only reader who would be confused on this. The word "restart" is pervasive in this document (I counted 48 occurances, including page headers), so I can't reasonably ask about using a different term, but I'm wondering if it would be clearer if the abstract said something like OLD The modification, RTO Restart (RTOR), allows the transport to restart its retransmission timer so that the effective RTO becomes more aggressive in situations where fast retransmit cannot be used. NEW The modification, RTO Restart (RTOR), allows the transport to restart its retransmission timer using a smaller delay, so that the effective RTO becomes more aggressive in situations where fast retransmit cannot be used. In the Introduction, Second, when a sender receives duplicate acknowledgments, or similar information via selective acknowledgments, the fast retransmit algorithm infers data loss and triggers a retransmission. this is describing retransmission without any conditions. A couple of sentences later, the text describes the conditions that trigger a retransmission, so the paragraph gets it right in total, but it might be clearer if this sentence said something like Second, when a sender receives duplicate acknowledgments, or similar information via selective acknowledgments, the fast retransmit algorithm suspects data loss and can trigger a retransmission. In this sentence, Further experimentation is needed to determine this and thereby move this specification from experimental to proposed standard. if you make other text changes, you might consider s/to proposed standard/to the standards track/. In a perfect world, the specification might advance beyond proposed standard, given deployment experience ...
Here is Tim's OPS DIR review: This document describes an experimental modification to the TCP Retransmission Timeout (RTO) to act more aggressivly in connections that are short-lived or application limited. It's well written. The document is for both TCP and SCTCP, though primarily the TCP implementation is discussed. This is fine as it is experimental. I found one thing in the introduction: This document describes a modified sender-side algorithm for managing the TCP and SCTP retransmission timers that provides faster loss recovery I believe that it should be "provide" singular and not plural. In section 4, there is this text: The RECOMMENDED value of rrthresh is four, as this value will ensure that RTOR is only used when fast retransmit cannot be triggered. This update needs TCP implementations to track the time elapsed since the transmission of the earliest outstanding segment (T_earliest). The text is saying the implementation track time elapsed, so should it say: "With this update, TCP implementations MUST track the time elapsed..."?
A comment to Benoît's comment that quotes the opsdir review saying, 'I believe that it should be "provide" singular and not plural.' No, "provides" goes with "algorithm", and is correct as written.
tow Tim Wicinski performed the opsdir review.
draft-ietf-v6ops-siit-dc-2xlat
A small editorial thing in the abstract:
This document describes an extension of the Stateless IP/ICMP
Translation for IPv6 Internet Data Centre Environments architecture
(SIIT-DC), which allows applications, protocols, or nodes that are
incompatible with IPv6, and/or Network Address Translation to operate
correctly in an SIIT-DC environment.
With the comma after "IPv6", it looks like you mean this:
which allows
1. applications, protocols, or nodes that are
incompatible with IPv6
and/or
2. Network Address Translation
to operate correctly in an SIIT-DC environment.
...when what you mean is this:
which allows applications, protocols, or nodes that are
incompatible with
1. IPv6
and/or
2. Network Address Translation
to operate correctly in an SIIT-DC environment.
I suggest removing the comma.
draft-ietf-v6ops-siit-dc
I didn't see a response to the SecDir review, so maybe you didn't see it: https://www.ietf.org/mail-archive/web/secdir/current/msg06071.html In particular, it would be good to see a response on the following: 2.2.1. e.g. we might want to expand more on the risk that the DC does by design not see that we translate this down to V4 at the edge and thereby loose some of the capabilities of V6 beyond the edge. Therefore the DC may assume a fully V6 conformant client, which is not the case. This may lead to the need of further filtering or protection mechanisms at the edge. 2.2.2. the authors should expand more on architecture requirements not to put two of these translators in sequence (see possibly conflicts with 2.2.3. the authors should expand more on restrictions of putting this in a mixed environment with NAT64 For this one, I was mostly fine with the text, but are there security considerations that need to be spelled out? 7. section 4.9. "MTU and Fragmentation": it is good that we spell out the series of key differences between IPv4 and IPv6 relating to packet sizes and fragmentation that one needs to consider when deploying SIIT-DC. I am not sure a "should" is sufficient here. Furthermore, it would be good to consider whether we need to specify and mandate the specific behaviour when encountering these limitations to avoid inconsistent behaviour from the BR if these parameters are encountered and this might be exploited as an attack vector. Thanks! I think you already address his concern for 2.1 in the Security Considerations.
draft-ietf-cdni-media-type
The secdir review [1] suggests to check some ABNF. I'd say that would be a good plan as errors like that are more of a pain later. [1] https://www.ietf.org/mail-archive/web/secdir/current/msg06093.html
Here is Menachem's OPS DIR review: "Introduction and Scope" section 4th sentence ------------------------------------------------------------------ OLD: To accomplish this aims, this document defines SUGGEST: To accomplish this aim, this document defines I found that the organization of the document caused me some difficulty because the definition of the media type and payload type parameter was handled within the request to IANA. Normally a separate IANA section is added at the end of the document which refers to the items in the main document body.
menachem dodge was the opsdir reviewer.
draft-blanchet-ccsds-urn
Suggestion: might be nice to add an ack to Adrian Hooke in section 9. Not sure why, but this kind of cross-organisational document seems like an appropriate place to acknowledge his efforts. But that's just a suggestion, if you don't think it is the right thing or right place for that, that's fine by me.
10.1: It seems to me that all of these should be normative references. 3.13: " Global URNs are relevant for the space agencies networks both in space and on Earth." One wonders if the "Global" scope is not big enough :-)
conflict-review-irtf-cfrg-curves