Hi Valery,
I'm OK with this resolution.
Thanks,
Yaron
On 2013-10-21 07:53, Valery Smyslov wrote:
HI Yaron,
Hi Yoav,
You're probably right in your speculation. But my point was that
Valery's subject line said "editorial changes", and two of these
changes were arguably non-editorial. Technical changes would be treated
Actually, I don't think #6 is technical, as It doesn't change protocol's
behaviour.
Current text doesn't specify what to do if SPIs are the same for AH and
ESP,
and we can leave the behaviour unspecified either. The only difference
is that current text is written as if this situation cannot happen, which
contradicts RFC4301. We can rewrite is so, that admit that it may
happen, but leave to implementers to decide what to do in this case.
I think that it is important that RFC4301 and IKEv2 be aligned.
What about #8 - it is a minor issue and we can forgo it.
Valery.
differently in an errata review and should be treated differently in a
"bis" document, whose main purpose in life is to progress (i.e.,
stabilize) the protocol.
Thanks,
Yaron
On 2013-10-19 15:27, Yoav Nir wrote:
Hi, Yaron
Suppose that instead of sending the message to the list yesterday,
Valery had submitted his comments as errata a few months ago, before
Sean asked us to do the revision. Would those errata not have been
verified?
If so (and I think it's true for at least #3, #4, #7, and #11, and #6
would also merit some new text), the corrections would now be in the
draft. So why not now?
Yoav
On Oct 19, 2013, at 2:56 PM, Yaron Sheffer <yaronf.i...@gmail.com>
wrote:
Hi Yaron,
Hi Valery,
Sorry for being the Bad Guy on this. Your #6 does not seem
editorial to
I think that current text is not aligned with RFC4301.
We may leave it as is or try to find other form that
would not appear so misaligned.
Your new text is fine, if we leave it at that. If we try to add text
to deal with the exceptional cases (same SPI shared between
protocols), this will quickly become normative. I don't want to do
it in "bis" and frankly, I think this situation is too rare to matter.
me. Similarly, #8 (adding new RFC 2119 language) is not editorial. I
would suggest to implement #6 only if it is critical to
interoperability or security, and to forgo #8.
What about #8 - it's just a question from me. From my feeling it must
be uppercase, but I might be wrong. We may leave it as is.
IETF process is very serious about the difference between lowercase
and uppercase (see RFC 6919). Maybe it should have been a SHOULD to
start with. But we SHOULD NOT change it for a "bis" document.
By the way, your correction #2 still does not do it IMHO. The
sentence
refers to RFC 5996. So:
"IKEv2 as stated in RFC 4306 was a change to the IKE protocol that
was
not backward compatible. RFC 5996 revised RFC 4306 to provide a
clarification of IKEv2, making minimum changes to the IKEv2 protocol.
The current document slightly revises RFC 5996 to make it suitable
for
progression to Internet Standard."
Yes, your text is for RFC5996bis, while I made my notes a while ago
and the text was for RFC5996. Of course your variant is better.
Valery.
Thanks,
Yaron
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
