Skip to main content

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