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

[Andreas Ripke <[e-mail]>]

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.

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.

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