IESG Narrative Minutes
Narrative Minutes of the IESG Teleconference on 2017-06-22. These are not an official record of the meeting.
Narrative scribe: John Leslie and Ignas Bagdonas (The scribe was sometimes uncertain who was speaking.)
Corrections from: (none)
1 Administrivia
2. Protocol actions
2.1 WG submissions
2.1.1 New items
Telechat:
Telechat:
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:
3.1.2 Returning items
3.2 Individual submissions via AD
3.2.1 New items
3.2.2 Returning items
3.3 Status changes
3.3.1 New items
3.3.2 Returning items
3.4 IRTF and Independent Submission stream documents
3.4.1 New items
Telechat:
Telechat:
3.4.2 Returning items
4 Working Group Actions
4.1 WG Creation
4.1.1 Proposed for IETF Review
4.1.2 Proposed for Approval
4.2 WG Rechartering
4.2.1 Under evaluation for IETF Review
4.2.2 Proposed for Approval
5. IAB News We can use
6. Management Issues
Telechat::
Telechat::
Telechat::
Telechat::
Telechat::
7a. Other Business
1054 EDT entered Executive Session
(at 2017-06-22 06:00:37 PDT)
draft-ietf-mpls-app-aware-tldp
1: Does this document really need 6 front page authors?
2: The shepherd writeup says: "We are aware of several intentions to implement
this secification. An implementation poll has been sent to the working group
and as further information is received, the write-up will be updated." -- was
any further info received?
3: The shepherd writeup also says: "There is one small issue that I'm currently
clearing with IANA." -- is this the value of the status code E bit? Or some
other issue?
Nits:
1: There are are a number of unexpanded acronyms -- e.g: LSP is no "well known"
- https://www.rfc-editor.org/materials/abbrev.expansion.txt
2: Sec 1 Introduction
"LDP uses extended discovery mechanism to establish..." - "LDP uses *the*
extended discovery mechanism" (or discovery *mechanisms*)
3: Sec 1 Introduction
"An LSR initiates extended discovery... " - "A LSR..." ("An Label Switch"
wouldn't make much sense)
4: Sec 1 Introduction
"In addition, since the session is initiated and established after adjacency
formation, the responding LSR has no targeted applications information to
choose the targeted application" - "has no targeted applications information
available to choose which targeted application".
5: Sec 1 Introduction
"Also, targeted LDP application is mapped .." - "Also, the targeted LDP
application is mapped"
6: Sec 1.2 Terminology
"This document uses terminology discussed in [RFC7473] along with others
defined in this document." feels clumsy. How about: "In addition to the
terminology defined in [RFC7473], this document uses the following terms: "
7: Sec 2.1 Encoding
"An LSR MAY advertise that it is capable to negotiate a targeted LDP ..." - "An
LSR MAY advertise that it is capable of negotiating a targeted LDP ..."
1. A pointer to the applications mentioned in the Introduction would be nice (FEC 128, rLFA, etc.) in first mention. 2. In Section 2.2 (Procedures): 2.1. "The TAC TLV's Capability data MAY consists of none, one or more TAE each pertaining to a unique TA-Id that a LSR supports over the session." If there is no TAE, how can it be related to a TA-Id? Also, I think that the "MAY" in this case is just stating a fact, so it should be "may". 2.2. "For instance, if the tLDP session is established for BGP auto discovered pseudowire, only FEC 129 label bindings MUST be distributed over the session." That "MUST" shouldn't be in caps because it is part of an example. 2.3. TAI is used instead of TA-Id twice at the end of the section.
I have a small list of issues that I think you should look at: LSR -- needs expansion in the Abstract, as it is not an abbreviation recognized by RFC Editor. In 2.2 If the receiver LSR does not receive the TAC TLV in the Initialization message or it does not understand the TAC TLV, the TAC negotiation MUST be considered unsuccessful and the session establishment MUST proceed as per [RFC5036]. Firstly, you can't have requirements on any implementation that doesn't support this specification. Secondly, the last MUST is already the default. So I think use of RFC 2119 lange here is not appropriate, you should just use "is considered" and "proceeds". The following text: If it sets the session setup retry interval to maximum, the session MAY stay in a non-existent state. When this LSR detects a change in the responding LSR configuration or its own configuration pertaining to TAC TLV, it MUST clear the session setup back off delay associated with the session in order to re-attempt the session establishment. is repeated twice in the same section. What is "TAI"? In 5.2: the section is titled "Use Cases", so I didn't expect any normative RFC 2119 language in there. Some MAY seem not to be specifying implementation choices, so they should be "may".
This should be easy to fix, but needs to be fixed before the draft progresses: Section 7 establishes a new IANA registry under the Label Distribution Protocol (LDP) Parameters page. Unless I missed something (which happens) it doesn't specify the registration policy as required by BCP26. Please see RFC 5226 section 4.1 for details.
-General: When you use the word "application", is a person skilled in MPLS automatically going to think in terms of the sort of "applications" listed here? If not, it would be good to have a paragraph early in the introduction that describes what you mean by "applications". As an application-layer person, I tend to think of it in terms of application-layer applications. Am I correct to assume that it would not make sense to register, for example, HTTP in the the LDP Targeted Application Identifier registry? - 1.1: I noticed a number instances of at least "may" in lower case. If your intent is that lower case words not be treated as keywords, please consider using the new boilerplate from RFC 8174 Nits: -1, first paragraph: "LDP uses extended discovery mechanism..." Missing article before "discovery". -2.2, paragraph 4 and 5, "... a maximum value, as 0xffff.": should "as" be "such as"? -2.2, paragraphs 6 and 7: the "it" in the opening sentence of each paragraph has an unclear antecedent.
nits regarding use of normative language: 1) sec 2.2.: „Therefore, if the intersection of the sets of received and sent TA-Id is null, then LSR MUST send 'Session Rejected/Targeted Application Capability Mis- Match' Notification message to the initiating LSR and close the session.“ Probably no need to make this normative MUST again in the example text -> s/MUST send/sends/ 2) Similar the use of normative language in the use case section (5) does not seem to be appropriate, or at least not consistent. Maybe just convert all upper cases MAYs to lower case in that section.
Document: draft-ietf-mpls-app-aware-tldp-00.txt
LDP can use the extended discovery mechanism to establish a tLDP
adjacency and subsequent session as described in [RFC5036]. An LSR
Please expand LDP and tLDP on first use. Also, I don't see tLDP in
RFC 5037 despite the citation
S 2.1.
A Targeted Applications Capability data consists of none, one
or more 32 bit Targeted Application Elements. Its encoding is
as follows:
This is ungrammatical. Is it intended to say "zero or more"?
S 2.2.
If the receiver LSR does not receive the TAC in the Initialization
message or it does not understand the TAC TLV, the TAC negotiation
MUST be considered unsuccessful and the session establishment MUST
proceed as per [RFC5036]. On the receipt of a valid TAC TLV, an LSR
MUST generate its own TAC TLV with TAEs consisting of unique TA-Ids
that it supports over the tLDP session. If there is at least one TAE
common between the TAC TLV it has received and its own, the session
MUST proceed to establishment as per [RFC5036]. If not, A LSR MUST
send a 'Session Rejected/Targeted Application Capability Mis-Match'
Notification message to the peer and close the session. The
initiating LSR SHOULD tear down the corresponding tLDP adjacency
after send or receipt of a 'Session Rejected/Targeted Application
Capability Mis-Match' Notification message to or from the responding
LSR respectively.
This seems like odd semantic: if I don't understand the TLV, I continue
with session establishment, but if I understand it but there's no overlap
I close the session?
instance, suppose a initiating LSR advertises A, B and C as TA-Ids.
Further, suppose the responding LSR advertises C, D and E as TA-Ids.
Than the negotiated TA-Id, as per both the LSRs is C. In the second
instance, suppose a initiating LSR advertises A, B and C as TA-Ids
and the responding LSR, which acts as a passive LSR, advertises all
the applications - A, B, C, D and E that it supports over this
session. Than the negotiated targeted application as per both the
Should this say "applications"? It seems like you're just computing
intersection.
If the Targeted Application Capability and Dynamic Capability, as
described in [RFC5561], are negotiated during session initialization,
TAC MAY be re-negotiated after session establishment by sending an
updated TAC TLV in LDP Capability message. The updated TAC TLV
carries TA-Ids with incremental update only. The updated TLV MUST
consist of one or more TAEs with E-bit set or E-bit off to advertise
or withdraw the new and old application respectively. This may lead
to advertisements or withdrawals of certain types of FEC-Label
bindings over the session or tear down of the tLDP adjacency and
subsequently the session.
So, advertisements are cumulative? If I advertise A, B and then C,
that means I do A, B, C?
Please expand the following acronyms upon first use and in the title; see https://www.rfc-editor.org/materials/abbrev.expansion.txt for guidance. - LSR - Label Switching Router - mLDP - Multipoint LDP - PQ - Unknown - TAI - Unknown - RSVP-TE - RSVP - Traffic Engineering - P2MP - Point-to-Multipoint - PW - pseudowire - P2P-PW - Peer-to-peer Psuedowire (presumably?) - MP2MP - Multipoint-to-Multipoint - HSMP - Unknown - LSP - Label Switched Path - MP2P - Unknown (should this be P2MP?) - MPT - Unknown
draft-ietf-avtcore-rfc5285-bis
Thanks to Carlos for the opsdir review. Nit: Page 6 - "Extension element types that dp not match the header extension format" s/dp/do/
In general this is a well written document, but I have a small list of issues that you should consider fixing: In Section 5: When SDP signaling is used for the RTP session, it is the presence of the 'extmap' attribute(s) that is diagnostic that this style of header extensions is used, not the magic number indicated above. You lost me here. Which magic number do you mean here? In Section 7: If an extension is marked as "sendonly" and the answerer desires to receive it, the extension MUST be marked as "recvonly" in the SDP answer. An answerer that has no desire to receive the extension or does not understand the extension SHOULD remove it from the SDP answer. Why is this not a MUST? If an extension is marked as "recvonly" and the answerer desires to send it, the extension MUST be marked as "sendonly" in the SDP answer. An answerer that has no desire to, or is unable to, send the extension SHOULD remove it from the SDP answer. As above. In Section 9: In order to prevent DOS attacks, for example, by changing the header extension integrity protection SHOULD be used. I can't parse this sentence.
I like it. I did have a couple of non-blocking questions. I couldn't parse this sentence. "A transmitter may be aware that an intermediary may add RTP header extensions in this case, the transmitter SHOULD use two-byte form." I think In the one-byte header form of extensions, the 16-bit value required by the RTP specification for a header extension, labeled in the RTP specification as "defined by profile", MUST have the fixed bit pattern 0xBEDE (the first version of this specification was written on the feast day of the Venerable Bede). is flipping awesome, but likely impenetrable for folks who haven't studied English history in the 600s and 700s. Perhaps a reference, or, more likely, just say "May 25" so it's not a mystery?
OLD: The other major change is to update the requirement from the RTP specification and[RFC5285] NEW: The other major change is to update the requirement from the RTP specification [RFC5285]
There are two variants of the extension: one-byte and two-byte headers. Since it is expected that (a) the number of extensions in any given RTP session is small and (b) the extensions themselves are small, the one-byte header form is preferred and MUST be supported by all receivers. A stream MUST contain only one-byte or two-byte "or only two-byte" would be clearer. headers unless it is known that all recipients support mixing, either by SDP Offer/Answer [RFC3264] negotiation (see section 6) or by out- of-band knowledge. Each RTP packet with an RTP header extension following this specification will indicate if it contains one or two byte header extensions through the use of the "defined by profile" field. Extension element types that dp not match the header do not match extension format, i.e. one- or two-byte, MUST NOT be used in that RTP packet. Transmitters SHOULD NOT use the two-byte form when all extensions are small enough for the one-byte header form. Transmitters that intend to send the two-byte form SHOULD negotiate the use of IDs above 14 if they want to let the Receivers know that they intend to use two-byte form, for example if the RTP header extension is longer than 16 bytes. A transmitter may be aware that an intermediary may add RTP header extensions in this case, the transmitter SHOULD use two-byte form. I think you want '; in this case...." if this means what I think it means. assignment of different IDs. Any RTP header extension that do not does not match this assumption MUST explicitly provide rules for what are cipher. It can be noted that the default SRTP ciphers (AES CM 128 bits with HMAC-SHA1) are relative weak and more modern ciphers are stronger and should be considered. What's weak about AES-CTR-HMAC? I recognize that this was in the secdir review, but I'm not sure what claim you are making here.
The use of the term "local" in this document is implicit and therefore confusing. Section 5 refers to "local identifier (ID)", while section 7 refers to "Local identifiers". Neither indicates what the identifiers are local to, and some implementors have chosen to interpret this as meaning "local to the sender machine." See, for example, https://bugzilla.mozilla.org/show_bug.cgi?id=1361206 I believe the intention here is for "local" to mean "local to this session." This meaning should be made explicit. And, for avoidance of doubt, the document should clarify that the negotiated identifiers use the same numeric value in both directions. This is implied by much of the text, but it never stated outright. Because so many other session attributes (e.g., payload types) can be negotiated to be different in each direction, many implementors are likely to assume the same applies here. As the above bug demonstrates, this leads to real interop issues in the field. Nits: element (no alignment is needed), and parsing stops at the earlier of the end of the entire header extension, or in one-byte headers only case, on encountering an identifier with the reserved value of 15. Put quotation marks around "one byte headers only". ____ Each extension element MUST starts with a byte containing an ID and a length: s/starts/start/ ____ The attribute definition in section 6 says "Value:" instead of "Value: none." -- Fix or refer to the IANA section instead.
draft-ietf-pals-p2mp-pw-lsp-ping
I share Mirja's curiosity about the potential for amplification attacks, but I'll watch that conversation, so no need to reply to me.
I like the solution, but the document could do with some editing. Major: 1: Sec 1. Introduction O: Multi-segment Pseudowires support is out of scope of this document at present and may be included in future. P: Multi-segment Pseudowires support is out of scope of this document. C: Once published as an RFC, the document doesn't change. Could be "... may be addressed in a future document", but I'd suggest leaving it out. 2: General The document has many unexpanded acronyms, e.g: ACH in "... MPLS label stack and IPv4 or IPv6 ACH." In the Introduction you have: "such as P2MP ATM over PSN." - while PSN might count as a well known acronym, it feels like, in an Intro it should be less opaque - see https://www.rfc-editor.org/materials/abbrev.expansion.txt for RFC known acronyms. 3: The "Controlling Echo Responses" section feels weak -- it says that "The procedures ... **can** be applied to P2MP PW LSP Ping." (emphasis added) - it feels like this should be a SHOULD? I think better a description of the DoS implications (other than just pointing at RFC6425) is also important. Nits: 1: The document would benefit from some serious grammar checking -- e.g: "... Echo Request to inform the receiver at P2MP MPLS LSP tail, of the P2MP PW being tested." - extra ','. "For Inclusive P-Trees, P2MP MPLS LSP label itself can uniquely identify the Throughout the document..." - missing 'the' - things like this, and confusion over plurals (especially near acronyms) makes the document hard to read / review. 2: "P2MP ATM over PSN. Requirements for ... " - extra space (nit!) 3: Sec 8. Security Considerations "The proposal introduced in this document does not introduce any new security considerations beyond that already apply to [RFC6425]." -- this sentence is poorly formed. Perhaps "beyond those that..."? Or "beyond those in"?
I agree with Suresh's DISCUSS.
I think the P2MP Pseudowire Sub-TLV in Section 4.1 is a bit under-specified. It is unclear how the address family of the originating router's IP address is communicated. Is this purely derived from the IP Addr Len (i.e. Len is 4 => IPv4, Len is 16 => IPv6)? If so, I think it would be useful to state this explicitly and add some validity checking and error handling for values other than 4 and 16.
Are there no alignment requirements for the IP address in "Originating Routers IP Addr" inside the sub-TLV? I would think that alignment on a 4 byte boundary might be needed.
Please expand LSP and FEC on first mention. Please consider expanding PSN and LDP (I see they are marked as "well-known" in the abbreviation list, but I think expansion would be helpful in context.)
The LSP Ping Echo request IPv4/UDP packets is encapsulated with the
MPLS label stack as described in previous sections, followed by one
of the two encapsulation options:
IPv4 only?
And here Tianran Zhou's OPS DIR review:
No issue found. This document is well written, and is ready for publication.
Only a couple of nits, for the authors consideration:
1. in section 1, "Multipoint LDP (mDLP)"
Is the acronym "mLDP"?
2. in section 1,
"Multi-segment Pseudowires support is out of scope of this document at
present and may be included in future."
At this stage, the I-D is stable. I think you can just say "Multi-segment
Pseudowires support is out of scope of this document".
3. in section 6,
"MLDP" should align with the previous acronym in section 1, i.e. "mLDP".
And there is auto check result from the system:
== Unused Reference: 'RFC5085' is defined on line 325, but no explicit
reference was found in the text
** Obsolete normative reference: RFC 4379
Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 1 comment (--).
Run idnits with the --verbose option for more detailed information about
the items above.
Document: draft-ietf-pals-p2mp-pw-lsp-ping-03.txt Assuming I am understanding this document correctly, it's just a refinement of MPLS Echo to point out a specific receiver to respond. Is that correct? If so, perhaps you could make that clear in the intro. This document is pretty acronym heavy. Please ensure that every acronym is expanded on first use. Examples include LSP, VPN, VPLS, etc. Similarly, LSP Tail/Bud, etc. need citations. Figure 2 would benefit from some explanations of the packet flow. Where does the echo packet start, where does it stop? Who answers, etc.
I share Suhas' concerns. Please expand the following acronyms upon first use and in the title; see https://www.rfc-editor.org/materials/abbrev.expansion.txt for guidance. - P2MP - Point-to-Multipoint - PW - pseudowire - LSP - Label Switched Path - VPLS - Virtual Private LAN Service - TE - Traffic Engineering (?) - FEC - Forwarding Equivalence Class - LSR - Label Switching Router - GAL - Generic Associated Channel Label - ACH - Associated Channel Header - CE - ??? - PE - Provider Edge
I understand that this document does not introduce any new mechanisms compared to rfc6425, however, I think both documents enable an amplification attack. Is this not a concern or should that be discussed somewhere?
draft-ietf-v6ops-v4v6-xlat-prefix
Thanks for rapidly addressing my DISCUSS point.
Like Suresh, I really appreciated the discussion of rationale in section 4. There is one possibility that I'm surprised is not discussed; namely, allocating 64:ff9b::/48 for this purpose, with the subset of addresses in 64:ff9b::/96 being *additionally* subject to the restrictions of RFC 6052. This would seem to have the advantages of: - Complete address adjacency without the disadvantages of using 64:ff9a:ffff::/48 - Sharing an even longer prefix (48 bits) than the 31-bit and 47-bit prefixes discussed in the document - Eliminating the caveat described in the final paragraph of section 5 entirely This is obvious enough that it had to be considered and rejected by the WG; including the rationale for rejecting it seems appropriate here.
draft-ietf-avtext-lrr
Firstly, thank you for addressing Fred Baker's OpsDir comments - https://datatracker.ietf.org/doc/review-ietf-avtext-lrr-05-opsdir-lc-baker-2017-06-07/ -- this change "fixes" the document for me. I found this document easy to read, and a useful introduction to the topic; this is in spite of my knowing basically nothing about codecs and RTCP. I did have some nits and a larger question: Question: 1: 3.1. Message Format (and others) The document says things like: " When C is 1, TTID MUST NOT be less than CTID, and TLID MUST NOT be less than CLID;" -- cool, no worries... But, what do I do if I receive an LRR feedback message where e.g: the TTID *is* less than CTID? Do I just ignore the message? Do I self destruct? (Basically, what does error-handling look like?) Nits: 1: 2.1. Terminology "In a layer refresh, however, other layers than the ones requested for refresh may still..." To me the "other layers" bit sounds clumsy - "In a layer refresh, however, layers other than the ones requested for refresh may still..." reads much better - this construct is in a few other places too. I don't think that this changes the meaning at all; tis just a nit, feel free to ignore. 2: The "numbers" in the figures feel like they are going backwards (or I've completely misunderstood the document :-)) -- I would expect the frame numbered '1' to be the first frame, and the second to be numbered 2. So, the number in the diagrams would go " 4 3 2 1 "; otherwise, you are counting "down" towards frame 0. It feels weird (and is somewhat confusing) for e.g frame 2 to be based on frame 3 (and not frame 1). I have no idea if this is the convention for frame numbering - if so, feel free to ignore. 3: The convention is Security Considerations go just before IANA Considerations -- swap S6 and 7? (Hey, I did say these are nits!)
S 2.1.
In a layer refresh, however, other layers than the ones requested for
refresh may still maintain dependency on earlier content of the
stream. This is the difference between a layer refresh and a Full
This "however" is hard to read because the entire previous graf
talks about layer refreshes.
All the diagrams in this section would be a lot easier to read
if they said that <- means "refers to"
S 3.1
The Feedback Control Information (FCI) for the Layer Refresh Request
consists of one or more FCI entries, the content of which is depicted
in Figure 5. The length of the LRR feedback message MUST be set to
2+3*N, where N is the number of FCI entries.
You should state that the length is in 32-bit words.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RES | TTID| TLID | RES | CTID| CLID (opt) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
How is CLID optional? It seems like it still has to be there,
unless I am misreading the text.
Reserved (RES) (16 bits / 5 bits / 5 bits) All bits SHALL be set to
0 by the sender and SHALL be ignored on reception.
I would mention that this is three fields.
Section 2.1: "...requires that a spatial layer be encoded in a way that references only lower-layer subpictures..." had me puzzled for quite some time, as I didn't think this was an inherent charateristic of *any* codec. It took quite a bit of re-reading before I figured out that this is referring only to the refresh packets themselves, not an intrinsic constraint on the stream across all time. Rephrase. The description of temporal scaling introduces the same confusion. I had the same heartburn as EKR regarding "(opt)" in Figure 5 -- given that it appears at the end of the data, there is a real risk that some implementors will attempt to literally omit the field rather than setting it to 0. Please remove the "(opt)". [n.b., I'm on the fence as to whether this should be a Comment or a Discuss, as it has the risk of introducing actual interop issues in the field]. The description for "Seq nr." indicates that the number is increased by "1 modulo 256." While it's certainly possible to figure out what is intended here, what this says on its face is to increase by one, as "1 modulo 256" is always one. Please rephrase to indicate that "modulo" applies to "Seq nr." instead of applying to "1". Section 3.2 indicates that the technique should not be used for picture losses (packet losses, presumably?), but instead for situations where not sending it would "render the video unusable." This all seems very subjective and ill-defined for normative statements. Please be precise with what you mean by "picture losses," and please give an example of when LRR SHOULD be used -- perhaps my imagination is a bit dull today, but I cannot come up with situations in which LRR would be appropriate, given this "MUST."
draft-jones-cose-rsa
This document seems sound overall. A few points which I believe
would improve it.
- The Private Key format seems like a straight translation of
RFC 8017's RSAPrivateKey but the explanation of the various
parameters in 8017 is a lot clearer. E.g.,
"exponent1 is d mod (p - 1)." versus "first factor CRT Exponent"
I would advice making the direct connection to 8017 and
adopting their descriptions.
- Is it really wise to be standardizing RSA-OAEP with SHA-1
at this point? I'm not claiming that there is a real attack,
but we are generally trying to not do anything new with
SHA-1.
"
value 32,768 is represented as the CBOR byte sequence 0b010_00010
(major type 2, additional information 2 for the length), 0x80
0x00."
I found this text hard to follow. I believe it would be improved by
putting the parenthetical at the end rather than in the middle.
- S 6.3. Rather than just saying "low" you should specify exactly
which ones you mean.
6.1: I wonder if "highly recommended" in paragraph 2 and "should not be used" in paragraph 3 warrant 2119 keywords. 6.3, paragraph 2: I wonder the same about "Keys used with RSAES-OAEP must follow the constraints...". But it's not clear to me whether this creates a new requirement to follow the constraints in 3447, or it it just references an existing requirement from 3447.
The "must" and "must not" in the final paragraph of section 6.3 seem normative in their intention (and are presumably why [Boneh99] is listed as "normative" rather than "informative" in the references section). Given that the document is using 2119 language elsewhere, I would suggest capitalizing them for avoidance of doubt. Please fix this nit: ** Obsolete normative reference: RFC 3447
draft-ietf-sacm-requirements
I am balloting ABSTAIN on this document as I don't see strong value in a set of requirements as a standalone document added to the RFC series. I appreciate it's an extension of the use-cases document and a WG milestone but it reads like the architecture and info model is already done (and indeed WG revisions of that work look mature). In which case I STRONGLY urge that the 10 pages of requirements be placed (as required) in appendices of the milestone documents (information-model, data-model, protocol/Interface, architecture etc). This maintains the rationale for the designs in question and aids the reader in comprehension of the work. That said, with ABSTAIN positions, I am not blocking publication of this document and I shall leave it to the responsible AD to adjudicate.
I spent a while trying to figure out how to ballot on this - I personally see
value in requirements, use-cases and similar (informational) documents - they
help newcomers to the technology understand how and why it is shaped as it is.
This document is also (kind of) mentioned in the charter ("A document or
documents describing the SACM Architecture. This will include protocol
requirements and their associated use cases as well as a description ..." , and
so I've decided on Yes
However, there are still some comments / nits which should be addressed,
including:
Abstract:
"The requirements and scope are based on the agreed upon use cases." -- what
use cases / agreed upon by whom? (Missing ref).
1. Introduction
"Today’s environment of rapidly-evolving security threats highlights the need
to automate the sharing of security information (such as posture information)
while protecting user information as well as the systems that store, process,
and transmit this information." - "... user information as well as the systems"
-> "user information and the systems" ? Not sure if this is better....
2. Requirements
I got somewhat lost in "A SACM transport protocol is one that runs on top of L3
protocols such as TCP/IP or L4 protocols such as HTTP, carries operations
(requests / responses), and moves data." - perhaps "A SACM transport protocol
is one that runs on top of L3 protocols (such as TCP/IP) or L4 protocols (such
as HTTP), carries operations (requests / responses), and moves data."
3: "With the information model defining assets and attributes to facilitate the
guidance, collection, and assessment of posture, these are some of the tasks
that should be considered:" - the "With" and "these" feel unrelated. I'm not
really sure how they are supposed to tie together, so I cannot suggest text.
G-001
"2. The query language MUST allow for general inquiries, as well as expression
of specific attributes or relationships between attributes to follow; the
retrieval of specific information ..." -- I don't really understand the "to
follow"; can it be struck?
G-002
"Interoperability: The data models, protocols, and transports must be
specified with enough details to ensure interoperability." -- I really don't
understand the point of saying this - are you expecting that if you *didn't*
say this that people would intentionally create models without enough detail?
Is this just a "motherhood and apple pie" statement?
G-006
"Mechanisms for this protection are unspecified but should include industry
best practices such as encrypted storage, encrypted transports, data checksums,
etc. " -- the list of best practices seems harmful; if you provide a list
people will implicitly assume it is exhaustive, and industry best practices
change over time. Also, what is a "data checksum"? I'm assuming you mean
something "cryptographic checksums" or "secure hash" - a data checksum implies
something like a simple CRC. I'd suggest just dropping the "such as..." list.
IM-004
"Data Model Identification: The information model MUST provide a means to
uniquely identify each data model uniquely." - you really really want this to
be unique, don't you :-P
5.2. Privacy Considerations
"In addition to identity and SACM capabilities information disclosure, the use
of time stamps or other attributes that can be used as identifiers especially
as they are coupled with an identity can be further used to determine a target
endpoint or user’s behavioral patterns." -- this sentence could use some work.
I agree with what it is trying to say, but it is long and confusing. Perhaps:
"In addition to identity and SACM capabilities information disclosure, the use
of time stamps (or other attributes that can be used as identifiers) could be
further used to determine a target endpoint or user’s behavioral patterns." --
I *think* that that maintains the meaning, but is clearer.
"Data confidentiality can provide some level of privacy but may fall short
where unecessary data is still transmitted." - "unnecessary" (typo)
The SACM charter requires the group to " whenever reasonable and possible, reuse existing protocols, mechanisms, information and data models. " If that is reflected anywhere in the requirements, I missed it. (which is possible.) In particular, I think section 2.6 needs to include requirements to favor use of existing "transfer protocols". (As written, T-001 seems almost tailored to counter arguments to "just use HTTP".)
General:
- I agree with the other abstain positions that the content in this draft
doesn't seem to warrant publication as an RFC. I'm not going to abstain over
it, since I think that sort of discussion should occur at charter or milestone
adoption time.
- I don't think the contents of this draft warrant the use of 2119 keywords.
While I think it reasonable to sometimes use 2119 keywords to add precision and
clarity to requirements on standards work, many of the requirements in this
draft seem vague and hand-wavy. All-caps MUSTs and SHOULDs only serve to give
the appearance of precision and verifiability. I mention a few more glaring
instances in my detailed comments, but those are not exhaustive.
Specifics:
- 1.1, 2nd paragraph: If you stick with using normative keywords, but want to
disclaim lower case versions, please consider switching to the boilerplate from
RFC 8174.
- 2.1 (and rest of document): I assume the requirements numbering scheme means
something. It would be helpful to describe that scheme prior to use.
- g-001: "SACM MUST allow
implementations to use their own extensions; either proprietary data
models, protocols or extensions to SACM data models or protocols
could be used though they are not considered to be SACM compliant."
That seems to say that SACM must allow extensions, but those extensions would
not be considered compliant. That seems like a contradiction. As worded with
the MUST, it seems like it says SACM cannot prevent implementations from doing
non-interoperable things.
- G-002: This is the whole point of IETF processes. It seems odd to state it as
a requirement.
- g-003: It seems like you are using "datagram" in an unconventional way. A
definition would help.
- g-004: "...MUST be suitably specified..." is vague and unverifiable.
- G-005: "For interoperability and
scope boundary,"
I don't understand what "scope boundary" means in that clause.
- G-006: Is this a requirement for e2e protection? It seems like it is, but the
description is vague. In particular, I cannot tell if the mention of
middleboxes is to say that middleboxes should not be able to read or modify
traffic, or if it is to say that middleboxes may be part of the architecture
and actually need that sort of access. (Also, the requirement title says
"integrity", but the text seems to be about both integrity and confidentiality.)
- G-015: "... accommodate considerations such as geographic,
regulatory, operational and federations..." seems vague for use with a MUST.
- ARCH-004: "The fact that a centralized or
decentralized deployment is used SHOULD be invisible to a consumer."
Can you elaborate on why? Might not a consumer want to consider the nature of a
data source?
- 2.6: The section switches between saying "transport protocols" and "transfer
protocols" Please be consistent.
- T-001: I think this needs some elaboration, or a citation to elaboration
somewhere else. Otherwise, it seems like this assertion opens the door for a
lot of complexity and lack of interoperability.
I generally dislike "requirements" documents, as most WG are not going to check
final protocol against requirements. However I can see that such documents can
be sometimes useful.
I have some specific comments on Section 2.6. It generally looks very confused
on transport protocol versa transfer protocol, which I don't think are synonyms:
2.6. Requirements for SACM Transport Protocols
I think you meant "Transfer Protocol" in the section title, as my understanding
that "SACM transfer protocol" != "SACM transport protocol"?
The term SACM transfer protocol is intended to be distinguished from
underlying layer 3 and 4 protocols such as TCP/IP, operating at an
equivalent level as the hyperText transfer protocol (HTTP). The SACM
transfer protocol is focused on moving data and performing necessary
access control operations; it is agnostic to the data model
operations.
The requirements for SACM transport protocols include:
Again, do you mean "transfer protocol" here?
(snip)
T-003 Data Confidentiality: SACM transfer protocols MUST be able to
support data confidentiality. SACM transport protocols MUST ensure
Do you really mean "transport protocol" above? This will rule out both TCP and
UDP.
data protection for data in transit (e.g. by encryption) to provide
confidentiality, integrity, and robustness against protocol-based
attacks. Note that while the transport MUST be able to support data
confidentiality, implementations MAY provide a configuration option
that enables and disables confidentiality in deployments.
Protection for data at rest is not in scope for transport protocols.
Again, "transfer protocols"?
Data protection MAY be used for both privacy and non-privacy
scenarios.
I do see the value of writing up the requirements to guide further work in the WG, but I do not see that value of publishing them in a standalone RFC. I would have much preferred the requirements to be included in the other WG deliverables (as Alvaro and Terry have noted). I do respect the WG's intent to publish and I am abstaining to move out of the way.
I'm following along with Mirja's Abstain, although I'm balloting No Objection.
I'm looking at
T-005 Transport Reliability: SACM transfer protocols MUST provide
reliable delivery of data. This includes the ability to perform
fragmentation and reassembly, and to detect replays. The SACM
transfer may take advantage of reliability features in the network
transport; however, the network transport may be unreliable (e.g.
UDP), in which case the SACM transport running over the unreliable
network transport is responsible for ensuring reliability (i.e. by
provisions such as confirmations and re-transmits).
and wondering why you'd want to run SACM transfer protocols over UDP in the
first place (and, assuming there's a fabulous reason to do that, why you
wouldn't run those protocols over UDP in all cases).
This is a No Objection position, but please recognize that these protocols
would be simpler if they were running over TCP.
I am ABSTAINing because I don't see publication value for this document given that the architecture and the information model are already done (or at least in an advanced state). I understand the interest of the WG to document the requirements as an RFC, so I won't stand in the way of publication. Having said that, if the original intent was for this document to be used as input for the development of the architecture, consider updating some of the text so that there's no mix of "timing": the text should probably read as if the architecture/information model don't exist yet; there are no references to them (which is good), but the text makes some mention of them... For example: Section 2 (Requirements) says that it "describes the requirements used by SACM to assess and compare candidate data models, interfaces, and protocols, to suit the SACM architecture." I'm guessing that "will be used", and that "by SACM" refers to the WG (SACM by itself is used extensively throughout). Note that the end says "to suit the architecture", which sounds like the architecture is a foregone conclusion and the requirements are just for the rest. Also in Section 2: "SACM defines an architecture and information model focused on addressing the needs for determining, sharing, and using posture information via Posture Information Providers and Posture Information Consumers mediated by a Controller." I didn't check, but this sounds like a quick description of the architecture and information model -- both of which would be developed based on this document.
- 3. The information model MUST accommodate the interoperable
addition of new data types and/or schemas.
I guess that you want to say: The data model MUST ...
See RFC 3444
-
Reading G-003, G-004, G-012, it seems like you want to be able to select your
"transport", with your own requirements.
However, I guess that, practically, you'll select a data model and the
transport will be obvious. MIB module => UDP IFPIX information elemeents =>
UDP/DTLS. Yeah, the specs say SCTP/TCP, but in practice ... YANG module, either
NETCONF => TCP/SSH or RESTCONF => HTTPS Not sure I believe into a single
transport to rules them all, where "them" is all the different data model
source of information. This was already my feedback during your previous
interim meeting (where I presented yangcatalog.org): your information model
draft is basically of a mix of elements already specified in IPFIX, YANG
module, MIB module. How do you consolidate all this?
Same remark with "2.5 requirements for data model operations".
You select your data model and the data model operations are given/specified
already Let's say: IPFIX. From there you have a push mechanism only (as opposed
to pull). Let's say: YANG module. From there you select NETCONF or NETCONF, and
the operations are already specified.
-
The SACM information model MUST include the
ability to discover and negotiate the use of a particular data model
or any data model.
What does it mean "negotiate"?
Either an end point supports a data model or it doesn't, no?
Same remark for:
DM-007 Data Model Negotiation: The interfaces and actions in the
data model MUST include capability negotiation to enable discovery
of supported and available data types and schemas.
- Read the following one multiple times, and I still don't understand it:
IM-005 Data Lifetime Management: The information model MUST provide
a means to allow data models to include data lifetime management.
-
The SACM information model represents an abstraction for "what"
information can be communicated and "how" it is to be represented and
shared.
Not sure it's aligned with RFC3444:
IM --> conceptual/abstract model
| for designers and operators
+----------+---------+
| | |
DM DM DM --> concrete/detailed model
for implementors
* Large datagrams: It is possible that the size of posture
assessment information can vary from a single assessment that is
small in size to a very large datagram or a very large set of
assessments (up to multiple gigabytes in size).
I would consider saying "message" here, because I usually think of "datagram"
as ~= packet/IP datagram.
I see little value in spending RFC editor resources on publishing this document, but don't feel strongly enough about it to abstain. I would be happy to see this document declared as having been useful for the working group's internal purposes, and having already served the entirety of its purpose, not progressed to an RFC.
I abstain because I don’t think there is a achievable value in publishing this document in the RFC series (for consumption outside the wg). However, I also don’t understand why there is a requirement to support multiple transport protocols, including potentially UDP. I don’t think this is worth a discuss on this document but if SACM plans to invent a new transport (over UDP) instead of just using TCP which seems more than appropriate, it needs a real justification for that (which is at least in this document not at all given)!
I too don't see the particular value of having this published as an RFC, but understand that the WG may view it differently. I offer the comments below for what they're worth. I think the document sows confusion in its use of the terms "transport protocol" and "transfer protocol." They appear to be used interchangeably (maybe? I'm not actually entirely sure), there seem to be claims that HTTP is a L4 transport protocol, and although the terms "SACM transport protocol" and "SACM transfer protocol" are used and vaguely defined in the draft, they are not defined in the terminology document. If this document goes forward it seems like an edit pass to clarify what is meant with these terms each time they are used, and their relationship to what we typically think of as a "transport protocol," is warranted. I would have thought target location information would be specifically called out in Section 5.2. I have not seen a response to the Gen-ART review.
draft-ietf-tcpm-dctcp
Thank you for a well constructed document, and (IMHO) a nice approach to the issue. I noticed a few nits (some caught by Alvaro) and others that are either me reading late at night or typographical concerns (such as "If SYN , SYN-ACK" [comma placement] first line of section 3.5 - so please give it a thorough read through)
Substantive Comments: - General: The purpose of this draft is not clear to me. Is the point to document the Microsoft implementation just for people's information? Do you have hopes other people will implement this? As written, this seems like a case of an informational draft defining protocol. That's not necessarily a problem, but it's helpful to put a paragraph near the beginning to describe why this is being published and what expectations people have of the outcome. (If the answer is along the lines of "We'd like people to implement this so we can get more operational experience", then I will wonder why the status was not "experimental".) -1, last paragraph: I assume this means that all participants need to live in the datacenter, right? That is, no flows where only one end lives in the datacenter? (I think you clarify that later, but it would be helpful to state it here.) - 3.3: first paragraph: Why not MUST? -- "The congestion estimator on the sender SHOULD process acceptable ACKs as follows:" Why not MUST? Nits: - 1: Can you offer a citation for MapReduce? - 2: The additional text assumes the usage of 2119 keywords here do not quite map to the 2119 definitions. -- "but even compliant implementations without the measures in sections 4-6 would still only be safe to deploy in controlled environments.": That seems too important of a statement to be buried in the terminology section. - 4.1: Citation for NewReno?
I think Alvaro's nits in his ballot are worth a look, but I'm really glad to see this work moving forward, and wanted to thank the authors for a clear explanation of a TCP mechanism that I think I could implement myself.
Several nits: - The Abstract says that "This memo documents existing DCTCP implementations ([WINDOWS], [LINUX], [FREEBSD])..." But in reality it doesn't, it just points to those references that presumably contain implementation information. The [WINDOWS] reference is only used in the Abstract -- last I looked, there shouldn't be references there [rfc7322]. - "...and deployment experience ([MORGANSTANLEY])." Again, this draft doesn't document deployment experience, just points at it. - rfc7942 recommends that the Implementation Status section be removed. If the intent is to keep it, then consider putting a note so that the RFC Editor doesn't remove it.. - The fact that this document describes the Microsoft Windows Server 2012 implementation should be made clear from the start (in the Introduction). You could then also get rid of the extra text in Section 2. - The reference to [RFC3168-ERRATA3639] seems strange to me...not because it is pointing to the report, but because it is Informative, when the reference to RFC3168 is Normative. I would assume that because Errata3639 has been Verified, then it means it is now "part of" RFC3168, so I would think that there's no need to mention it separately...
Given the nature of this mechanism, I would have expected some qualitative analysis of its performance under typical data center conditions, rather than the somewhat vague descriptions of it being an "improvement." If the cited literature contains such numbers, I would suggest (a) specifically citing where such data can be found; and (b) copying a very high-level summary into this document (e.g., something like: "Under typical data center load conditions, intra-center transfers of large (muti-gigabyte) files were improved by approximately 12% over Standard TCP using commodity switches in their default configuration. See [REFERENCE] for details.") Please expand the following acronyms upon first use; see https://www.rfc-editor.org/materials/abbrev.expansion.txt for guidance. - L3 - Level 3 - ECT - ECN-Capable Transport - DSCP - Differentiated Services Code Point - AQM - Active Queue Management - RED - Random Early Detection
draft-ietf-bmwg-dcbench-terminology
I didn't put in a discuss because it’s not worth holding up the document as the content seems fine, BUT I really don't see why this terminology is specified FOR data centers ONLY. All terminology seem to be applicable in general and as such this seems to be an extension of RFC1242. Even incast, which is actually a data center term, is so generally defined that one could use it also in a different context as well. Further latency is defined in both documents, where this drafts mentions RFC1242 and mainly extends the description there. That's in general fine, but I probably would recommend to simply change the title, remove the work data center there, and make this document update RFC 1242. (+ remove the intro text on data centers because the same text is anyway in draft-ietf-bmwg-dcbench-methodology).
I find the naming of the draft fairly confusing. It goes way beyond "terminology"; it makes a number of normative (using 2119 language) statements about benchmarking procedures. I wonder why the sections about procedure did not go into the methodology draft instead. In general, I don't think putting normative language in an informational terminology draft is a good idea. (This would have been a DISCUSS, except that I am aware the bmwg has decided to make all its drafts informational and to still use 2119 language. For the record, I think that policy falls down with this draft.) I agree with the comment from others that this does not seem to be specific to datacenters. - 2.2: Definitions of "store-and-forward" and "cut-through" when used in this context would be helpful. The first may be obvious, but the best I can do with "cut-through" is assume it means the opposite of "store-and-forward". - 6.2: After reading the definition of "Incast" several times, I'm still not sure what it means or what is being measured.
(I'm making the same comment on draft-ietf-bmwg-dcbench-terminology and
draft-ietf-bmwg-dcbench-methodology)
I'm looking at the ballot positions on draft-ietf-bmwg-dcbench-terminology and
draft-ietf-bmwg-dcbench-methodology that assert these documents aren't specific
to "data centers". That wouldn't surprise me, but I'm not seeing a definition
of "data center" in either document - did I miss it?
I suspect that the authors have specific technical characteristics in mind,
that happen to map onto what data centers look like today, but may not in the
future ("RFCs last forever"). Is it possible to tease those characteristics out?
(Full disclosure: my first working group in the IETF could have been called
"TCP over cellular links", but it turned out that when we said "cellular
links", we meant "low-speed links with high loss rates and asymmetric
bandwidth". "Cellular links" in the late 1990s didn't have the same
characteristics that "cellular links" have in 2017, but there are other link
types with those characteristics, so the documents ended up being useful in
places like CORE. I'm not suggesting anything like a restructure of the
document(s), only that they be clear about how future readers would know
whether they should be reading them in 2027)
I agree with Mirja. Given that the text (in the Abstract) already recognize the broader applicability, I would like to see that reflected in a clear way on the title and the contents.
I am surprised to find normative statements in a terminology document. It might
be appropriate -- if awkward -- to say things like "this term MUST mean x," but
this document includes statements pertaining specifically to what "MUST be
measured," which seems well beyond its purported scope. I would suggest either
removing all such statements, or clearly expanding the scope of the document
(including, and quite importantly, revising its title).
Editorial:
- The first paragraph of Section 6.1 uses plural forms for B, kB, and MB, but
singular for GB. Please make these consistent. - Typically, data units are
capitalized per SI-system prefix rules, which would make "kB" the correct
abbreviation for kilobytes, rather than "KB." - Something has gone well and
truly bonkers with the references section formatting. - Please fix reference
[1] so that it correctly points to draft-ietf-bmwg-dcbench-methodology. This
will ensure that it is updated to the correct RFC value at publication.
Please expand the following acronyms upon first use;
see https://www.rfc-editor.org/materials/abbrev.expansion.txt for guidance.
- FPGA - Field-Programmable Gate Array
- LLDP - Link Layer Discovery Protocol
Nits:
** The abstract seems to contain references ([1]), which it shouldn't.
Please replace those with straight textual mentions of the documents in
question.
== Missing Reference: 'RFC5481' is mentioned on line 285, but not defined
== Unused Reference: 'RFC5841' is defined on line 732, but no explicit
reference was found in the text
** Obsolete normative reference: RFC 2554 (ref. 'RFC2544') (Obsoleted by
RFC 4954)
draft-ietf-bmwg-dcbench-methodology
There are two discusses in place that perfectly capture my thoughts.
Again, I don't really understand why any of these tests are specific for data center equipment. These tests can be applied to any equipment. I think the only point is that these tests are especially important to run for data center equipment but that doesn't change the fact that the test itself are not specific for data center equipment. The reason why it's a discuss this time, is that I further really don't understand why existing tests have to be specified again is this document even though a test for that case already exists that specifies exactly the same thing in another RFC; I'm talking about Section 5 on Head of Line Blocking that specifies the same test as in section 5.5 of RFC2889 (there called Congestion Control which a confusing term because this doesn't address end-to-end congestion control, anyway...). I didn't check if that's also the case for any of the other tests.
Please provide the appropriate references for DSCP and COS!
Also I find the name of section 6 confusing ("Incast Stateful and Stateless
Traffic ") because your microburst test (section 4) is basically also incast
testing but without TCP cross-traffic. Further the terms stateful and stateless
are also confusing to me; I'd usually use adaptive and constant bit rate
(CBR)/non-adaptive; or is stateful/stateless the commonly-used term in
benchmarking?
Not sure if the WG discussed this, but it would have been interesting to have some energy efficiency related metrics as the draft is datacenter focused and energy efficiency is an important consideration in datacenters.
- I support Alvaro's DISCUSS - I agree with the questions about why this is specific to datacenters. - Please expand DUT on first use.
At some point in time, I was wondering if this document was about (benchmarking) terminology or about (benchmarking) performance metric definition? And I was wondering what the connection was with the RFC 6390 PMOL template and with https://tools.ietf.org/html/draft-ietf-ippm-metric-registry-11? When I look at the section 3 "jitter", there are obvious elements from the PMOL template. Thinking about it, whether a performance metric is used for benchmark or not, we need a formal definition. Is it time for: 1. IPPM to finish up draft-ietf-ippm-metric-registry 2. start populating the registry 3. BMWG to start using/specifying those performance metrics Thoughts? Below is Tim Chown's OPS DIR review: verall, the document is well written, and I believe it to be Ready with minor nits. General comment: It would be interesting to see an Appendix with an example of a recorded test using the language defined here. Specific comments: Section 1: “- Low amount of buffer (in the Mb range)” Change to MB? (given later you refer to KB/MB/GB as the measurement unit for buffers) Section 2.1 Expand DUT on first use. Section 3.1 Perhaps clarify relationship of Delay and Latency, since you focus on Latency in the document and not Delay? Last para, you say “If” here, but for Latency the FILO timestamp was a MUST in Section 2? This doesn’t seem consistent? Expand PDV on first use. Section 6.1.1 “1518 bytes frames” -> “1518 byte frames” Section 7.1, Why is ‘and’ in quotes here? Not sure you can say the balance is defined by goodput? Do you mean that goodput is an indication of the balance? For standard TCP, a very small loss can have a dramatic effect on application throughput. The second para should follow the first, change “[RFC2647]. Goodput…” to “[RFC2647], i.e., goodput…” Section 7.3 I don’t understand how the example given correlates to G = S/Ft ? There’s a few typos in this section; please re-check.
(I'm making the same comment on draft-ietf-bmwg-dcbench-terminology and
draft-ietf-bmwg-dcbench-methodology)
I'm looking at the ballot positions on draft-ietf-bmwg-dcbench-terminology and
draft-ietf-bmwg-dcbench-methodology that assert these documents aren't specific
to "data centers". That wouldn't surprise me, but I'm not seeing a definition
of "data center" in either document - did I miss it?
I suspect that the authors have specific technical characteristics in mind,
that happen to map onto what data centers look like today, but may not in the
future ("RFCs last forever"). Is it possible to tease those characteristics out?
(Full disclosure: my first working group in the IETF could have been called
"TCP over cellular links", but it turned out that when we said "cellular
links", we meant "low-speed links with high loss rates and asymmetric
bandwidth". "Cellular links" in the late 1990s didn't have the same
characteristics that "cellular links" have in 2017, but there are other link
types with those characteristics, so the documents ended up being useful in
places like CORE. I'm not suggesting anything like a restructure of the
document(s), only that they be clear about how future readers would know
whether they should be reading them in 2027)
I agree with Alvaro's discuss -- you can't cite 2119 and then override it. It
may well be that what 2119 does not make sense for this document; if so, don't
cite it, and be clear up front that you're using a *different* set of meanings
for these specific terms.
I *think* I can suss out the nature of "east-west" versus "north-south" in the
introduction, but I'm really not sure. Can you please define these terms or
point to a document that does so?
Editorial:
- Something has gone well and truly bonkers with the references section
formatting.
- Please fix reference [1] so that it correctly points to
draft-ietf-bmwg-dcbench-terminology. This will ensure that it is updated to the
correct RFC value at publication.
Nits:
Please expand "SUT" on first use.
** The abstract seems to contain references ([1]), which it shouldn't.
Please replace those with straight textual mentions of the documents in
question.
[Thanks for addressing my DISCUSS.]
conflict-review-hao-jpake
conflict-review-hao-schnorr