Universal Plug and Play (UPnP) Internet Gateway Device - Port Control Protocol Interworking Function (IGD-PCP IWF)
draft-ietf-pcp-upnp-igd-interworking-10
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2013-07-23
|
10 | (System) | RFC Editor state changed to AUTH48-DONE from AUTH48 |
2013-06-24
|
10 | (System) | RFC Editor state changed to AUTH48 from RFC-EDITOR |
2013-05-30
|
10 | (System) | RFC Editor state changed to RFC-EDITOR from EDIT |
2013-05-17
|
10 | Amy Vezza | State changed to RFC Ed Queue from Approved-announcement sent |
2013-05-17
|
10 | (System) | RFC Editor state changed to EDIT |
2013-05-17
|
10 | (System) | Announcement was received by RFC Editor |
2013-05-16
|
10 | (System) | IANA Action state changed to No IC |
2013-05-16
|
10 | Amy Vezza | State changed to Approved-announcement sent from Approved-announcement to be sent |
2013-05-16
|
10 | Amy Vezza | IESG has approved the document |
2013-05-16
|
10 | Amy Vezza | Closed "Approve" ballot |
2013-05-16
|
10 | Amy Vezza | Ballot approval text was generated |
2013-05-03
|
10 | Ted Lemon | State changed to Approved-announcement to be sent from IESG Evaluation::AD Followup |
2013-05-03
|
10 | Sean Turner | [Ballot Position Update] Position for Sean Turner has been changed to No Objection from Discuss |
2013-05-02
|
10 | Tero Kivinen | Request for Last Call review by SECDIR Completed: Has Issues. Reviewer: Vincent Roca. |
2013-04-26
|
10 | Martin Stiemerling | [Ballot comment] Thank you for addressing my issues. |
2013-04-26
|
10 | Martin Stiemerling | [Ballot Position Update] Position for Martin Stiemerling has been changed to No Objection from Discuss |
2013-04-26
|
10 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2013-04-26
|
10 | Mohamed Boucadair | New version available: draft-ietf-pcp-upnp-igd-interworking-10.txt |
2013-04-25
|
09 | Cindy Morgan | State changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation |
2013-04-25
|
09 | Stephen Farrell | [Ballot comment] - I support Sean's discuss. (And thought that the secdir review was a really good one.) - uPnP seems to cause a lot … [Ballot comment] - I support Sean's discuss. (And thought that the secdir review was a really good one.) - uPnP seems to cause a lot of folks security concerns so I was surprised that there was such a short security considerations section. However, since I know almost nothing about uPnP and only a little about PCP and have not had a chance to properly go into this, I don't have a valid discuss to ballot (unless I find time in the next two hours to read more about it;-) |
2013-04-25
|
09 | Stephen Farrell | [Ballot Position Update] New position, No Objection, has been recorded for Stephen Farrell |
2013-04-25
|
09 | Sean Turner | [Ballot discuss] Most of these are based on the secdir review from Vincent: 0) Are there any additional recommendations this document should be making wrt … [Ballot discuss] Most of these are based on the secdir review from Vincent: 0) Are there any additional recommendations this document should be making wrt devices not implementing the default security policy recommended by [IGD2]? There's this text in IGD2 that makes me a little happier: The InternetGatewayDevice MUST support IGD Specific security as defined in section 2.3, but MAY implement stricter security policy. But then, there's this bit in s2.3 that seems to be a bit contradictory: This document RECOMMENDS the default access level to be applied for each action of the legacy services (version 1 and version 2). In other words, this document does NOT REQUIRE that a vendor MUST implement the access level defined in this document for each action of his InternetGatewayDevice:2 implementation. As a result, vendors are allowed to implement different access control policies than defined in this document. For example, a vendor can decide to set a Public access level for opening port mappings with ports lower than or equal to 1023 instead of a Basic access level. 1) My assumption is that your models are the 3-box models because you want access control applied based on the SHOULD [IGD2]. But, I really can't tell. 2) I think the bit about: Means to prevent a malicious user from creating mappings on behalf of a third party must be enabled as discussed in Section 13.1 of [I-D.ietf-pcp-base]. The reason IGD2 is the SHOULD because then you've got ACLs - right? But, in reality is the LAN trusted almost all of the time? 3) In s7, please elaborate on why it's SHOULD NOT: When only IGD:1 is available, operation on the behalf of a third party SHOULD NOT be allowed because there's no authorization supported in IGD:1. That's my suggestion, but doesn't the desire to have IGD2 because of it's authorization model mean that maybe this protocol isn't applicable to IGD1? |
2013-04-25
|
09 | Sean Turner | [Ballot comment] 0) I found the authorization framework and authentication options in other documents referenced by [IGD2], but I did find them so I'm thinking … [Ballot comment] 0) I found the authorization framework and authentication options in other documents referenced by [IGD2], but I did find them so I'm thinking it's probably okay to not add more references. (no action required) 1) If the UPnP control point is the IGD control point, can we use the same term in all the figures? 2) Why not reference: [DeviceProtection] – UPnP DeviceProtection:1, version 1.0, UPnP Forum, February 24, 2011. Available at: http://upnp.org/specs/gw/UPnP-gw-DeviceProtection-v1-Service.pdf. |
2013-04-25
|
09 | Sean Turner | [Ballot Position Update] New position, Discuss, has been recorded for Sean Turner |
2013-04-25
|
09 | Stewart Bryant | [Ballot comment] I am puzzled about the inconsistency between the terminology on slide 2, and that in slide 3 & 4. Why has a Client … [Ballot comment] I am puzzled about the inconsistency between the terminology on slide 2, and that in slide 3 & 4. Why has a Client become a Local Host and a Host become a Remote Host? Note 'Host' is defined in the text as a remote peer reachable in the Internet. |
2013-04-25
|
09 | Stewart Bryant | [Ballot Position Update] New position, No Objection, has been recorded for Stewart Bryant |
2013-04-25
|
09 | Benoît Claise | [Ballot Position Update] New position, No Objection, has been recorded for Benoit Claise |
2013-04-24
|
09 | Joel Jaeggli | [Ballot Position Update] New position, No Objection, has been recorded for Joel Jaeggli |
2013-04-24
|
09 | Richard Barnes | [Ballot comment] Thanks, this looks like a very clearly written document. The flow diagrams help a lot. One minor thing: It would be helpful for … [Ballot comment] Thanks, this looks like a very clearly written document. The flow diagrams help a lot. One minor thing: It would be helpful for terminology to be consistent between Figures 2/3/4. For example, Client vs. Local Host, and Host vs. Peer. Also, the "PREFER_FAILURE" option makes me laugh :) |
2013-04-24
|
09 | Richard Barnes | [Ballot Position Update] New position, No Objection, has been recorded for Richard Barnes |
2013-04-24
|
09 | Pete Resnick | [Ballot Position Update] New position, No Objection, has been recorded for Pete Resnick |
2013-04-24
|
09 | Barry Leiba | [Ballot Position Update] New position, No Objection, has been recorded for Barry Leiba |
2013-04-24
|
09 | Martin Stiemerling | [Ballot discuss] Thank you for addressing my concerns so far and we are converging (based on draft version -09): 1) Ok, fixed. 2) Ok, fixed. … [Ballot discuss] Thank you for addressing my concerns so far and we are converging (based on draft version -09): 1) Ok, fixed. 2) Ok, fixed. 3) Ok, fixed. 4) Ok, fixed. 5) Section 5.3., paragraph 1: > The IGD-PCP IWF MUST store locally all the mappings instantiated by > internal UPnP Control Points in the PCP Server. All mappings SHOULD > be stored in permanent storage. Are there timeouts specified for each table entry? I have not seen any information about it, despite the fact that IGD and PCP have timeouts. How are those timeouts handled? Section 5.9 describes how the protocol is used to emulate finite and infinite lifetimes, but there is no linking between what's in Section 5.9 and the Port Mapping Table in Section 5.3. Probably, only a bit of text in Section 5.3 is missing on what timers are kept per table entry and also to make the linking to Section 5.9. 6) Ok, fixed 7) Section 5.6.2.: > 1. If a short lifetime error is returned, the IGD-PCP IWF MAY resend > the same request to the PCP Server after 30 seconds without > relaying the error to the UPnP Control Point. The IGD-PCP IWF > MAY repeat this process until a positive answer is received or > some maximum retry limit is reached. When the maximum retry > limit is reached, the IGD-PCP IWF relays a negative message to > the UPnP Control Point with ConflictInMappingEntry as the error > code. What is the maximum retry limit? Is it specified, implementation specific or what? I can understand that this is implementation specific for a stand-alone PCP client, but those parameters are the key of IWF, if they are expected to have predictable behavior. No information about the maximum retry limit is leaving the implementer alone and I would give some useful recommendation to that limit. For instance, a UPnP control point might resend its AddPortMapping() request after some time and the IWF should give a reply (postive or negative) before the UPnP entity is resending its request. I.e., there can be a relationship between the retry limit and when UPnP implementations are re-sending requests. 8) Section 5.7., paragraph 3: > Upon receipt of GetSpecificPortMappingEntry() from a UPnP Control > Point, the IGD-PCP IWF MUST check first if the external port number > is used by the requesting UPnP Control Point. If the external port > is already in use by the requesting UPnP Control Point, the IGD-PCP > IWF MUST send back a positive answer. If not, the IGD-PCP IWF MUST What is this 'positive answer' in UPnP terms? Can you replace the 'positive answer' by 'sending back the mapping entry matching...'? 9) Section 5.7., paragraph 4: > relay to the PCP Server a MAP request, with short lifetime (e.g., 60 > seconds), including a PREFER_FAILURE Option. If the requested > external port is in use, a PCP error message will be sent by the PCP > Server to the IGD-PCP IWF indicating CANNOT_PROVIDE_EXTERNAL as the > error cause. Then, the IGD-PCP IWF relays a negative message to the > UPnP Control Point. If the port is not in use, the mapping will be > created by the PCP Server and a positive response will be sent back > to the IGD-PCP IWF. Once received by the IGD-PCP IWF, it MUST relay > a negative message to the UPnP Control Point indicating > NoSuchEntryInArray as the error code so that the UPnP control point > knows the queried mapping doesn't exist. What happens to the established binding at the PCP server? It is requested for a short time, though 60s might not be considered short, and is still around even though it is not needed anymore. Isn't this a potential security issue, as a UPnP Control Point can issue a large number of ' GetSpecificPortMappingEntry()' requests that cause the PCP server to potentially maintain a lot of bindings for 60s or so? I've understand why and how this works, but my point is that a UPnP control point can issue a lot of etSpecificPortMappingEntry() requests in a shorter time frame that will create a lot of state of the PCP server. My recommendation is to document this as a potential security issue. 10) Ok, fixed. 11) Ok, fixed. 12) Section 5.8., paragraph 10: > The IWF MAY send a positive answer to the requesting UPnP Control > Point without waiting to receive all the answers from the PCP > Server. It is unlikely to encounter a problem in the PCP leg > because the IWF has verified authorization rights and also the > presence of the mapping in the local table. 'It is unlikely...' is not a proper statement for Standards Tracks. What is the expected behavior if the PCP leg is not doing what it is expected. It is correct that there shouldn't be an error if all authorization rights are correct, but why is the text saying 'it is unlikely' if this cannot happen? The phase 'it is unlikely' hints to the fact that something can go wrong. I would clarify that this step assumes that authorization is checked and ok and that justifies sending the reply already, unless there is some pitfall that isn't documented here. 13) Section 5.10., paragraph 2: > Upon change of the external IP address of the IWF, the IWF MAY renew > the mappings it maintained. This can be achieved only if a full > state table is maintained by the IWF. If the port quota is not > exceeded in the PCP server, the IWF will receive a new external IP > address and port numbers. The IWF has no means to notify the change > of the external IP address and port to internal UPnP Control Points. > Stale mappings will be maintained by the PCP Server until their > lifetime expires. This change of the external IP address has a number of side effects and the text looks 'easy' in doing this, but in realty this becomes very difficult. For instance, a change of the external IP address at the IGD will terminate all ongoing TCP connections between IGD/NAT1 and the CGN. It is at least worth documenting that this is effort on the PCP side but can have nonetheless very negative impact on the data path. Probably it would be the best to document this in some sort of operational considerations. Or at least a statement that says something along these lines: "Even though the IWF might be able to maintain the external mappings at the PCP server and the NAT of the IGD, the data plane between the PCP server's NAT and the NAT of the IGD might experience severe issues, such as TCP connections that will be reset." |
2013-04-24
|
09 | Martin Stiemerling | Ballot comment and discuss text updated for Martin Stiemerling |
2013-04-24
|
09 | Mohamed Boucadair | New version available: draft-ietf-pcp-upnp-igd-interworking-09.txt |
2013-04-24
|
08 | Peter Yee | Request for Telechat review by GENART Completed: Ready. Reviewer: Peter Yee. |
2013-04-24
|
08 | Jari Arkko | [Ballot Position Update] New position, No Objection, has been recorded for Jari Arkko |
2013-04-23
|
08 | Adrian Farrel | [Ballot comment] I am balloting No Objection on this document on the strength of the sponsoring AD's review and the document's apparent non-impact on the … [Ballot comment] I am balloting No Objection on this document on the strength of the sponsoring AD's review and the document's apparent non-impact on the routing system. --- From the shepherd write-up: The PCP WG has a policy to not send a document until the WG has consensus and there are at least 5 people who have reviewed and ok'ed the document. Many others were involved in reviews of earlier versions, but the WGLC oks came from: Xiaohong Deng Dave Thaler Reinaldo Penno Tiru Reddy Paul Selkirk Noting that one of the five is an author :-) |
2013-04-23
|
08 | Adrian Farrel | [Ballot Position Update] New position, No Objection, has been recorded for Adrian Farrel |
2013-04-23
|
08 | Brian Haberman | [Ballot comment] The changes proposed in response to Martin's DISCUSS resolve my concerns with the document. |
2013-04-23
|
08 | Brian Haberman | Ballot comment text updated for Brian Haberman |
2013-04-22
|
08 | Brian Haberman | [Ballot comment] I agree with much of Martin's DISCUSS points on the status of this document. It could easily be written as an Informational RFC … [Ballot comment] I agree with much of Martin's DISCUSS points on the status of this document. It could easily be written as an Informational RFC (without the gratuitous use of 2119 keywords) that describes how interwork UPnP and PCP. |
2013-04-22
|
08 | Brian Haberman | Ballot comment text updated for Brian Haberman |
2013-04-22
|
08 | Brian Haberman | [Ballot Position Update] New position, No Objection, has been recorded for Brian Haberman |
2013-04-22
|
08 | Martin Stiemerling | [Ballot discuss] I have an objection to publish this draft as Standards Track in the current shape and also in general, as I believe that … [Ballot discuss] I have an objection to publish this draft as Standards Track in the current shape and also in general, as I believe that this type of interworking specification is on an informational level. The content is potentially very implementation specific and does not have protocol characteristics. 1) Is it required to read through the UPnP documents to understand the details of the IWF. Therefore, IGD1 and IGD2 are normative references. 2) Section 4.1., paragraph 5: > The UPnP IGD-PCP Interworking Function simulates long and even > infinite lifetimes using renewals (see Section 5.9). The behavior > in the case of a failing renewal is currently undefined. I am lost about what exactly is undefined in this case? Is it the behavior of UPNP or the IW? 3) Section 4.3: > 1 UNSUPP_VERSION: 501 "ActionFailed" > Should not happen. The information 'Should not happen' does not provide any information. Errors should not happen, but they happen nonetheless. What is the information here? This holds also true for the other 'Should not happen' in this section. To achieve interoperability it is necessary required to specify what happens in all possible cases. and similar here Section 4.3 > 13 EXCESSIVE_REMOTE_PEERS: 501 "ActionFailed" > Should not happen, since the IGD-PCP Interworking Function should > not need to use the FILTER option. This is a more than weak and confusing statement for a Standards Track specification. 4) Section 4.3: > 7 NETWORK_FAILURE: Not applicable > Should not happen after communication has been successfully > established with a PCP Server. Any disruption in the communication with the PCP server can happen quite frequently, e.g., every 24 hours on a DSL line, if the DSL line is disconnected by the operator. What is the reaction to such an error? 5) Section 5.3., paragraph 1: > The IGD-PCP IWF MUST store locally all the mappings instantiated by > internal UPnP Control Points in the PCP Server. All mappings SHOULD > be stored in permanent storage. Are there timeouts specified for each table entry? I have not seen any information about it, despite the fact that IGD and PCP have timeouts. How are those timeouts handled? 6) Section 5.6.1., paragraph 2: > If a PCP Error is received from the PCP Server, a corresponding > WANIPConnection error code (see Section 4.3) is generated by the IGD- > PCP IWF and sent to the requesting UPnP Control Point. If a short > lifetime error is returned (e.g., NETWORK_FAILURE, NO_RESOURCES), the > PCP IWF MAY resend the same request to the PCP Server after 30 > seconds. If a negative answer is received, the error is then relayed > to the requesting UPnP Control Point. What happens if no response is received or if the response is not readable by the PCP client? This is not specified. 7) Section 5.6.2.: > 1. If a short lifetime error is returned, the IGD-PCP IWF MAY resend > the same request to the PCP Server after 30 seconds without > relaying the error to the UPnP Control Point. The IGD-PCP IWF > MAY repeat this process until a positive answer is received or > some maximum retry limit is reached. When the maximum retry > limit is reached, the IGD-PCP IWF relays a negative message to > the UPnP Control Point with ConflictInMappingEntry as the error > code. What is the maximum retry limit? Is it specified, implementation specific or what? 8) Section 5.7., paragraph 3: > Upon receipt of GetSpecificPortMappingEntry() from a UPnP Control > Point, the IGD-PCP IWF MUST check first if the external port number > is used by the requesting UPnP Control Point. If the external port > is already in use by the requesting UPnP Control Point, the IGD-PCP > IWF MUST send back a positive answer. If not, the IGD-PCP IWF MUST What is this 'positive answer' in UPnP terms? 9) Section 5.7., paragraph 4: > relay to the PCP Server a MAP request, with short lifetime (e.g., 60 > seconds), including a PREFER_FAILURE Option. If the requested > external port is in use, a PCP error message will be sent by the PCP > Server to the IGD-PCP IWF indicating CANNOT_PROVIDE_EXTERNAL as the > error cause. Then, the IGD-PCP IWF relays a negative message to the > UPnP Control Point. If the port is not in use, the mapping will be > created by the PCP Server and a positive response will be sent back > to the IGD-PCP IWF. Once received by the IGD-PCP IWF, it MUST relay > a negative message to the UPnP Control Point indicating > NoSuchEntryInArray as the error code so that the UPnP control point > knows the queried mapping doesn't exist. What happens to the established binding at the PCP server? It is requested for a short time, though 60s might not be considered short, and is still around even though it is not needed anymore. Isn't this a potential security issue, as a UPnP Control Point can issue a large number of ' GetSpecificPortMappingEntry()' requests that cause the PCP server to potentially maintain a lot of bindings for 60s or so? 10) Section 5.8., paragraph 2: > In IGD:2, we assume the IGD applies the appropriate security policies > to determine whether a Control Point has the rights to delete one or > a set of mappings. When authorization fails, the "606 Action Not > Authorized" error code MUST be returned to the requesting Control > Point. Is this draft mandating what the UPnP part must do, i.e., sending a 606 error back? 11) Section 5.8., paragraph 8: > When a positive answer is received from the PCP Server, the IGD-PCP > IWF updates its local mapping table (i.e., removes the corresponding > entry) and notifies the UPnP Control Point about the result of the > removal operation. Once the PCP MAP delete request is received by > the PCP Server, it removes the corresponding entry. A PCP MAP > SUCCESS response is sent back if the removal of the corresponding > entry was successful; if not, a PCP Error is sent back to the IGD-PCP > IWF including the corresponding error cause (see Section 4.3). What happens if no response is received from the PCP server? 12) Section 5.8., paragraph 10: > The IWF MAY send a positive answer to the requesting UPnP Control > Point without waiting to receive all the answers from the PCP > Server. It is unlikely to encounter a problem in the PCP leg > because the IWF has verified authorization rights and also the > presence of the mapping in the local table. 'It is unlikely...' is not a proper statement for Standards Tracks. What is the expected behavior if the PCP leg is not doing what it is expected. 13) Section 5.10., paragraph 2: > Upon change of the external IP address of the IWF, the IWF MAY renew > the mappings it maintained. This can be achieved only if a full > state table is maintained by the IWF. If the port quota is not > exceeded in the PCP server, the IWF will receive a new external IP > address and port numbers. The IWF has no means to notify the change > of the external IP address and port to internal UPnP Control Points. > Stale mappings will be maintained by the PCP Server until their > lifetime expires. This change of the external IP address has a number of side effects and the text looks 'easy' in doing this, but in realty this becomes very difficult. For instance, a change of the external IP address at the IGD will terminate all ongoing TCP connections between IGD/NAT1 and the CGN. It is at least worth documenting that this is effort on the PCP side but can have nonetheless very negative impact on the data path. |
2013-04-22
|
08 | Martin Stiemerling | [Ballot comment] Section 3., paragraph 7: > Figure 2: UPnP IGD Model … [Ballot comment] Section 3., paragraph 7: > Figure 2: UPnP IGD Model Figure 3 has the Internet listed, but not Figure 2. Figure 3 says peer on the right hand side while all others say host Section 5, paragraph 0: > 5 UNSUPP_OPTION: 501 "ActionFailed" > Should not happen except if PREFER_FAILURE is not supported on the > PCP server. Note that PREFER_FAILURE is not mandatory to support, > but AddPortMapping() cannot be implemented without it. There are a number of places where this IW requires certain functionalities from UPnP or PCP. I recommend to add a section where those requirements are listed. Section 5.7., paragraph 2: > GetGenericPortMappingEntry() and GetListOfPortMappings() methods MUST > NOT be proxied to the PCP Server since a local mapping is maintained > by the IGD-PCP IWF. This section describes only the handling of the ' GetSpecificPortMappingEntry()'. What about the other two? Section 5.10., paragraph 1: > When the IWF is co-located with the DHCP server, the state maintained > by the IWF MUST be updated using the state in the local DHCP server. > Particularly, if an IP address expires or is released by an internal > host, the IWF MUST delete all the mappings bound to that internal IP > address. Isn't this going beyond the IWF, though it is useful advice for implementers. Section 7., paragraph 1: > The IGD:2 authorization framework SHOULD be used [IGD2]. When only > IGD:1 is available, operation on the behalf of a third party SHOULD > NOT be allowed. This draft gives guidance on IGD use which is out of scope IMHO. |
2013-04-22
|
08 | Martin Stiemerling | [Ballot Position Update] New position, Discuss, has been recorded for Martin Stiemerling |
2013-04-18
|
08 | Jean Mahoney | Request for Telechat review by GENART is assigned to Peter Yee |
2013-04-18
|
08 | Jean Mahoney | Request for Telechat review by GENART is assigned to Peter Yee |
2013-04-12
|
08 | Ted Lemon | Placed on agenda for telechat - 2013-04-25 |
2013-04-11
|
08 | Ted Lemon | State changed to IESG Evaluation from Waiting for AD Go-Ahead |
2013-04-11
|
08 | Ted Lemon | Ballot has been issued |
2013-04-11
|
08 | Ted Lemon | [Ballot Position Update] New position, Yes, has been recorded for Ted Lemon |
2013-04-11
|
08 | Ted Lemon | Created "Approve" ballot |
2013-04-11
|
08 | Ted Lemon | Ballot writeup was changed |
2013-04-10
|
08 | Mohamed Boucadair | New version available: draft-ietf-pcp-upnp-igd-interworking-08.txt |
2013-04-09
|
07 | Peter Yee | Request for Last Call review by GENART Completed: Ready with Issues. Reviewer: Peter Yee. |
2013-04-08
|
07 | (System) | State changed to Waiting for AD Go-Ahead from In Last Call |
2013-04-04
|
07 | (System) | IANA Review state changed to IANA OK - No Actions Needed from IANA - Review Needed |
2013-04-04
|
07 | Amanda Baber | IESG/Authors/WG Chairs: IANA has reviewed draft-ietf-pcp-upnp-igd-interworking-07, which is currently in Last Call, and has the following comments: We understand that this document doesn't require … IESG/Authors/WG Chairs: IANA has reviewed draft-ietf-pcp-upnp-igd-interworking-07, which is currently in Last Call, and has the following comments: We understand that this document doesn't require any IANA actions. If this assessment is not accurate, please respond as soon as possible. |
2013-03-29
|
07 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Vincent Roca |
2013-03-29
|
07 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Vincent Roca |
2013-03-28
|
07 | Jean Mahoney | Request for Last Call review by GENART is assigned to Peter Yee |
2013-03-28
|
07 | Jean Mahoney | Request for Last Call review by GENART is assigned to Peter Yee |
2013-03-25
|
07 | Amy Vezza | IANA Review state changed to IANA - Review Needed |
2013-03-25
|
07 | Amy Vezza | The following Last Call announcement was sent out: From: The IESG To: IETF-Announce CC: Reply-To: ietf@ietf.org Subject: Last Call: (Universal Plug and Play (UPnP) Internet … The following Last Call announcement was sent out: From: The IESG To: IETF-Announce CC: Reply-To: ietf@ietf.org Subject: Last Call: (Universal Plug and Play (UPnP) Internet Gateway Device (IGD)-Port Control Protocol (PCP) Interworking Function) to Proposed Standard The IESG has received a request from the Port Control Protocol WG (pcp) to consider the following document: - 'Universal Plug and Play (UPnP) Internet Gateway Device (IGD)-Port Control Protocol (PCP) Interworking Function' 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 2013-04-08. 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 the behavior of the UPnP IGD (Internet Gateway Device)/PCP Interworking Function. A UPnP IGD-PCP Interworking Function (IGD-PCP IWF) is required to be embedded in CP (Customer Premises) routers to allow for transparent NAT control in environments where UPnP IGD is used on the LAN side and PCP on the external side of the CP router. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-pcp-upnp-igd-interworking/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-pcp-upnp-igd-interworking/ballot/ No IPR declarations have been submitted directly on this I-D. |
2013-03-25
|
07 | Amy Vezza | State changed to In Last Call from Last Call Requested |
2013-03-25
|
07 | Ted Lemon | Last call was requested |
2013-03-25
|
07 | Ted Lemon | Last call announcement was generated |
2013-03-25
|
07 | Ted Lemon | Ballot approval text was generated |
2013-03-25
|
07 | Ted Lemon | Ballot writeup was generated |
2013-03-25
|
07 | Ted Lemon | I've thoroughly reviewed this document and the authors made a few minor updates for clarity; I think it's ready for last call and (assuming it … I've thoroughly reviewed this document and the authors made a few minor updates for clarity; I think it's ready for last call and (assuming it passes) IESG review. |
2013-03-25
|
07 | Ted Lemon | State changed to Last Call Requested from AD Evaluation |
2013-03-24
|
07 | Mohamed Boucadair | New version available: draft-ietf-pcp-upnp-igd-interworking-07.txt |
2013-03-13
|
06 | Cindy Morgan | Shepherding AD changed to Ted Lemon |
2013-03-11
|
06 | Ted Lemon | State changed to AD Evaluation from Publication Requested |
2013-03-04
|
06 | Cindy Morgan | (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? … (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, as noted in the PCP WG charter, since this is a protocol specification with WG consensus. Title page header does say Standards Track. (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 Relevant content can frequently be found in the abstract and/or introduction of the document. If not, this may be an indication that there are deficiencies in the abstract or introduction. This document specifies the behavior of the UPnP IGD (Internet Gateway Device)/PCP Interworking Function. A UPnP IGD-PCP Interworking Function (IGD-PCP IWF) is required to be embedded in CP (Customer Premises) routers to allow for transparent NAT control in environments where UPnP IGD is used on the LAN side and PCP on the external side of the CP router. 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? Nothing unusual. 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? But representatives of a number of potential implementations have been involved in authoring and/or reviewing the document. A public implementation is available at http://sourceforge.net/projects/pcpclient/?source=directory. The authors are also aware of other implementations from some CPE vendors that are not yet disclosed publically. The PCP WG has a policy to not send a document until the WG has consensus and there are at least 5 people who have reviewed and ok'ed the document. Many others were involved in reviews of earlier versions, but the WGLC oks came from: Xiaohong Deng Dave Thaler Reinaldo Penno Tiru Reddy Paul Selkirk The above reviewers collectively represent multiple implementations or potential future implementations. Personnel Who is the Document Shepherd? Dave Thaler Who is the Responsible Area Director? Ralph Droms (outgoing), Ted Lemon (incoming) (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 Document Shepherd: 1) compared the spec against the UPnP-IGD protocol reference to verify that all UPnP-IGD fields were appropriately handled and nothing was missed. 2) reviewed the document for readability 3) reviewed the document from an implementability standpoint (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? No concerns. (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. No additional review expected. The document does not modify the behavior of, or use messages of, DNS, DHCP, etc. The document does not use text strings, hence no internationalization issues. (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. No concerns. (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 disclosures filed. (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 as a whole understands it and has consensus on it. The primary points of discussion centered around the fact that PCP is soft state (must be refreshed before expiration) whereas UPnP-IGD is hard state (doesn't expire until deleted), and so proxying between them is only best effort. This is a limitation of UPnP-IGD and the WG has consensus that the document takes a reasonable approach given this underlying limitation. (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.) No appeals threatened. (11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. No errors found, just warnings that are expected. That is, the following are due to the version having being posted in December. == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (December 19, 2012) is 73 days in the past. Is this intentional? == Outdated reference: A later version (-05) exists of draft-boucadair-pcp-failure-04 == Outdated reference: A later version (-06) exists of draft-ietf-pcp-dhcp-05 == Outdated reference: A later version (-02) exists of draft-ietf-pcp-proxy-01 (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. No formal review criteria as this is not a MIB, media type, URI type, etc. (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? It only normatively references RFC 2119, and draft-ietf-pcp-base which is currently in AUTH48. (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. No downward normative references. (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. No change to the status of any existing RFCs. (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). This document makes no request of IANA and the IANA considerations section may be removed on publication. The Document Shepherd verified that the document doesn't need any request of IANA. (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. No new IANA registries needed. (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. No formal language exists in the document to verify. |
2013-03-04
|
06 | Cindy Morgan | Note added 'Dave Thaler (dthaler@microsoft.com) is the document shepherd.' |
2013-03-04
|
06 | Cindy Morgan | Intended Status changed to Proposed Standard |
2013-03-04
|
06 | Cindy Morgan | IESG process started in state Publication Requested |
2012-12-19
|
06 | Mohamed Boucadair | New version available: draft-ietf-pcp-upnp-igd-interworking-06.txt |
2012-11-07
|
05 | Mohamed Boucadair | New version available: draft-ietf-pcp-upnp-igd-interworking-05.txt |
2012-09-23
|
04 | Mohamed Boucadair | New version available: draft-ietf-pcp-upnp-igd-interworking-04.txt |
2012-09-14
|
03 | Mohamed Boucadair | New version available: draft-ietf-pcp-upnp-igd-interworking-03.txt |
2012-08-03
|
02 | Mohamed Boucadair | New version available: draft-ietf-pcp-upnp-igd-interworking-02.txt |
2012-03-12
|
01 | Mohamed Boucadair | New version available: draft-ietf-pcp-upnp-igd-interworking-01.txt |
2011-11-21
|
00 | (System) | New version available: draft-ietf-pcp-upnp-igd-interworking-00.txt |