Diameter Credit-Control Application
draft-ietf-dime-rfc4006bis-12
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2019-02-25
|
12 | (System) | RFC Editor state changed to AUTH48-DONE from AUTH48 |
2019-01-07
|
12 | (System) | RFC Editor state changed to AUTH48 from RFC-EDITOR |
2018-12-13
|
12 | (System) | RFC Editor state changed to RFC-EDITOR from AUTH |
2018-11-12
|
12 | (System) | RFC Editor state changed to AUTH from EDIT |
2018-09-13
|
12 | Yuval Lifshitz | New version available: draft-ietf-dime-rfc4006bis-12.txt |
2018-09-13
|
12 | (System) | New version approved |
2018-09-13
|
12 | (System) | Request for posting confirmation emailed to previous authors: David Dolson , Lyle Bertz , Yuval Lifshitz |
2018-09-13
|
12 | Yuval Lifshitz | Uploaded new revision |
2018-09-12
|
11 | (System) | IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor |
2018-09-12
|
11 | (System) | IANA Action state changed to Waiting on RFC Editor from In Progress |
2018-09-12
|
11 | (System) | IANA Action state changed to In Progress from Waiting on Authors |
2018-08-29
|
11 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2018-08-29
|
11 | (System) | IANA Action state changed to In Progress from Waiting on WGC |
2018-08-29
|
11 | (System) | IANA Action state changed to Waiting on WGC from In Progress |
2018-08-27
|
11 | (System) | RFC Editor state changed to EDIT |
2018-08-27
|
11 | (System) | IESG state changed to RFC Ed Queue from Approved-announcement sent |
2018-08-27
|
11 | (System) | Announcement was received by RFC Editor |
2018-08-27
|
11 | (System) | IANA Action state changed to In Progress |
2018-08-27
|
11 | Cindy Morgan | IESG state changed to Approved-announcement sent from Approved-announcement to be sent |
2018-08-27
|
11 | Cindy Morgan | IESG has approved the document |
2018-08-27
|
11 | Cindy Morgan | Closed "Approve" ballot |
2018-08-27
|
11 | Cindy Morgan | Ballot approval text was generated |
2018-08-27
|
11 | Ben Campbell | IESG state changed to Approved-announcement to be sent from IESG Evaluation::AD Followup |
2018-08-27
|
11 | Suresh Krishnan | [Ballot comment] Thanks for addressing my DISCUSS point. Section 8.65 Any reason you are allowing encoding an IPv4 address as a IPv4-Mapped IPv6 Address while … [Ballot comment] Thanks for addressing my DISCUSS point. Section 8.65 Any reason you are allowing encoding an IPv4 address as a IPv4-Mapped IPv6 Address while you can directly use address family 1 to encode it directly as an IPv4 address? This allows for two different encodings for the same address. |
2018-08-27
|
11 | Suresh Krishnan | [Ballot Position Update] Position for Suresh Krishnan has been changed to No Objection from Discuss |
2018-08-26
|
11 | Benjamin Kaduk | [Ballot comment] Thank you for addressing my DISCUSS points. Original ballot comments preserved below: Some additional significant but not necessarily DISCUSS-worthy comments, followed by more … [Ballot comment] Thank you for addressing my DISCUSS points. Original ballot comments preserved below: Some additional significant but not necessarily DISCUSS-worthy comments, followed by more editorial- and nit-level things. In Section 1.3, "Advertising Application Support" uses the same Auth-Application-ID value as for RFC 4006; what are the interop consequences of this? Alissa already noted that the text about how to split (sub-)AVPs between the foo and foo-Extension AVPs is inconsistent among them -- e.g., Redirect-Server-Extension and User-Equipment-Info say "SHOULD send [in the old one]", but Subscription-Id-Extension has separate text about "[i]f full backward compatibility with [RFC4006] is required" and slightly different behavior described. We should try to catch all instances of this sort of backwards compatibility and make them consistent. The use of UTF8String for URLs and URIs (e.g., Redirect-Address-URL) might benefit from additional text about the expected contents. A lot of the time when we use a UTF8 container for names (whether domain names or other kinds), we specify what normalization form and canonicalization are performed, whether domain names are A-labels or U-labels, etc., as there's a lot of potential flexibility not all of which is good. In this case, since the communication is only between trusted actors, perhaps the additional restrictions are not needed, but I am curious if the topic was raised in the WG. Thank you for adding the Privacy Considerations and list of Privacy-Sensitive AVPs! Section 14 [...] The Diameter credit- control application is often used within one domain, and there may be a single hop between the peers. In these environments, the use of TLS/TCP, DTLS/SCTP or IPsec is sufficient. I did not see any concrete guidance on what would suffice in other environments (with multiple hops between peers). Is this the realm of the mythical "end-to-end security mechanism" for Diameter that is much-desired? (The last paragraph does have guidance on what might *not* suffice, which is not exactly the same thing.) Even without any modification to the messages, an adversary can eavesdrop on transactions that contain privacy-sensitive information about the user. This ("an adversary can") makes it sounds as if there is no confidentiality protection anywhere in the system, but that's what TLS/DTLS/IPSec are supposed to provide. So maybe "an adversary that can eavesdrop on transactions can obtain privacy-sensitive information [...]" is better. (Editorial- and nit-level stuff follows.) Section 4 A flexible credit-control application specific failure handling is defined in which the home service provider can model the credit- control client behavior according to its own credit risk management policy. This sentence is hard to parse -- in "credit-control application specific" what does "specific" bind to? What is being modelled? Is anything being controlled (as opposed to modelled)? Section 4.1.1 2. The Service-Parameter-Info AVP MAY be used as a container to pass legacy rating information in its original encoded form (e.g., ASN.1 BER). [...] Why BER and not DER? The unnecessary flexibility in BER vs. DER has been known to tickle parser bugs and create security vulnerabilities. Section 4.1.2 [...] To facilitate interoperability, it is RECOMMENDED that the rating input and the values of the Service-Context-Id be coordinated via an informational RFC or other permanent and readily available reference. The specification of another cooperative standardization body (e.g., 3GPP, OMA, or 3GPP2) SHOULD be used. The RECOMMENDED and SHOULD seem slightly in conflict. Section 5.1.1 As noted elsewhere, 60 seconds per minute does not always hold; it seems that this text could be reworded to just talk about a "constant rate" or "constant level per fixed time period" or similar. Section 5.1.2 [...] timer (Section 13) every time a CCR message with the value UPDATE_REQUEST is sent while they are in PendingU state. When answers to all pending messages are received, the state machine moves to OPEN state, and Tx is stopped. Transmission, or the Tx timer (is stopped)? Using a different title for Section 5.2.2 might make the parallel between it and Section 5.2.1 more clear. That is, perhaps something like "First Interrogation Included with Authorization Messages". Section 5.7 [...] It is RECOMMENDED that the client complement the credit- control failure procedures with backup accounting flow toward an accounting server. [...] Nit: it looks like there's a missing article here, maybe "a backup accounting flow" is better. The AAA transport profile [RFC3539] defines the application layer watchdog algorithm that enables failover from a peer that has failed and is controlled by a watchdog timer (Tw) defined in [RFC3539]. Nit: Is it "the" watchdog algorithm or "an" watchdog algorithm? Section 6.2 Should there be text indicating how the client indicates what service the balance check is being requested for? Section 8.54 Maybe give a section reference in RFC 3580 for how the formatting is done? Section 12 [...] Initially, such Expert discussions take place on the AAA WG mailing list. That list appears to be dead, suggesting that this text should be updated. (I also agree with Adam's comments about updating the IANA Considerations.) Why is the disclaimer in Section B.4 (and other examples) not needed in Section B.3? |
2018-08-26
|
11 | Benjamin Kaduk | Ballot comment text updated for Benjamin Kaduk |
2018-08-26
|
11 | Benjamin Kaduk | [Ballot Position Update] Position for Benjamin Kaduk has been changed to No Objection from Discuss |
2018-08-26
|
11 | Yuval Lifshitz | New version available: draft-ietf-dime-rfc4006bis-11.txt |
2018-08-26
|
11 | (System) | New version approved |
2018-08-26
|
11 | (System) | Request for posting confirmation emailed to previous authors: David Dolson , Lyle Bertz , Yuval Lifshitz |
2018-08-26
|
11 | Yuval Lifshitz | Uploaded new revision |
2018-08-20
|
10 | Alissa Cooper | [Ballot comment] Thanks for addressing my DISCUSS. Original COMMENT: = Section 1 = (1) I know it's a term of art, but the term "next … [Ballot comment] Thanks for addressing my DISCUSS. Original COMMENT: = Section 1 = (1) I know it's a term of art, but the term "next generation wireless networks" seems a bit out of place in two ways: (1) "wireless" seems more generic than what is implied (i.e., "cellular," I assume), and (2) is Rel-13 considered "next generation" still? (2) "Diameter base protocol" should cite RFC 6733. = Section 5.1 = Assuming G-S-U stands for granted service unit, the acronym should be given upon first use here. = Section 8.52 = (1) Why do you need to specify the ability to send either the IMEISV or the IMEI? (2) "If the type of the equipment is one of the enumerated types of User-Equipment-Info-Type AVP, then the credit- control client SHOULD send the information in the User-Equipment-Info AVP, in addition to or instead of the User-Equipment-Info-Extension AVP." Why is this normative recommendation in support of backwards compatibility different from the one given for the Subscription-Id-Extension AVP in Sec. 8.58? = Section 15.1 = "Redirect-Server-Address AVP: the service-provider may embed personal information on the subscriber in the URL/I (e.g. to create a personalized message)." This seems like a bad idea that, if it's going to be mentioned, should be recommended against. |
2018-08-20
|
10 | Alissa Cooper | [Ballot Position Update] Position for Alissa Cooper has been changed to No Objection from Discuss |
2018-07-15
|
10 | Yuval Lifshitz | New version available: draft-ietf-dime-rfc4006bis-10.txt |
2018-07-15
|
10 | (System) | New version approved |
2018-07-15
|
10 | (System) | Request for posting confirmation emailed to previous authors: David Dolson , Lyle Bertz , Yuval Lifshitz |
2018-07-15
|
10 | Yuval Lifshitz | Uploaded new revision |
2018-06-11
|
09 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2018-06-11
|
09 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed |
2018-06-11
|
09 | Yuval Lifshitz | New version available: draft-ietf-dime-rfc4006bis-09.txt |
2018-06-11
|
09 | (System) | New version approved |
2018-06-11
|
09 | (System) | Request for posting confirmation emailed to previous authors: David Dolson , Lyle Bertz , Yuval Lifshitz |
2018-06-11
|
09 | Yuval Lifshitz | Uploaded new revision |
2018-05-24
|
08 | Cindy Morgan | IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation |
2018-05-24
|
08 | Ignas Bagdonas | [Ballot Position Update] New position, No Objection, has been recorded for Ignas Bagdonas |
2018-05-24
|
08 | Alexey Melnikov | [Ballot comment] I only scanned the document, so I only have one minor question/comment: In Section 8.39: Redirect-Server-Address looks underspecified to me. It says "address". … [Ballot comment] I only scanned the document, so I only have one minor question/comment: In Section 8.39: Redirect-Server-Address looks underspecified to me. It says "address". Is it a well known DIAMETER term? What is the syntax of address? Is it a URI or something else? |
2018-05-24
|
08 | Alexey Melnikov | [Ballot Position Update] New position, No Objection, has been recorded for Alexey Melnikov |
2018-05-24
|
08 | Martin Vigoureux | [Ballot Position Update] New position, No Objection, has been recorded for Martin Vigoureux |
2018-05-23
|
08 | Eric Rescorla | [Ballot comment] Rich version of this review at: https://mozphab-ietf.devsvcdev.mozaws.net/D3353 I only gave this a light read. Some minor comments below. COMMENTS S 1.2. > … [Ballot comment] Rich version of this review at: https://mozphab-ietf.devsvcdev.mozaws.net/D3353 I only gave this a light read. Some minor comments below. COMMENTS S 1.2. > deduction of credit from the end user account when service is > completed and refunding of reserved credit that is not used. > > Diameter Credit-control Server A Diameter credit-control server acts > as a prepaid server, performing real-time rating and credit- > control. It is located in the home domain and is accessed by a definition of "home domain" would be useful S 2. > credit-control application. > > When an end user requests services such as SIP or messaging, the > request is typically forwarded to a service element (e.g., SIP Proxy) > in the user's home domain. In some cases it might be possible that > the service element in the visited domain can offer services to the also define visited domain, or at least point to a reference. S 3.1. > [ CC-Correlation-Id ] > [ User-Equipment-Info ] > [ User-Equipment-Info-Extension ] > *[ Proxy-Info ] > *[ Route-Record ] > *[ AVP ] Please expand AVP on first use. S 4. > control client requests credit authorization from the credit-control > server prior to allowing any service to be delivered to the end user. > > In the first model, the credit-control server rates the request, > reserves a suitable amount of money from the user's account, and > returns the corresponding amount of credit resources. Note that Sorry, reserves the balance or the amount reserved? S 14. > > Even without any modification to the messages, an adversary can > eavesdrop on transactions that contain privacy-sensitive information > about the user. Also, by monitoring the credit-control messages one > can collect information about the credit-control server's billing > models and business relationships. I'm having trouble reading these two paragraphs. Are they about what happens if TLS isn't used? |
2018-05-23
|
08 | Eric Rescorla | [Ballot Position Update] New position, No Objection, has been recorded for Eric Rescorla |
2018-05-23
|
08 | Terry Manderson | [Ballot Position Update] New position, No Objection, has been recorded for Terry Manderson |
2018-05-23
|
08 | Amanda Baber | IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed |
2018-05-23
|
08 | Suresh Krishnan | [Ballot discuss] Section 8.38. RFC5952 contains significant changes in text representation from RFC3513 and I am concerned that there might be RFC4006 compliant implementations that … [Ballot discuss] Section 8.38. RFC5952 contains significant changes in text representation from RFC3513 and I am concerned that there might be RFC4006 compliant implementations that will no longer be legal with a MUST level use of RFC5952. e.g. Addresses with upper case hex digits, with leading zeroes in 16 bit fields etc. Has the working group considered this break in compatibility already in its discussions? If it has, this text should still be finessed a bit because RFC5952 recommendations (even at the MUST level) are a SHOULD for senders with the receivers being required to handle all possible legal formats as per RFC4291. So at least the sender rules and receiver rules need to be written differently. |
2018-05-23
|
08 | Suresh Krishnan | [Ballot comment] Section 8.65 Any reason you are allowing encoding an IPv4 address as a IPv4-Mapped IPv6 Address while you can directly use address family … [Ballot comment] Section 8.65 Any reason you are allowing encoding an IPv4 address as a IPv4-Mapped IPv6 Address while you can directly use address family 1 to encode it directly as an IPv4 address? This allows for two different encodings for the same address. |
2018-05-23
|
08 | Suresh Krishnan | [Ballot Position Update] New position, Discuss, has been recorded for Suresh Krishnan |
2018-05-23
|
08 | Alvaro Retana | [Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana |
2018-05-22
|
08 | Warren Kumari | [Ballot comment] Thanks for Joel for his OpsDir review - I looked at the diffs between 4006 and this, and am balloting based on that. … [Ballot comment] Thanks for Joel for his OpsDir review - I looked at the diffs between 4006 and this, and am balloting based on that. Helpful link for other ADs: http://tools.ietf.org/tools/rfcdiff/rfcdiff.pyht?url1=https://www.ietf.org/id/draft-ietf-dime-rfc4006bis-08.txt&url2=https://tools.ietf.org/rfc/rfc4006.txt |
2018-05-22
|
08 | Warren Kumari | [Ballot Position Update] New position, No Objection, has been recorded for Warren Kumari |
2018-05-22
|
08 | Benjamin Kaduk | [Ballot discuss] I support Alissa's Discuss point about sensitive AVPs. I appear to have a different understanding of Section 5.6.2, though, with a different potential … [Ballot discuss] I support Alissa's Discuss point about sensitive AVPs. I appear to have a different understanding of Section 5.6.2, though, with a different potential issue (but again, it's possible that I'm confused to how things work): With the redirection schemes covered in Section 5.6.2, it sounds like the user can be redirected (at the application protocol level, e.g., HTTP or SIP) to a top-up server to purchase more credits. I don't see a way described how user agents can distinguish between a Diameter-induced redirect and an attacker-induced redirect to a (potentially phishing) site that accepts payment information. To be clear, the scenario here is that a user is using a credit-controlled application session to talk to "arbitrary application servers", including potentially attacker-controllled HTTP/SIP/etc. servers; the attacker could introduce a redirect to a phishing page that asks for payment information, and the user would be led to believe that this was the normal flow for "my prepaid balance has been used up", and give their payment information to the phishing site. I think that either user agents need to give some indication that this DIAMETER-level redirect is different than an application-protocol-level redirect (e.g., http) or the Security Considerations need to mention the risk of acclimating users to arbitrary websites redirecting to sites asking for payment credentials, which may or may not be legitimate sites. Separately, in Section 8.68 (for QoS-Final-Unit-Indication): If the Final-Unit-Action AVP is set to REDIRECT at least the Redirect-Server-Extension AVP MUST be present. This MUST seems in conflict with the text in 8.64 (actually, is section 8.64 even internally inconsistent, too?) about "Redirect-Server AVP, in addition to or instead of the Redirect-Server-Extension AVP", in particular, the "instead of" portion. (The ABNF-based formal language spec in 8.68 does match up with the above MUST, though.) |
2018-05-22
|
08 | Benjamin Kaduk | [Ballot comment] Some additional significant but not necessarily DISCUSS-worthy comments, followed by more editorial- and nit-level things. In Section 1.3, "Advertising Application Support" uses the … [Ballot comment] Some additional significant but not necessarily DISCUSS-worthy comments, followed by more editorial- and nit-level things. In Section 1.3, "Advertising Application Support" uses the same Auth-Application-ID value as for RFC 4006; what are the interop consequences of this? Alissa already noted that the text about how to split (sub-)AVPs between the foo and foo-Extension AVPs is inconsistent among them -- e.g., Redirect-Server-Extension and User-Equipment-Info say "SHOULD send [in the old one]", but Subscription-Id-Extension has separate text about "[i]f full backward compatibility with [RFC4006] is required" and slightly different behavior described. We should try to catch all instances of this sort of backwards compatibility and make them consistent. The use of UTF8String for URLs and URIs (e.g., Redirect-Address-URL) might benefit from additional text about the expected contents. A lot of the time when we use a UTF8 container for names (whether domain names or other kinds), we specify what normalization form and canonicalization are performed, whether domain names are A-labels or U-labels, etc., as there's a lot of potential flexibility not all of which is good. In this case, since the communication is only between trusted actors, perhaps the additional restrictions are not needed, but I am curious if the topic was raised in the WG. Thank you for adding the Privacy Considerations and list of Privacy-Sensitive AVPs! Section 14 [...] The Diameter credit- control application is often used within one domain, and there may be a single hop between the peers. In these environments, the use of TLS/TCP, DTLS/SCTP or IPsec is sufficient. I did not see any concrete guidance on what would suffice in other environments (with multiple hops between peers). Is this the realm of the mythical "end-to-end security mechanism" for Diameter that is much-desired? (The last paragraph does have guidance on what might *not* suffice, which is not exactly the same thing.) Even without any modification to the messages, an adversary can eavesdrop on transactions that contain privacy-sensitive information about the user. This ("an adversary can") makes it sounds as if there is no confidentiality protection anywhere in the system, but that's what TLS/DTLS/IPSec are supposed to provide. So maybe "an adversary that can eavesdrop on transactions can obtain privacy-sensitive information [...]" is better. (Editorial- and nit-level stuff follows.) Section 4 A flexible credit-control application specific failure handling is defined in which the home service provider can model the credit- control client behavior according to its own credit risk management policy. This sentence is hard to parse -- in "credit-control application specific" what does "specific" bind to? What is being modelled? Is anything being controlled (as opposed to modelled)? Section 4.1.1 2. The Service-Parameter-Info AVP MAY be used as a container to pass legacy rating information in its original encoded form (e.g., ASN.1 BER). [...] Why BER and not DER? The unnecessary flexibility in BER vs. DER has been known to tickle parser bugs and create security vulnerabilities. Section 4.1.2 [...] To facilitate interoperability, it is RECOMMENDED that the rating input and the values of the Service-Context-Id be coordinated via an informational RFC or other permanent and readily available reference. The specification of another cooperative standardization body (e.g., 3GPP, OMA, or 3GPP2) SHOULD be used. The RECOMMENDED and SHOULD seem slightly in conflict. Section 5.1.1 As noted elsewhere, 60 seconds per minute does not always hold; it seems that this text could be reworded to just talk about a "constant rate" or "constant level per fixed time period" or similar. Section 5.1.2 [...] timer (Section 13) every time a CCR message with the value UPDATE_REQUEST is sent while they are in PendingU state. When answers to all pending messages are received, the state machine moves to OPEN state, and Tx is stopped. Transmission, or the Tx timer (is stopped)? Using a different title for Section 5.2.2 might make the parallel between it and Section 5.2.1 more clear. That is, perhaps something like "First Interrogation Included with Authorization Messages". Section 5.7 [...] It is RECOMMENDED that the client complement the credit- control failure procedures with backup accounting flow toward an accounting server. [...] Nit: it looks like there's a missing article here, maybe "a backup accounting flow" is better. The AAA transport profile [RFC3539] defines the application layer watchdog algorithm that enables failover from a peer that has failed and is controlled by a watchdog timer (Tw) defined in [RFC3539]. Nit: Is it "the" watchdog algorithm or "an" watchdog algorithm? Section 6.2 Should there be text indicating how the client indicates what service the balance check is being requested for? Section 8.54 Maybe give a section reference in RFC 3580 for how the formatting is done? Section 12 [...] Initially, such Expert discussions take place on the AAA WG mailing list. That list appears to be dead, suggesting that this text should be updated. (I also agree with Adam's comments about updating the IANA Considerations.) Why is the disclaimer in Section B.4 (and other examples) not needed in Section B.3? |
2018-05-22
|
08 | Benjamin Kaduk | [Ballot Position Update] New position, Discuss, has been recorded for Benjamin Kaduk |
2018-05-22
|
08 | Alissa Cooper | [Ballot discuss] = Section 5.6.2 = I'm having a little trouble understanding the expected behavior described in Section 5.6.2 so wanted to see if I'm … [Ballot discuss] = Section 5.6.2 = I'm having a little trouble understanding the expected behavior described in Section 5.6.2 so wanted to see if I'm just confused or if there is something to be clarified. The text says: "In addition to the Redirect-Server AVP or Redirect-Server-Extension AVP, the credit-control server MAY include one or more Restriction- Filter-Rule AVPs, one or more Filter-Rule AVPs, or one or more Filter-Id AVPs in the Credit-Control-Answer message to enable the user to access other services (for example, zero-rated services). In such a case, the access device MUST drop all the packets not matching the IP filters specified in the Restriction-Filter-Rule AVPs, Filter- Rule AVPs or Filter-Id AVPs. If enforcement actions other than allowing the packets (e.g., QoS), are indicated in the Filter-Rule AVPs or Filter-Id AVPs, they SHOULD be performed as well. In addition, if possible, to redirecting the user to the destination specified in the Redirect-Server AVP or Redirect-Server-Extension AVP." It seems like if the server sends a Redirect-Server AVP or Redirect-Server-Extension AVP without any of the other AVPs, then all the traffic is supposed to be redirected. But if a Restriction-Filter-Rule AVP, Filter-Rule AVP, or Filter-Id AVP is also included, then the non-matching traffic MUST be dropped, in which case how does the user get redirected? Is the last sentence (which is a sentence fragment, actually) supposed to address this somehow? And in the case of enforcement actions involving QoS, the text seems to say that packets matching the filter MUST be dropped AND have the QoS rules applied to them, so I don't understand how that works. = Section 15.1 = RFC 6733 lists a bunch of sensitive AVPs and then says this about them: "Diameter messages containing these or any other AVPs considered to be security-sensitive MUST only be sent protected via mutually authenticated TLS or IPsec. In addition, those messages MUST NOT be sent via intermediate nodes unless there is end-to-end security between the originator and recipient or the originator has locally trusted configuration that indicates that end-to-end security is not needed." It seems like the list of AVPs in Section 15.1 should have these same requirements applied to them explicitly. |
2018-05-22
|
08 | Alissa Cooper | [Ballot comment] = Section 1 = (1) I know it's a term of art, but the term "next generation wireless networks" seems a bit out … [Ballot comment] = Section 1 = (1) I know it's a term of art, but the term "next generation wireless networks" seems a bit out of place in two ways: (1) "wireless" seems more generic than what is implied (i.e., "cellular," I assume), and (2) is Rel-13 considered "next generation" still? (2) "Diameter base protocol" should cite RFC 6733. = Section 5.1 = Assuming G-S-U stands for granted service unit, the acronym should be given upon first use here. = Section 8.52 = (1) Why do you need to specify the ability to send either the IMEISV or the IMEI? (2) "If the type of the equipment is one of the enumerated types of User-Equipment-Info-Type AVP, then the credit- control client SHOULD send the information in the User-Equipment-Info AVP, in addition to or instead of the User-Equipment-Info-Extension AVP." Why is this normative recommendation in support of backwards compatibility different from the one given for the Subscription-Id-Extension AVP in Sec. 8.58? = Section 15.1 = "Redirect-Server-Address AVP: the service-provider may embed personal information on the subscriber in the URL/I (e.g. to create a personalized message)." This seems like a bad idea that, if it's going to be mentioned, should be recommended against. |
2018-05-22
|
08 | Alissa Cooper | [Ballot Position Update] New position, Discuss, has been recorded for Alissa Cooper |
2018-05-21
|
08 | Spencer Dawkins | [Ballot Position Update] New position, No Objection, has been recorded for Spencer Dawkins |
2018-05-21
|
08 | Adam Roach | [Ballot comment] Thanks to the authors and other participants who helped with this revision of the credit-control application. Thanks in particular for the addition of … [Ballot comment] Thanks to the authors and other participants who helped with this revision of the credit-control application. Thanks in particular for the addition of an extensive privacy considerations section. I will note that I only reviewed the diffs between this document and RFC 4006. I have a handful of comments. --------------------------------------------------------------------------- General nit: This document uses the term "service specific" as a compound adjective in several places. As a compound adjective, this should be hyphenated (i.e., "service-specific"). --------------------------------------------------------------------------- §1.1: This document uses lowercase forms of RFC-2119-defined terms. Please update this section to use the boilerplate from RFC 8174. --------------------------------------------------------------------------- §5.1.2: > If independent credit-control of multiple services is used, the > Validity-Time AVP and Final-Unit-Indication AVP or QoS-Final-Unit- > Indication AVP SHOULD be present either in the Multiple-Services- > Credit-Control AVP(s) or at command level as single AVPs. The phrasing here is ambiguous -- it's not clear whether the requirement is: (Validity-Time and Final-Unit-Indication) or QoS-Final-Unit-Indication ... or ... Validity-Time and (Final-Unit-Indication or QoS-Final-Unit-Indication) I suspect it's the latter, in which case I suggest: If independent credit-control of multiple services is used, the Validity-Time AVP, and either the Final-Unit-Indication AVP or the QoS-Final-Unit-Indication AVP, SHOULD be present either in the Multiple-Services- Credit-Control AVP(s) or at command level as single AVPs. --------------------------------------------------------------------------- §5.2.1: The alignment of the "Diameter AAA Server" title on Figure 3 has changed from RFC 4006 in a way that looks worse. --------------------------------------------------------------------------- §5.6.2: > The credit-control > client receives a Credit-Control-Answer or service specific > authorization answer with the Final-Unit-Indication or the QoS-Final- > Unit-Indication AVP and Validity-Time AVPs but no Granted-Service- > Unit AVP. This has the same confusion as above regarding the application of logical combinations. The second half of the statement is of the form "A or B and C but not D," which is pretty ambiguous. It's also a little unclear whether the client receives a Credit-Control-Answer (with A or B and C but not D), or just a Credit-Control-Answer of any description, full stop. --------------------------------------------------------------------------- §8.19 > Note: The values reported in a Used-Service-Unit AVP does not > necessarily have a relation to the grant provided in a Granted- > Service-Unit AVP, e.g., the value in this AVP may exceed the value in > the grant. Nit: "...values reported in a Used-Service-Unit AVP do not..." ^^ (or "...value... does not...") --------------------------------------------------------------------------- §8.54: > The User-Equipment-Info-MAC (AVP Code TBD3) is of type OctetString. > The User-Equipment-Info-MAC AVP contains the 48-bit MAC address is > formatted as described in [RFC3580]. Nit: remove "is" after "address". --------------------------------------------------------------------------- §8.65: > The Redirect-Address-IPAddress AVP (AVP Code TBD14) is of type > Address and defines the IPv4 or IPv6 address of the redirect server > with which the end user is to be connected when the account cannot > cover the service cost. This appears to be underspecified, unless I've missed some specification elsewhere regarding what the client is supposed to do with this IP address. While the other redirection methods (HTTP, SIP) have relatively clear means of contact (they indicate a protocol), the indication of only an IP address with neither protocol nor port doesn't seem to provide enough information for a client to act on. Please either flesh this out in this section, or point to another document that indicates how this IP address is to be used. --------------------------------------------------------------------------- §12: When new documents obsolete an RFC that originally registered values with IANA, I'm used to seeing that document also update the IANA registry so that the corresponding entries now point to the new document. You may consider text that instructs IANA to update the existing RFC-4006-registered values so that they point to this document instead of RFC 4006. --------------------------------------------------------------------------- Appendix B: As a general comment for all of the examples: I'm surprised that none of the examples have been updated to reflect the newly defined capabilities in this document. For example, all the examples in this appendix use Final-Unit-Indication rather than QoS-Final-Unit-Indication. In practice, to show maximally flexible and compatible examples, I would expect that the examples would include both AVPs. This applies to all of the "Extension" AVPs as well. --------------------------------------------------------------------------- Appendix B.2: > control server. Therefore, in this example, it is assumed that the > SIP Proxy adds a Record-Route header in the initial SIP INVITE "...a Record-Route header field..." (A SIP header is everything before the first blank line; individual lines within a SIP header are called "header fields") |
2018-05-21
|
08 | Adam Roach | [Ballot Position Update] New position, No Objection, has been recorded for Adam Roach |
2018-05-21
|
08 | Deborah Brungard | [Ballot Position Update] New position, No Objection, has been recorded for Deborah Brungard |
2018-05-18
|
08 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed |
2018-05-18
|
08 | David Dolson | New version available: draft-ietf-dime-rfc4006bis-08.txt |
2018-05-18
|
08 | (System) | New version approved |
2018-05-18
|
08 | (System) | Request for posting confirmation emailed to previous authors: David Dolson , Lyle Bertz , Yuval Lifshitz |
2018-05-18
|
08 | David Dolson | Uploaded new revision |
2018-05-18
|
07 | Mirja Kühlewind | [Ballot Position Update] New position, No Objection, has been recorded for Mirja Kühlewind |
2018-05-03
|
07 | Ben Campbell | IESG state changed to IESG Evaluation from Waiting for AD Go-Ahead::Revised I-D Needed |
2018-05-03
|
07 | Linda Dunbar | Request for Last Call review by GENART Completed: Almost Ready. Reviewer: Linda Dunbar. Sent review to list. |
2018-04-22
|
07 | Joel Jaeggli | Request for Last Call review by OPSDIR Completed: Ready. Reviewer: Joel Jaeggli. Sent review to list. |
2018-04-19
|
07 | Tero Kivinen | Request for Last Call review by SECDIR Completed: Has Nits. Reviewer: David Mandelberg. |
2018-04-16
|
07 | Ben Campbell | IESG state changed to Waiting for AD Go-Ahead::Revised I-D Needed from Waiting for AD Go-Ahead |
2018-04-16
|
07 | Ben Campbell | Placed on agenda for telechat - 2018-05-24 |
2018-04-16
|
07 | Amanda Baber | IANA Review state changed to IANA OK - Actions Needed from IANA - Not OK |
2018-04-12
|
07 | (System) | IANA Review state changed to IANA - Not OK from IANA - Review Needed |
2018-04-12
|
07 | Sabrina Tanamal | (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Services Operator has completed its review of draft-ietf-dime-rfc4006bis-07. If any part of this review is inaccurate, please let … (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Services Operator has completed its review of draft-ietf-dime-rfc4006bis-07. If any part of this review is inaccurate, please let us know. The IANA Services Operator has a question about one of the actions requested in the IANA Considerations section of this document. The IANA Services Operator understands that, upon approval of this document, there are twenty-one actions which we must complete. First, in the Application IDs registry on the Authentication, Authorization, and Accounting (AAA) Parameters registry page located at: https://www.iana.org/assignments/aaa-parameters/ The existing registration for: ID Value: 4 Name: Diameter Credit Control has a reference of [RFC6733]. IANA Question --> Should the reference be changed to [ RFC-to-be ]? Second, in the Command Codes registry on the Authentication, Authorization, and Accounting (AAA) Parameters registry page located at: https://www.iana.org/assignments/aaa-parameters/ The existing registration for: Code Value: 272 Name: CCR / CCA has a reference of [RFC6733]. Third, section 12.3 of the current draft suggests that we should "see Section 8 for the assignment of the namespace in this specification." IANA Question -> Section 8 of the current draft provides a table that appears to be AVP codes, but the table does not match the AVP code table on the Authentication, Authorization, and Accounting (AAA) Parameters registry page located at: https://www.iana.org/assignments/aaa-parameters/ Is the table in Section 8 intended to be a new registry or a subset of the existing AVP Codes table? Could the authors redraft section 12.3 to explicitly show which AVP Codes are new additions, and which are restatements of existing registrations that should have their reference change? Fourth, in the Result-Code AVP Values (code 268) - Transient Failures registry also on the Authentication, Authorization, and Accounting (AAA) Parameters registry page located at: https://www.iana.org/assignments/aaa-parameters/ the existing values 4010 4011 4012 are already registered. IANA Question --> Should the reference for these registrations be changed to [ RFC-to-be ]? Fifth, in the Result-Code AVP Values (code 268) - Permanent Failure registry also on the Authentication, Authorization, and Accounting (AAA) Parameters registry page located at: https://www.iana.org/assignments/aaa-parameters/ the existing values 5030 5031 are already registered. IANA Question --> Should the reference for these registrations be changed to [ RFC-to-be ]? Sixth, in the CC-Request-Type AVP registry also on the Authentication, Authorization, and Accounting (AAA) Parameters registry page located at: https://www.iana.org/assignments/aaa-parameters/ Values 1 - 4 will remain in place and in the future, the registry will be maintained via Designated Expert as defined in RFC 8126. IANA Question -> What are "all remaining values" for this registry that are currently unassigned? Seventh, in the CC-Session-Failover AVP registry also on the Authentication, Authorization, and Accounting (AAA) Parameters registry page located at: https://www.iana.org/assignments/aaa-parameters/ Values 0 and 1 will remain in place and in the future, the registry will be maintained via Designated Expert as defined in RFC 8126. IANA Question -> What are "all remaining values" for this registry that are currently unassigned? Eighth, in the CC-Unit-Type AVP registry also on the Authentication, Authorization, and Accounting (AAA) Parameters registry page located at: https://www.iana.org/assignments/aaa-parameters/ Values 0 - 5 will remain in place and in the future, the registry will be maintained via Designated Expert as defined in RFC 8126. IANA Question -> What are "all remaining values" for this registry that are currently unassigned? Ninth, in the Check-Balance-Result AVP registry also on the Authentication, Authorization, and Accounting (AAA) Parameters registry page located at: https://www.iana.org/assignments/aaa-parameters/ Values 0 and 1 will remain in place and in the future, the registry will be maintained via Designated Expert as defined in RFC 8126. IANA Question -> What are "all remaining values" for this registry that are currently unassigned? Tenth, in the Credit-Control AVP registry also on the Authentication, Authorization, and Accounting (AAA) Parameters registry page located at: https://www.iana.org/assignments/aaa-parameters/ Values 0 and 1 will remain in place and in the future, the registry will be maintained via Designated Expert as defined in RFC 8126. IANA Question -> What are "all remaining values" for this registry that are currently unassigned? Eleventh, in the Credit-Control-Failure-Handling AVP registry also on the Authentication, Authorization, and Accounting (AAA) Parameters registry page located at: https://www.iana.org/assignments/aaa-parameters/ Values 0 - 2 will remain in place and in the future, the registry will be maintained via Designated Expert as defined in RFC 8126. IANA Question -> What are "all remaining values" for this registry that are currently unassigned? Twelfth, in the Direct-Debiting-Failure-Handling AVP registry also on the Authentication, Authorization, and Accounting (AAA) Parameters registry page located at: https://www.iana.org/assignments/aaa-parameters/ Values 0 and 1 will remain in place and in the future, the registry will be maintained via Designated Expert as defined in RFC 8126. IANA Question -> What are "all remaining values" for this registry that are currently unassigned? Thirteenth, in the Final-Unit-Action AVP registry also on the Authentication, Authorization, and Accounting (AAA) Parameters registry page located at: https://www.iana.org/assignments/aaa-parameters/ Values 0 - 2 will remain in place and in the future, the registry will be maintained via Designated Expert as defined in RFC 8126. IANA Question -> What are "all remaining values" for this registry that are currently unassigned? Fourteenth, in the Multiple-Services-Indicator AVP registry also on the Authentication, Authorization, and Accounting (AAA) Parameters registry page located at: https://www.iana.org/assignments/aaa-parameters/ Values 0 and 1 will remain in place and in the future, the registry will be maintained via Designated Expert as defined in RFC 8126. IANA Question -> What are "all remaining values" for this registry that are currently unassigned? Fifteenth, in the Redirect-Address-Type AVP registry also on the Authentication, Authorization, and Accounting (AAA) Parameters registry page located at: https://www.iana.org/assignments/aaa-parameters/ Values 0 - 3 will remain in place and in the future, the registry will be maintained via Designated Expert as defined in RFC 8126. IANA Question -> What are "all remaining values" for this registry that are currently unassigned? Sixteenth, in the Requested-Action AVP registry also on the Authentication, Authorization, and Accounting (AAA) Parameters registry page located at: https://www.iana.org/assignments/aaa-parameters/ Values 0 - 3 will remain in place and in the future, the registry will be maintained via Designated Expert as defined in RFC 8126. IANA Question -> What are "all remaining values" for this registry that are currently unassigned? Seventeenth, in the Subscription-Id-Type AVP registry also on the Authentication, Authorization, and Accounting (AAA) Parameters registry page located at: https://www.iana.org/assignments/aaa-parameters/ Values 0 - 4 will remain in place and in the future, the registry will be maintained via Designated Expert as defined in RFC 8126. IANA Question -> What are "all remaining values" for this registry that are currently unassigned? Eighteenth, in the Tariff-Change-Usage AVP registry also on the Authentication, Authorization, and Accounting (AAA) Parameters registry page located at: https://www.iana.org/assignments/aaa-parameters/ Values 0 - 2 will remain in place and in the future, the registry will be maintained via Designated Expert as defined in RFC 8126. IANA Question -> What are "all remaining values" for this registry that are currently unassigned? Nineteenth, in the User-Equipment-Info-Type AVP registry also on the Authentication, Authorization, and Accounting (AAA) Parameters registry page located at: https://www.iana.org/assignments/aaa-parameters/ Values 0 - 3 will remain in place and in the future, the registry will be maintained via Designated Expert as defined in RFC 8126. IANA Question -> What are "all remaining values" for this registry that are currently unassigned? Twentieth, in section 13 of the current draft, there is a discussion of Credit-Control Application Related Parameters. Upon examining this section, we do not believe that there is any request for IANA action in this section. IANA Question -> Is it correct that there is no IANA Action contained in section 13 of the current draft? Twenty-first: IANA Question -> Is there any other place in IANA registries where RFC4006 is referenced and should be changed to [ RFC-to-be ]? The IANA Services 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 |
2018-04-12
|
07 | (System) | IESG state changed to Waiting for AD Go-Ahead from In Last Call |
2018-04-11
|
07 | Michael Tüxen | Request for Last Call review by TSVART Completed: Ready. Reviewer: Michael Tüxen. Sent review to list. |
2018-04-05
|
07 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to David Mandelberg |
2018-04-05
|
07 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to David Mandelberg |
2018-04-05
|
07 | Jean Mahoney | Request for Last Call review by GENART is assigned to Linda Dunbar |
2018-04-05
|
07 | Jean Mahoney | Request for Last Call review by GENART is assigned to Linda Dunbar |
2018-04-04
|
07 | Magnus Westerlund | Request for Last Call review by TSVART is assigned to Michael Tüxen |
2018-04-04
|
07 | Magnus Westerlund | Request for Last Call review by TSVART is assigned to Michael Tüxen |
2018-04-04
|
07 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Joel Jaeggli |
2018-04-04
|
07 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Joel Jaeggli |
2018-03-29
|
07 | Amy Vezza | IANA Review state changed to IANA - Review Needed |
2018-03-29
|
07 | Amy Vezza | The following Last Call announcement was sent out (ends 2018-04-12): From: The IESG To: IETF-Announce CC: ben@nostrum.com, jouni.nospam@gmail.com, Jouni Korhonen , draft-ietf-dime-rfc4006bis@ietf.org, … The following Last Call announcement was sent out (ends 2018-04-12): From: The IESG To: IETF-Announce CC: ben@nostrum.com, jouni.nospam@gmail.com, Jouni Korhonen , draft-ietf-dime-rfc4006bis@ietf.org, dime-chairs@ietf.org, dime@ietf.org Reply-To: ietf@ietf.org Sender: Subject: Last Call: (Diameter Credit-Control Application) to Proposed Standard The IESG has received a request from the Diameter Maintenance and Extensions WG (dime) to consider the following document: - 'Diameter Credit-Control Application' 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 2018-04-12. 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 specifies a Diameter application that can be used to implement real-time credit-control for a variety of end user services such as network access, Session Initiation Protocol (SIP) services, messaging services, and download services. The Diameter Credit- Control application as defined in this document obsoletes RFC4006, and it must be supported by all new Diameter Credit-Control Application implementations. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-dime-rfc4006bis/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-dime-rfc4006bis/ballot/ No IPR declarations have been submitted directly on this I-D. |
2018-03-29
|
07 | Amy Vezza | IESG state changed to In Last Call from Last Call Requested |
2018-03-29
|
07 | Ben Campbell | Last call was requested |
2018-03-29
|
07 | Ben Campbell | IESG state changed to Last Call Requested from AD Evaluation::AD Followup |
2018-03-29
|
07 | Ben Campbell | Last call announcement was generated |
2018-03-28
|
07 | Ben Campbell | Last call announcement was generated |
2018-03-28
|
07 | Ben Campbell | Ballot has been issued |
2018-03-28
|
07 | Ben Campbell | [Ballot Position Update] New position, Yes, has been recorded for Ben Campbell |
2018-03-28
|
07 | Ben Campbell | Created "Approve" ballot |
2018-03-28
|
07 | Ben Campbell | Ballot writeup was changed |
2018-03-28
|
07 | Ben Campbell | Ballot approval text was generated |
2018-03-21
|
07 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2018-03-21
|
07 | Yuval Lifshitz | New version available: draft-ietf-dime-rfc4006bis-07.txt |
2018-03-21
|
07 | (System) | New version approved |
2018-03-21
|
07 | (System) | Request for posting confirmation emailed to previous authors: David Dolson , dime-chairs@ietf.org, " ylifshitz@sandvine.com" , Lyle Bertz |
2018-03-21
|
07 | Yuval Lifshitz | Uploaded new revision |
2018-02-12
|
06 | Ben Campbell | IESG state changed to AD Evaluation::Revised I-D Needed from AD Evaluation |
2018-02-12
|
06 | Ben Campbell | RFC 4006. ————————————— Major Comment: I strongly suggest that you add more privacy considerations. I realize that it inherits its existing privacy considerations from … RFC 4006. ————————————— Major Comment: I strongly suggest that you add more privacy considerations. I realize that it inherits its existing privacy considerations from RFC 4006, but that was published in 2005. The IETF’s focus on privacy has evolved considerably since then, and I think this draft will get objections during IESG review without adding some more. I suggest the following: — Create a “Privacy Considerations” section separate from the security considerations. — Enumerate the AVPs that you think contain user identifiable information, persistent identifiers, or other privacy sensitive data. — Make some non-normative recommendations concerning data minimization. That is, add a few sentences recommending that clients and servers avoid capturing and/or log personal information beyond that needed for the application's purpose. Minor Comments: -Section 12 and subsections: Please clarify that many of these elements were already registered by RF 4006, and are not being “re-registered” here. ( It’s perfectly okay to pull the registration information forward into the bis draft; it just needs clarification.) Also, please consider wether existing registrations should be updated to point to this document rather than 4006. Appendices: Would any of the example flows benefit from including one or more of the new AVPs? Editorial and Nits: -Section 8.34: “ If the Final-Unit-Action AVP is set to RESTRICT_ACCESS or REDIRECT and the classification of the restricted traffic cannot be expressed using IPFilterRule, or different actions (e.g., QoS) than just allowing QoS needs to be enforced traffic, … “ I have trouble parsing the sentence. -14: "Even without any modification to the messages, an adversary can invite a security threat by eavesdropping, as the transactions contain private information about the user. ” I suggest “ … an adversary can eavesdrop on transactions that contain privacy-sensitive imformation” |
2018-02-08
|
06 | Ben Campbell | IESG state changed to AD Evaluation from Publication Requested |
2018-01-03
|
06 | Jouni Korhonen | 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? Standards Track and it is indicated on the title page. (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 will obsolete RFC4006. This document specifies a Diameter application that can be used to implement real-time credit-control for a variety of end user services. Working Group Summary WG has a solid support for this document. Document Quality 3GPP has adopted RFC4006 and it has been widely implemented, deployed and in production use basically in every cellular carrier with LTE deployment. The changes/updates described in this specification are not deployed but being one of the core Diameter specifications in 3GPP there are high probability it getting a wide deployment. Maintaining backward compatibility was one of the design guidelines. The update to RFC4006, which this document is, was requested by 3GPP. There has not been any expert reviews of the document. 3GPP CT3 and CT4 should review the document before its publication. Personnel Jouni Korhonen (jouni.nospam@gmail.com) is the document shepherd. Ben Campbell (ben@nostrum.com) is the responsible AD. (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. The shepherd was part of the initial team thinking the changes required and how to proceed with those. During the publication process the shepherd has done review on the parts of the document required when writing the proto write-up. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? No. (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. The document should be reviewed by AAA doctors and 3GPP CT3/CT4 WGs. (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. None. There is just the generic issue with Diameter enums that has changed since the publication of the original RFC4006, which is described in RFC7423 and reflected in the IANA considerations that list the AVPs type of enum and requiring designated expert review. (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. Yes. (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. No IPRs disclosed with this update of the RFC. (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? Solid WG consensus behind the document. (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.) None. (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. None that matter. Downrefs are discussed in step 15) (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. None required. (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? None. (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. Following downward references exists: -- Possible downref: Non-RFC (?) normative reference: ref. 'CE164' -- Possible downref: Non-RFC (?) normative reference: ref. 'CE212' -- Possible downref: Non-RFC (?) normative reference: ref. 'E164' -- Possible downref: Non-RFC (?) normative reference: ref. 'E212' -- Possible downref: Non-RFC (?) normative reference: ref. 'EUI64' -- Possible downref: Non-RFC (?) normative reference: ref. 'ISO4217' -- Possible downref: Non-RFC (?) normative reference: ref. 'TGPPIMEI' All these are normative required references to documents/specifications outside IETF. (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. This document obsoletes RFC4006 and it is listed in appropriate places in the document. This document is an update based on the original RFC4006. (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). The IANA requirements were checked against RFC8126 not the obsoleted RFC5226. The document defines 17 new AVPs that are listed in Section 8. No new registries are created. The IANA considerations for AVPs of type enum and the associated existing RFC4006 created IANA registry have a new additional clarification: "All remaining values are available for assignment by a Designated Expert [RFC8126], under the conditions for enumerated values described in [RFC7423] Section 5.6." (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. None. (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. None. |
2018-01-03
|
06 | Jouni Korhonen | Responsible AD changed to Ben Campbell |
2018-01-03
|
06 | Jouni Korhonen | IETF WG state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up |
2018-01-03
|
06 | Jouni Korhonen | IESG state changed to Publication Requested |
2018-01-03
|
06 | Jouni Korhonen | IESG process started in state Publication Requested |
2018-01-03
|
06 | Jouni Korhonen | Changed document writeup |
2018-01-03
|
06 | Jouni Korhonen | Tags Other - see Comment Log, Revised I-D Needed - Issue raised by WGLC cleared. |
2018-01-03
|
06 | Jouni Korhonen | IETF WG state changed to WG Consensus: Waiting for Write-Up from Waiting for WG Chair Go-Ahead |
2018-01-03
|
06 | Jouni Korhonen | Changed document writeup |
2018-01-03
|
06 | Jouni Korhonen | Changed document writeup |
2018-01-03
|
06 | Jouni Korhonen | Changed document writeup |
2018-01-03
|
06 | David Dolson | New version available: draft-ietf-dime-rfc4006bis-06.txt |
2018-01-03
|
06 | (System) | New version approved |
2018-01-03
|
06 | (System) | Request for posting confirmation emailed to previous authors: David Dolson , " ylifshitz@sandvine.com" , Lyle Bertz |
2018-01-03
|
06 | David Dolson | Uploaded new revision |
2018-01-03
|
05 | Jouni Korhonen | Changed document writeup |
2018-01-03
|
05 | Jouni Korhonen | Changed document writeup |
2017-12-21
|
05 | David Dolson | New version available: draft-ietf-dime-rfc4006bis-05.txt |
2017-12-21
|
05 | (System) | New version approved |
2017-12-21
|
05 | (System) | Request for posting confirmation emailed to previous authors: David Dolson , " ylifshitz@sandvine.com" , Lyle Bertz |
2017-12-21
|
05 | David Dolson | Uploaded new revision |
2017-12-10
|
04 | Jouni Korhonen | Changed document writeup |
2017-12-10
|
04 | Jouni Korhonen | Changed document writeup |
2017-12-10
|
04 | Jouni Korhonen | Notification list changed to Jouni Korhonen <jouni.nospam@gmail.com> |
2017-12-10
|
04 | Jouni Korhonen | Document shepherd changed to Jouni Korhonen |
2017-12-01
|
04 | David Dolson | New version available: draft-ietf-dime-rfc4006bis-04.txt |
2017-12-01
|
04 | (System) | New version approved |
2017-12-01
|
04 | (System) | Request for posting confirmation emailed to previous authors: David Dolson , " ylifshitz@sandvine.com" , Lyle Bertz |
2017-12-01
|
04 | David Dolson | Uploaded new revision |
2017-11-13
|
03 | (System) | Document has expired |
2017-11-08
|
03 | Jouni Korhonen | WGLC passed - no further comments on the draft anymore. Needs to fix IDnits. |
2017-11-08
|
03 | Jouni Korhonen | Tag Revised I-D Needed - Issue raised by WGLC set. |
2017-11-08
|
03 | Jouni Korhonen | IETF WG state changed to Waiting for WG Chair Go-Ahead from In WG Last Call |
2017-11-01
|
03 | Jouni Korhonen | The WGLC ends 11/8/2017. |
2017-11-01
|
03 | Jouni Korhonen | IETF WG state changed to In WG Last Call from Waiting for WG Chair Go-Ahead |
2017-10-23
|
03 | Jouni Korhonen | Need to check NITs and small things. ** Obsolete normative reference: RFC 1738 (Obsoleted by RFC 4248, RFC 4266) ** Obsolete normative reference: … Need to check NITs and small things. ** Obsolete normative reference: RFC 1738 (Obsoleted by RFC 4248, RFC 4266) ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) Below one is most likely intentional as it was like this in RFC4006 already: ** Downref: Normative reference to an Informational RFC: RFC 3580 |
2017-10-23
|
03 | Jouni Korhonen | IETF WG state changed to Waiting for WG Chair Go-Ahead from In WG Last Call |
2017-05-11
|
03 | David Dolson | New version available: draft-ietf-dime-rfc4006bis-03.txt |
2017-05-11
|
03 | (System) | New version approved |
2017-05-11
|
03 | (System) | Request for posting confirmation emailed to previous authors: David Dolson , " ylifshitz@sandvine.com" , dime-chairs@ietf.org, Lyle Bertz |
2017-05-11
|
03 | David Dolson | Uploaded new revision |
2017-04-16
|
02 | Jouni Korhonen | WGLC #1 starts 4/16/17. Will end 4/30/17. |
2017-04-16
|
02 | Jouni Korhonen | Tag Other - see Comment Log set. |
2017-04-16
|
02 | Jouni Korhonen | IETF WG state changed to In WG Last Call from WG Document |
2017-03-09
|
02 | David Dolson | New version available: draft-ietf-dime-rfc4006bis-02.txt |
2017-03-09
|
02 | (System) | New version approved |
2017-03-09
|
02 | (System) | Request for posting confirmation emailed to previous authors: David Dolson , " ylifshitz@sandvine.com" , dime-chairs@ietf.org, Lyle Bertz |
2017-03-09
|
02 | David Dolson | Uploaded new revision |
2017-02-23
|
01 | David Dolson | New version available: draft-ietf-dime-rfc4006bis-01.txt |
2017-02-23
|
01 | (System) | New version approved |
2017-02-23
|
01 | (System) | Request for posting confirmation emailed to previous authors: Marco Stura , " ylifshitz@sandvine.com" , John Loughney , Leena Mattila , Juha-Pekka Koskinen , dime-chairs@ietf.org … Request for posting confirmation emailed to previous authors: Marco Stura , " ylifshitz@sandvine.com" , John Loughney , Leena Mattila , Juha-Pekka Koskinen , dime-chairs@ietf.org, Lyle Bertz , David Dolson , Harri Hakala |
2017-02-23
|
01 | David Dolson | Uploaded new revision |
2016-09-21
|
00 | Jouni Korhonen | Changed consensus to Yes from Unknown |
2016-09-21
|
00 | Jouni Korhonen | Intended Status changed to Proposed Standard from None |
2016-09-21
|
00 | Jasmine Magallanes | This document now replaces draft-bertz-dime-rfc4006bis instead of None |
2016-09-21
|
00 | Lyle Bertz | Posted submission manually |
2016-09-21
|
00 | Lyle Bertz | Uploaded new revision |
2016-09-21
|
00 | Lyle Bertz | New version available: draft-ietf-dime-rfc4006bis-00.txt |