Re: [pcp] New Version Notification for draft-ripke-pcp-tunnel-id-option-01.txt

[Andreas Ripke <[e-mail]>]

Hi Med,

Thanks for the hint on UPnP relay. This might not be necessary.
Apparently, we have to describe the scenario in more detail.

Best,

Andreas

> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]]
> Sent: Wednesday, July 09, 2014 4:27 PM
> To: Andreas Ripke; [e-mail]
> Subject: RE: New Version Notification for draft-ripke-pcp-tunnel-id-option-
> 01.txt
> 
> Re-,
> 
> Please see inline.
> 
> Cheers,
> Med
> 
> >-----Message d'origine-----
> >De : Andreas Ripke [mailto:[e-mail]] Envoyé : mercredi 9
> >juillet 2014 12:02 À : BOUCADAIR Mohamed IMT/OLN; [e-mail] Objet :
> >RE: New Version Notification for draft-ripke-pcp-tunnel-id-option-
> >01.txt
> >
> >Hi Med,
> >
> >Thanks for your comments.
> >
> >Our scenario is a supplement to situations when PCP is not yet on hand
> >in the subscriber realm.
> >The carrier IWF is offered as a service to the subscribers.
> >It does not prevent subscribers to directly use PCP to control ports on
> >the CGN.
> 
> [Med] But how the CPE will decide to leak UPnP IGD outside the LAN?
> Shouldn't this require an upgrade of the CPE to support some "kind" of UPnP
> IGD relay?
> 
> >
> >And thanks for your pointer to your pcp-sfc draft.
> >It looks like the PCP TUNNEL_ID option aligns to this direction of an
> >extension proposal.
> >
> >The decision we called the new option TUNNEL_ID was driven by the given
> >scenario.
> >Yes, it might be an idea to change and generalize the option name to ID
> >instead of TUNNEL_ID.
> 
> [Med] Great!
> 
> >
> >Best,
> >
> >Andreas
> >
> >> -----Original Message-----
> >> From: [e-mail]
> >> [mailto:[e-mail]]
> >> Sent: Wednesday, July 09, 2014 10:42 AM
> >> To: Andreas Ripke; [e-mail]
> >> Subject: RE: New Version Notification for draft-ripke-pcp-tunnel-id-
> >option-
> >> 01.txt
> >>
> >> Hi Andreas,
> >>
> >> Thank you for sharing this updated version of the document.
> >>
> >> I'm not sure about the carrier-hosted IWF because one of the
> >> motivations for PCP to avoid overloading the carrier network with a
> chatty protocol.
> >>
> >> FWIW, I have identified in this document as case that require an
> >> identification information that cannot be included in a THIRD_PARTY
> >option:
> >> http://tools.ietf.org/html/draft-boucadair-pcp-sfc-classifier-control-00
> >> "   o  Extended THIRD_PARTY option to include a L2 identifier (e.g., MAC
> >>       address), an opaque subscriber-identifier, an IMSI, etc."
> >>
> >> I suggest you change TUNNEL_ID to something that won't mislead the
> >> reader that a tunneling technique is always in place when this option
> >> is
> >in
> >> use.
> >>
> >> Cheers,
> >> Med
> >>
> >> >-----Message d'origine-----
> >> >De : pcp [mailto:[e-mail]] De la part de Andreas Ripke
> >> >Envoyé : vendredi 4 juillet 2014 13:05 À : [e-mail] Objet :
> >> >[pcp]
> >> >FW: New Version Notification for draft-ripke-pcp-tunnel-id-
> >> >option-01.txt
> >> >
> >> >Dear all,
> >> >
> >> >Thank you for all the feedback we received at the last meeting on
> >> >the TUNNEL_ID option. This was very helpful. We have updated our
> >> >draft accordingly and aligned our use case with use cases from
> >> >existing PCP drafts/RFCs. Particularly we moved the focus from a
> >> >rather static web portal scenario to a more dynamic UPnP Interworking
> scenario.
> >> >
> >> >http://www.ietf.org/internet-drafts/draft-ripke-pcp-tunnel-id-option
> >> >-01
> >> >.txt
> >> >
> >> >Please have a look at the draft and give us your feedback.
> >> >
> >> >Best regards,
> >> >
> >> >Andreas
> >> >
> >> >
> >> >NEC Europe Ltd | Registered Office: Athene, Odyssey Business Park,
> >> >West End Road, London, HA4 6QE, GB | Registered in England 2832014
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >A new version of I-D, draft-ripke-pcp-tunnel-id-option-01.txt
> >> >has been successfully submitted by Andreas Ripke and posted to the
> >> >IETF repository.
> >> >
> >> >Name:		draft-ripke-pcp-tunnel-id-option
> >> >Revision:	01
> >> >Title:		PCP Tunnel-ID Option
> >> >Document date:	2014-07-03
> >> >Group:		Individual Submission
> >> >Pages:		10
> >> >URL:            http://www.ietf.org/internet-drafts/draft-ripke-pcp-
> >tunnel-
> >> >id-option-01.txt
> >> >Status:         https://datatracker.ietf.org/doc/draft-ripke-pcp-tunnel-
> >id-
> >> >option/
> >> >Htmlized:       http://tools.ietf.org/html/draft-ripke-pcp-tunnel-id-
> >> >option-01
> >> >Diff:           http://www.ietf.org/rfcdiff?url2=draft-ripke-pcp-tunnel-
> >id-
> >> >option-01
> >> >
> >> >Abstract:
> >> >   This document describes a new Port Control Protocol (PCP) option
> >> >   called TUNNEL_ID.  It serves for identifying a Third Party in
> >> >   addition to the means that PCP's THIRD_PARTY option already provides
> >> >   for that purpose.
> >> >
> >> >
> >> >
> >> >
> >> >Please note that it may take a couple of minutes from the time of
> >> >submission until the htmlized version and diff are available at
> >> >tools.ietf.org.
> >> >
> >> >The IETF Secretariat
> >> >
> >> >_______________________________________________
> >> >pcp mailing list
> >> >[e-mail]
> >> >https://www.ietf.org/mailman/listinfo/pcp