Re: [IPsec] Last Call: <draft-ietf-i2nsf-sdn-ipsec-flow-protection-08.txt> (Software-Defined Networking (SDN)-based IPsec Flow Protection) to Proposed Standard
tom petch <daedulus-6b45v/[email protected]>
| Newsgroups | gmane.ietf.i2nsf,gmane.ietf.ipsec |
|---|---|
| Message-ID | <[email protected]> |
On 23/09/2020 07:16, Fernando Pereñíguez García wrote: > Hi Tero, > > Thank you very much for your clarification. We will update reference RFC > 822 accordingly in our draft. > > Tom, you proposed us to replace RFC 822 with 2822, but it is also obsoleted > by 5322. So, if you agree, we will reference RFC 5322 instead. That is fine by me; my comment was that RFC822 is obsoleted by RCC2822 so you should consider a more up-to-date version not that RFC2822 was the correct update! You said previously that you did not understand my comment on RFC6020 in IANA Considerations. It is fine. What I was trying to say is that in most places, RFC7950 is the better reference so RFC6020 should not be used but for IANA Considerations, RFC6020 is the better reference so when updating elsewhere in the I-D, leave IANA Considerations alone. Tom Petch > Best regards, > Fernando. > > El mar., 22 sept. 2020 a las 19:50, Tero Kivinen (<[email protected]>) > escribió: > >> Fernando Pereñíguez García writes: >>> I note that RFC822 and RFC3280 are Obsoleted which makes their use >>> problematic. >>> >>> [Authors] Following your recommendation, we have replaced RFC 3280 with >> RFC >>> 5280. Regarding RFC 822, we reference it because the IKEv2 protocol >>> specification (RFC 7296) explicitly defines RFC 822 emails address (see >> page >>> 90) as a valid identification type. If we replace RFC 822 with RFC 2821, >> we >>> don't know its impact on IKEv2. >> >> IKEv2 talks about RFC 822 email addresses, the reference points >> Internationalized Email Headers RFC 6532, with comment of: >> >> Because of [EAI], implementations would be wise to treat this >> field as UTF-8 encoded text, not as pure ASCII. >> >> So it uses RFC822 as name not as reference. There should not be any >> problems to replace that with newer versions. Most of the >> implementations simply consider that as a string and some cases they >> actually do not even follow the string email address format, as they >> add some routing information for AAAA in the end or something. >> -- >> [email protected] >> > > _______________________________________________ I2nsf mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2nsf