IESG Narrative Minutes
Narrative Minutes of the IESG Teleconference on 2016-12-01. These are not an official record of the meeting.
Narrative scribe: John Leslie and Susan Hares (The scribe was sometimes uncertain who was speaking.)
Corrections from: (none)
1 Administrivia
2. Protocol actions
2.1 WG submissions
2.1.1 New items
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
2.1.2 Returning items
2.2 Individual submissions
2.2.1 New items
Telechat:
Telechat:
Telechat:
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:
Telechat:
3.2.2 Returning items
3.3 Status changes
3.3.1 New items
3.3.2 Returning items
3.4 IRTF and Independent Submission stream documents
3.4.1 New items
3.4.2 Returning items
1036 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::
4.2.2 Proposed for Approval
5. IAB News We can use
6. Management Issues
Telechat::
Telechat::
7. Working Group News
Amy: I'll be traveling to California
1056 EDT Adjourned
(at 2016-12-01 06:00:03 PST)
draft-ietf-straw-b2bua-rtcp
I agree with Alissa that the set of attributes that fall into each category is just not clear or fully specified. I'm not sure about better wording - but at least indicating how to categorize the different attributes (if listing them all isn't reasonable) would help. Describing the category as "those that cause issues"' is not helpful.
Thanks for responding to Magnus's thorough TSV-ART review (for reference, https://www.ietf.org/mail-archive/web/tsv-art/current/msg00111.html). I'm inclined to agree with the resolutions you've proposed (for reference, https://www.ietf.org/mail-archive/web/tsv-art/current/msg00112.html), but I do have one question - given that you want to include REMB, because it's deployed in Chrome and Firefox, and given that https://datatracker.ietf.org/doc/draft-alvestrand-rmcat-remb/ hasn't moved in three years and RMCAT is doing something else, what's your plan for publishing this draft as an RFC that's not stuck in MISSREF forever?
High level comment: This document mainly talks about cases where the SSRC or the RTP seq# is changed. Are they no other fields that could be changed as well? Would there need to be additional guidance (in 3.2) then, or are SSRC and seq# more special then other fields? And why would a relay change those fields? Wouldn't it be appropriate to give the guidance somewhere that those fields SHOULD NOT be changed!?! Smaller comments: section 3.1: "Apart from the mentioned attributes, B2BUAs SHOULD forward all other SDP attributes they don't have a reason not to forward, in order to avoid breaking additional functionality endpoints may be relying on." Shouldn't that be a MUST (with all the exceptions given already)...? "...a B2BUA MAY rewrite CNAME items if any potential collision is detected..." And why is that a MAY? Shouldn't this be a SHOULD at least?
intro: Including the LI example in section 1 seems wrong given RFC2804. And I don't see why you need it if there are other justifications that are not controversial in the IETF. Why not just delete that? (The problem with including that justification in a standards track document is that doing so goes entirely against RFC2804.) But this should be an easy fix, via a revised ID or RFC editor note.
- The security considerations section is pretty good, thanks!
[1] As I understand it, a Media-Aware Relay is an instance of a RTP/RTCP translator. I'm wondering whether the behavior in 3.2 can/should be more broadly applied to other types of translators, and not just to a media-aware B2BUA. ?? [Disclaimer: I am out of my depth here...] [2] The guidelines in 3.2 have a normative "MUST" attached to them: "...a media-aware B2BUA MUST handle incoming RTCP messages to forward following this guideline". However, some of the references are not Normative. I assume that (as with the guidelines related to RFC3550) the text in 3.2 represents a behavior beyond what is described in the references, which implies to me that those references should be Normative. The solution seems simple: move rfc3611, rfc5104, etc. to be Normative references...but I-D.alvestrand-rmcat-remb is also referenced, which not only expired 3 years ago, but it is marked as Experimental. Can the expected behavior from I-D.alvestrand-rmcat-remb be somehow defined in this document so that the reference is not needed?
Two points were raised by Russ Housley's Gen-ART review. On the first one, I plan to watch the resolution of the Discusses related to the unclear SHOULD NOT. (It certainly would have been a Discuss from me if a Discuss wasn’t already raised.) On the second point regarding the document class, I have noted the issue but don't plan on block document based on it. Looking forward to further discussion if people want to argue it.
= Section 3.1 =
I think there is a lack of clarity in the recommendations here, because "such
attributes" aren't listed out anywhere and then later it's not clear what the
"mentioned attributes" are referring to. I've proposed some edits below to try
to clarify what I think the recommendations are saying -- does this capture the
intent?
OLD
However, certain SDP attributes may
lead to call failures when forwarded by a media relay. Such
attributes SHOULD NOT be forwarded. One notable example is the
'rtcp' [RFC3605] attribute, that UAC may make use of to explicitly
state the port they're willing to use for RTCP. Considering the
B2BUA would relay RTCP messages, the port as seen by the other UAC
involved in the communication would differ from the one negotiated
originally, and it MUST be rewritten accordingly. Apart from the
mentioned attributes, B2BUAs SHOULD forward all other SDP attributes
they don't have a reason not to forward, in order to avoid breaking
additional functionality endpoints may be relying on.
NEW
However, certain SDP attributes may
lead to call failures when forwarded by a media relay. One notable example
is the 'rtcp' [RFC3605] attribute, that UAC may make use of to explicitly
state the port it is willing to use for RTCP. Assuming that the B2BUA would
relay RTCP messages, the port as seen by the other UAC involved in the
communication would differ from the one negotiated originally. The 'rtcp'
attribute MUST be rewritten accordingly, rather than being forwarded. Any
other attributes known to the B2BUA to cause call failures when forwarded
SHOULD NOT be forwarded. B2BUAs SHOULD forward all other SDP attributes in
order to avoid breaking additional functionality endpoints may be relying on.
= Section 3.2 =
(1)
"It is worthwile to point out that such a B2BUA may not necessarily
forward all the packets it receives, though. Selective Forwarding
Units (SFU) [RFC7667], for instance, may aggregate or drop incoming
RTCP messages, while at the same time originating new ones on their
own. For the messages that are forwarded and/or aggregated, though,
it's important to make sure the information is coherent."
I don't see much beyond this text that discusses the implications of dropping
and aggregating RTCP messages. Is this written down in another document? If
not, I'm wondering about what happens with RTCP information aside from
identifiers, SSRCs, and sequence numbers in these cases. E.g., if a B2BUA drops
one RTCP message containing an RFC 7002 block but forwards the next one
containing such a block, won't the interval and the discard count reported to
the receiver be wrong? I assume there are a lot of cases involving XR blocks
where this could be a problem, but this document doesn't address those cases.
(2)
"SR: [RFC3550]
If the B2BUA has changed the SSRC of the sender RTP stream a
Sender Report refers to, it MUST update the SSRC in the SR packet
header as well. If the B2BUA has changed the SSRCs of other RTP
streams too, and any of these streams are addressed in any of the
SR report blocks, it MUST update the related values in the SR
report blocks as well. If the B2BUA has also changed the base RTP
sequence number when forwarding RTP packets, then this change
needs to be properly addressed in the 'extended highest sequence
number received' field in the Report Blocks."
Why is the recommendation about the extended highest sequence number received
not also a MUST?
= Section 3.2 = s/properly address/reflected/
draft-ietf-appsawg-mdn-3798bis
Should the Media-Type registration go to the authors of the draft, as specified, or instead to the appsawg & eventually defaulting to the IESG?
I am the editor.
Thanks for the good work to improve the privacy properties here. = Section 6.2 = "Disposition mode (Section 3.2.6.1) can leak information about recipient's MUA configuration, in particular whether MDNs are acknowledged manually or automatically. If this is a concern, MUAs can return "manual-action/MDN-sent-manually" disposition mode in generated MDNs." I see why this is here, but doesn't recommending falsifying these fields put their integrity in question whenever they are set to manual? I mean, why would recipients trust this information if the RFC actually suggests sending a field that lies about an MDN being automatically acknowledged? = Section 6.2.2 = "The "Reporting-UA" field (Section 3.2.1) might contain enough information to uniquely identify a specific device, usually when combined with other characteristics, particularly if the user agent sends excessive details about the user's system or extensions. However, the source of unique information that is least expected by users is proactive negotiation, including the Accept-Language header fields." I think the use of "However" is tripping me up here. Earlier in the document you have good recommendations about how to mitigate the risk of fingerprinting based on the Reporting-UA field. That guidance is valid regardless of whether other header fields might also contribute to fingerprinting or whether users would expect that (frankly, I don't see how user expectations are relevant here, since most users don't understand fingerprinting anyway). I think something along the following lines to replace the last sentence above would be more accurate: "Even when the guidance in Section 3.2.1 is followed to avoid fingerprinting, other sources of unique information may still be present, including the Accept-Language header fields."
draft-ietf-savi-mix
There are a number of acronyms that could use expansion or a reference for the first time they are used (CGA, DAD are the 2 I caught). This will probably be caught by the RFC Editor, but help sooner might be useful. I'm fairly certain that Joel Halpern hasn't worked at Newbridge Networks for quite a few years...
I agree with Alissa's comment.
Probably Ben caught them already but there are a few cases where there should be an upper letter SHOULD instead of a lower latter should.
I have a few minor (non-binding) comments, and some editorial comments: Substantive: -3, 7th paragraph: "... SAVI binding table should be shared..." This seems like it might deserve a SHOULD, given that it seems like one of the main points of the document. -4: Can you define (or cite a definition) for "binding anchor"? - 6.1.1: Is the "manual" method excluded from consideration here? If so, it would be helpful to explain that, and why. - 6.1.2: It's not clear to me what the title "Overwritten preferences" means. Should this be "Exceptions"? - 6.1.2.2, paragraph 6, "message should be discarded": That seems important, should the should be SHOULD? -- (same paragraph), "It is suggested to limit the rate of defense NAs to reduce security threats to the switch." Can you elaborate on that threat, or cite something that does? - 6.2: I'm a bit surprised this section doesn't prioritize the binding with the longest expiration time. Or do you assume the manual method and FCFS method do not have expirations? -8: Can you elaborate on the correlation concern? Editorial: - General: There are a number of abbreviations that should be expanded on the first use. -1, paragraph 1: s/Validaiton/Validation - 3: Is there a reason the 4th method (manual) doesn't get a place on the list? If so, it would be helpful to add text to explain why. - 5: The DHCP/SLAAC and SeND/non-SeND headings seem ambiguous, in that it is not clear to me that the "/" means "these two things in combination", as opposed to "either of these methods". I suggest writing out what you mean rather than using the "/" as a shortcut. (Also, are these the only combinations that people need to think about?) -6: I assume "assignment separation" is the method described in section 5, but that section never uses those exact words. Please consider using a consistent term. -6.1.1, first paragraph "decide to whom" Does this mean to decide which binding anchor to use? (Otherwise, who is "whom"?) -- The use of a numbered list in 6.1.1 seems to imply some ordering or preference, but I don't think that is the intent. If so, please consider using an non-numbered list. - 6.1.2.2 could use some proofreading--there are a number of grammar errors and unclear statements. -- "value of a know binding anchor": s/know/known -- last paragraph: What is the antecedent of "It" in "It should not install..." -- s/"... prevent the node to assign..."/"... prevent the node from assigning..." -- I don't understand the intent of the second to last sentence well enough to suggest wording. - 6.1.3: Please spell out FCFS
= Abstract = The phrase "must be used" sounds too prescriptive. I think something along the following lines would be more accurate: In networks that use multiple techniques for address assignment, the spoofing of addresses assigned by each technique can be prevented using the appropriate Source Address Validation Improvement (SAVI) methods.
4. Architecture A SAVI device may implement ant use multiple SAVI methods. A SAVI device may implement and use multiple SAVI methods. 6.1.2.2. 2. The target is within configured "prefix" (or equal to "address") 2. The target is within the configured "prefix" (or equal to the "address")
draft-ietf-6lo-6lobac
In Appendix B, given that there is code, it would be good to specifically mark it as such. As I recall, there are different copyright aspects to the code fragments in an RFC than to the text. I believe that https://www.ietf.org/iesg/statement/copyright.html provides pointers to the implications and encourages marking the code segments with <CODE_BEGINS> and <CODE_ENDS>.
1) Agree with Ben that normative wording should not be used if it just summarizes things that are specified in a different doc. 2) Section 5: "A node implementing [RFC7400] MUST probe its peers for GHC support before applying GHC." How? 3) Just to make sure I get the security section right: MS/TP networks are not connected to the Internet or use something like a gateway. Maybe make this point more clear: basically say that the reason to use IPv6 is NOT that you want to send these packets eventually directly to the Internet!
- 1.3: "cost effective" and similar marketing language is better avoided. I'd say deleting that sentence is better. - section 5: It's not clear to me why the 115k data rate "dictates" header compression to reduce latency. I'm not doubting that it might, but it's not clear from what's stated that it does. - Appendices B/C: I'm not clear how these are not part of the standard. I think what you mean is that the code is not, but the algorithms in fact are in fact necessary to implement this. (I also agree with Alia's suggestion to add the IETF trust <CODE BEGINS> stuff, assuming that's not problematic.)
Good comments by Alissa, Mirja and others.
Substantive: - 1.3 Do I undertand correctly that this section is strictly an overview of something described elsewhere? If so, I am surprised to find the MUSTs in the the 5th paragraph from the end of the section. - 2 and 3 also have some MUSTs that seem to describe MS/TP nodes in general--are those new requirements described in this spec, or existing requirements? (If the later, please consider stating them without 2119 keywords.) -6, 2nd paragraph: Why is the SHOULD NOT not a MUST NOT? What is the consequences of ignoring the SHOULD NOT? - 12, 2nd paragraph: "MS/TP networks are by definition wired and not susceptible to casual eavesdropping. " I think this depends on too many factors to state this broadly. It may be easier to eves drop on an unprotected piece of wire than, say, an encrypted wireless link. - 14.2: [EUI-64] and [I-D.ietf-6lo-privacy-considerations] seem to be cited normatively. Editorial: - 4: Please expand MSDU
Comments from Orit Levin's Gen-ART review should be addressed: --- Document: draft-ietf-6lo-6lobac-06 Reviewer: Orit Levin Review Date: 2016-11-26 IETF LC End Date: 2016-11-30 IESG Telechat date: (if known) Summary: This draft is basically ready for publication, but has editorial nits that should be fixed before publication. Abstract: Remove the word "extensively" from the first sentence. Introduction: 1. Remove the word "extensively" from the first sentence. (Not a standard-appropriate language.) 2.Consider rephrasing to "... these constraints are similar to those faced in 6LoWPAN networks, which suggests that some elements of that solution might be leveraged." 3. Consider rephrasing the last sentence to "This document also specifies a mandatory header compression mechanism, based on [RFC6282], which reduces latency and makes IPv6 practical on MS/TP networks." Section 1.3 1. This section is called "MS/TP Overview". The overview of the existing specifications is "mingled" with the new features and profiling defined in "this specification". By just reading this section, it is not always clear which statements refer to the "baseline" specifications and which to the new "features" defined in this document. Either consider introducing/improving "linking" sentences to clarify the text or reorganize/split the text into two independent summaries: of baseline functionality and of new functionality. 2. In the second paragraph, rephrase to "These features make MS/TP a cost-effective field bus applicable to building an automation network." (Not a standard-appropriate language: "for the most numerous and least expensive devices".) 3. Add the word "only" to "A master node may initiate the transmission of a data frame only when it holds the token." 4. Consider changing "MS/TP COBS-encoded frame fields have the following descriptions:" to "MS/TP COBS-encoded frame fields are defined as follows:" 5. Remove "MUST"s from "Frame Types 32 - 127 designate COBS-encoded frames and MUST convey Encoded Data and Encoded CRC-32K fields. All master nodes MUST understand Token, Poll For Master, and Reply to Poll For Master control frames." (See my first comment to this section above. Where is this defined? In the baseline specs or in this document?) Section 3 Rephrase to "The method specified in Section 6 for creating a MAC-layer-derived Interface Identifier (IID) ensures that an IID of all zeros can never be generated." Section 4 Consider rephrasing to "This specification restricts an MSDU length for at least 1280 octets and at most 1500 octets (before encoding)." Section 5 1. Rephrase to "Because of the relatively low data rates of MS/TP, header compression is used as a means to reduce latency." 2. Add "of" after "comprises" in "The encapsulation format defined in this section ... comprises of the MSDU of an IPv6 over MS/TP frame." 3. In "The Dispatch value may be treated as an unstructured namespace", it would be simpler to say "is treated" unless there is a special significance to "may be". In later case, it needs to be explained. Section 6 Consider replacing ", as" by "and is" in "The general procedure for creating a MAC-address-derived IID is described in [RFC4291] Appendix A, "Creating Modified EUI-64 Format Interface Identifiers", as updated by [RFC7136]." Section 10 Consider replacing the second and the third sentences with "This section provides the text substitutions for [RFC6282] that make it applicable to LoBAC as follows:" Section 12 Consider rephrasing to "MS/TP networks are by definition wired and thus not susceptible to casual eavesdropping. Furthermore, because MS/TP nodes are stationary, correlation of activities or location tracking of individuals is unlikely." Thank you, Orit Levin.
Section 12 says: "For this reason, it is RECOMMENDED that a different (but stable) IID be generated for each globally scoped address in use according to, for example, [RFC3315], [RFC3972], [RFC4941], [RFC5535], or [RFC7217]." I have a couple of questions about this recommendation that should be easy to clear up. First, do you really mean "different" IID? EUI-64 identifiers are different from each other, but embedding one in an IID still leaves you susceptible to address scanning attacks. Maybe what is meant here is "semantically opaque" or "with maximum supportable entropy" or something along those lines? Second, what is meant by the word "stable" here? The mechanisms cited offer a variety of different "stability" spans -- DHCP lease lifetime, temporary address lifetime, lifetime of connection to a link, etc. So it's not clear what is actually being recommended or if the cited mechanisms all provide the desired property.
I mostly understand why Sections 6 and 12 are specified as they are but there
are a couple of points of departure from draft-ietf-6lo-privacy-considerations
and draft-ietf-6man-default-iids that I'd like to discuss.
(1) draft-ietf-6man-default-iids says that the choice of address generation
mechanism should be configurable when a mechanism is specified to embed a link
layer address in an IID. Is there a reason that doesn't apply here? The
document doesn't say anything about it for the link-local case.
(2) draft-ietf-6lo-privacy-considerations says:
"Specifications should make sure that an IPv6 address can change
over long periods of time. For example, the interface identifier
might change each time a device connects to the network (if
connections are short), or might change each day (if connections
can be long). This is necessary to mitigate correlation over
time."
This document doesn't seem to provide any guidance about supporting the ability
to change an IPv6 address within the life span of a long-lived attachment to
the same physical network. Some of the mechanisms cited in Section 12 provide
this and some do not. I appreciate that correlation of activities over time
isn't perceived to be a huge threat here, but aren't there cases where being
able to change an address despite remaining attached to the same physical
network would be desirable? That seems worth some guidance for nodes that want
to support it.
Mahesh Jethanandani <mjethanandani@gmail.com> performed the opsdir review
it would probably be good to discuss these concerns before it gets out the door.
I have reviewed this document as part of the Operational directorate’s ongoing
effort to review all IETF documents being processed by the IESG. These
comments were written with the intent of improving the operational aspects of
the IETF drafts. Comments that are not addressed in last call may be included
in AD reviews during the IESG review. Document editors and WG chairs should
treat these comments just like any other last call comments.
Document reviewed: draft-ietf-6lo-6lobac-06
Summary:
The abstract of the document says “This specification defines the frame
format for transmission of IPv6 packets and the method of forming
link-local and statelessly autoconfigured IPv6 addresses on MS/TP networks.
This document is on a standards track.
Operational Considerations
Operations. The document does talk about existence of legacy Master
Slave/Token Passing (MS/TP) along with nodes that will implement this new
MS/TP frame format. It says that if these legacy nodes are present, they
will ignore the frame format defined in this specification. It also says
that co-existence with legacy implementations is only a secondary goal. To
enable this, no changes are permitted to the MS/TP addressing modes, frame
header format, control frames, or Master Node state machine. From an
operational perspective, everything that can be configured can also be
misconfigured. One way to simplify configuration, would be by specifying
reasonable defaults, including default modes and parameters. Are there
default parameters? If so, what are they? It appears from the draft that
the deployment scenario in consideration is a green field opportunity. That
only nodes that implement the new MS/TP frame format will be able to
communicate with each other. So there is no consideration outlined for a
migration path. In other words, even though co-existence with legacy
implementations is one of the goals, it is not clear how that will enable a
migration from that implementation to the new format. It is also not clear
on what the impact if any this new format may have on existing legacy
implementations. For example, for multicast frames, it states that
multicast is not supported in MS/TP. That all multicast frames are
broadcasted at the MAC layer and filtered at the IPv6 layer. What impact
could this have on the nodes that have to process these multicast packets
that are broadcasted to all the nodes? How is the node with the new MS/TP
frame format expected to verified for correct operation? Is it by actively
monitoring the node, and if so what are the elements that can be verified
for correct operation. Are there events generated as part of protocol
operations that can be used to verify its operation?
Management Considerations:
Will the nodes with this new MS/TP frame format need to be configured, or
monitored? What are some of the management operations that are needed? How
are these operations performed, e.g. locally, remotely etc. Where is this
management interface defined? Are there any new faults or health indicators
associated with this new frame formats? How are the alarms and events
exposed? Will they be pushed or do the devices have to be polled?
Similarly, if one of the nodes in the network is not behaving correctly,
how would an operator be able to determine which node it is? Are there
counters maintained by each node that can be monitored to see what each
node is doing? Anything that can be used to do a root cause analysis, and
or fault isolation is helpful. Are there any performance considerations
that an operator should be aware of with this new frame format? Certain
properties of this new frame format can be useful to monitor. For example,
the number of packets received with the frame format or the number of
packets sent. Are there particular counters that can be used for monitoring?
Accounting Considerations
Is it appropriate to collect usage information related to this new frame
format? If so, what usage information would be appropriate to collect?
A run of idnits reveals one misc. warning that might be worth looking at.
Miscellaneous warnings:
----------------------------------------------------------------------------
-- Found something which looks like a code comment -- if you have code
sections in the document, please surround them with '<CODE BEGINS>' and
'<CODE ENDS>' lines.
Thanks.
Mahesh Jethanandani
mjethanandani@gmail.com
_______________________________________________
OPS-DIR mailing list
OPS-DIR@ietf.org
https://www.ietf.org/mailman/listinfo/ops-dir
draft-ietf-dnsop-resolver-priming
In section 3.1, is there a reason the requirement in paragraph 2 does not get a 2119 keywords, when the requirement in the first paragraph does? They seem similar in impact.
I find myself curious about both SHOULDs in Resolver software SHOULD treat the response to the priming query as a normal DNS response, just as it would use any other data fed to its cache. Resolver software SHOULD NOT expect exactly 13 NS RRs. Do you think these SHOULDs (especially the first one) are required for interoperation? I'm wondering (1) why they aren't MUSTs, and (2) why RFC 2119 language is actually needed at all. If they are RFC 2119 SHOULDs, what happens if the resolver software violates them?
- intro: References for directions that fail "disastrously" would be good, if only to decrease the chances that other implementers choose known-bad approaches. - section 5, 2nd para: such an attacker can also see what queries are being emitted by the resolver, and, in the absence of qname minimisation, that can be quite privacy sensitive. I think it'd be well worth noting that with a reference to RFC7816 as a possible mitigation.
I support Stephen's comments.
Thank you for producing a well written artefact. I also support Stephen's request to identify the scenarios in which "Some implementers have chosen other directions, some of which work well and others of which fail (sometimes disastrously) under different conditions." An appendix would be fine IMHO. Given you raise some (awareness) issues in the security consideration section, if an administrator implements RFC7706 would that alter any of those concerns? (admittedly, potentially buying others that are well documented in 7706)
draft-ietf-kitten-rfc6112bis
Is this intended to go to Internet Standard or Proposed Standard again?
- 4.3, 2nd paragraph: Absent what sort of other information? That's a bit vague for a condition for a MUST. -9: Isn't Sam an author? :-)
draft-ietf-kitten-pkinit-freshness
I am concerned about the issue that Russ Housley raised in his Gen-ART review: bad practices in creating the freshness tokens creates a security issue. If this cannot be handled in the way that Russ initially suggested (setting a minimum number of bits) then a proper discussion of the issue and recommendations to avoid the problems need to be included in the security considerations section.
Other issues from Russ' Gen-ART review should also be addressed (editorial ones + possible max size).
As mentioned by Scott Bradner in his OPS-DIR review, some words about operational guidance (not implementation guidance) would be welcome: " what kind of message could the operator give to their users to minimize the disruption when errors start popping up " would be welcome. See https://www.ietf.org/mail-archive/web/ops-dir/current/msg02267.html.
Holding a discuss until the Gen-art conversation on minimum size of the fressness token resolves. Will switch to a yes once that is resolved. https://www.ietf.org/mail-archive/web/gen-art/current/msg13942.html
draft-ietf-behave-ipfix-nat-logging
This should be a quick issue to handle, but given that there is no language describing what a low threshold event is, I think it needs to be a Discuss. Sec 5.5 & Table 4: I see that only the address pool has a low threshold event. There is no text describing what this means or how to handle it. Also, why does only the address pool need the low threshold event and not the other resources?
vlanID is defined as 16 bits, which is fine, but there are also extensions q-in-q, I believe, to allow an extended vlan tag. That might be useful for future-proofing.
One high level comments: Why are there subevent for natQuotaExceededEvent and natThresholdEvent? I don't see any reason why not to simply have them as natEvents (and part of table 2). Minor comments: 1) section 5 says: "The list of collectors and its associated information like the transport address, port and protocol MUST be preserved across reboots." - I don't think this should be an upper-letter MUST because there could be other mechanisms to retain this list. I would go for lower case or SHOULD. - What's an transport address? Do you mean IP address? 2) No need to have table 3 (22) an 4 (23) twice; just refer to it as done in section 8.1.6.
(1) This document has been on the go for 6 years and was a WG document for a while before behave closed. In all that time did anybody consider whether or not we ought define different modes of logging, with different privacy implications, as suggested e.g. in Kathleen's comments - one could have a normal/default mode that's typically used and more privacy friendly, and an "I might be under attack" mode that's more intrusive but useful in such situations? If not, why was that not considered given that CGN logging can be very intrusive and is open to some forms of abuse? (Note that I'm not asserting that such modes absolutely need to be visible in the RFC, I'm asking was that considered.) (2) In an overall system that uses this kind of logging, how would one control the duration for which events are stored? Would or should that need to be visible in this e.g. in a template? I figure the answer is probably no, but just wanted to check in case we ought be defining an IE for "max. retention duration" here or something similar that might be needed e.g. if different cross-border requirements applied to CGN boxes in different jurisdictions using one log service. (This is only a discuss because if it were missing, it might be hard to introduce later.)
- 5.1: RFC6888 says destinations SHOULD NOT be logged. That is more than "discussed" I think and would be better repeated here - even if defining the IEs is the right thing, we really ought say that they SHOULD NOT be used unless one has to (or else justify whey 6888 is wrong). I also don't understand what "done with caution" here could mean. I think you mean "SHOULD NOT be done unless one is forced" maybe but not sure? - section 10: What is the valid use-case where logging information is ok to not use TLS but one is using IPFIX? I can't really think of one TBH, but maybe I'm missing something? (FWIW, I would not consider "too much trouble to bother" as a valid use-case:-)
* Section 5.6.7.5 The rationale for making the sourceIPv6 address mandatory and sourceIPv4 address not mandatory for NAT64s is not clear to me. I am assuming the translator is reassembling packets to meet the REQ-14 "Received Fragment Out of Order" behavior of RFC4787. In this case the fragmented packets could be received from either direction, right? A fragmented return packet from the IPv4 domain can cause this issue and in this case the source IPv4 address would be useful to have.
* Section 5.2. Is there any reason that the example does not use documentation addresses from RFC5737?
Substantive Comments: - General: I think this document would benefit from a privacy considerations section. In particular, has any thought been given to log minimization? For example, source addresses are mostly marked as mandatory--is there no use case for logs without them? (I considered making this a DISCUSS, but I recognize that NAT logging needs certain elements to be minimally useful, and maybe source addresses fall into that category.) - 2, first paragraph, third sentence: Please consider saving the MUST for the detailed procedures, or at least avoid stating it in passing as part of a definition. -3, first paragraph, last sentence: This is an odd usage of a 2119 SHOULD NOT. Is the point to say that, whatever the transport choice, some reliability mechanism SHOULD be used? -4 , third paragraph: "An appropriate throttling mechanism shall be used to handle the oversubscription" Is that "shall" intended as normative? -5, last paragraph: Accounting use cases often have stringent reliability and timing requirements that go beyond simply saying "SHOULD NOT lose records." Does this document consider those requirements? Or more to the point, does the working group consider this appropriate for accounting applications? (As opposed to something like RADIUS or Diameter.) - section 5.2, "Some of the IPFIX IEs are not assigned yet, and hence the detailed description of these fields are requested in the IANA considerations section.": I don't understand the intent. This section should (and does) include the descriptions. Did you mean to say that the IPFIX ID numbers (marked TBD in a few cases) are requested in the IANA consideration section? Editorial Comments and Nits: - IDNits complains about several references, including a normative downref to RFC2663 that does not appear to be in either the downref registry of the LC announcement. - 2: It seems a bit odd to get all the way to section 2 before seeing a basic intro of what the doc is about. It's up to you, but please consider merging section 1 into section 2.1, and decrementing the section numbers accordingly. - section 5, general: There are a lot of 2119 keywords in this section that seem to generically apply to IPFIX. Are these new requirements specific to NAT logging? If not, please consider replacing the 2119 keywords with descriptive language. - 11.2: Given that the security considerations are almost completely delegated to RFC7011, the reference should probably be normative.
Thanks for this document. I will recommend its publication as an RFC shortly, after we complete the following discussion: Paul's Gen-ART review comments should be looked at and responded to. I'm going to raise one particular issue that in my view needs fixing. The language at the beginning of Section 5.6 gives some room for flexibility in what IEs to include in specific implementations, but it isn't clear how that relates to the mandatory/optional information provided in later tables. Can you clarify?
Paul's review comments: Document: draft-ietf-behave-ipfix-nat-logging-11 Reviewer: Paul Kyzivat Review Date: IETF LC End Date: 2016-02-12 IESG Telechat date: 2016-12-01 Summary: This draft is on the right track but has open issues, described in the review. Major: 0 Minor: 5 Nits: 1 (1) Minor: A sentence in Section 3 says: "This document focuses exclusively on the specification of IPFIX IEs." But this statement appears to be false. A large part of the document (Section 5.6) specifies Templates. It appears to be an important aspect of the document that goes beyond specifying just IEs. So the statement should be expanded. (2) Minor: Section 5.2 starts with "The templates could contain a subset of the Information Elements(IEs) shown in Table 1 depending upon the event being logged." This is not a normative statement. It isn't clear what is normative regarding the use and content of templates. If I understand RFC7011, a NAT device can use any number of templates, and those templates can reference any defined IE. Is *this* document intended to *restrict* the form and number of templates used for logging NAT devices? Or is it simply suggesting some templates that may be modified as desired to fit the needs of a particular NAT device device? These templates do not have any Information Element that uniquely identifies to the IPFIX collector that this template is being used. So how does the collector know that the particular event is intended to follow the definitions in this draft, rather than simply some proprietary template? Absent that, how do normative statements of what must be in the template mean anything? (3) Minor: Section 5.6 says: "Depending on the implementation and configuration various IEs specified can be included or ignored." What is the normative intent of this statement? Is it defining what is meant by the "Mandatory" field in the tables? (I.e., that in the templates it sends the NAT device MUST include fields with Mandatory=Yes but MAY omit fields with Mandatory=No.) This should be revised to make the normative behavior clearer. (4) Minor: Within the IANA Considerations, section 8.1 deals with Information Elements, with one subsection for each new IE being defined. Some of these (8.1.4 natQuotaExceededEvent, 8.1.5 netThresholdEvent, 8.1.6 netEvent) each require a new IANA subregistry to be defined. They do this rather informally within the body of the corresponding subsection. Perhaps IANA will figure this out, but there is opportunity for misunderstanding. It would be better if there were separate subsection of section 8 for each of these registry creation actions. E.g. 8.2 NAT Quota Exceeded Event Type, 8.3 NAT Threshhold Event Type, 8.4 NAT Event Type. (5) Minor: Section 9 appears to be normative, since it uses 2119 language. But it appears at a position in the document (after Acknowledgements and IANA Considerations, before Security Considerations), where I would normally not expect to find normative language. Perhaps this is intended to be more of an appendix. If so, then the normative language should be removed, and it ought to be formatted as an appendix. If it is intended to be normative, then I suggest that it be moved ahead of the Acknowledgements. (6) Nit: Running IDNits returns a number of issues, mostly regarding references.
I am agreeing with Mirja that tables shouldn't be duplicated.
Thanks for your work on this draft. Logging is going to be increasingly more important. In section 4, I think it could be important to note the use of logs for debugging. As sessions are increasingly encrypted, debugging will rely on information in other places. In regard to the privacy concerns associate with logs raised by Ben & Alissa, since this is tied to syslog, I would rather see the configurable levels allow for the privacy options needed. On one hand, organizations may need the ability to debug issues, but on normal operations, a lower level of logging to protect privacy should be the recommendation. Some organizations will need the ability to increase logging levels and this might be completely within reason if it is contained to their organization's network.
= General = (1) I agree with Ben's comments. In particular, while the citation to RFC 7011 in Section 10 is helpful, there are new privacy threats introduced by this specification based on the information it exposes which are not documented in RFC 7011. (2) Was it not possible to find someone from the community to shepherd this document? = Section 5.1 = "Logging of destination information also results in the loss of privacy and hence should be done with caution." This is true not only for destination information but for source address information, and ports and timestamps when combined with address information. It's fine to advise caution, but it would be better if this didn't sound like destination information is the only privacy-impacting exposure.
draft-levine-herkula-oneclick
Thanks for the changes from -07 to -08 which are good enough to resolve my discuss points. I note you say that cookies etc SHOULD NOT be sent, whereas I'd argue for MUST NOT. If you want to leave that at SHOULD NOT then please do add the logic for when/why it is ok to send state information (which I guess is to handle some kind of intranet/internal list use cases is it?) -- OLD DISCUSS BELOW I have two discuss points, both much more of interest if this spec is implemented within an MUA, which is not the use-case that the authors are (very reasonably) mainly interested in handling. (1) This needs to say to never send client state (cookies etc.) esp for the case the client is an MUA. (2) The ability to cause the POST to match such a broad range of web forms seems wrong. Surely there's no need for that? Can't you limit the set of post data that are allowed to be emitted in some way to get rid of that aspect? I can't imagine such flexibility is really needed for just this. -- OLD COMMENTS BELOW - I'm not clear whether or not changes discussed in the secdir review [1] are all reflected in the current draft. [1] https://www.ietf.org/mail-archive/web/secdir/current/msg06783.html - I think it might be useful to more clearly state where you really intend for this to be implemented, which iiuc is within a webmail server. - Intro: Why no mention of http schemed URLs? Wouldn't it be a good idea to at least say these SHOULD/MUST NOT be used? - Section 4: The 2nd para there means that the http client MUST NOT send the POST message unless the DKIM signature is valid. If that's correct (and I hope it is) then might it be good to be more explicit about that? The current wording doesn't tie the signature validation so clearly to the action being (dis)allowed I think. (If someone has implemented this based on just the I-D and gotten this correct, then a change is probably not needed.) I wonder if implementations will easily be able to still check the DKIM signature status when sending the http POST message, but I'll believe you if you tell me that's ok.
Regarding JSON versa other formats question that came up during IETF LC: I believe this is an implementation preference and not everyone wants to have a JSON parser on the server side. Similarly about what is exactly returned in the form-data.
Thanks for addressing my comments
I support Stephen's discuss points and also did not find any changes that resulted from the SecDir review. Thanks.
I agree with Stephen that either the SHOULD NOT send cookies, etc. bit should be changed to MUST NOT or the exceptional circumstances under which it's ok to send them need to be listed. I don't get what those exceptions would be.
Victor Kuarsingh <victor@jvknet.com> performed the opsdir review
draft-holmberg-dispatch-received-realm
Thanks for engaging with the secdir review. [1] I think the two changes (or equivalents) that ended up with are needed but since those seem to be agreed there's no need for this to be a DISCUSS. [1] waiting the mail I fwd'd to show up in the archive
IESG question: Do we need to point the 3GPPP liaison to the publication of this doc? Three high level questions: - Is this actually a SIP specific problem/use case or would you also need a 'received-realm' value for other protocols? - Actions that would be done based on this value are still quite unclear. Can you give more concrete examples? - How is the 'received-realm' assigned to a network? How does a transit network know which value belongs to which network?
This is a well written document, but I have a few minor comments I would like to discuss: In 5.1: The procedures for encoding the JWS and calculating the signature are defined in [RFC7515]. As the JWS Payload information is found in other SIP information elements, the JWS Payload is not attached to the serialized JWS conveyed in the header field parameter, as described in Appendix F of [RFC7515]. The operator identifier and the serialized JWS are separated using a colon character. I read this several times and I am still not sure what the second sentence is trying to say. If you are saying that you are using detached signature, I think it is better to say so. In 5.6.2: jws = header ".." signature header = *base64-char signature = *base64-char If neither "header" nor "signature" can be empty, you should use "1*" when defining them. In 9: A SIP entity MUST use different key values for each parameter value that it recognizes and use to trigger actions. I am not sure what this is trying to say. Are you advising against key reuse between this document and keys used for other purposes?
I agree with Alexey's clarification request, it would be helpful to be more explicit in that text.
draft-leiba-3967upd-downref
I do think that our discussion about ensuring that downrefs are called out at Last Call time, whether or not they're in the downref registry, is headed in the right direction.
I support this change because delaying a doc to repeat the last call often doesn't make sense. However, I guess it would be easy to have tooling support that would automatically add a list of downrefs to the last call text (given it's already in the nits check)...?
Should there be any recommendation on where IESG should record that a particular DownRef was not Ladt Called, but is considered "safe"? E.g. using a datatracker comment, IESG telechat meeting notes.
do it
draft-ietf-taps-transports
I'm a co-author.
Thanks for a useful document. I think this will be quite informative for many people so please consider my comments below as just suggestions offered for consideration, and it's entirely fine if you'd rather not even think about 'em. (I can well imagine that a document like this could be polished forever and never finished.) - abstract: Having finished a first read of this I don't find the "classifies" and "compares" claims from the abstract to have really been met. - end of p11 - seems like a truncated paragraph there or something. - 3.5 (and to a lesser extent 3.6): This reads to me as if the authors regret that the world hasn't adopted the SCTP (resp. DCCP) as "planned." There's no particular action following from that, but we might want to consider whether or not that's the impression we want readers to get. I think it might be a tiny bit better to do a pass to try make the language in those bits more neutral. - 3.7: I agree with Alissa that referring to the TLS1.3 draft would be good. SSL can also be referred to via RFC6101. It'd be a little better to refer to RFC7525 as BCP195 I think. - 3.7.2: I think it'd be good to consider whether or not this should describe the so-called 0RTT feature of TLS1.3. That is a dangerous implement that could be usefully covered in this document as informing likely readers of this about how to properly use (or more importantly, not use) that new "feature" could be well worth while. - 3.7.2: The mention of RNGs here is a bit odd. Those aren't usually an external interface but rather a dependency that the implementation has on the system/OS. Similar things didn't seem to be mentioned in other equivalent sections. You also don't say that there's no standard API. There was also a relatively recent paper on how awful TLS cert APIs are and how those damage security that might be worth a reference. [1] This section could maybe do with a little more work. (If you want to, I'm nowhere near trying to insist.) [1] https://crypto.stanford.edu/~dabo/pubs/abstracts/ssl-client-bugs.html - 3.9.1: Cookies as "MIME headers"? Huh? Was this text checked over by some HTTP folks? That sentence makes me think 3.9 might need some more checking. - 3.10.2: Seems odd to have URLs here for non-maintained implementations of a rarely used protocol when the same wasn't provided for very widely used protocols. - 3.10 and 3.11: It wasn't clear to me why it's useful to include these. - 3.12: This seems oddly placed and I'm not clear why it's worth including ICMP but not DNS or CDNs or load balancing or issues related to head of line blocking.
Thanks for writing this document. I found it to be very useful summary of the transport protocols. * Section 3.1 Missing the Abort command. * Section 3.3 Why does UDP has a reference to the base IPv6 spec [RFC2460]? Is this for the pseudo-header calculation? If so, it needs to be added to TCP as well. * Section 3.3.1 - Might be worthwhile adding a reference to RFC6936 as well to explain the applicability of UDP zero checksums in IPv6. e.g. OLD: IPv6 does not permit UDP datagrams with no checksum, although in certain cases this rule may be relaxed [RFC6935]. NEW: IPv6 does not permit UDP datagrams with no checksum, although in certain cases [RFC6936] this rule may be relaxed [RFC6935]. The following sentence at the end of Page 11 seems incomplete Applications that need to provide fragmentation * Section 3.12 The reference for ICMPv6 is wrong. It should be RFC4443 instead of RFC4433 as stated in the draft. * Section 3.12.1 RFC1716 has long been obsoleted by RFC1812. Is there any reason to use the old router requirement spec? * Section 5 ICMP can be used with multicast addresses as well.
Just a few very minor comments: - 1, 2nd paragraph: Would it make sense to include citations for things like NewReno, TFRC, and LEDBAT? - 3.5.1, 2nd to last paragraph: Would a citation to WebRTC (perhaps the overview or the transports draft)? -3.5.2, paragraph starting with "For the following SCTP protocol extensions the BSD Sockets API..." The paragraph is hard to parse.
Thanks for adding in TLS to the replay protection list in section 5 from the SecDir review: https://www.ietf.org/mail-archive/web/secdir/current/msg06774.html
In Sec 5, I wondered why only IPv4 was specified for the broadcast? "IPv4 broadcast (UDP, UDP-Lite, ICMP)"
In Section 3.7, it seems like a reference to draft-ietf-tls-tls13 is warranted.
draft-ietf-pim-join-attributes-for-lisp
For the values for the "transport" (and I do agree with Mirja that it isn't entirely clear what should be there - I was expecting different encapsulations), I'd recommend having 0 as being unallocatable & having 255 be reserved for future use as was suggested in https://datatracker.ietf.org/doc/draft-haas-code-point-reservation-bcp.
One minor but I think important comment (I don't think this justifies a discuss but I would really like to see that changed or at least discussed): For me as a 'transport person' using the plain term '(underlaying) transport' is really confusing because it's very unspecific. In section 4.1. you actually call it the 'type of transport' and later on you talk about the mode of transport, but in general you just talk about the transport which is also reflected in the name of the attribute. In draft-ietf-taps-transports we classify this transport feature as part of addressing. I guess that might not be completely appropriate for your case. However, I would like to see the terminology here cleaned up to not only talk about '(underlaying) transport' but choose a more specific term. Given that you only have a 0 or 1 as choices in the attribute, I would even recommend to call this attribute 'Unicast Replication' or something like this instead of just 'Transport'. One other minor comment: There are many abbreviations that are not spelled out once and make the reading slightly harder, e.g. ITR and ETR and so on
I think it would be helpful to have a paragraph on the goal of the "experiment", even if the goal is to gather implementation/deployment/operational experience. There are a number of abbreviations that should be expanded on first mention.
Discussion inspired by Lucy's Gen-ART review might result in some clarifications in the document. Please make sure any clarifications, if you decide to have them, are done before the document is finally approved.
draft-ietf-tsvwg-diffserv-intercon
- I'm puzzled by this being informational, it sure seems like something that could/should be a standard. (I'm not objecting, just puzzled.) - Section 2: For an IETF consensus document wouldn't it be good to have some references for claims like "has proven to be a poor operational practice"? Is that actually a statement where we're confident of IETF consensus? (I have no clue, I'm just checking based on the language and the Informational RFC status.)
PHB should probably be spelled out somewhere at the beginning of the doc; maybe even MPLS...?
I'm pleased with the changes that Last Call review, but I noticed a couple of
nits that crept into new text.
In this sentence,
It is extensible and allows to
add a few more PHBs and DSCPs to the Diffserv-intercon scheme.
the text would be clearer if it said who was allowed to add PHBs and DSCPs, or
what the process is to do that (which probably makes that clear) - I'm pretty
sure I know that, but I'm not getting that from the text.
It looks like s/RFC5127s/RFC5127's/, to match other usages in the draft.
Thanks for addressing the SecDir review and in particular, adding in the privacy consideration into the security considerations section. https://www.ietf.org/mail-archive/web/secdir/current/msg06802.html
Lou Berger did the rtg-dir review of this document.
draft-ietf-6lo-privacy-considerations
intro, 1st bullet: doesn't that same issue arise with prefixes as well as IIDs? (At least if there are few hosts per /48 or /56.) It may be worth making that point somewhere separate from points about IIDs.
draft-ietf-siprec-callflows
* Section 3.1 Can you please clarify what a "Turret flow" is (and hopefully add a reference)? It is not immediately clear why this is special.
Dan Romascanu's Gen-ART review brought up editorial suggestions that are worth looking at.
I had the smae question about privacy considerations that the SecDir reviewer noted: https://www.ietf.org/mail-archive/web/secdir/current/msg06953.html But see it is covered in the referenced drafts. As such, could you note in the security considerations section the references are for both security and privacy considerations? Just add "and privacy".
draft-bbf-bbf-urn
Maybe stupid question: if only "bbf" is used for new work, does bbf need to specify an assignment process for the other two?
Process of identifier assignment:
BBF procedures for URN assignment are provided at [BBF-RESOURCES].
[BBF-RESOURCES] currently redirects to:
https://wiki.broadband-forum.org/display/BBF/Assigned+Names+and+Numbers#AssignedNamesandNumbers-URNNamespaces.1
This web page says:
To get a namespace assignment, requesters must go through the Broadband Forum
project and documentation creation process.
Is this clear enough for BBF users to get an assignment?
draft-ieee-urn
I wondered whether these URNs are only for IEEE standards use, or could in principle be used for other things that IEEE does. While I don't care if the answer is yes or no, and a "yes" answer would maybe be speculative, it might have been good to say in this document if the answer is known.