Subject: [v6ops] draft-ietf-v6ops-rfc7084-bis-01

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Thu, 13 Apr 2017 12:04:40 +0200

(changed subject to focus in the actual version and discussion)

Hi Barbara,

I see your point and I understand it, but I’ve done the following to make sure that there is no discrepancy.

1) I’ve re-read with a lot of care RFC5569 (6rd), RFC3056 (6to4), RFC2893 and RFC4213.
2) I’ve also searched for MAY, SHOULD, MUST, etc., and other “picky” text in those documents.
3) I’ve concluded that there is nothing that any of those documents is requiring that is not already part of the 6rd requirements.

It will be nice if someone else can reassess that, so is not just me …

If that’s the case, and even more, considering that the complete section is a MAY, I don’t see how this will conflict with your actual RFQs, etc.?

Regards,
Jordi

-----Mensaje original-----
De: "STARK, BARBARA H" <[email-masked]>
Responder a: <[email-masked]>
Fecha: miércoles, 12 de abril de 2017, 21:20
Para: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Asunto: RE: [v6ops] LISP support for draft-ietf-v6ops-rfc7084-bis-00

    > RFC5569 (6rd) is referring to 6to4 encapsulation (RFC3065), which is referring
    > to RFC2893 (6in4, protocol 41), which has been updated by RFC4213.
    > 
    > We are talking about the same.
    > 
    > If you have a 6to4 router at home, you can just try. Create a HE tunnel
    > broker, and input manually the parameters even if your router only shows a
    > 6rd in the GUI. It works. Believe me.
    
    What I think I hear you saying is:
    If a CE router implements RFC 5569, then the access network can use the CE router's RFC 5569 functionality to deliver a RFC 4213 tunnel.
    
    If this is correct, then what I'm saying is I will not support a requirement that dictates I and my CE router vendors (who implement 6rd) MUST look at or read  or scour RFC 4213 to see if there is some additional requirement that RFC 4213 introduces, because they are now required to be compliant with it. The reference to RFC 5569 SHALL be sufficient to direct implementation of the functionality, with no reference to RFC 4213.
    UI requirements are out of scope.
    Barbara

**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.consulintel.es
The IPv6 Company

This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.

---

From: [email-masked]
Date: Thu, 13 Apr 2017 12:35:18 +0200

Jordi,

> 1) I’ve re-read with a lot of care RFC5569 (6rd), RFC3056 (6to4), RFC2893 and RFC4213.

6RD is specified in RFC5969.

> If that’s the case, and even more, considering that the complete section is a MAY, I don’t see how this will conflict with your actual RFQs, etc.?

It doesn't appear to me that anyone else but you want to include configured tunnels.

Cheers,
Ole

> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Thu, 13 Apr 2017 12:40:54 +0200

Yes, sorry, typo in my original email about this that carried over the following. I’ve been talking all the time about the RFC5969, not the informational version.

Saludos,
Jordi

-----Mensaje original-----
De: <[email-masked]>
Responder a: <[email-masked]>
Fecha: jueves, 13 de abril de 2017, 12:35
Para: <[email-masked]>
CC: "[email-masked]" <[email-masked]>
Asunto: Re: [v6ops] draft-ietf-v6ops-rfc7084-bis-01

    Jordi,

    

    Cheers,
    Ole