IESG Narrative Minutes
Narrative Minutes of the IESG Teleconference on 2017-08-17. 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:
Telechat:
Telechat:
Telechat:
Telechat:
2.1.2 Returning items
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:
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
Telechat:
3.3.2 Returning items
3.4 IRTF and Independent Submission stream documents
3.4.1 New items
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
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::
7. Working Group News
7a. Other Business
1046 EDT Adjourned
(at 2017-08-17 05:27:24 PDT)
draft-ietf-payload-rtp-ancillary
I'd like to begin by noting that I know basically nothing about SMPTE or ST 291 or Ancillary Data. I opened the document thinking that this was going to be either impenetrable, a huge waste of my time, or both... I was very pleasantly surprised by how clear, accessible and interesting the document is -- it clearly describes the use case / problem, provides just enough background to make understanding the discussion (relatively) easy, and documents the solution / protocol in a clear and concise manner. I'm not really qualified to evaluate if this is the best way to implement / if it has hidden landmines (see first sentence!), but I'd like to thank the author and WG for producing a document which was a pleasure to read. I'd also like to draw your attention to Nevil's OpsDir review, which contains some good questions, and some nits: https://datatracker.ietf.org/doc/review-ietf-payload-rtp-ancillary-06-opsdir-lc-brownlee-2016-11-03/
One comment at the end of section 2: "One millisecond is a reasonable upper bound for the amount of time between when an ANC data packet becomes available to a sender and the emission of an RTP payload containing that ANC data packet." While it makes sense to send out the packet as soon as possible, I'm not sure what this sentence gives you. I don't think you can guanrantee 1ms as there might be additional delays on the NIC and as such I don't think there are any actions that could follow based on this value. To avoid that anybody is taking this as a hard requirement, I would maybe rather just remove this note.
Thank you for addressing the SecDir review comments. https://www.ietf.org/mail-archive/web/secdir/current/msg06947.html
I wasn’t sure whether this text was giving three examples of SDIs, or two. Am I the only one who’s confused? ANC is generally associated with the carriage of metadata within the bit stream of a Serial Digital Interface (SDI) such as SMPTE ST 259 [ST259], the standard definition (SD) Serial Digital Interface (with ANC data inserted as per SMPTE ST 125 [ST125]), or SMPTE ST 292-1 [ST292], the 1.5 Gb/s Serial Digital Interface for high definition (HD) television applications. Perhaps using the descriptions first in each case, and ending with the name and reference in parentheses, would be clearer?
The grouping semantics here are problematic. Section 4.1 talks about LS to
associate ANC streams with other streams. LS is strictly a synchronization
construct, not used to otherwise state relationships between streams. More
importantly, there's nothing that prevents it being used to synchronize an
arbitrary number of video streams with each other. The problem that arises is
best illustrated by this example, where I'm going to transmit two video
streams, each with their own ANC data, but need them to be synchronized (e.g.,
perhaps I'm going to have two border-less screens physically right next to each
other for a double-wide image, and synchronization is important to avoid
tearing):
v=0
o=Al 123456 11 IN IP4 host.example.com
s=Professional Networked Media Test
i=A test of synchronized video and ANC data
t=0 0
a=group:LS V1 V2 M1 M2
m=video 50000 RTP/AVP 96
c=IN IP4 233.252.0.1/255
a=rtpmap:96 raw/90000
a=fmtp:96 sampling=YCbCr-4:2:2; width=1280; height=720; depth=10
a=mid:V1
m=video 50002 RTP/AVP 96
c=IN IP4 233.252.0.1/255
a=rtpmap:96 raw/90000
a=fmtp:96 sampling=YCbCr-4:2:2; width=1280; height=720; depth=10
a=mid:V2
m=video 50010 RTP/AVP 97
c=IN IP4 233.252.0.2/255
a=rtpmap:97 smpte291/90000
a=fmtp:97 DID_SDID={0x61,0x02};DID_SDID={0x41,0x05}
a=mid:M1
m=video 50012 RTP/AVP 97
c=IN IP4 233.252.0.2/255
a=rtpmap:97 smpte291/90000
a=fmtp:97 DID_SDID={0x61,0x02};DID_SDID={0x41,0x05}
a=mid:M2
If the recipient of these mutually synchronized streams needs to reintegrate
the ANC data into the video for offloading to an HDMI connection, how does it
know which ANC stream to insert into which video stream?
There needs to be some additional association mechanism here. You can either
add an attribute to the smpte291 media sections that clearly indicates which
video stream they correspond to, or you can include the smpte291 packets in the
same stream as the corresponding video, like so:
v=0
o=Al 123456 11 IN IP4 host.example.com
s=Professional Networked Media Test
i=A test of synchronized video and ANC data
t=0 0
m=video 50000 RTP/AVP 96 97
c=IN IP4 233.252.0.1/255
a=rtpmap:96 raw/90000
a=rtpmap:97 smpte291/90000
a=fmtp:96 sampling=YCbCr-4:2:2; width=1280; height=720; depth=10
a=fmtp:97 DID_SDID={0x61,0x02};DID_SDID={0x41,0x05}
m=video 50002 RTP/AVP 96 97
c=IN IP4 233.252.0.1/255
a=rtpmap:96 raw/90000
a=rtpmap:97 smpte291/90000
a=fmtp:96 sampling=YCbCr-4:2:2; width=1280; height=720; depth=10
a=fmtp:97 DID_SDID={0x61,0x02};DID_SDID={0x41,0x05}
(See RFC4733 for an example of a payload that performs stream association in
this fashion)
It is common in examples of RTP payloads (such as Figure 1) to include values for those fields whose values are illustrative of the format itself. The "V=2" in Figure 1 is an example of this. I would suggest that the example would be slightly improved by including a similar notation for (e.g.) "Length = 32", "ANC_Count = 2", and the two Data_Count fields. Section 2.1 defines "b01" as "invalid" for the F field. It does not, however, prescribe what recipients of such a value should do; reasonable options would include (a) treat it as 0b00; (b) ignore the ANC but process any others that might be present; or (c) ignore the entire packet. I'll note that (b) allows you to come back and add semantics for "0b01" at a later date, if you find a reason to do so. In any case, to minimize variations among recipients, I would suggest defining concrete behavior here. [Warning: I'm not terribly familiar with SMPTE video formats, and with the UHD-and-higher specs in particular, so it may be that the following comment can be answered with "that can never happen no matter how high-res streams get in the future."] As far as I know, SMPTE defines 4k as having 4 streams (each efectively a normal 1080 stream), 8k as having 16, and the future-looking 16k (presumably) having 64. Given that the Horizontal_Offset can communicate widths only up to 4093 samples (well within striking distance of the 2640 samples used by a single stream), and that the StreamNum field can communicate at most 128 streams, it seems that any sizes larger than 16k run the risk of exceeding the ability for these fields to place ancillary data packets at the correct horizontal position. I would recommend defining another reserved value for Horizontal_Offset (0xFFD), that can be used to mean "longer field follows" in a future specification; and a reserved value (0x7F) for StreamNum for the same purpose. Line_Number, with a maximum value of 2045, is similarly within striking distance of the 1125 lines used by a single stream, and would likely need the same accommodations. It is implied, but not stated, that implementations should use different sessions (or at least different media sections) to convey smpte291 payloads than the video streams they correspond to. If this is the intention, please include a normative statement to that effect. If it is okay to include both payload types in the same media section, please add a statement explicitly saying so, and indicate that this can be used as an alternative to using LS groups. Section 5.1 indicates that the answerer can respond with "all or a subset" of the DID_SDID parameters, or that it "MAY reject the offer." Of course, an answerer is always able to reject an offer, but this text seems to imply that it might do so if it doesn't want to receive any of the DID_SDID parameters indicated in the offer. That seems like massive overkill. Since the model here appears to be using multiple sessions (or, at least, separate media sections) to convey smpte291 data, I would offer that this should instead say something like "MAY set the corresponding port number to 0 to decline the smpte291 stream". (If you opt to allow the smpte291 payloads to be in the same media section as their corresponding video streams, this would instead involve removing the corresponding PT). Nit: The final line in the final example of section 4 is too long. Consider outdenting by two characters.
This is generally a well written document. As the media type registration template in Section 3.1 is supposed to be self contained (it will be posted to IANA website as a web page), it should define (or point to) ABNF for different parameters and specify that some parameters (e.g. DID_SDID) can be repeated multiple times. I can find this information in Section 4, so please add references to section 4 in the template.
draft-ietf-dmm-mag-multihoming
Thank you for making the change to address Mirja's Discuss, which I agreed with. I also agree with your proposed resolution.
Sri Gundavelli's proposal text in https://mailarchive.ietf.org/arch/msg/dmm/hh4xrA5vOkC3NuH3l-e3zH9-aM8 addresses my concern. Thanks Sri, W -------------- Old discuss position for posterity: "Section 3.2. Traffic distribution schemes "Per-packet management: the LMA and the MAG distribute packets, belonging to a same IP flow, over more than one bindings (i.e. more than one WAN interface)." This immediately made my out-of-order-packets antenna pop up, so I read the section looking for mitigations. The very next sentence reads: "Packet distribution can be done either at the transport level, e.g. using MPTCP or at When operating at the IP packet level, different packets distribution algorithms are possible. " -- the fact that this sentence is a: malformed and b: hand-wavy did nothing to allay my concerns, so I read further: "The distribution algorithm is left to implementer but whatever the algorithm is, packets distribution likely introduces packet latency and out-of-order delivery. LMA and MAG shall thus be able to make reordering before packets delivery." - I agree with the first sentence (although it is poorly worded), but the second sentence doesn't follow from the first; "shall thus be able to" implies that the prior text somehow provides a solution, not points out a problem (the sentence is also malformed)-- I think you mean something like "The LMA and MAG thus need to be able reorder packets to their original order before delivery." This then continues with "Sequence number can be can be used for that purpose, for example using GRE with sequence number option [RFC5845]." - I think that the actual reference should be RFC2890, but regardless of this, I don't think that what you are proposing works - "The Sequence Number field is used to maintain sequence of packets **within** the GRE Tunnel." (from RFC2890, emphasis added). This means that sequence numbers are local to the tunnel, and (as I understand it) your solution involves diverse tunnels. Further, Section 2.2. Sequence Number says: "The receiver may perform a small amount of buffering in an attempt to recover the original sequence of transmitted packets. In this case, the packet may be placed in a buffer sorted by sequence number." - if you are proposing using a single sequence number space for multiple tunnels, you will end up with sequence number space gabs, and lots of buffering, etc. The section ends with: "However, more detailed considerations on reordering and IP packet distribution scheme (e.g. definition of packets distribution algorithm) are out the scope of this document." - I think that, unless the prior paragraph is significantly reworked, it should not try and suggest any mitigations. The whole idea of striping packets of a flow across (notably) different transports seems like a really bad idea to me -- is it actually needed?"
I have a few editorial comments/nits: - There are several acronyms that should be expanded on first mention. (including at least a couple that are expanded on _second_ mention (MAG and LMA). - 3.2, "Per-packet management" bullet: The second sentence does not make sense. - 3.2, last paragraph: Are we really talking about the latency introduced by per-packet management, or jitter (i.e. variation in latency)? - 4.1, definition of "Interface Label": This doesn't really define the term "interface label". It talks about how it is used, but not what it represents.
1) This document should not recommend the use of MPTCP for tunneling, as TCP-in-TCP tunnels are generally not recommend if that can be avoided. Please remove the following part from section 3.2 and leave IP-level tunneling as the only option: „Packet distribution can be done either at the transport level, e.g. using MPTCP …“ 2) Further the following sentences also in section 3.2 should be revised: „For example, high throughput services (e.g. video streaming) may benefit from per-packet distribution scheme, while latency sensitive applications (e.g. VoIP) are not be spread over different WAN paths.“ High throughput services only benefit from per-packet scheduling if the service requires higher throughput than one of the links can provide. Also video streaming may not be a good example here because high latency variations can lead to stalls. Therefore in general per-flow scheduling should be recommend for all traffic. It could still be beneficial to schedule flows that require low latency over the link with the lower base latency, or maybe more important lower jitter, however, often it is not known to the network what the requirements on latency are for a given flow. Therefore is should probably be recommended to schedule all traffic on the "better" link (where better can be pre-configured knowledge or measured) as long as the bandwidth of the incoming traffic is smaller than the bandwidth of the that link, and only use a second link (with per-flow scheduling) if the capacity is required. 3) This document does not really normative specify the use of the newly defined options. It only gives an examples but it does not specify normatively any actions that need to performed on receipt of these options. How does the MAG know if the LMA does not support Multipath binding? An LMA that does not implement this spec will not send back an error message. Why are there two different options? What happens if one of the options is present in the Proxy Binding Update but not the other?
Please also clarify the definitions of Interface Label and Binding Identifier as requested by the gen-art review (Thanks Robert!)
Thanks for your work on this draft. I had the same concern as the SecDir reviewer in reading the draft, the concern about leaking traffic as a result of multiple tunnels is not addressed in the security considerations section. Hilary's writeup is quite helpful https://www.ietf.org/mail-archive/web/secdir/current/msg07446.html
1) Sec 3.2: "Packet distribution can be done
either at the transport level, e.g. using MPTCP or at When
operating at the IP packet level, different packets distribution
algorithms are possible. " is clearly not a properly written sentence.
I also share Mirja's concerns about TCP inside TCP.
2) Sec 4.1: "This flag MUST NOT be set to a
value of (1), if the value of the Registration Overwrite Flag (O)
is set to a value of (1).
Binding Overwrite (O)"
Please make the draft consistent as to the name of the flag (O)
Figure 1 labels the bottom-left most construct "Flow0-4" -- I suspect this should be "Flow-4." I see the requests to remove MPTCP from the document, and the rationale seems sound. If, by some chance, any mention of MPTCP remains in the final version, please make sure it gets expanded (as an acronym) and cited. The final paragraph in section 3.2 starts with "Because latency introduced by..." -- this isn't the reason damage can arise. The problem is the *variation* in latency. Suggest something like: "Because the variation in packet latency, also known as jitter, introduced by per-packet scheduling between access networks can cause..." Section 4.1, definition of If-ATT -- suggest citing the specific section: "[RFC5213] section 8.5." Section 4.1, definition of If-Label -- the value of 0 appears to be reserved? Ideally, this would prescribe specific behavior for an LMA if they receive an If-Label of 0. Section 4.1, definition of BID -- same comment; ideally, this would specify recipient behavior if set to 0 or 255. Section 4.3 defines a new response code for LMAs that don't implement this spec. Existing, already deployed LMAs will necessarily have a different reaction to receiving these unknown options than sending this response code. This section should provide guidance for MAGs letting them know what observable behavior they should expect when sending these options to LMAs unaware of this extension at all. Additionally, _if_ such observable behavior is sufficient for the MAG to understand what is happening, I would assert that the new response code is unnecessary and should be removed. Please expand the following acronyms upon first use and in the title; see https://www.rfc-editor.org/materials/abbrev.expansion.txt for guidance. - MAG - Mobile Access Gateway (in the title) - GRE - Generic Routing Encapsulation - LMA - Local Mobility Anchor - LTE - Long-Term Evolution - MN - Mobile Node - BCE - Bonding Channel Entity
Nit: IANA-3 value is referenced in the IANA Considerations, but is not used. I think you meant IANA-4 in the place where IANA-3 is currently referenced.
draft-ietf-mmusic-dtls-sdp
This falls well into the "This is outside my area of expertise" part of: This ballot position may be interpreted as "This is outside my area of expertise or have no cycles", in that you exercise the ability to move a document forward on the basis of trust towards the other ADs. :-)
Mostly a nit... RFC4572 has been Obsoleted by RFC8122. I think that this change in status implicitly means that all references to RFC4572 should now really refer to RFC8122. I then don't think there's a need to explicitly Update the references from RFC4572 to RFC8122. In the text Updating RFC5763 (10.2.1), the document says: "The reference to [RFC4572] is replaced with a reference to [RFC8122]." I don't think that is necessary. Also, the Update to RFC7345 (10.3.3) adds a Normative bibliographical entry to RFC8122, but no text is updated to point at that RFC. I don't think this is necessary either.
This is nothing big and should be easy to fix: On section 7.1, of course... "If DTLS is transported on top of a connection-oriented transport protocol (e.g., TCP or SCTP), where all IP packets are acknowledged, all DTLS packets associated with a previous DTLS association MUST be acknowledged (or timed out) before a new DTLS association can be established on the same instance of that transport (5-tuple)." I don't think this would be necessary for QUIC. The point here is, I believe, not the fact that TCP and SCTP are connection-oriented, but that re-transmissions cannot be easily distinguished from the original packet. So the point is rather the use of a reliable protocol that retransmits in a specific way. However, why would you use DTLS with TCP instead of TLS? And I also don't think you want to use DTLS with QUIC because it has it's own crypto. I guess the recommendation should rather be that reliable transports should use TLS, and if DTLS is needed a new DTLS connection can only be established if there is not retransmission ambiguity which is always the case when all outstanding packets are ack'ed or considered lost (timed out). Or am I missing the point?
A couple mostly editorial comments: - Probably a nit: In section 3.2 'must' is used while in section 3.3 'MUST' is used. I would assume that both sections should probably use the same. - in sec 5.1: "Because of this, if an unordered transport is used for the DTLS association, a new transport (3-tuple) must be allocated by at least one of the endpoints so that DTLS packets can be de-multiplexed." Why is this a 3-tuple (instead of a 5-tuple)? I guess you talk about the source address, source port, transport 3-tuple? May say this more explicitly. Also the word of the use transport is confusing to me here because it's used for the transport protocol as well as for the transport 'connection' (if a connection-oriented transport protocol is used). Maybe s/new transport/new flow/? Moreover, there should probably be a 'MUST' here instead of 'must'! - sec 5.2:"In addition, the offerer MUST insert in the offer an SDP 'tls-id' attribute with a unique attribute value." Is that a MUST or rather a SHOULD? The rest of the text reads like this should be a SHOULD. - Shouldn't this document cite RFC6347 normatively, e.g. here (sec 5.3): "... the answerer MUST initiate a DTLS handshake by sending a DTLS ClientHello message towards the offerer." - I would like to see more discussion about linkability based on the introduction of the "tls-id" in the security considerations section.
I agree with Alexey's discuss, thanks for addressing it.
1. Assuming I understand this document correctly, it conflicts with
the guidance in JSEP. Specifically, S 4 says:
No default value is defined for the SDP 'tls-id' attribute.
Implementations that wish to use the attribute MUST explicitly
include it in SDP offers and answers. If an offer or answer does not
contain a 'tls-id' attribute (this could happen if the offerer or
answerer represents an existing implementation that has not been
updated to support the 'tls-id' attribute), unless there is another
mechanism to explicitly indicate that a new DTLS association is to be
established, a modification of one or more of the following
characteristics MUST be treated as an indication that an endpoint
wants to establish a new DTLS association:
o DTLS setup role; or
o fingerprint set; or
o local transport parameters; or
o ICE ufrag value
This seems to say that if there is no tls-id attribute, then an ICE restart
(which necessitates a ufrag change) requires a DTLS restart. JSEP isn't
incredibly clear on this point, but 5.7.3 seems to say that tls-id
neeed not be present:
* tls-id value, which MUST be set according to
[I-D.ietf-mmusic-dtls-sdp], Section 5. If this is a re-offer
and the tls-id value is different from that presently in use,
the DTLS connection is not being continued and the remote
description MUST be part of an ICE restart, together with new
ufrag and password values. If this is an answer, the tls-id
value, if present, MUST be the same as in the offer.
I believe that the first sentence is in error, as we clearly
can't have JSEP implementations requiring that tls-id be present.
...
o If the remote DTLS fingerprint has been changed or the tls-id has
changed, tear down the DTLS connection. This includes the case
when the PeerConnection state is "have-remote-pranswer". If a
DTLS connection needs to be torn down but the answer does not
indicate an ICE restart or, in the case of "have-remote-pranswer",
new ICE credentials, an error MUST be generated. If an ICE
restart is performed without a change in tls-id or fingerprint,
then the same DTLS connection is continued over the new ICE
channel.
I think the best interpretation of this is that if tls-id is not present
(and hence unchanged) then ICE restart does not cause DTLS restart.
This is also my memory of the consensus in RTCWEB. In any case, these
two documents clearly must match.
2. S 4 says:
The mux category [I-D.ietf-mmusic-sdp-mux-attributes] for the 'tls-
id' attribute is 'IDENTICAL', which means that the attribute value
must be identical across all media descriptions being multiplexed
[I-D.ietf-mmusic-sdp-bundle-negotiation].
This is not actually what JSEP requires:
different categories. To avoid unnecessary duplication when
bundling, attributes of category IDENTICAL or TRANSPORT MUST NOT be
repeated in bundled m= sections, repeating the guidance from
[I-D.ietf-mmusic-sdp-bundle-negotiation], Section 8.1. This includes
I suspect this is old text.
3. S 7.1 says:
If DTLS is transported on top of a connection-oriented transport
protocol (e.g., TCP or SCTP), where all IP packets are acknowledged,
This is incorrect, because none of these protocols ack all IP packets.
all DTLS packets associated with a previous DTLS association MUST be
acknowledged (or timed out) before a new DTLS association can be
established on the same instance of that transport (5-tuple).
More generally, I'm not sure that this is useful, because the
required semantic isn't *acknowledged* but rather that the receiver
can appropriately demux. So, say you just stop sending DTLS on
connection A and start sending on B, what's the delimiter, given
that you don't require close_notify here? IIRC, we just decided to
punt on this whole thing. Does anyone try to have successive
connections over the same transport, even when it's connection oriented?
4. The demux instructions seem to have gotten lost from 6.7.1. At minimum
these need a reference to RFC 7983.
S 5.1. media session immediately (see [RFC8122]). Note that it is permissible to wait until the other side's fingerprint(s) has been received before establishing the connection; however, this may have undesirable latency effects. I agree that it's permissible, but why would you do this? This does not seem like helpful guidance. S 10. Please do something about the "NEW" constructions. I literally had to pull these into ediff to know what had changed. That's not useful to people. I'm not a fan of this construction in general, but at minimum you need to explain what has changed. S 9. Regardless of the previous existence of a DTLS association, the SDP 'setup' attribute MUST be included according to the rules defined in [RFC4145] and if ICE is used, ICE restart MUST be initiated. What is the rationale for this rule?
Section 5.4 says: NOTE: A new DTLS association can be established based on changes in either an SDP offer or answer. When communicating with legacy endpoints, an offerer can receive an answer that includes the same fingerprint set and setup role. A new DTLS association MUST still be established if such an answer was received as a response to an offer which requested the establishment of a new DTLS association. Unless I've misunderstood something important, this isn't going to work with legacy implementations, unless you also specify that an "offer which requested the establishment of a new DTLS association" must also change something else that the legacy answerer will recognize as requiring a new DTLS association. For example, if I send a re-offer with a changed tls-id but the same fingerprint, setup, and transport, the far end will have no reason to think it needs to establish a new DTLS association. So I'll sit there waiting for a new association to be established, and the remote side will never send one. This doesn't seem backwards-compatible. At the very least, more text needs to be added explaining how this is intended to work.
I agree with the core assertion of EKR's DISCUSS: this document needs to be aligned with JSEP. I think we're going to need a little additional work figuring out which document needs to change where they disagree. In addition to those areas he highlights in his DISCUSS, the following text is also in conflict: DTLS-SDP: "the offerer and answerer generate their own local 'tls-id' attribute values, and the combination of both values identify the DTLS association." JSEP: "If this is an answer, the tls-id value, if present, MUST be the same as in the offer." I would think the long-form title of this document should include "TLS," to reflect that it also contains TLS-related procedures. Section 1: "...but currently there is no way..." will not age well once this is an RFC. Suggest "...previously, there was no way..." or somesuch. Section 2 uses RFC 2119 boilerplate, and then the very next sentence uses a non-normative "must." I would strongly recommend moving to RFC 8174 boilerplate. The conventional name for DTLS-SRTP is "DTLS-SRTP" -- please change replace "SRTP-DTLS" with "DTLS-SRTP" everywhere it appears. The last paragraph in section 5.4 starts with "NOTE" (which implementors frequently read as non-normative) and then contains a normative statement. Suggest removing "NOTE:" Please expand the following acronyms upon first use and in the title; see https://www.rfc-editor.org/materials/abbrev.expansion.txt for guidance. - SDP - Session Description Protocol - DTLS - Datagram Transport Layer Security - TLS - Transport Layer Security - ICE - Interactive Connectivity Establishment - SCTP - Stream Control Transmission Protocol - SRTP - Secure Realtime Transport Protocol - UDPTL - UDP Transport Layer
This is a fine document, but I have one [hopefully easy to answer] question and a couple of other minor ones: In Section 5.1. General Endpoints MUST support the cipher suites as defined in [RFC8122]. I don't see any ciphers specified in that RFC. Can you clarify what you mean?
8. TLS Considerations NOTE: Even though the SDP 'connection' attribute can be used to indicate whether a new TLS connection is to be established, the unique combination of SDP 'tls-id' attribute values can be used to identity a TLS connection. The unique value can be used e.g., within TLS protocol extensions to differentiate between multiple TLS connections and correlate those connections with specific offer/ answer exchanges. Are any such extensions defined or in the process of being standardized? If an offerer or answerer receives an offer/answer with conflicting attribute values, the offerer/answerer MUST process the offer/answer as misformed. I think a pointer to document and section where such handling is specified would be useful here.
draft-ietf-curdle-cms-ecdh-new-curves
One purely editorial comment: I much prefer the use of the RFC numbers as reference keys, however, I know that this style is possible as well and I also don't know if there are any recommendations by the RFC editor for this. However, I can say that the other style (use of [RFCXXX]) is more common.
Thanks for a well-written draft. I trust the TBDs Alexey already mentioned will be addressed.
This citation does not appear to be used anywhere in the document, and RFC 5480
is not mentioned (at least, not by number):
[PKIXECC] Turner, S., Brown, D., Yiu, K., Housley, R., and T. Polk,
"Elliptic Curve Cryptography Subject Public Key
Information", RFC 5480, March 2009.
Section 8 still has some TBD. These should be completed before the document is published as an RFC.
draft-ietf-webpush-vapid
*Very* minor nits: 1: I'm reviewing both this document and draft-ietf-webpush-encryption (both of which have Martin Thomson as an author) -- these use different capitalizations for many terms, for example "user agent" vs "User Agent" -- this document references RFC8030, which has these lower-case, and so I suspect that it is draft-ietf-webpush-encryption which should change, but I figured I'm mention it here as well. 2: Section 7. Acknowledgements "This document would have been much worse than it currently is if not for the contributions ..." Once published as an RFC, it is cast in stone. I support your the above, but think you should remove "currently", so perhaps: "This document would have been much worse if not for the contributions ..." Again, these are tiny nits, I don't have enough knowledge of the topic to make more useful comments :-P Edited: Sorry, managed to click submit before thanking Stefan Winter for his OpsDir review, and the authors for addressing them.
Thanks for addressing my DISCUSS and COMMENT points.
I have cleared my DISCUSS based on changes in git. I am looking forward to continuing discussion about advertising support for the "vapid" authentication scheme in WWW-Authenticate: In Section 3, 3rd para: This authentication scheme does not require a challenge. Clients are able to generate the Authorization header field without any additional information from a server. Therefore, a challenge for this authentication scheme MUST NOT be sent in a WWW-Authenticate header field. Does this mean that there is no way to discover whether a particular server supports "vapid" HTTP authentication scheme?
Thanks for your work on this draft. In section 3, it seems that you are just signing the JWK and that seems fine from the text and the purpose listed - origin server authentication. Then in section 3.2, there's a reference to I-D.ietf-webpush-encryption saying, "An application server MUST select a different private key for the key exchange". This makes me think that encryption is used as well, but I think it would be helpful to see the point made more clear here or in the security considerations section. Is confidentiality provided/required or just integrity for this draft?
This design seems to have the unfortunate security property that the JWT is really just a bearer token. The only reason it has to involve public key cryptography at all is to allow the push cient to refer to the public key when it makes a subscription. However, as the Security Considerations acknowledge, this allows a cut-and-paste attack (more than just replay) by an attacker who acquires any JWT, because it does not include the message itself. The primary motivation for this appears to be to minimize CPU cost on the push service. However, there are designs which do this without allowing replay. For instance: - Have the push service have a static public key K_svc which is published to application servers (e.g., via well-known). - In order to form the JWT, have the application server generate a fresh DH key K_app, which is embedded in the JWT. - The message which the app server sends to the push service is then MACed with the DH shared secret Z. This removes the cut-and-paste attack (though of course replay attacks are still possible) unless the push service keeps a replay cache. The replay service can trivially amortize the DH computation (it has to amortize the signature verification in any case to get any computational benefit) but it's soft state, so it can just forget it at any time. Ultimately, this is a WG decision, but given that there are designs with much better security properties, I'd like to know that the WG considered and rejected this kind of design alternative before we advance the weaker design.
Abstract This identification information can be used to restrict the use of a push subscription a single application server. to a single S 1. Additionally, this design also relies on endpoint secrecy as any application server in possession of the endpoint is able to send messages, albeit without payloads. In situations where usage of a subscription can be limited to a single application server, the ability to associate a subscription with the application server could reduce the impact of a data leak. I don't understand this text. S 1.2 The words "MUST", "MUST NOT", "SHOULD", and "MAY" are used in this document. It’s not shouting, when they are capitalized, they have the special meaning described in [RFC2119]. This seems over-cute. We now have a document that describes this convention. S 2. This JWT is included in an Authorization header field, using an auth- scheme of "vapid". A push service MAY reject a request with a 403 (Forbidden) status code [RFC7235] if the JWT signature or its claims are invalid. Given that "vapid" is tied to "P-256" it seems like it would be better to rename this "vapid-p256" S 4.2. When a push subscription has been associated with an application server, the request for push message delivery MUST include proof of possession for the associated private key that was used when creating the push subscription. This really isn't a proof of possession, as the Security Considerations makes clear. S 5. You should call out that the email address is just a bare assertion.
Wondering if the new registry in section 6.2 is really needed. Is it expected that new parameters show up any time soon? For me this doc reads like that's the only two parameter you actually need.
draft-ietf-v6ops-unique-ipv6-prefix-per-host
* Section 4 It is not clear what you intend here "IPv6 Router Advertisement Interval = 300s" The router advertisement interval is not configured as an absolute value but as minimum and maximum bounds (MinRtrAdvInterval and MaxRtrAdvInterval) which are used to calculate the actual advertisement interval. When the RA is sent from an interface, the actual interval is an uniformly distributed random value between the MinRtrAdvInterval and MaxRtrAdvInterval. At the very minimum you need to clarify if you would like to have this as a lower bound or as an upper bound.
* Section 4 -> I think text is needed here to handle the case where the DNS server is provided in the RA itself (RFC8106) "In addition it will use stateless DHCPv6 to get the IPv6 address of the DNS server" -> I am not sure what is the motivation for this text. "however it SHOULD NOT use stateful DHCPv6 to receive a service provider managed IPv6 address" -> This text seems incorrect "due to the L-bit set, it SHOULD send this traffic to the First Hop Provider Router" I think it should be the exact opposite. i.e. say *unset* instead of set "due to the L-bit being unset, it SHOULD send this traffic to the First Hop Provider Router"
To me this seems approriate for BCP; I'm saying this because this was mentioned in the shepherd-write-up as it was brought up by the gen-art review. Please also consider the following comment from the gen-art review (Thanks Joel!): "The issue of status for the document (BCP vs Informational) is for the IESG to conclude. However, even if it is a BCP, as I understand the purpose, this document is intended to describe the practices to be used when a provider has decided to deploy a /64 per host. The wording that is chosen throughout the document makes it appear that the underlying decision about such a deployment is also a recommended practice." I agree that wording could be made clearer here!
I have no technical comments, but a number of editorial comments: - General: I think this could use another proofreading and/or editing pass for the following issues: -- Inconsistent tense--especially use of future or present continuous. -- Wordy and convoluted sentences -- Use of "/" as a conjunction. - Abstract: The abstract is longer and more detailed than is useful. The last paragraph could have stood alone as the abstract. It's not clear to me if "hosts (subscribers)" means something different than "hosts" in context. -1: Please expand "IA_NA" on first use. s/"This document will focus..."/"This document focuses..." "As such the use of IPv6 SLAAC based subscriber and address management for provider managed shared network services is the recommended technology of choice, as it does not exclude any known IPv6 implementation." Does this document make that recommendation, or is that some pre-existing recommendation? -3: "The Best Current Practice documented in this note is to provide a unique IPv6 prefix to hosts/subscribers devices connected to the provider managed shared network." The sentence hard to follow. Consider "This document recommends...". I'm not sure how to interpret "hosts/subscribers devices" "Each unique IPv6 prefix can function as control-plane anchor point to make sure that each subscriber is receiving" s/"... subscriber is receiving ..."/"... subscriber receives..." -4: Is "First Hop Provider Router" different than "First Hop Router"? In the last bullet (L-flag=0), are NEVER and ALWAYS in all-caps expected to have different meaning than if they had normal capitalization? The sentence starting with "The architected result of designing the RA as documented above..." is convoluted and hard to follow. "... however it SHOULD NOT use stateful DHCPv6 to receive a service provider managed IPv6 address": Is that really a normative requirement, or is it a statement of fact about existing requirements? "it SHOULD send this traffic to the First Hop Provider Router." : statement of fact? - 5: "To reduce undesired resource consumption on the First Hop Router the desire is to remove UE/subscriber context in the case of non-permanent UE, such as in the case of WiFi hotspots as quickly as possible. " Convoluted sentence. "A possible solution is to use a subscriber inactivity timer which, after tracking a pre-defined (currently unspecified) number of minutes, deletes the subscriber context on the First Hop Router." s/which/that (Consider " ... timer that deletes...after a predetermined number of minutes" -7: "The combination of both IPv6 privacy extensions and operator based assignment of a Unique IPv6 Prefix per Host provides each implementing operator a tool to manage and provide subscriber services and hence reduces the experienced privacy within each operator controlled domain." I have trouble following that sentence. Is the point to say that providing tools to manage and provide services reduces privacy in general? As worded, it almost sounds like this is meant as a feature, which I assume is not the case.
Thank you for addressing the SecDir review: https://mailarchive.ietf.org/arch/msg/secdir/wWp_0vlmsz7Ss-nowjhehYImOeg
One nit: Please consider moving Benefits of unique IPv6 prefix over a unique IPv6 address from the service provider include improved subscriber isolation and enhanced subscriber management. to the first paragraph of the Abstract. I’m assuming that this explains the “needs that have arisen” in the first sentence of the Abstract, of course.
Document: draft-ietf-v6ops-unique-ipv6-prefix-per-host-07.txt
I found the discussion of the shared network medium a bit
confusing. As I understand it, the idea is that if we are
on a shared network and we have the same prefix, I might
try to send to you directly. What you want to do is make
that not happen by having each node have a separate prefix.
Correct? If so, perhaps promote this bullet, and also have
it describe the problem and why this provides a solution:
o Two devices (subscriber/hosts), both attached to the same provider
managed shared network should only be able to communicate through
the provider managed First Hop Router
It's a bit unclear to me how much you are saying that
something is current practice versus how much you are
recommending it. For instance, the abstract reads more
like what you would expect for PS.
This document outlines an approach utilising existing IPv6 protocols
to allow hosts to be assigned a unique IPv6 prefix (instead of a
unique IPv6 address from a shared IPv6 prefix). Benefits of unique
IPv6 prefix over a unique IPv6 address from the service provider
include improved subscriber isolation and enhanced subscriber
management.
But then S 4 seems to be documenting:
The IPv6 RA flags used for best common practice in IPv6 SLAAC based
Provider managed shared networks are:
The use of a unique IPv6 prefix per UE adds an additional level of
protection and efficiency as it relates to how IPv6 Neighbor
Discovery and Router Discovery processing. Since the UE has a unique
IPv6 prefix all traffic by default will be directed to the First Hop
provider router. Further, the flag combinations documented above
maximise the IPv6 configurations that are available by hosts
including the use of privacy IPv6 addressing.
It's not quite clear to me why unique prefixs are needed here if
people set L=0. Is it that people ignore L=0?
Finally, I'm a bit confused about how to read this text about the
L=0 bit in cases where I have multiple devices rather than just one
at the customer prem. Say I have a topology with a home router
and devices behind it. I.e.,
Service Provider
|
|
Customer
Router
|
+-----------+-----------+
| | |
Host 1 Host 2 Host 3
I assume what happens here is that the router gets prefix X, assigns
itself XY, and then the Hosts get XA, XB, XC, etc, a la 7278. Is that
right? If so, my question is about packets coming into the Router from
the SP, which have (say) XA. The text about the L-flag suggests that
the router should send them back to the gateway, but that's clearly
not right. What am I missing?
Radius should have an informative reference on first use.
draft-ietf-webpush-encryption
Firstly, thanks to Tim Chown for his helpful OpsDir review ( https://datatracker.ietf.org/doc/review-ietf-webpush-encryption-08-opsdir-lc-chown-2017-08-01/ ) and for your response. I only have nits on this document: 1: I reviewed this and draft-ietf-webpush-vapid together. This document uses title case for "User Agent" (and many other terms), while draft-ietf-webpush-vapid and RFC8030 uses lower-case. Consistency would be nice here. 2: Section 2: "In addition to the reasons described in [I-D.ietf-webpush-protocol], this ensures that the authentication secret is not revealed to unauthorized entities, which can be used to generate push messages that will be accepted by the User Agent." -- this is ambiguous / confusing. It is unclear which which is which. I'd suggest rewording to something like "... to unauthorized entities, which would allow that entities to generate push messages that would be accepted by the User Agent as valid" (or similar) 3: Section 7. Security Considerations "In particular, any HTTP header fields are not protected by the content encoding scheme." -- I think you may mean "In particular, no HTTP header fields are protected ..." (or similar)
Just a few minor and editorial comments: Substantive: - 1: "For efficiency reasons, multiple users of Web Push often share a central agent that aggregates push functionality." Is the "central agent" a push server, application server, or something else? Editorial: -1: "Web Push messages are the payload of an HTTP message " - Plural disagreement. -1.1: Please consider using the boilerplate from RFC 8174. -4, first paragraph: s/ "... some of the length..." / "... sum of the length ..."
This is a fine document. One nit: 4. Restrictions on Use of "aes128gcm" Content Coding An Application Server MUST encrypt a push message with a single record. This allows for a minimal receiver implementation that handles a single record. An application server MUST set the "rs" parameter in the "aes128gcm" content coding header to a size that is greater than the some of the length of the plaintext, the padding s/some/sum ? delimiter (1 octet), any padding, and the authentication tag (16 octets).
Thank you for addressing the SecDir review comments. https://mailarchive.ietf.org/arch/msg/secdir/6wE0iKyBOoUHKsWILu7fdTPHsHw
This is really well written and clear. Thank you for that. I found “for efficiency reasons” in this text For efficiency reasons, multiple users of Web Push often share a central agent that aggregates push functionality. To be so broad that I wasn’t sure what you were telling the reader. Are there any specific efficiencies that you could call out, so that we’d better understand why central agents are used? And if that’s already written down someplace, adding a pointer would be even better. I’m curious about algorithm agility, but I’m not the person to ask that question ...
Moving to No Objection because my DISCUSS is fixed in: https://github.com/webpush-wg/webpush-encryption/commit/645a04b3b86ffe10322134e27a3d3c5eb5a8b06b Note, I think technically only the UA needs to do point verification if the app generates a fresh key as implied by S 2. It would also be nice to have a cite to how to do the point verification. This text can be stolen from TLS 1.3. S 1. This document describes how messages sent using this protocol can be secured against inspection, modification and falsification by a Push Service. "forgery" is more customary than falsification. S 3.3. key_info = "WebPush: info" || 0x00 || ua_public || as_public You should make clear that the string is not null-terminated. Ugh, I know. S 3.4. You should clearly separate which pieces are defined in this document and which are defined in the HTTP encryption document.
That would have been fixed by the RFC editor but anyway s/[I-D.ietf-webpush-protocol]/[RFC8030]/
draft-ietf-slim-multilangcontent
Hi, just some minor comments: Substantive: - 3.1: "This initial message part SHOULD explain briefly to the recipient that the message contains multiple languages and the parts may be rendered sequentially or as attachments. This SHOULD be presented in the same languages that are provided in the subsequent language message parts." It seems likely that this message will be relatively static (perhaps preloaded or configured) for messages sent by any particular MUA. Is it reasonable to expect the MUA (or the person who configures it) to know in advance all languages likely to be used? Is it expected to dynamically select the languages from the ones used by the language specific body parts? -3.3: I'm not sure I understand the first sentence. Why does that ''intent" matter? This section seems to take about a single language-independent part. Could there be multiple language-Independent attachments? -11, first paragraph: It seems like there might be some more subtle abuses than slipping past a spam filter. For example, if a recipient falsely assumes that all the body parts say the same thing, might they be induced into taking some action? (e.g. forwarding offensive material targeted at speakers of a specific language)? Editorial: - Abstract: Please consider mentioning the subtype by name in the abstract. - 1: "The objective of this document is to define..." Did it succeed in its objective? :-) (Consider "This document defines...:) - 3.2: "Each language message part SHOULD have a Subject field in the appropriate language for that language part." Since section 7 restates this SHOULD, and covers the topic in more detail, perhaps section 3.2 should state this descriptively rather than normatively? -7, last paragraph: Should the first "should" be a "SHOULD"?
Comments from Ben and Mirja need to be considered. Also Adam's points about using Language codes instead of Language tags also needs a clarification.
Thanks for your work on this well-written draft!
As I understand it, this is designed so that if you have an MUA which doesn't understand this document you get the preface as the first thing you see. That doesn't seem crazy, but isn't the common case that you have one preferred language that most recipients speak and then some translations. Wouldn't it make sense to at least allow people to have that be what non-updated MUAs display? That seems at least disfavored if not impossible (because I can't tag that one with its actual language). Am I missing something?
I note that this mechanism uses only language tags and implicitly leaves aside any discussion of script or region tags. I'm going to assume this was a intentional decision that was considered by the group with the end result being that there was no perceived need to distinguish between (e.g.) Latin and Jawi scripts for Malay, or (e.g.) Brazilian and Portuguese variations of 'pt'. (If this was not an explicit decision made by the WG, I would ask that it be posed to the WG for an explicit decision -- the current mechanism seems somewhat deficient in this regard from my admittedly brief analysis of the situation.) I'm a little worried that an imprecise reading by implementors of the citation to RFC5646 may lead them to believe that script and region tags may be included in the Content-Language header fields. If the assumptions I discuss above are true, please add text making it clear that script and region tags are forbidden.
Minor comments: - sec 3.2: "If there is a From field present, its value MUST include the same email address as the top-level From header..." What happen if they are no the same? The security considerations section mentions this case but there is no guidance given what to do in this case (which address to display)? - The security considerations section mentions the risk that the content might actually be different in different languages. I think it would be nice to give some recommendation that there SHOULD be a way for the user to see all content fields.
draft-ietf-codec-opus-update
I don't have much to add, other than agreeing with Mirja's (and others') observation that this whole situation is a bit weird, and that we need a better system for things like reference implementations, and bug-fixes to same. Benoit, Richard and Joe's https://datatracker.ietf.org/doc/draft-claise-semver/ is a start, but this document reiterates the need. Also, Spencer's review mean that I now need a new keyboard, mine's full of coffee...
While I support the publication as this seems to be the right thing for me to do in this situation, I find it really weird that we have to publish an RFC to fix bugs in an example implementation in the appendix (that is even encoded). While it is a good thing to have code in an RFC as far as this helps implementation, maybe rfc6716 went to far with putting a whole reference implementation in there. I guess that has also led to a situation where everybody is just using the provided code while efforts to reimplement the spec could have detected these bugs earlier in the process. Maybe it's an item for the IESG to thinking about how to provide a reference implementation with an RFC (that maybe can be updated easier) other than just putting it in the appendix. One more actionable comment: I think the abstract could say more about the updates, especially maybe noticing that this only updates the code in the appendix and not the normative language in the body.
I agree with Mirja, we do need a better way for this type of update.
Thanks for producing this specification. I have some questions, but nothing at Discuss level. I have no idea what an “extreme bitstream” is. Aren’t they all pretty much 0s and 1s? More seriously, it would be nice to know what about the bitstream is extreme. Googling for ‘opus “extreme bitstream”’ turns up one hit for side effects from a drug being tested, so that wasn’t much help. Is there an obvious way that the decoder can know whether audio will be downmixed outside the decoder? Section 10 thinks decoders can know that, apparently. In the security considerations, why is it highly unlikely that the read-only table will be placed next to sensitive data? I’m not balloting Discuss on this because the assertion is nested in a reported vulnerability with no known exploit, but I am curious.
Document: draft-ietf-codec-opus-update-08.txt
These patches are kind of hard to understand and evaluate without
context. For instance, consider the following fragment
/* Padding flag is bit 6 */
if (ch&0x40)
{
- int padding=0;
int p;
do {
if (len<=0)
return OPUS_INVALID_PACKET;
p = *data++;
len--;
- padding += p==255 ? 254: p;
+ len -= p==255 ? 254: p;
} while (p==255);
- len -= padding;
}
Without knowing the type of len, it is not possible to determine
whether this code is correct. For instance, say len is uint32_t,
then the decrement of len may wrap.
In S 5, why did you change one of these memcpys to a memmove,
but not the other.
S 6.
LPC_inverse_pred_gain_QA(), causing a wrap-around. Although the
error is harmless in practice, the C standard considers the behavior
as undefined, so the following patch to line 87 of silk/
LPC_inv_pred_gain.c detects values that do not fit in a 32-bit
integer and considers the corresponding filters unstable:
Claiming that this is harmless in practice seems over-strong, given
that undefined behavior can do anything. Even if it's harmless
in practice today, it might not be in some other future compiler.
S 11.
In addition, any Opus implementation that passes the original test
vectors from RFC 6716 [RFC6716] is still compliant with the Opus
specification. However, newer implementations SHOULD be based on the
new test vectors rather than the old ones.
I'm not sure I understand what compliance means in this case. Are you
saying that *either* behavior is compliant?
Additionally, WRT the discussion on list, I don't think it's useful
to go into a lot of detail about why you don't think this stuff is
exploitable. It takes a huge amount of effort to validate those kinds
of claims (and such claims have been wrong in other code bases in
the past). I would just say what the best known attack is and leave
it at that.
draft-ietf-calext-caldav-attachments
I agree with Mirja's concerns / confusion on the change from PS to Informational. I read the background / shepherds write-up with explains this, but am still not hugely comfortable with the situation -- if it is PS material, and is implemented by a number of folk, PS seems acceptable -- but then again, I fully get the desire to just get it shipped and done. I had thought that I'd made some notes somewhere on an earlier version, but can no longer find them. I'm fairly sure that they were written on a plane heading somewhere, and were only minor nits, so...
IANA Considerations need to mention that this document allows for Content-Disposition header field to be used in HTTP requests. RFC 6266 only defined its use for HTTP responses. Also, the IANA Expert Reviewer has mentioned: I would like section 4.3. MANAGED-ID Property Parameter to clarify the scope of uniqueness of the MANAGED-ID values (e.g., globally unique like UID, unique per iCalendar component? unique per VEVENT?).
Loosely related to Mirja's comment: The abstract mentions why this is informational. That information should be repeated in the Introduction. It would be helpful to see that expanded (in the introduction) to explain what the non-standard bits are, and if there are preferred approaches (whether standards or potential standards.) - 3.12.2: "Access to the managed attachments store in a calendar object resource SHOULD be restricted to only those calendar users who have access to that calendar object either directly, or indirectly (via being an attendee who would receive a scheduling message)." Why not MUST? When might it make sense to allow others to access attachments?
I also agree with Mirja on the document status.
Regarding concerns from others on the topic of document status: even without the ARTART review, I would have DISCUSSed the top-level issues identified by Julian, and in particular the hardcoding of query strings. I would be quite uncomfortable with the precedent of a PS document going out in that form. I'm a little squeamish about having it in an Informational document, but given the apparently pervasive deployment indicated by section 7, I suppose it's better to have it documented than not. Section 3.2 is ambiguous about whether the use of "calendar-managed-attachments-no-recurrance" is in addition to or instead of "calendar-managed-attachments." In this sentence, please replace "the server MUST include" with "the server MUST also include" or "the server MUST instead include", depending on what is intended here. I'd be happy if section 3.12.3 indicated that such redirects are performed with 307 or 308 responses, as other redirect codes change the method from POST to GET. Presumably, when section 7 is removed, section 11.3 is to also be removed? The document should indicate this. Please expand iTIP (iCalendar Transport-independent Interoperability Protocol) on first use.
To be honest I find the solution to publish this as informational a bit strange given it is implemeted and deployed. However, this is really not my expetise.
status-change-rfc3044-rfc3187-orig-urn-regs-to-historic
This ballot position may be interpreted as "This is outside my area of expertise or have no cycles", in that you exercise the ability to move a document forward on the basis of trust towards the other ADs.