Re: [Pce] PCE WG Last Call - draft-ietf-pce-pceps-04

Hi Cyril, WG,

Here are the proposed changes  –

OLD:
   If the PCEP speaker supports PCEPS but cannot establish a TLS
   connection for some reason (e.g. the certificate server is not
   responding) it MUST return a PCErr message with Error-Type set to xx
   (TBA by IANA) (PCEP StartTLS failure) and Error-value set to:

   o  3 (not without TLS) if it is not willing to exchange PCEP messages
      without the solicited TLS connection.

   o  4 (ok without TLS) if it is willing to exchange PCEP messages
      without the solicited TLS connection.
NEW:
   If the PCEP speaker supports PCEPS but cannot establish a TLS
   connection for some reason (e.g. the certificate server is not
   responding) it MUST return a PCErr message with Error-Type set to xx
   (TBA by IANA) (PCEP StartTLS failure) and Error-value set to:

   o  3 (not without TLS) if it is not willing to exchange PCEP messages
      without the solicited TLS connection and it MUST close the TCP
      session.

   o  4 (ok without TLS) if it is willing to exchange PCEP messages
      without the solicited TLS connection and it MUST close the TCP
      session. The peer MAY choose to re-establish PCEP session
      without TLS next.

We can also clarify the behavior for error-value 1 and 2 as well –

OLD:
   A PCEP speaker receiving a StartTLS message after any other PCEP
   exchange has taken place (by receiving or sending any other messages
   from either side) MUST treat it as an unexpected message and reply
   with a PCErr message with Error-Type set to xx (TBA by IANA)(PCEP
   StartTLS failure) and Error-value set to 1 (reception of StartTLS
   after any PCEP exchange).  A PCEP speaker receives any other message
   apart from StartTLS or PCErr MUST treat it as an unexpected message
   and reply with a PCErr message with Error-Type set to xx (TBA by
   IANA)(PCEP StartTLS failure) and Error-value set to 2 (reception of
   non-StartTLS or non-PCErr message).
NEW:
   A PCEP speaker receiving a StartTLS message after any other PCEP
   exchange has taken place (by receiving or sending any other messages
   from either side) MUST treat it as an unexpected message and reply
   with a PCErr message with Error-Type set to xx (TBA by IANA)(PCEP
   StartTLS failure) and Error-value set to 1 (reception of StartTLS
   after any PCEP exchange) and MUST close the TCP
   session.  A PCEP speaker receives any other message
   apart from StartTLS or PCErr MUST treat it as an unexpected message
   and reply with a PCErr message with Error-Type set to xx (TBA by
   IANA)(PCEP StartTLS failure) and Error-value set to 2 (reception of
   non-StartTLS or non-PCErr message) and MUST close the TCP session.

Thanks you for your review!

Regards,
Dhruv

From: Pce [mailto:pce-bounces@ietf.org] On Behalf Of DIEGO LOPEZ GARCIA
Sent: 03 November 2015 09:52
To: Dhruv Dhody
Cc: pce@ietf.org; Cyril Margaria
Subject: Re: [Pce] PCE WG Last Call - draft-ietf-pce-pceps-04

Hi,

Indeed. Thanks for the comments Cyril.

I have just uploaded a new version with a few cosmetic changes to deal with the expiration deadline. We’ll discuss how to address your comments and have a new version anytime soon.

Be goode,

On 2 Nov 2015, at 11:16 , Dhruv Dhody <dhruv.ietf@gmail.com<mailto:dhruv.ietf@gmail.com>> wrote:

Hi Cyril,

Thanks for your review and comments. Much Appreciated.

Let me sink up with my co-authors and reply to you with a proposed text.

Regards,
Dhruv

On Mon, Nov 2, 2015 at 2:07 AM, Cyril Margaria <cyril.margaria@gmail.com<mailto:cyril.margaria@gmail.com>> wrote:
I have reviewed the id.
I think the document describes well the TLS  procedure.
I have the following comments/questions on the nonTLS support: what should a PCE peer  do when the error code "pcep startTLS failure" and error value 3 or 4.
For error value 3 i believe closing the connection shoud be done
For error code 4 (ok without TLS) should the peer:
A)Continue without TLS at all
B) close and reconnect without using tls
A) would require more descrption of that case. B) would require the peer to retry without tls or require a reconfiguration. The reconnect introduces more states (how long to keep retrying withiut tls,... etc)
I think those points should be specified.
Best regards
Cyril
On Oct 8, 2015 18:57, "JP Vasseur (jvasseur)" <jvasseur@cisco.com<mailto:jvasseur@cisco.com>> wrote:
Dear WG,

This starts a 2-week WG Last Call on draft-ietf-pce-pceps-04, ending on Oct 23 at noon ET. Please send your comments to the authors and copy the list.

Thanks.

JP, Julien and Jon.

_______________________________________________
Pce mailing list
Pce@ietf.org<mailto:Pce@ietf.org>
https://www.ietf.org/mailman/listinfo/pce

_______________________________________________
Pce mailing list
Pce@ietf.org<mailto:Pce@ietf.org>
https://www.ietf.org/mailman/listinfo/pce

_______________________________________________
Pce mailing list
Pce@ietf.org<mailto:Pce@ietf.org>
https://www.ietf.org/mailman/listinfo/pce

--
"Esta vez no fallaremos, Doctor Infierno"

Dr Diego R. Lopez
Telefonica I+D
http://people.tid.es/diego.lopez/

e-mail: diego.r.lopez@telefonica.com<mailto:diego.r.lopez@telefonica.com>
Tel:    +34 913 129 041
Mobile: +34 682 051 091
----------------------------------

________________________________

Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede contener información privilegiada o confidencial y es para uso exclusivo de la persona o entidad de destino. Si no es usted. el destinatario indicado, queda notificado de que la lectura, utilización, divulgación y/o copia sin autorización puede estar prohibida en virtud de la legislación vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma vía y proceda a su destrucción.

The information contained in this transmission is privileged and confidential information intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this transmission in error, do not read it. Please immediately reply to the sender that you have received this communication in error and then delete it.

Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário, pode conter informação privilegiada ou confidencial e é para uso exclusivo da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário indicado, fica notificado de que a leitura, utilização, divulgação e/ou cópia sem autorização pode estar proibida em virtude da legislação vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e proceda a sua destruição