Re: [pcp] WG last call on draft-ietf-pcp-upnp-igd-interworking-01

[Dave Thaler <[e-mail]>]

A marked up version with my full comments is available at:
http://research.microsoft.com/~dthaler/draft-ietf-pcp-upnp-igd-interworking-01.pdf

A summary of the main non-editorial issues follows:

1) The UPnP IGD state variables and methods fall into two categories: those
relevant to port mapping, and those not relevant to port mapping.   Currently
some the latter are listed as "not applicable", some are omitted from the document,
and of those not omitted, I think some of the statements aren't correct.   Instead,
I think this doc should be scoped to only discussion of the first category and say
the rest are covered in [IGD2], without enumerating them.   And I think we should
also say that an IGD with the IWF MUST be compliant to [IGD2].   I believe that
will maximize the chance of interoperability with UPnP-IGD clients.

2) The doc currently assumes that there's only one ExternalIPAddress.   I don't
think that's as scalable, and it's certainly not required by the PCP protocol.
Instead, I think we should explicitly state that the ExternalIPAddress should be stored
on a per control-point basis, so that different control points could see different 
values.   Each value comes from the PCP responses for mappings for that control point.
This means that just because there's a collision in external port for some other
control point doesn't mean that adding a mapping will fail.   It would only fail
if that other control point used the same ExternalIPAddress as the requesting one.
If the requesting control point hadn't yet been assigned an ExternalIPAddress, then
the request should be relayed to the PCP server(s).    [See also my comment #10
on the pcp-dhcp draft.]    Section 11.3 of the pcp-base spec already has logic where
the server will accept a port MAP request even when one IP already has a mapping,
as long as it has another available external IP that can service the request.

3) It would be good to add a paragraph, say in the discussion of Figure 4 
(Cascaded NAT scenario), explaining that without the PCP IWF, the control point
would see an "ExternalIPAddress" and port of the WAN link between the IGD
and NAT2, not the public address/port on the Internet.   With the PCP IWF,
the control point will instead see the public address/port on the Internet.
It will no longer see the intermediate address/port between the IGD and
NAT2, even though it would be useful for communication with another
host  behind the same NAT2 but not behind the IGD.   Such learning is not
supported, and so it would be good to point that out.   This helps the reader
understand the point of the rest of the logic.

4) Renewals are mentioned in passing under the "PortMappingLeaseDuration"
state variable.   However the behavior is never specified.   This should be added
as a new section 5.10.

5) The assumption in UPnP-IGD is that GetSpecificPortMappingEntry() can not
return something that wouldn't be returned by GetGenericPortMappingEntry()
and GetListOfPortMappings().   Section 5.8 breaks that, without giving any justification.
That is, it says GetListOfPortMappings and GetGenericPortMappingEntry are
served locally, never relayed, but that GetSpecificPortMappingEntry can be
relayed when no mapping is found.   This is inconsistent.  I think it should be
handled locally as well, to retain consistency.   Yes that means you can't use
it to look up third party information about other IGDs.   And that's a good thing.

-Dave

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf Of Dave
> Thaler
> Sent: Friday, July 13, 2012 1:08 PM
> To: [e-mail]
> Subject: [pcp] WG last call on draft-ietf-pcp-upnp-igd-interworking-01
> 
> From the IETF 83 minutes:
> > 1330-1340 UPnP-IGD Interworking Function             (Mohamed Boucadair, 10)
> >           Document: draft-ietf-pcp-upnp-igd-interworking-01
> >           Slides: http://www.ietf.org/proceedings/83/slides/slides-83-pcp-1.pdf
> >
> > Any objections to starting a WG Last Call on this?
> > Francis objected that the issue of an IGD client that asks for a lifetime
> >     longer than the PCP server is willing to grant can never be solved,
> >     and therefore the entire work item is futile.
> > Dave: This is an issue, but not an open issue.
> > Dave: will confer with Alain about whether to start WG Last Call.
> 
> The chairs have agreed to start a WG last call.   We've seen no additional
> discussion on this draft since last IETF, so this email initiates a last call on
> draft-ietf-pcp-upnp-igd-interworking-01.   This call will conclude in two
> weeks (Friday July 27th), just prior to IETF.   Hopefully that will allow
> for discussion of WGLC comments in Vancouver.
> 
> We need at least 5 reviewers.  Please send comments to the list.
> 
> Thanks,
> -Dave
> 
> 
> 
> 
> _______________________________________________
> pcp mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/pcp