IESG Narrative Minutes
Narrative Minutes of the IESG Teleconference on 2016-06-14. These are not an official record of the meeting.
Narrative scribe: John Leslie (The scribe was sometimes uncertain who was speaking.)
Corrections from: (none)
1 Administrivia
2. Protocol actions
2.1 WG submissions
2.1.1 New items
Telechat:
Telechat:
Telechat:
Telechat:
2.1.2 Returning items
Telechat:
2.2 Individual submissions
2.2.1 New items
2.2.2 Returning items
2.3 Status changes
2.3.1 New items
2.3.2 Returning items
3. Document actions
3.1 WG submissions
3.1.1 New items
Telechat:
Telechat:
Telechat:
3.1.2 Returning items
3.2 Individual submissions via AD
3.2.1 New items
3.2.2 Returning items
3.3 Status changes
3.3.1 New items
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
Telechat:
1021 EDT no break
4 Working Group Actions
4.1 WG Creation
4.1.1 Proposed for IETF Review
Telechat::
Telechat::
Telechat::
4.1.2 Proposed for Approval
Telechat::
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::
Telechat::
Telechat::
7. Working Group News
Amy: we need to have chairs as soon as possible
1050 EDT Scribe left meeting (virtually impossible to scribe the conflict-resolution!)
(at 2016-06-16 06:00:02 PDT)
draft-ietf-teas-rsvp-te-srlg-collect
- 5.3: "...this SHOULD NOT be done unless explicitly mandated by local policy." Is that the same as saying this should default to off unless the administrator chooses to turn it on?
Minor comments/questions:
- Please spell out RRO in section 4.2
- Why are the following SHOULDs not MUSTs?
"[...] the Path message SHOULD NOT be rejected due to the SRLG recording
restriction and the Path message SHOULD be forwarded without any SRLG
sub-object(s) added to the RRO of the corresponding outgoing Path
message."
- Why do you need two (potentially different) policies for the two points
below. Shouldn't a node that provides SRLG information initially, also always
provide updates (as the initial information might otherwise be wrong and
therefore not be able to address the originial intention anymore - disjoint
paths)?
"o Whether the node is allowed to participate in SRLG collection.
o Whether the node should notify changes to collected SRLG
information to endpoint nodes as described in section 5.2."
"It is recommended that domain/layer boundary policies take the implications of releasing SRLG information into consideration and behave accordingly during LSP signaling." Eh, that's a bit opaque for me at least. Can you say a bit more about what those implications might be and how one might take them into account, and why that doesn't need to be mentioned in the document? I'm asking since there is a bit of a breach of the blood-brain barrier going on here (as is ack'd in the draft) and while it's hard to envisage that much going wrong if providers expose this information, I guess there might easily be something too subtle for this particular reader:-)
My comments are relatively minor but I would like to see them addressed before publication. 1. Section 4.1. (SRLG Collection Flag): "…this document defines a new flag in the Attribute Flags TLV…which MAY be carried…" I think a clearer description would be something worded more along the lines of "…which MUST be set in…to indicate that SRLG information SHOULD be reported…" It would also be good if in this section the difference between LSP_REQUIRED_ATTRIBUTES and LSP_ATTRIBUTES is also explained. 2. Section 4.2. (RRO SRLG sub-object): "…The SRLG sub-object SHOULD be pushed…before the node IP address…SHOULD be pushed after the Attribute sub-object, if present, and after the LABEL sub-object, if requested." Knowing that it is a stack, does it really make a difference where the SRLG sub-object is pushed? Put another way, why are you using "SHOULD" and not "MUST"? 3. Section 5.1. (SRLG Collection) "A node SHOULD NOT add SRLG information without an explicit request…" What happens if a node does? Should the "SHOULD NOT" be "MUST NOT"? 4. Section 5.2. (SRLG Update): "If local policy is that the SRLG change SHOULD be suppressed…" s/SHOULD/should The policy is being described, so a normative keyword is not appropriate. 5. Section 5.3 (Domain Boundaries) "If mandated by local policy, a node…MAY add a summary of the removed SRLGs or map them to other SRLG values." How is this (summary or mapping) done? If specified somewhere else, please add a reference. 6. Section 6.2. (Coherent SRLG IDs): "…SRLG IDs SHOULD be unique." Why is this not a MUST?
Adrian's explanation makes sense to me. I would have liked to see something similar to be added in the draft to clarify the behavior, but I leave it up to the authors/shepherds to decide if they want to do this or not. In Section 5.1 when the SRLG collection request was contained in an LSP_REQUIRED_ATTRIBUTES and the RRO would become too big, a node drops the RRO from the Path message entirely. It is not clear what the next node that receives this SRLG collection request without an RRO would need to do as the spec only says that the RRO is inserted at the ingress. What is the expected behavior here on the subsequent node?
opsdir review by Niclas Comstedt <nco@comstedt.net>
draft-ietf-avtext-splicing-notification
I believe this is more a discussion for the IESG. First, this is way out of my area and I'm not particularly commenting on the details - but I do agree with Mirja's discuss about "- The following action does not seem to be appropriate for a specification of an end-to-end protocol: "And if the splicer wishes to prevent the downstream receivers from detecting splicing, it MUST NOT forward the message."" The full paragraph at the end of Sec 3.2 is: "When the splicer intercepts the RTCP splicing notification message, it SHOULD NOT forward the message to the down-stream receivers in order to reduce RTCP bandwidth consumption. And if the splicer wishes to prevent the downstream receivers from detecting splicing, it MUST NOT forward the message." Even more specifically to me, superficially this seems to me to be a way to change what is in the stream that a receiver has requested or subscribed to without permission or notification. In that light, the idea that the splicer is able to prevent downstream receivers from detecting the splicing does not sound good. Similarly, the end of Sec 3.1 says "After the splicer intercepts the RTP header extension and derives the Splicing Interval, it will generate its own stream and SHOULD NOT include the RTP header extension in outgoing packets to reduce header overhead." This looks like another example of making the choice to hide information from the receiver. I realize that there is probably an technical arms-race going on - of inserting advertisements and building receivers to block undesired advertisements. I am not seeing a balanced solution that considers the receivers as well as the senders. I am startled that there is no consideration of the impact of this extension on the receivers in the security considerations. The only reference I see in the Security Considerations further assumes that it is appropriate to have an undetectable splicing. " A malicious endpoint may also break an undetectable splicing. To mitigate this effect, the splicer SHOULD NOT forward the splicing time information RTP header extension defined in Section 4.1 to the receivers. And it MUST NOT forward this header extension when considering an undetectable splicing. " At a minimum, I feel like there should be a very clear consideration of the pros and cons - including from the viewpoint of a receiver. If we end up with this biased technology, then it should be clearly stated - not hidden in assumptions.
I do share the question about the definition of "undetectable splicing".
I have a few points which I would like to have answers for before moving the doc forward (which may not even results in text changes). I happy to clear my position when answered before the telechat: - The following action does not seem to be appropriate for a specification of an end-to-end protocol: "And if the splicer wishes to prevent the downstream receivers from detecting splicing, it MUST NOT forward the message." I guess if a middlebox decides to drop the message, there is not much we can do. But I definitely would prefer to not see this specified in an RFC. - Why is just having the RTCP message not sufficient? Why are the RTP extensions needed as well? - And is the RTCP message send only once or multiple time? This is not specified. - There is some discussion about the implementation of the slicer in section 5 (where btw. the title "Failure Cases" seems inappropriate), while there is one sentence saying: "If the splicer is implemented following [RFC6828], it will have its own SSRC and will send its own RTCP reports, and will forward translated RTCP reports from the receivers." Why are alternatives discussed here, if there is already a recommendation given in RFC6828? And how would proper congestion handling be ensure in the other setups not described in RFC6828?
- As a general comment, I found it quite hard to read this doc without reading RFC6828 which is only listed as a informative reference as it is informational only. I think it is wrong. Further, RFC6828 describes some action that a slicers has to perform. However, all language in RFC6828 is non normative. This is slightly confusing to me as well. I would further recommend to briefly give an overview of the assumed scenario is this document. - Minor comment: The definition of the new SDP grouping semantic should be mentioned in the abstract and RFC4566 should be referenced. And I don't think the SDP grouping registry requires a contact. - Quick question: Maybe I'm missing something here but why do you need a splicer in a scenario where "the substitutive sender is implemented together with the main RTP sender inside a single device" (as written in section 2)?
(1) Section 7, 3rd para: Saying that "splicer works as a trusted entity" seems wrong - you need to say who trusts whom for what I think. I also don't get what you mean by saying there'll be a security association between the splicer and the receiver, nor how that might ever be possible if the splicer wants to hide what it's doing. I think what you're after is some general statement that splicing breaks all security unless all the parties involved share the same security association. IIRC there is text like that in other RTP documents that might be copied but I forget the detail. (2) Section 7, 4th para: You say there is a case where header extension encryption SHOULD be used - how would that work? If there's a clear way to do it that'd get interop, then why is that not described? If there are ways in which might or might not work, or if some proprietary arrangements might be needed then how is it ok to have a SHOULD there? I suspect that the right thing here may be to not pretend that that can be done but to just stick with saying that splicing is inherently not going to work if you use any real security mechanisms, or something similar. (3) In discussion of RFC6828 there was some concern about possible creation of loops. I forget the issues though, but wanted to check this in case it also applies here. (See 4.5 of 6828 maybe or the history for that RFC in the tracker.)
- I agree with Alia's discuss, but suspect the ship has sailed. (Sadly IMO, but sailed nonetheless.) - The security considerations here are similar to but not quite the same as those in RFC6828 which I think was the last time a similar document was before the IESG. I wondered if those differences were significant or not, it might be no harm to commpare the two (if that's not already been done) since they really ought be pretty much the same.
I strongly support Mirja's and Alia's discuss points and would like to see more of a discussion of the capability to hide splicing in the security considerations text. My ballot would be discuss, but they pulled out the relevant sections and that would be duplication. I'd like to review agreed upon text though to address these concerns. I don't like the idea of enabling a MiTM, but do see the draft talks about how to protect headers when this happens and confidentiality is needed as well as session protection between the endpoints and the splicer (which I don't like either, but you do call out the security considerations of this and that's what is needed).
= Section 4 = "Either the main RTP sender or the substitutive sender SHOULD send the synchronization metadata early enough so that the receivers can play out the multimedia in a synchronized fashion." In Section 2 you gave a guideline for how to figure out how far in advance to send the splicing information. I think a similar guideline would be useful here. s/e.g., choosing media sender/e.g., choosing main RTP sender/ = Section 7 = What is undetectable splicing? = Section 8.3 = In the past when we've registered these there was no contact I don't think. Not sure what IANA would do with one here.
draft-ietf-idr-ix-bgp-route-server
Quick question: Why is the following statement a SHOULD and not a MUST: "the route server SHOULD NOT prepend its own AS number to the AS_PATH segment nor modify the AS_PATH segment in any other way. " Is this because the clients might eitherwise not accept the message? Maybe add one sentence to explain the SHOULD!
From an operational point of view, when an ISP wants to go change from bilateral interconnections to the multilateral interconnection within one IXP, is this correct to say that all bilateral interconnections should be removed? So that basically the ISP must chose between the two models, and not combined them? If this is the case, it should be mentioned. I thought it was clear to me until I saw figure 1: The dotted line is the IXP or the IXP Route Server? At first glance, I thought that it was the IXP and that AS1 was connected to the IXP Route Server while still having a bilateral connection with AS4. I hope now that the dotted line is the IXP Route Server, otherwise I've confused.
Thanks for addressing the SecDir review comments: https://www.ietf.org/mail-archive/web/secdir/current/msg06613.html
Was wondering the same thing as Mirja.
I'm at a bit of a loss to understand why path hiding would be a considered an undesirable property of an MLPE routeserver. IMHO as an operator that peers on MLPE exchanges as well as bilaterally on exchange fabrics and via PNIs. blinding a client of the MLPE which I may have a session already with at the exchange or via PNI is basically mandatory. Likewise without per-asn export policy at exchanges my ability to advertise anycast prefixes via the MLPE is basically noexistant If an IXP operator deploys a route server without implementing a per-client routing policy control system, then path hiding does not occur as all paths are considered equally valid from the point of view of the route server. Does not seem like a particularly desirable outcome. While I'm fine with 2.3 not being normative, it does seem desirable that an MLPE service offer the client control, it greatly increases the sorts of clients that can safely use the service.
draft-ietf-mmusic-msid
I made some editorial comments in my AD evaluation[1] that have not yet been addressed due to an email misconnect. There are no showstoppers there, so I'd like to move this along in parallel. [1] https://mailarchive.ietf.org/arch/msg/mmusic/KejxusGmZxF6IcEyKmlftpQqosw
I'm not sure that the answer to this question will require any change to the document but wanted to check... I wondered about the privacy properties of these (and related) WebRTC identifiers, esp. if they are being handled at various different layers. Is there work somewhere in the WebRTC space that's analysing that? For example, one concern might be that msid-appdata could end up with some kind of privacy sensitive value, but there's no guidance here about that and as the examples use UUIDs it's not clear to me those represent nor what typical values will be used. (Note: I'm not saying that I believe this is a problem, I'm just checking if it's been considered.) I hope that there's no reason why these can't be very ephemeral values that don't identify (or help re-identification of) people or their preferences, locations etc., and I'd imagine there's little reason to e.g. log them. If that's the case wouldn't it be useful to add such guidance (somewhere, maybe not here) to help developers to do the right thing?
No sure the following is useful information: This document is a work item of the MMUSIC WG, whose discussion list is mmusic@ietf.org. First time I see this in an abstract.
= Section 2 = OLD Multiple media descriptions with the same value for msid-id and msid- appdata is not permitted. NEW Multiple media descriptions with the same combination of msid-id and msid- appdata are not permitted. = Section 3 = s/and when the corresponding media description is disabled/or when the corresponding media description is disabled/
Susan Hares <shares@ndzh.com> performed the opsdir review.
Copied here for completeness as it hasn't been addressed yet.
---
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.
Status: Almost ready to go, 2 minor concerns, NIT
General comment: Document and concept are generally clear. Thank you for
providing a simple solution to this problem.
Caveat: My expertise is at lower end of the stack. I cross referenced all the
WebRTC documentation, but I’ve missed how implementations provide feedback that
this protocols is up and working. Therefore, I’ve indicated the operational
issues as a set of questions for the authors to consider.
Minor concern:
1) Error handling: Is it possible that the msid-value, msid-id, and
msid-appdata can be inserted, and then received with values that are not valid
(1*64token-char]?
a. If so, an error sequence is necessary.
b. If not, it is important to explain why not
Add section to 3.2
2) Operational issues: A few questions for your to consider to provide
the link to operational issues.
Normal operational: How does the person who is utilizing this protocol in
WebRTC situation check the status of the protocols? Is it part of the WebRTC
status information that the implementations provide? If so, is there any
common management parameters that you can suggest? Is this in another document
in IETF or W3C?
Error operations: If you can have errors, how does the person who utilizes
this protocol in WebRTC find out the error rate. Again, is it part of the
WebRTC status information on errors? Is it in another document W3C?
Editorial NITS:
Page 7, section 3.1
Paragraph 2: double “,” in the section highlighted makes this sentence’s
meaning unclear.
Are these two sub-thoughts? If not two sub-thoughts, then perhaps the /new/
suggested text.
When MSID is used, the only time this can happen is when, at a time
subsequent to the initial negotiation, a negotiation is performed
where the answerer adds a MediaStreamTrack to an already established
connection and starts sending data before the answer is received by
the offerer. For initial negotiation, packets won't flow until the
ICE candidates and fingerprints have been exchanged, so this is not
an issue.
/new suggested/
When MSID is used, the only time this can happen is at a time
subsequent to the initial negotiation,
/
Paragraph 3
Pagination makes the following text difficult. Repagination in /new/ may help.
Or it may highlight where I was confused by your document.
/old/
The recipient of those packets will perform the following steps:
o When RTP packets are initially received, it will create an
appropriate MediaStreamTrack based on the type of the media
(carried in PayloadType), and use the MID RTP header extension
[I-D.ietf-mmusic-sdp-bundle-negotiation] (if present) to associate
the RTP packets with a specific media section. If the connection
is not in the RTCSignalingState "stable", it will wait at this
point.
o When the connection is in the RTCSignalingState "stable", it will
look at the relevant media section to find the msid attribute.
o If there is an msid attribute, it will use that attribute to
populate the "id" field of the MediaStreamTrack and associated
MediaStreams, as described above.
o If there is no msid attribute, the identifier of the
MediaStreamTrack will be set to a randomly generated string, and
it will be signalled as being part of a MediaStream with the
WebIDL "label" attribute set to "Non-WebRTC stream".
o After deciding on the "id" field to be applied to the
MediaStreamTrack, the track will be signalled to the user.
/
/new/
The recipient of those packets will perform the following steps:
o When RTP packets are initially received, it will create an
appropriate MediaStreamTrack based on the type of the media
(carried in PayloadType), and use the MID RTP header extension
[I-D.ietf-mmusic-sdp-bundle-negotiation] (if present) to associate
the RTP packets with a specific media section.
- If the connection is not in the RTCSignalingState "stable", it will wait
at this point.
- When the connection is in the RTCSignalingState "stable", it will look at
the relevant media section to find the msid attribute.
· Looking a Media section:
o If there is an msid attribute, it will use that attribute to populate the
"id" field of the MediaStreamTrack and associated MediaStreams, as described
above.
o If there is no msid attribute, the identifier of the MediaStreamTrack will
be set to a randomly generated string, and it will be signalled as being part
of a MediaStream with the WebIDL "label" attribute set to "Non-WebRTC stream".
o After deciding on the "id" field to be applied to the
MediaStreamTrack, the track will be signalled to the user.
/
_______________________________________________
OPS-DIR mailing list
OPS-DIR@ietf.org
https://www.ietf.org/mailman/listinfo/ops-dir
draft-ietf-sidr-rfc6485bis
The SecDir reviewer picked up on a stray "/>" in section 6, just making a note of that here, but I'm sure the RFC editor would see it too. https://www.ietf.org/mail-archive/web/secdir/current/msg06151.html
Thank you for amending the text in Section 5 (Additional Requirements) to reflect the work in RFC6916 and removing the explicit contradiction. Setting my ballot to No Objection.
draft-ietf-rtgwg-bgp-routing-large-dc
I would have liked to know a bit more about how these schemes behave if some of the servers or say a ToR device in the DC are considered as attackers e.g. having been compromised, but you only mention attacks from outside the DC. I assume the answer is to not accept servers as BGP speakers, but I'm not sure how you do that reliably. And I also don't know whether or not ToR devices are successfully attacked often.
Thanks for addressing the SecDir review: https://www.ietf.org/mail-archive/web/secdir/current/msg06610.html
Lionel Morand performed the opsdir review
draft-ietf-dmarc-interoperability
- Abstract: Please expand DMARC on first mention.
- 4.1.1.1, last bullet: "However, for known brands, all active domains are
likely to be
targeted equally by abusers."
I'm not sure quite what is meant by "known brands". Is this the same as well
known email services?
6. Some of the mentioned mitigations involved relaxing alignment checks. Do
those warrant a mention here?
-- last paragraph: " Section 4.1.3.3 warns that rewriting the RFC5322.From
header field
and changing the domain name should not be done with any domain."
I'm not sure I understand that sentence, especially around "not be done with
any domain". Nor do I see which text in 4.1.3.3 specifically says that.
- I think the abstract and intro are too coy in saying that DMARC "can" introduce interop issues when we know that it definitely does introduce such issues. Better to be up front about that I think. The same issue arises elsewhere (e.g. in 3.2.3.1) and I don't see any real benefit in almost pretending that this isn't a real issue. - I think the abstract and intro would be better if they explicitly ack'd that DMARC affects mailing lists. So maybe replacing the relevant sentence with something like: "Collectively these email flows are referred to as indirect email flows, and include mailing lists, such as those used to discuss this document." - 2.3: I'm surprised that we don't know the prevalence of simple vs. relaxed support and use. - 3.1.2: Saying that the MTA is the thing to "introduce" the interop issue here seems a bit wrong - isn't the issue caused by the existing MTA practice combined with the introduction of DMARC?
draft-ietf-ccamp-additional-signal-type-g709v3
Per IANA #912091 Management Item, need approval of Designated Experts for this registry. After Experts approved and Expert Review completed, will remove Discuss.
Shouldn't [G.Sup43] be a normative reference...?
Bert Wijnen performed the opsdir review
conflict-review-davie-stt
Although I have no objection to this review outcome I think we should be clear on where we hope this will head? Back to NVO3?
conflict-review-jabley-dnssec-trust-anchor
I have a concern with the text in the IANA considerations section of this document which I *think* conflicts with IETF process. I'm not concerned with the assignment of the value in the SMI Security for PKIX Module Identifier registry. That is fine given the construct of that registry. It is with: "Key Signing Key (KSK) management for the root zone is an IANA function. This document describes an initial set of publication mechanisms for trust anchors related to that management. In the future, additional publication schemes may also be made available, in which case they will be described in a new document that updates this one." I don't think this is appropriate for an informational ISE document. It feels like it's trying to add subtle 'IANA can do what it likes' text. I've reached out to Joe and Paul and suggested text as follows given the vast descriptive text in this document about what IANA/etc does. =-=-=-==- This document defines id-mod-dns-resource-record, value 70 (see section 2.2), in the SMI Security for PKIX Module Identifier registry. Beyond the registry assignment above, this document makes no other requests and places no further restrictions on IANA. =-=-=-=-=-
I agree with Terry though.
conflict-review-tcs-coap-no-response-option
COAP options need Expert Review to register. An earlier codepoint was registered, but codepoint values depend on bits that denote properties of options. In Buenos Aires the list of properties has changed, thus the codepoint change. I haven't received a confirmation from the Designated Expert, but I think author's explanation is plausible and I am not particularly concerned. The draft was presented in COAP and it doesn't look controversial.