Session Description Protocol (SDP) Offer/Answer Procedures for Interactive Connectivity Establishment (ICE)
draft-ietf-mmusic-ice-sip-sdp-39
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2020-06-02
|
39 | (System) | RFC Editor state changed to AUTH48-DONE from AUTH48 |
2020-05-18
|
39 | (System) | RFC Editor state changed to AUTH48 from RFC-EDITOR |
2020-03-16
|
39 | (System) | RFC Editor state changed to RFC-EDITOR from REF |
2019-11-25
|
39 | (System) | RFC Editor state changed to REF from EDIT |
2019-08-30
|
39 | (System) | IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor |
2019-08-29
|
39 | (System) | IANA Action state changed to Waiting on RFC Editor from In Progress |
2019-08-29
|
39 | (System) | IANA Action state changed to In Progress from Waiting on ADs |
2019-08-29
|
39 | (System) | IANA Action state changed to Waiting on ADs from In Progress |
2019-08-29
|
39 | (System) | IANA Action state changed to In Progress from Waiting on Authors |
2019-08-26
|
39 | Gunter Van de Velde | Assignment of request for Last Call review by OPSDIR to Shwetha Bhandari was marked no-response |
2019-08-22
|
39 | Tero Kivinen | Assignment of request for Telechat review by SECDIR to Magnus Nystrom was marked no-response |
2019-08-21
|
39 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2019-08-19
|
39 | Wesley Eddy | Closed request for Last Call review by TSVART with state 'Overtaken by Events' |
2019-08-19
|
39 | Wesley Eddy | Assignment of request for Last Call review by TSVART to Jana Iyengar was withdrawn |
2019-08-16
|
39 | (System) | RFC Editor state changed to EDIT from MISSREF |
2019-08-15
|
39 | (System) | RFC Editor state changed to MISSREF |
2019-08-15
|
39 | (System) | IESG state changed to RFC Ed Queue from Approved-announcement sent |
2019-08-15
|
39 | (System) | Announcement was received by RFC Editor |
2019-08-14
|
39 | (System) | IANA Action state changed to In Progress |
2019-08-14
|
39 | Adam Roach | RFC Editor Note was changed |
2019-08-14
|
39 | Adam Roach | RFC Editor Note was changed |
2019-08-14
|
39 | Cindy Morgan | IESG state changed to Approved-announcement sent from Approved-announcement to be sent |
2019-08-14
|
39 | Cindy Morgan | IESG has approved the document |
2019-08-14
|
39 | Cindy Morgan | Closed "Approve" ballot |
2019-08-14
|
39 | Cindy Morgan | Ballot approval text was generated |
2019-08-14
|
39 | Adam Roach | IESG state changed to Approved-announcement to be sent from IESG Evaluation::AD Followup |
2019-08-14
|
39 | Adam Roach | RFC Editor Note was changed |
2019-08-14
|
39 | Adam Roach | RFC Editor Note for ballot was generated |
2019-08-14
|
39 | Adam Roach | RFC Editor Note for ballot was generated |
2019-08-14
|
39 | Alexey Melnikov | [Ballot comment] As per my response to the mailing list, section 10.2 and 10.3 might benefit from having Contact and Change Controller in the registration … [Ballot comment] As per my response to the mailing list, section 10.2 and 10.3 might benefit from having Contact and Change Controller in the registration template. |
2019-08-14
|
39 | Alexey Melnikov | [Ballot Position Update] Position for Alexey Melnikov has been changed to No Objection from Discuss |
2019-08-13
|
39 | Roman Danyliw | [Ballot comment] Thank you for addressing my Discuss and Comment items. |
2019-08-13
|
39 | Roman Danyliw | [Ballot Position Update] Position for Roman Danyliw has been changed to No Objection from Discuss |
2019-08-13
|
39 | Benjamin Kaduk | [Ballot comment] Thank you for addressing my Discuss (and Comment) points! |
2019-08-13
|
39 | Benjamin Kaduk | [Ballot Position Update] Position for Benjamin Kaduk has been changed to No Objection from Discuss |
2019-08-13
|
39 | Suhas Nandakumar | New version available: draft-ietf-mmusic-ice-sip-sdp-39.txt |
2019-08-13
|
39 | (System) | New version approved |
2019-08-13
|
39 | (System) | Request for posting confirmation emailed to previous authors: Marc Petit-Huguenin , Suhas Nandakumar , Ari Keranen , Christer Holmberg , Roman Shpount |
2019-08-13
|
39 | Suhas Nandakumar | Uploaded new revision |
2019-08-09
|
38 | Benjamin Kaduk | [Ballot discuss] A fairly minor point, but the example in Section 5.6 is not compliant with the ABNF for the ice-options production, which uses SP … [Ballot discuss] A fairly minor point, but the example in Section 5.6 is not compliant with the ABNF for the ice-options production, which uses SP to separate different ice-option-tag values; the example uses a comma. |
2019-08-09
|
38 | Benjamin Kaduk | [Ballot comment] Thank you for addressing most of my comments from the -37! A few still remain, below. Can you remind me why the discussion … [Ballot comment] Thank you for addressing most of my comments from the -37! A few still remain, below. Can you remind me why the discussion of an additional three-second waiting period for SIP with forking was removed from (now-) Section 7? Do we have anywhere a definition of what it means to "indicate ICE support in an SDP offer/answer"? (As distinct from ice2 support.) I remember some discussion about containing a ufrag/password being enough, but that doesn't seem to have ended up in the document. Section 4.2.2 Aren't "rtcp attribute SHOULD be included" and "rtcp attribute MAY be omitted" just duplicating existing normative requirements from previous specifications (which thus would not need new normative language here)? I think we talked about how this is slightly different from some of the previous relevant specifications, so calling out any differences here might be worthwhile. Section 5.1 I appreciate that IP address privacy is mentioned here. (It might be good in the security considerations, too.) Section 9 I think this top-level section would be a great place to reiterate that the SDP and ICE security considerations apply, since we are using both of them in combination. Specifically, the IP Address Privacy concerns are only briefly mentioned elsewhere in the document, and could be worth reiterating. |
2019-08-09
|
38 | Benjamin Kaduk | Ballot comment and discuss text updated for Benjamin Kaduk |
2019-08-09
|
38 | Alexey Melnikov | [Ballot discuss] This is a fine document and I only found a few minor things that should be easy to fix. Thank you for addressing … [Ballot discuss] This is a fine document and I only found a few minor things that should be easy to fix. Thank you for addressing my comments. Unfortunately it doesn't look like my DISCUSS point was addressed yet. Also, your IANA change introduced another issue. 1) In 5.1: The candidate attribute can itself be extended. The grammar allows for new name/value pairs to be added at the end of the attribute. Such extensions MUST be made through IETF Review or IESG Approval [RFC8126] and the assignments MUST contain the specific extension and a reference to the document defining the usage of the extension. This is effectively creating a new registry, but this information is not present in the IANA Considerations section. So you need to do one of the following: a) Remove the last sentence b) Reword it to only talk about IETF stream documents for defining extensions (IESG can't really do what you ask, unless you have an IANA registry established for these.) c) Move this text to the IANA considerations and update it to properly define a new IANA registry. 2) In 10.2: You removed the following text: o Name, Email, and Address of a contact person for the registration o Organization or individuals having the change control I think removing (postal) Address is a good thing. However the rest of this is still needed, as IANA uses this information to decide whether a person/organization is allowed to update an existing registry entry. So please consider adding it back or explain why this information is not needed for a registry where external organizations can add value (without publishing an RFC). |
2019-08-09
|
38 | Alexey Melnikov | Ballot comment and discuss text updated for Alexey Melnikov |
2019-08-09
|
38 | Alissa Cooper | [Ballot comment] Thanks for addressing my DISCUSS. Previous comments are still below. Note that the "Obsoletes" header still appears although I thought Christer said he … [Ballot comment] Thanks for addressing my DISCUSS. Previous comments are still below. Note that the "Obsoletes" header still appears although I thought Christer said he had removed it. ----- Since RFC 5245 is already obsolete, this document cannot obsolete it I don't think. RFC 8445 references this document, so readers of that document will be able to find this one. Section 2: Please use the precise boilerplate from RFC 8174. Section 4.1: It's not clear why IESG Approval is included as one of the registration policies to extend the candidate attribute. Does the WG anticipate cases where IETF Review will not be appropriate? And I agree with Alexey that a registry needs to be defined in the IANA Considerations section. Section 8: Agree with Ben about adding references to ICE and SDP security considerations. Section 9.1.1: s/esg@ietf.org/iesg@ietf.org/ Section 9.2: Further to Alexey's point, the minimal information necessary for the registry to function should be collected and/or published. |
2019-08-09
|
38 | Alissa Cooper | [Ballot Position Update] Position for Alissa Cooper has been changed to Yes from Discuss |
2019-08-08
|
38 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2019-08-08
|
38 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed |
2019-08-08
|
38 | Suhas Nandakumar | New version available: draft-ietf-mmusic-ice-sip-sdp-38.txt |
2019-08-08
|
38 | (System) | New version approved |
2019-08-08
|
38 | (System) | Request for posting confirmation emailed to previous authors: Marc Petit-Huguenin , Suhas Nandakumar , Ari Keranen , Christer Holmberg , Roman Shpount |
2019-08-08
|
38 | Suhas Nandakumar | Uploaded new revision |
2019-08-08
|
37 | Cindy Morgan | IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation |
2019-08-07
|
37 | Barry Leiba | [Ballot Position Update] New position, No Objection, has been recorded for Barry Leiba |
2019-08-06
|
37 | Suresh Krishnan | [Ballot Position Update] New position, No Objection, has been recorded for Suresh Krishnan |
2019-08-06
|
37 | Amanda Baber | IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed |
2019-08-06
|
37 | Warren Kumari | [Ballot comment] I have nothing really to add, other than supporting Roman and Alissa's points. |
2019-08-06
|
37 | Warren Kumari | [Ballot Position Update] New position, No Objection, has been recorded for Warren Kumari |
2019-08-06
|
37 | Alvaro Retana | [Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana |
2019-08-06
|
37 | Alissa Cooper | [Ballot discuss] Apologies for multiple ballot emails, wrapped up a bit too soon the first time. I'm confused about Section 7. The mechanisms in RFC … [Ballot discuss] Apologies for multiple ballot emails, wrapped up a bit too soon the first time. I'm confused about Section 7. The mechanisms in RFC 4091 and RFC 4092 were deprecated in RFC 5245, and this is mentioned in RFC 8445. Why does this specification then need to additionally normatively recommend the use of ICE for dual-stack scenarios? This could be interpreted as saying that ANAT is an alternative option for this use case, but it shouldn't be according to RFC 8445. |
2019-08-06
|
37 | Alissa Cooper | [Ballot Position Update] Position for Alissa Cooper has been changed to Discuss from Yes |
2019-08-06
|
37 | Alissa Cooper | [Ballot comment] Since RFC 5245 is already obsolete, this document cannot obsolete it I don't think. RFC 8445 references this document, so readers of that … [Ballot comment] Since RFC 5245 is already obsolete, this document cannot obsolete it I don't think. RFC 8445 references this document, so readers of that document will be able to find this one. Section 2: Please use the precise boilerplate from RFC 8174. Section 4.1: It's not clear why IESG Approval is included as one of the registration policies to extend the candidate attribute. Does the WG anticipate cases where IETF Review will not be appropriate? And I agree with Alexey that a registry needs to be defined in the IANA Considerations section. Section 8: Agree with Ben about adding references to ICE and SDP security considerations. Section 9.1.1: s/esg@ietf.org/iesg@ietf.org/ Section 9.2: Further to Alexey's point, the minimal information necessary for the registry to function should be collected and/or published. |
2019-08-06
|
37 | Alissa Cooper | [Ballot Position Update] New position, Yes, has been recorded for Alissa Cooper |
2019-08-05
|
37 | Roman Danyliw | [Ballot discuss] (1) Section 8.1. Per “These require techniques for message integrity and encryption for offers and answers, which are satisfied by the TLS mechanism … [Ballot discuss] (1) Section 8.1. Per “These require techniques for message integrity and encryption for offers and answers, which are satisfied by the TLS mechanism [RFC3261] when SIP is used”, the guidance is right (use TLS), but this reference is outdated. Section 26.2.1 of RFC3261 provides rather old guidance on the ciphersuite. Is there a reason why not to use BCP195 for guidance on versions/ciphersuites? (2) Section 8.2.1, The “voice hammer attack” appears to be an artifact of SDP. The text explicitly notes that this attack is not “specific to ICE but that ICE can help provide a remediation” (aside, should “remediation” be “mitigation”). However, the preceding introductory section (8.2) explicitly says “there are several attacks possible with ICE”. These two statements aren’t consistent. (3) Section 8.2.2. This section reads like an operational consideration. The setup scoped in the parent Section 8.2, “there are several attacks possible with ICE when the attacker is an authenticated and valid participant in the ICE exchange”, isn’t discussed here (i.e., how is the presence or absence of an ALG germane to an attacker who is a participant in the ICE exchange) (4) Section 8. Is there a reason why the security considerations from RFC8445 are not noted as also applying (e.g., Section 19.1 - .4. |
2019-08-05
|
37 | Roman Danyliw | [Ballot comment] (5) Section 3.2.6. The example in this section is appreciated. Additional text to explain what this example is showing would be helpful. (6) … [Ballot comment] (5) Section 3.2.6. The example in this section is appreciated. Additional text to explain what this example is showing would be helpful. (6) Section 3.4.1.2.1. Per “the offer MUST include the same set of ICE-related information that the offerer included in the previous offer or answer”, what happens if the ICE information is different? (7) Section 3.4.1.2.2. Per “In addition, if the agent is controlling, it MUST include the ‘a=remote-candidates’ attribute for each data stream whose check list is in the completed state”, what is a ‘check list’ in this context? (8) Section 4.4. Per “If two data streams have identical ice-ufrag's, they MUST have identical ice-pwd's”, what happens if there are not identical? (9) Section 4.4. Per “Its large upper limit allows for increased amounts of randomness to be added over time”, what is the time horizon being mentioned? Is this saying that in the future, longer password and users could be adopted? (10) Section 4.5. Unlike the other sections in 4.*, this one doesn’t have an example. (11) Section 8.2. The title “Insider Attack” seems like a forced fit – perhaps “Malicious Peer” (although Section 19.5 of RFC8445 seems to use that language) (12) Section 8.2.2. Per “Unfortunately, many ALGs are known to work poorly in these corner cases”, it is worth reiterating here what that corner case is – I’m inferring it is what the ALF does when m= or c= has an internal address, right? (13) Appendix A. (Just as Ben pointed out in his DISCUSS for the example in Section 4.6) Shouldn’t the examples in this appendix include a “a=ice-options:ice2” per the guidance in Section 3.2.1.5? |
2019-08-05
|
37 | Roman Danyliw | [Ballot Position Update] New position, Discuss, has been recorded for Roman Danyliw |
2019-08-05
|
37 | Benjamin Kaduk | [Ballot discuss] A fairly minor point, but the example in Section 4.6 is not compliant with the rest of the document. Specifically, any implementation *of … [Ballot discuss] A fairly minor point, but the example in Section 4.6 is not compliant with the rest of the document. Specifically, any implementation *of this document* must include the "ice2" ice-option in addition to any other option being used, per Section 3.2.1.5. |
2019-08-05
|
37 | Benjamin Kaduk | [Ballot comment] Do we have anywhere a definition of what it means to "indicate ICE support in an SDP offer/answer"? (As distinct from ice2 support.) … [Ballot comment] Do we have anywhere a definition of what it means to "indicate ICE support in an SDP offer/answer"? (As distinct from ice2 support.) We refer to the concept in several places but there are many protocol fields that might be interpreted as such; is any one of them sufficient? Section 2 The suggested text in RFC 8174 includes a full BCP 14 citation with both RFCs; please consider using that form. Section 3.2.1.5 An agent compliant to this specification MUST include an SDP ice- options attribute with an "ice2" attribute value [RFC8445]. If an agent receives an SDP offer or answer that does not contain an SDP ice-options attribute with an "ice2" attribute value, the agent can assume that the peer is compliant to [RFC5245]. I think this can only be assumed if there is some other indication of ICE support -- stock SDP O/A does not mandate ICE, IIRC. Section 3.2.2 Aren't "rtcp attribute SHOULD be included" and "rtcp attribute MAY be omitted" just duplicating existing normative requirements from previous specifications (which thus would not need new normative language here)? Section 3.2.5 implementation dependent. Informally, the responding agent MAY consider the mismatched transport address information as a Perhaps the capitalized "MAY" is not needed for an informatl description? 2. The transport address from the peer for the default destination correspond to IPv4/IPv6 address values "0.0.0.0"/"::" and port What does "correspond to" mean here (and later)? Section 3.3.1 If the initial offer SHOULD contain an ice-pacing attribute, why do we not include one in the examples (both in Section 3.2.6 and Appendix A)? Section 3.3.2 (ice-pacing in examples could be good for answers, too) To check my understanding, the requirement for transport protocol match beween m= offer/answer applies just to the *default* destination, i.e., the address from the c= line and the port from the m= line, and thus I can have a=candidate entries for both IPv4 and IPv6 for the same m= section? Or does "In each "m=" line, the answerer MUST use the same transport protocol as was used in the offer "m=" line." also restrict the a=candidate attributes? (As Éric notes, IPv6 examples would go a long way.) Section 3.3.4 If there are one or more check lists with the state set to Failed, the controlling agent MUST generate a subsequent offer in order to remove the associated data streams by setting the port value of the data streams to zero (Section 3.4.1.1.2), even if the peer did indicate support for the 'ice2' ice-option. If needed, such offer can also be used to align the connection address, port and transport protocol, as described above. It feels a little weird to me that we say "can also be used" instead of "is used", since it seems to be a MUST-level requirement for the next offer to normalize the address/port/protocol in the offer with those discovered via ICE. Section 3.4.1.1 The rules governing the ICE restart imply that setting the connection address in the "c=" line to 0.0.0.0 (for IPv4)/ :: (for IPv6) will cause an ICE restart. Consequently, ICE implementations MUST NOT utilize this mechanism for call hold, and instead MUST use "a=inactive" and "a=sendonly" as described in [RFC3264]. Is this really "ICE implementations" or "SDP O/A implementations supporting ICE"? Section 3.4.1.2.2 line associated with that data stream MUST match the data associated with the nominated pair for that data stream. In addition, the offerer only includes SDP candidates representing the local candidates of the nominated candidate pair. The offerer MUST NOT include any other SDP candidate attributes in the subsequent offer. Does this mean that exactly one a=candidate line must appear in the corresponding m= section? Section 3.4.1.3 A lite implementation MUST NOT add additional host candidates in a subsequent offer. If an agent needs to offer additional candidates, it MUST restart ICE. Similarly, the username fragments and passwords MUST remain the same as used previously. If an agent needs to change one of these, it MUST restart ICE for that data stream. nit: This "MUST remain the same" is worded oddly, as the next sentence effectively contradicts it. Section 3.4.3.1 o If ICE state is completed and the SDP answer conforms to Section 3.4.2, the agent MUST remain in the ICE completed state. It's not entirely clear what "conforms to Section 3.4.2" means, given that some situations in Section 3.4.2 effectuate ICE restart. Section 3.4.3.2 there as described in section 12 of [RFC8445]. The state of ICE processing for each data stream MUST change to Running, and the state of ICE processing MUST change to Running Did this sentence get cut off prematurely? Section 4.1 I appreciate that IP address privacy is mentioned here. (It might be good in the security considerations, too.) Section 4.2 I don't really understand why there can be more than one remote-candidate for a given component. Isn't there only going to be one nominated pair, and thus the single remote part of the pair? Section 4.5 If absent in an offer and answer the default value of the attribute is 50 ms, which is the recommended value specified in [RFC8445]. nit: is this "offer and answer" or "offer or answer"? Section 6 Note that ICE is not intended for NAT traversal for SIP, which is assumed to be provided via another mechanism [RFC5626]. This sentence reads a bit oddly when one recalls that the full title of RFC 8445 is "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal". Perhaps the intended sentiment is more that the scheme described in this document for using SDP to provide an ICE usage is not the primary mechanism for NAT traversal for SIP, though if one chooses to use it as such, the procedures in the rest of the section are needed. Section 6.1.1 described in [RFC3262]. Such retransmissions MUST cease on receipt of a STUN Binding request with transport address matching candidate address for one of the data streams signaled in that SDP or on transmission of the answer in a 2xx response. If no Binding request nit: I think "candidate address" needs an article. the session terminated. For the ICE lite peers, the agent MUST cease retransmitting the 18x after sending it four times since there will be no Binding request sent and the number four is arbitrarily chosen to limit the number of 18x retransmits (poor man's version of [RFC3262] basically). (ICE will actually work even if the peer never nit: the tone of the parenthetical is rather distinct from conventional RFC style. Section 6.4 Indeed, an agent SHOULD NOT indicate that QoS preconditions have been met until the checks have completed and selected the candidate pairs to be used for media. Does this include the updated offer/answer exchange having completed? Section 8 I think this top-level section would be a great place to reiterate that the SDP and ICE security considerations apply, since we are using both of them in combination. Specifically, the IP Address Privacy concerns are only briefly mentioned elsewhere in the document, and could be worth reiterating. Section 11.2 draft-ietf-ice-pac has to be normative, since it is an OPTIONAL protocol feature (per https://www6.ietf.org/iesg/statement/normative-informative.html). |
2019-08-05
|
37 | Benjamin Kaduk | [Ballot Position Update] New position, Discuss, has been recorded for Benjamin Kaduk |
2019-08-05
|
37 | Mirja Kühlewind | [Ballot comment] 1) First I have a processing question for the IESG (and maybe the RFC editor) but it might be just me not knowing … [Ballot comment] 1) First I have a processing question for the IESG (and maybe the RFC editor) but it might be just me not knowing this: As I understand it, RFC5245 was spilt up into RFC8445 and this document, however, I find it a bot odd that both documenst obsolete RFC5245. Is that what we usually do? Did we have this case before? Is that the right thing to do? 2) One quick question: Why is a port value of "9" used to signal use of the default destination, instead of e.g. "0"? Is that because port "0" is used to reset the data stream? However, couldn't this combination of address and port "0" not be treated differently? Or is that to avoid any potential false connections? How could that happen? Isn't there a better way to do that? I mainly would like to understand what the reason is and maybe request to also explain this in the document. 3) A minor editorial comment Sec 4: "This specification defines eight new SDP attributes" Given these attributes have already been specified in RFC5245, I wouldn't call them "new". 4) Question on sec 4.1: " : indicates the transport protocol for the candidate. This specification only defines UDP. However, extensibility is provided to allow for future transport protocols to be used with ICE by extending the sub-registry "ICE Transport Protocols" under "Interactive Connectivity Establishment (ICE)" registry." The registry also contain an entry for TCP (see RFC6544). However, I also wonder a bit why a new registry was created initially instead of just using the protocol numbers or keyword in the IANA Protocol Numbers Registry...? 5) A request in section 5.4: "If absent in an offer and answer the default value of the attribute is 50 ms, which is the recommended value specified in [RFC8445]." RFC8445 also specifies a minimum of 5ms (MUST). It would be good to also indicate here that this minimum exists without relying on the user to look up RFC8445. 6) Also further on in section 5.4: "Once both agents have indicated the pacing value they with to use, both agents MUST use the larger of the indicated values." Given this in normatively specified in RFC8445, maybe you should not use normative language in this document but provide in addition again a reference to RFC8445. 7) And similar on the use of MUST in section 5: "The keepalives MUST be sent regardless of whether the data stream is currently inactive, .." This is specified in RFC8445, so maybe consider not using normative language here as well... however, this case is maybe less clear. 8) You probably should explicitly instruct IANA in the IANA consideration section to update the references to this RFC instead of RFC5245 in the respective registry. |
2019-08-05
|
37 | Mirja Kühlewind | [Ballot Position Update] New position, No Objection, has been recorded for Mirja Kühlewind |
2019-08-05
|
37 | Deborah Brungard | [Ballot Position Update] New position, No Objection, has been recorded for Deborah Brungard |
2019-08-05
|
37 | Alexey Melnikov | [Ballot discuss] This is a fine document and I only found a few minor things that should be easy to fix. In 4.1: The … [Ballot discuss] This is a fine document and I only found a few minor things that should be easy to fix. In 4.1: The candidate attribute can itself be extended. The grammar allows for new name/value pairs to be added at the end of the attribute. Such extensions MUST be made through IETF Review or IESG Approval [RFC8126] and the assignments MUST contain the specific extension and a reference to the document defining the usage of the extension. This is effectively creating a new registry, but this information is not present in the IANA Considerations section. |
2019-08-05
|
37 | Alexey Melnikov | [Ballot comment] This is a fine document and I only found nits: 1) A document which is effectively a bis of RFC 5245 should have … [Ballot comment] This is a fine document and I only found nits: 1) A document which is effectively a bis of RFC 5245 should have a section describing changes since the original RFC. Can such section be added? 2) In 4.1: component-id = 1*5DIGIT : is a positive integer between 1 and 256 (inclusive) that identifies the specific component of the data stream for which this is a candidate. Is there any reason why component-id ABNF production allows up to 5 digits, while the description only allows 3? 3) In 9.2: o Name, Email, and Address of a contact person for the registration Considering EU GDPR, I think the WG needs to discuss whether collecting postal address is needed, and if it is, whether IANA has to publish them on the website. |
2019-08-05
|
37 | Alexey Melnikov | [Ballot Position Update] New position, Discuss, has been recorded for Alexey Melnikov |
2019-08-03
|
37 | Éric Vyncke | [Ballot comment] Thank you for the work put into this document; I just have a couple of comments and some nits. All easy to fix. … [Ballot comment] Thank you for the work put into this document; I just have a couple of comments and some nits. All easy to fix. Regards, -éric == COMMENTS == -- Section 3.2.4 -- Please add reference to STUN. -- Section 3.2.6 -- The example would benefit by having an IPv6 candidate. Same applies for section 4.2. -- Section 4.1 -- It is not clear to me whether FQDN are valid: they are accepted by the grammar but they are rejected in the text. == NITS == -- Section 3.4.1.1.1. -- Please use quotes around "0.0.0.0" and "::". -- section 9.1.1 -- Typo in the contact email "esg@ietf.org" -- Appendix A -- IPv6 addresses are usually all lower case :-) |
2019-08-03
|
37 | Éric Vyncke | Ballot comment text updated for Éric Vyncke |
2019-07-30
|
37 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed |
2019-07-30
|
37 | Suhas Nandakumar | New version available: draft-ietf-mmusic-ice-sip-sdp-37.txt |
2019-07-30
|
37 | (System) | New version approved |
2019-07-30
|
37 | (System) | Request for posting confirmation emailed to previous authors: mmusic-chairs@ietf.org, Suhas Nandakumar , Ari Keranen , Marc Petit-Huguenin |
2019-07-30
|
37 | Suhas Nandakumar | Uploaded new revision |
2019-07-17
|
36 | Amanda Baber | IANA Review state changed to IANA OK - Actions Needed from IANA - Not OK |
2019-07-15
|
36 | Tero Kivinen | Request for Telechat review by SECDIR is assigned to Magnus Nystrom |
2019-07-15
|
36 | Tero Kivinen | Request for Telechat review by SECDIR is assigned to Magnus Nystrom |
2019-07-13
|
36 | Éric Vyncke | [Ballot comment] Thank you for the work put into this document; I just have a couple of comments and some nits. All easy to fix. … [Ballot comment] Thank you for the work put into this document; I just have a couple of comments and some nits. All easy to fix. Regards, -éric == COMMENTS == -- Section 3.2.4 -- Please add reference to STUN. -- Section 3.2.6 -- The example would benefit by having an IPv6 candidate. Same applies for section 4.2. -- Section 4.1 -- It is not clear to me whether FQDN are valid: they are accepted by the grammar but they are rejected in the text. == NITS == -- Abstract -- Not sure whether the sentence about obsoleting RFC 5245 has its place in the abstract. -- Section 3.4.1.1.1. -- Please use quotes around "0.0.0.0" and "::". -- section 9.1.1 -- Typo in the contact email "esg@ietf.org" -- Appendix A -- IPv6 addresses are usually all lower case :-) |
2019-07-13
|
36 | Éric Vyncke | [Ballot Position Update] New position, No Objection, has been recorded for Éric Vyncke |
2019-07-12
|
36 | Cindy Morgan | Placed on agenda for telechat - 2019-08-08 |
2019-07-12
|
36 | Adam Roach | IESG state changed to IESG Evaluation from Waiting for Writeup |
2019-07-12
|
36 | Adam Roach | Ballot has been issued |
2019-07-12
|
36 | Adam Roach | [Ballot Position Update] New position, Yes, has been recorded for Adam Roach |
2019-07-12
|
36 | Adam Roach | Created "Approve" ballot |
2019-07-12
|
36 | Adam Roach | Ballot writeup was changed |
2019-06-20
|
36 | (System) | IANA Review state changed to IANA - Not OK from IANA - Review Needed |
2019-06-20
|
36 | Sabrina Tanamal | (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Functions Operator has completed its review of draft-ietf-mmusic-ice-sip-sdp-35. If any part of this review is inaccurate, please let … (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Functions Operator has completed its review of draft-ietf-mmusic-ice-sip-sdp-35. If any part of this review is inaccurate, please let us know. The IANA Functions Operator has a question about one of the actions requested in the IANA Considerations section of this document. The IANA Functions Operator understands that, upon approval of this document, there are five actions which we must complete. First, in the att-field (media level only) registry on the Session Description Protocol (SDP) Parameters registry page located at: https://www.iana.org/assignments/sdp-parameters/ the following existing registrations will have their references changed to [ RFC-to-be ]: Type: att-field (media level only) SDP Name: candidate Mux Category: Transport Reference: [ RFC5245 ][ RFC-to-be ] Section 4 Type: att-field (media level only) SDP Name: remote-candidates Mux Category: Transport Reference: [ RFC5245 ][ RFC-to-be ] Section 4 Type: att-field (media level only) SDP Name: ice-mismatch Mux Category: Normal Reference: [ RFC5245 ][ RFC-to-be ] Section 4 Second, in the att-field (session level only) registry on the Session Description Protocol (SDP) Parameters registry page located at: https://www.iana.org/assignments/sdp-parameters/ the following existing registrations will have their references changed to [ RFC-to-be ]: Type: att-field (session level only) SDP Name: ice-lite Mux Category: Normal Reference: [ RFC5245 ][ RFC-to-be ] Section 4 Type: att-field (session level only) SDP Name: ice-options Mux Category: Normal Reference: [ RFC5245 ][ RFC-to-be ] Section 4 Third, also in the att-field (session level only) registry on the Session Description Protocol (SDP) Parameters registry page located at: https://www.iana.org/assignments/sdp-parameters/ a single, new registration will be added to the registry as follows: Type: att-field (session level only) SDP Name: ice-pacing Mux Category: Normal Reference: [ RFC-to-be ] Section 4 As this document requests registrations in a Specification Required (see RFC 8126) registry, we will initiate the required Expert Review via a separate request. An expert review will need to be completed before your document can be approved for publication as an RFC. Fourth, in the att-field (both session and media level) registry on the Session Description Protocol (SDP) Parameters registry page located at: https://www.iana.org/assignments/sdp-parameters/ the following existing registrations will have their references changed to [ RFC-to-be ]: Type: att-field (both session and media level) SDP Name: ice-pwd Mux Category: Transport Reference: [ RFC5245 ][ RFC-to-be ] Section 4 Type: att-field (both session and media level) SDP Name: ice-ufrag Mux Category: Transport Reference: [ RFC5245 ][ RFC-to-be ] Section 4 Fifth, IANA understands section 9.2 of the current draft to document the existing ICE Options registry at: https://www.iana.org/assignments/ice/ IANA Question --> Should the existing registry add or replace [RFC6336] with [ RFC-to-be ]? IANA understands that there are no other changes to be made to the ICE Options registry. The IANA Functions Operator understands that these are the only actions required to be completed upon approval of this document. Note: The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed. Thank you, Sabrina Tanamal Senior IANA Services Specialist |
2019-06-20
|
36 | (System) | IESG state changed to Waiting for Writeup from In Last Call |
2019-06-17
|
36 | Stewart Bryant | Request for Last Call review by GENART Completed: Ready with Nits. Reviewer: Stewart Bryant. Sent review to list. |
2019-06-13
|
36 | Jean Mahoney | Request for Last Call review by GENART is assigned to Stewart Bryant |
2019-06-13
|
36 | Jean Mahoney | Request for Last Call review by GENART is assigned to Stewart Bryant |
2019-06-07
|
36 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Shwetha Bhandari |
2019-06-07
|
36 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Shwetha Bhandari |
2019-06-06
|
36 | Suhas Nandakumar | New version available: draft-ietf-mmusic-ice-sip-sdp-36.txt |
2019-06-06
|
36 | (System) | New version approved |
2019-06-06
|
36 | (System) | Request for posting confirmation emailed to previous authors: Marc Petit-Huguenin , Suhas Nandakumar , Ari Keranen |
2019-06-06
|
36 | Suhas Nandakumar | Uploaded new revision |
2019-06-06
|
35 | Wesley Eddy | Request for Last Call review by TSVART is assigned to Jana Iyengar |
2019-06-06
|
35 | Wesley Eddy | Request for Last Call review by TSVART is assigned to Jana Iyengar |
2019-06-06
|
35 | Cindy Morgan | IANA Review state changed to IANA - Review Needed |
2019-06-06
|
35 | Cindy Morgan | The following Last Call announcement was sent out (ends 2019-06-20): From: The IESG To: IETF-Announce CC: fandreas@cisco.com, mmusic-chairs@ietf.org, adam@nostrum.com, mmusic@ietf.org, draft-ietf-mmusic-ice-sip-sdp@ietf.org … The following Last Call announcement was sent out (ends 2019-06-20): From: The IESG To: IETF-Announce CC: fandreas@cisco.com, mmusic-chairs@ietf.org, adam@nostrum.com, mmusic@ietf.org, draft-ietf-mmusic-ice-sip-sdp@ietf.org Reply-To: ietf@ietf.org Sender: Subject: Last Call: (Session Description Protocol (SDP) Offer/Answer procedures for Interactive Connectivity Establishment (ICE)) to Proposed Standard The IESG has received a request from the Multiparty Multimedia Session Control WG (mmusic) to consider the following document: - 'Session Description Protocol (SDP) Offer/Answer procedures for Interactive Connectivity Establishment (ICE)' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2019-06-20. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document describes Session Description Protocol (SDP) Offer/ Answer procedures for carrying out Interactive Connectivity Establishment (ICE) between the agents. This document obsoletes RFC 5245. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-mmusic-ice-sip-sdp/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-mmusic-ice-sip-sdp/ballot/ No IPR declarations have been submitted directly on this I-D. |
2019-06-06
|
35 | Cindy Morgan | IESG state changed to In Last Call from Last Call Requested |
2019-06-06
|
35 | Adam Roach | Changed consensus to Yes from Unknown |
2019-06-06
|
35 | Adam Roach | AD Review is at https://mailarchive.ietf.org/arch/msg/mmusic/XPmziO5SUo-VGN6nI_hj5txbxmw |
2019-06-06
|
35 | Adam Roach | Last call was requested |
2019-06-06
|
35 | Adam Roach | Ballot approval text was generated |
2019-06-06
|
35 | Adam Roach | Ballot writeup was generated |
2019-06-06
|
35 | Adam Roach | IESG state changed to Last Call Requested from AD Evaluation |
2019-06-06
|
35 | Adam Roach | Last call announcement was generated |
2019-06-06
|
35 | Adam Roach | IESG state changed to AD Evaluation from Publication Requested |
2019-06-06
|
35 | Flemming Andreasen | As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. Changes are expected over time. This version is dated … As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. Changes are expected over time. This version is dated 24 February 2012. (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header? Proposed Standard. The document obsoletes RFC 5245, which itself is a Proposed Standard. (2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary This document describes Session Description Protocol (SDP) Offer/Answer procedures for carrying out Interactive Connectivity Establishment (ICE) between the agents. This document obsoletes RFC 5245. Working Group Summary Was there anything in WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough? The document has been in progress since 2013 (as a companion document to the now published RFC 8445). The document has generally been non-controversial, however more recently (starting in July 2018 at IETF 102), the lack of DNS and mDNS support was raised as a concern by a few people. A consensus call to leave it out was made at IETF 102. Recent MMUSIC mailing list discussions raised the issue again, however in the interest of moving the document forward, the previous consensus was reconfirmed, with provisions in this document to enable DNS procedures to be added as an extension later on. Document Quality Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted? The document obseletes RFC 5245, which has a number of existing implementations. The document is one of the deliverables needed by RTCWeb, and as such is expected to see significant implementation. Roman Shpount in particular has been instrumental in moving this document forward by resolving a variety of issues and contributing specific text proposals. Christer Holmberg and Adam Roach have been very helpful as well. Personnel Who is the Document Shepherd? Who is the Responsible Area Director? Flemming Andreasen is the Document Shepherd Adam Roach is the Responsible Area Director (3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG. I have reviewed -16, -18 and -30 in detail as well as subsequent changes in the current version (-35). The document is ready for publication at this point. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? No concerns. The document itself has received several reviews, incl. by a couple of people that are familiar with both this document and the updated ICE specification (RFC8445). (5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place. N/A (6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. N/A (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why. Confirmed. It should be noted however, that while no IPR disclosures have been filed on this document, IPR disclosures were filed on the original RFC 5245 and the updated ICE companion document (RFC 8245). See https://datatracker.ietf.org/ipr/search/?rfc=8445&submit=rfc (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. N/A (but see above) (9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? The WG consensus is solid. (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) N/A (11) Identify any ID nits the Document Shepherd has found in this document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. The Shepherd review has not revealed any real issues, however the I-D nits tool provides a few warnings: - All reference warnings are false positives. - The pre-RFC5378 disclaimer is currently needed – the original author of RFC 5245 was recently contacted to see if we can obtain the BCP78 rights to the IETF trust (TBD) (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. N/A. The document only defines/updates SDP attributes and the ice-options registry. (13) Have all references within this document been identified as either normative or informative? Yes (14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion? N/A (15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure. N/A (16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary. Yes. The document obsoletes RFC 5245, as indicated on the Title page, Abstract and Introduction of the document. (17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 5226). Confirmed. The Shepherd has reviewed the IANA Considerations section for consistency with the body of the document and the above requirements. (18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries. N/A (the ice-options registry exists already) (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc. I have performed a detailed review of -30 and subsequent changes in -35 (current version). ABNF has been checked (successfully) with Bill Fenner’s ABNF parser. |
2019-06-06
|
35 | Flemming Andreasen | Responsible AD changed to Adam Roach |
2019-06-06
|
35 | Flemming Andreasen | IETF WG state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up |
2019-06-06
|
35 | Flemming Andreasen | IESG state changed to Publication Requested from I-D Exists |
2019-06-06
|
35 | Flemming Andreasen | IESG process started in state Publication Requested |
2019-06-06
|
35 | Flemming Andreasen | Tags Revised I-D Needed - Issue raised by WG, Doc Shepherd Follow-up Underway cleared. |
2019-06-06
|
35 | Flemming Andreasen | As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. Changes are expected over time. This version is dated … As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. Changes are expected over time. This version is dated 24 February 2012. (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header? Proposed Standard. The document obsoletes RFC 5245, which itself is a Proposed Standard. (2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary This document describes Session Description Protocol (SDP) Offer/Answer procedures for carrying out Interactive Connectivity Establishment (ICE) between the agents. This document obsoletes RFC 5245. Working Group Summary Was there anything in WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough? The document has been in progress since 2013 (as a companion document to the now published RFC 8445). The document has generally been non-controversial, however more recently (starting in July 2018 at IETF 102), the lack of DNS and mDNS support was raised as a concern by a few people. A consensus call to leave it out was made at IETF 102. Recent MMUSIC mailing list discussions raised the issue again, however in the interest of moving the document forward, the previous consensus was reconfirmed, with provisions in this document to enable DNS procedures to be added as an extension later on. Document Quality Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted? The document obseletes RFC 5245, which has a number of existing implementations. The document is one of the deliverables needed by RTCWeb, and as such is expected to see significant implementation. Roman Shpount in particular has been instrumental in moving this document forward by resolving a variety of issues and contributing specific text proposals. Christer Holmberg and Adam Roach have been very helpful as well. Personnel Who is the Document Shepherd? Who is the Responsible Area Director? Flemming Andreasen is the Document Shepherd Adam Roach is the Responsible Area Director (3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG. I have reviewed -16, -18 and -30 in detail as well as subsequent changes in the current version (-35). The document is ready for publication at this point. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? No concerns. The document itself has received several reviews, incl. by a couple of people that are familiar with both this document and the updated ICE specification (RFC8445). (5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place. N/A (6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. N/A (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why. Confirmed. It should be noted however, that while no IPR disclosures have been filed on this document, IPR disclosures were filed on the original RFC 5245 and the updated ICE companion document (RFC 8245). See https://datatracker.ietf.org/ipr/search/?rfc=8445&submit=rfc (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. N/A (but see above) (9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? The WG consensus is solid. (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) N/A (11) Identify any ID nits the Document Shepherd has found in this document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. The Shepherd review has not revealed any real issues, however the I-D nits tool provides a few warnings: - All reference warnings are false positives. - The pre-RFC5378 disclaimer is currently needed – the original author of RFC 5245 was recently contacted to see if we can obtain the BCP78 rights to the IETF trust (TBD) (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. N/A. The document only defines/updates SDP attributes and the ice-options registry. (13) Have all references within this document been identified as either normative or informative? Yes (14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion? N/A (15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure. N/A (16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary. Yes. The document obsoletes RFC 5245, as indicated on the Title page, Abstract and Introduction of the document. (17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 5226). Confirmed. The Shepherd has reviewed the IANA Considerations section for consistency with the body of the document and the above requirements. (18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries. N/A (the ice-options registry exists already) (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc. I have performed a detailed review of -30 and subsequent changes in -35 (current version). ABNF has been checked (successfully) with Bill Fenner’s ABNF parser. |
2019-06-06
|
35 | Suhas Nandakumar | New version available: draft-ietf-mmusic-ice-sip-sdp-35.txt |
2019-06-06
|
35 | (System) | New version approved |
2019-06-06
|
35 | (System) | Request for posting confirmation emailed to previous authors: Marc Petit-Huguenin , Suhas Nandakumar , Ari Keranen |
2019-06-06
|
35 | Suhas Nandakumar | Uploaded new revision |
2019-06-06
|
34 | Suhas Nandakumar | New version available: draft-ietf-mmusic-ice-sip-sdp-34.txt |
2019-06-06
|
34 | (System) | New version approved |
2019-06-06
|
34 | (System) | Request for posting confirmation emailed to previous authors: Marc Petit-Huguenin , Suhas Nandakumar , Ari Keranen |
2019-06-06
|
34 | Suhas Nandakumar | Uploaded new revision |
2019-06-04
|
33 | Suhas Nandakumar | New version available: draft-ietf-mmusic-ice-sip-sdp-33.txt |
2019-06-04
|
33 | (System) | New version approved |
2019-06-04
|
33 | (System) | Request for posting confirmation emailed to previous authors: Marc Petit-Huguenin , Suhas Nandakumar , Ari Keranen |
2019-06-04
|
33 | Suhas Nandakumar | Uploaded new revision |
2019-06-03
|
32 | Suhas Nandakumar | New version available: draft-ietf-mmusic-ice-sip-sdp-32.txt |
2019-06-03
|
32 | (System) | New version approved |
2019-06-03
|
32 | (System) | Request for posting confirmation emailed to previous authors: Marc Petit-Huguenin , Suhas Nandakumar , Ari Keranen |
2019-06-03
|
32 | Suhas Nandakumar | Uploaded new revision |
2019-06-02
|
31 | Suhas Nandakumar | New version available: draft-ietf-mmusic-ice-sip-sdp-31.txt |
2019-06-02
|
31 | (System) | New version approved |
2019-06-02
|
31 | (System) | Request for posting confirmation emailed to previous authors: Marc Petit-Huguenin , Suhas Nandakumar , Ari Keranen |
2019-06-02
|
31 | Suhas Nandakumar | Uploaded new revision |
2019-06-01
|
30 | Suhas Nandakumar | New version available: draft-ietf-mmusic-ice-sip-sdp-30.txt |
2019-06-01
|
30 | (System) | New version approved |
2019-06-01
|
30 | (System) | Request for posting confirmation emailed to previous authors: Marc Petit-Huguenin , Suhas Nandakumar , Ari Keranen |
2019-06-01
|
30 | Suhas Nandakumar | Uploaded new revision |
2019-05-29
|
29 | Suhas Nandakumar | New version available: draft-ietf-mmusic-ice-sip-sdp-29.txt |
2019-05-29
|
29 | (System) | New version approved |
2019-05-29
|
29 | (System) | Request for posting confirmation emailed to previous authors: Marc Petit-Huguenin , Suhas Nandakumar , Ari Keranen |
2019-05-29
|
29 | Suhas Nandakumar | Uploaded new revision |
2019-05-27
|
28 | Suhas Nandakumar | New version available: draft-ietf-mmusic-ice-sip-sdp-28.txt |
2019-05-27
|
28 | (System) | New version approved |
2019-05-27
|
28 | (System) | Request for posting confirmation emailed to previous authors: Marc Petit-Huguenin , Suhas Nandakumar , Ari Keranen |
2019-05-27
|
28 | Suhas Nandakumar | Uploaded new revision |
2019-05-27
|
28 | (System) | Request for posting confirmation emailed to previous authors: Marc Petit-Huguenin , Suhas Nandakumar , Ari Keranen |
2019-05-27
|
28 | Suhas Nandakumar | Uploaded new revision |
2019-05-18
|
27 | Suhas Nandakumar | New version available: draft-ietf-mmusic-ice-sip-sdp-27.txt |
2019-05-18
|
27 | (System) | New version approved |
2019-05-18
|
27 | (System) | Request for posting confirmation emailed to previous authors: Marc Petit-Huguenin , Suhas Nandakumar , Ari Keranen |
2019-05-18
|
27 | Suhas Nandakumar | Uploaded new revision |
2019-05-17
|
26 | Suhas Nandakumar | New version available: draft-ietf-mmusic-ice-sip-sdp-26.txt |
2019-05-17
|
26 | (System) | New version approved |
2019-05-17
|
26 | (System) | Request for posting confirmation emailed to previous authors: Marc Petit-Huguenin , Suhas Nandakumar , Ari Keranen |
2019-05-17
|
26 | Suhas Nandakumar | Uploaded new revision |
2019-05-12
|
25 | Suhas Nandakumar | New version available: draft-ietf-mmusic-ice-sip-sdp-25.txt |
2019-05-12
|
25 | (System) | New version approved |
2019-05-12
|
25 | (System) | Request for posting confirmation emailed to previous authors: Marc Petit-Huguenin , Suhas Nandakumar , Ari Keranen |
2019-05-12
|
25 | Suhas Nandakumar | Uploaded new revision |
2018-11-09
|
24 | Suhas Nandakumar | New version available: draft-ietf-mmusic-ice-sip-sdp-24.txt |
2018-11-09
|
24 | (System) | New version approved |
2018-11-09
|
24 | (System) | Request for posting confirmation emailed to previous authors: Marc Petit-Huguenin , Suhas Nandakumar , Ari Keranen |
2018-11-09
|
24 | Suhas Nandakumar | Uploaded new revision |
2018-10-10
|
23 | Suhas Nandakumar | New version available: draft-ietf-mmusic-ice-sip-sdp-23.txt |
2018-10-10
|
23 | (System) | New version approved |
2018-10-10
|
23 | (System) | Request for posting confirmation emailed to previous authors: Marc Petit-Huguenin , Suhas Nandakumar , Ari Keranen |
2018-10-10
|
23 | Suhas Nandakumar | Uploaded new revision |
2018-10-09
|
22 | Suhas Nandakumar | New version available: draft-ietf-mmusic-ice-sip-sdp-22.txt |
2018-10-09
|
22 | (System) | New version approved |
2018-10-09
|
22 | (System) | Request for posting confirmation emailed to previous authors: Marc Petit-Huguenin , Suhas Nandakumar , Ari Keranen |
2018-10-09
|
22 | Suhas Nandakumar | Uploaded new revision |
2018-07-02
|
21 | Bo Burman | Added to session: IETF-102: mmusic Thu-1330 |
2018-06-30
|
21 | Suhas Nandakumar | New version available: draft-ietf-mmusic-ice-sip-sdp-21.txt |
2018-06-30
|
21 | (System) | New version approved |
2018-06-30
|
21 | (System) | Request for posting confirmation emailed to previous authors: Marc Petit-Huguenin , Suhas Nandakumar , Ari Keranen |
2018-06-30
|
21 | Suhas Nandakumar | Uploaded new revision |
2018-04-02
|
20 | Suhas Nandakumar | New version available: draft-ietf-mmusic-ice-sip-sdp-20.txt |
2018-04-02
|
20 | (System) | New version approved |
2018-04-02
|
20 | (System) | Request for posting confirmation emailed to previous authors: Marc Petit-Huguenin , Suhas Nandakumar , Ari Keranen |
2018-04-02
|
20 | Suhas Nandakumar | Uploaded new revision |
2018-04-01
|
19 | Suhas Nandakumar | New version available: draft-ietf-mmusic-ice-sip-sdp-19.txt |
2018-04-01
|
19 | (System) | New version approved |
2018-04-01
|
19 | (System) | Request for posting confirmation emailed to previous authors: Marc Petit-Huguenin , Suhas Nandakumar , Ari Keranen |
2018-04-01
|
19 | Suhas Nandakumar | Uploaded new revision |
2018-03-30
|
18 | Suhas Nandakumar | New version available: draft-ietf-mmusic-ice-sip-sdp-18.txt |
2018-03-30
|
18 | (System) | New version approved |
2018-03-30
|
18 | (System) | Request for posting confirmation emailed to previous authors: Marc Petit-Huguenin , Suhas Nandakumar , Ari Keranen |
2018-03-30
|
18 | Suhas Nandakumar | Uploaded new revision |
2018-03-27
|
17 | Suhas Nandakumar | New version available: draft-ietf-mmusic-ice-sip-sdp-17.txt |
2018-03-27
|
17 | (System) | New version approved |
2018-03-27
|
17 | (System) | Request for posting confirmation emailed to previous authors: Marc Petit-Huguenin , Suhas Nandakumar , Ari Keranen |
2018-03-27
|
17 | Suhas Nandakumar | Uploaded new revision |
2018-03-22
|
16 | Bo Burman | Added to session: IETF-101: mmusic Fri-0930 |
2018-03-06
|
16 | Flemming Andreasen | Tag Revised I-D Needed - Issue raised by WG set. |
2017-12-13
|
16 | Flemming Andreasen | Tag Doc Shepherd Follow-up Underway set. Tag Revised I-D Needed - Issue raised by WGLC cleared. |
2017-12-13
|
16 | Flemming Andreasen | IETF WG state changed to WG Consensus: Waiting for Write-Up from WG Document |
2017-11-24
|
16 | Suhas Nandakumar | New version available: draft-ietf-mmusic-ice-sip-sdp-16.txt |
2017-11-24
|
16 | (System) | New version approved |
2017-11-24
|
16 | (System) | Request for posting confirmation emailed to previous authors: Marc Petit-Huguenin , Suhas Nandakumar , Ari Keranen |
2017-11-24
|
16 | Suhas Nandakumar | Uploaded new revision |
2017-11-23
|
15 | Suhas Nandakumar | New version available: draft-ietf-mmusic-ice-sip-sdp-15.txt |
2017-11-23
|
15 | (System) | New version approved |
2017-11-23
|
15 | (System) | Request for posting confirmation emailed to previous authors: Marc Petit-Huguenin , Suhas Nandakumar , Ari Keranen |
2017-11-23
|
15 | Suhas Nandakumar | Uploaded new revision |
2017-11-14
|
14 | Flemming Andreasen | Tag Revised I-D Needed - Issue raised by WGLC set. |
2017-10-02
|
14 | Suhas Nandakumar | New version available: draft-ietf-mmusic-ice-sip-sdp-14.txt |
2017-10-02
|
14 | (System) | New version approved |
2017-10-02
|
14 | (System) | Request for posting confirmation emailed to previous authors: Marc Petit-Huguenin , Suhas Nandakumar , Ari Keranen |
2017-10-02
|
14 | Suhas Nandakumar | Uploaded new revision |
2017-06-27
|
13 | Suhas Nandakumar | New version available: draft-ietf-mmusic-ice-sip-sdp-13.txt |
2017-06-27
|
13 | (System) | New version approved |
2017-06-27
|
13 | (System) | Request for posting confirmation emailed to previous authors: Marc Petit-Huguenin , Suhas Nandakumar , Ari Keranen |
2017-06-27
|
13 | Suhas Nandakumar | Uploaded new revision |
2017-03-24
|
12 | Bo Burman | Added to session: IETF-98: mmusic Thu-1300 |
2017-03-13
|
12 | Suhas Nandakumar | New version available: draft-ietf-mmusic-ice-sip-sdp-12.txt |
2017-03-13
|
12 | (System) | New version approved |
2017-03-13
|
12 | (System) | Request for posting confirmation emailed to previous authors: Marc Petit-Huguenin , Suhas Nandakumar , =?utf-8?q?Ari_Ker=C3=A4nen?= , mmusic-chairs@ietf.org |
2017-03-13
|
12 | Suhas Nandakumar | Uploaded new revision |
2017-01-20
|
11 | Suhas Nandakumar | New version available: draft-ietf-mmusic-ice-sip-sdp-11.txt |
2017-01-20
|
11 | (System) | New version approved |
2017-01-20
|
11 | (System) | Request for posting confirmation emailed to previous authors: "Marc Petit-Huguenin" , "Suhas Nandakumar" , "Ari Keranen" |
2017-01-20
|
11 | Suhas Nandakumar | Uploaded new revision |
2016-11-07
|
10 | Bo Burman | Added to session: IETF-97: mmusic Wed-1110 |
2016-07-22
|
10 | Suhas Nandakumar | New version available: draft-ietf-mmusic-ice-sip-sdp-10.txt |
2016-07-08
|
09 | Suhas Nandakumar | New version available: draft-ietf-mmusic-ice-sip-sdp-09.txt |
2016-03-18
|
08 | Suhas Nandakumar | New version available: draft-ietf-mmusic-ice-sip-sdp-08.txt |
2015-10-19
|
07 | Suhas Nandakumar | New version available: draft-ietf-mmusic-ice-sip-sdp-07.txt |
2015-10-16
|
06 | Flemming Andreasen | Intended Status changed to Proposed Standard from None |
2015-09-10
|
06 | Suhas Nandakumar | New version available: draft-ietf-mmusic-ice-sip-sdp-06.txt |
2015-03-09
|
05 | Ari Keränen | New version available: draft-ietf-mmusic-ice-sip-sdp-05.txt |
2014-10-27
|
04 | Marc Petit-Huguenin | New version available: draft-ietf-mmusic-ice-sip-sdp-04.txt |
2014-07-04
|
03 | Ari Keränen | New version available: draft-ietf-mmusic-ice-sip-sdp-03.txt |
2014-01-10
|
02 | Marc Petit-Huguenin | New version available: draft-ietf-mmusic-ice-sip-sdp-02.txt |
2014-01-10
|
01 | Marc Petit-Huguenin | New version available: draft-ietf-mmusic-ice-sip-sdp-01.txt |
2013-11-07
|
00 | Ari Keränen | Set of documents this document replaces changed to draft-petithuguenin-mmusic-ice-sip-sdp from None |
2013-10-06
|
00 | Flemming Andreasen | Document shepherd changed to Flemming Andreasen |
2013-07-15
|
00 | Marc Petit-Huguenin | New version available: draft-ietf-mmusic-ice-sip-sdp-00.txt |