The TCP Authentication Option
draft-ietf-tcpm-tcp-auth-opt-11
Yes
(Lars Eggert)
(Magnus Westerlund)
(Ross Callon)
No Objection
(Dan Romascanu)
(Jari Arkko)
(Pasi Eronen)
(Robert Sparks)
(Tim Polk)
Recuse
(Ron Bonica)
Note: This ballot was opened for revision 11 and is now closed.
Lars Eggert Former IESG member
Yes
Yes
()
Unknown
Magnus Westerlund Former IESG member
Yes
Yes
()
Unknown
Ross Callon Former IESG member
Yes
Yes
()
Unknown
Adrian Farrel Former IESG member
No Objection
No Objection
(2010-03-09)
Unknown
Thanks for this document. General sigh of "at last" :-)
A few small wrinklettes...
ISN is used in Section 1 without expansion.
(although it is subsequently expanded multiple times)
---
Section 4.2
>> The Length value MUST be consistent with the TCP header length;
this is a consistency check and avoids overrun/underrun abuse.
When the Length value is invalid, TCP MUST discard the segment.
"MUST be consistent" is a little vague. I can only assume that you
mean that the length must not imply that the option extends beyond the
end of the header as specified by the header length.
---
MKT is used in Section 4.2 without expansion or reference.
Add a forward pointer to 5.1?
---
Semantic tautology.
I think the phrase "TCP-AO option" may include some redundancy.
Cf. the header to Section 4.2.
---
Section 9.1
s/implmentation/implementation/
Alexey Melnikov Former IESG member
(was Discuss)
No Objection
No Objection
(2010-03-06)
Unknown
4.2. The TCP-AO Option
o RNextKeyID: An unsigned 1-byte field indicating the MKT that the
sender is ready use to receive authenticated segments, i.e., the
"ready use to receive"?
desired 'receive next' keyID.
14. IANA Considerations
[NOTE: This section be removed prior to publication as an RFC]
I don't think this note is correct, the section is non empty.
Cullen Jennings Former IESG member
(was Discuss)
No Objection
No Objection
(2010-03-10)
Unknown
Give this disables much of ICMP, particularly destination unreachable, would it be worth mentioning in the applicability statement of situations when it was not appropriate to use it or timing consideration changes that needed to be made to applications using it?
Dan Romascanu Former IESG member
No Objection
No Objection
()
Unknown
Jari Arkko Former IESG member
No Objection
No Objection
()
Unknown
Pasi Eronen Former IESG member
(was Discuss)
No Objection
No Objection
()
Unknown
Ralph Droms Former IESG member
No Objection
No Objection
(2010-03-10)
Unknown
Section 2.1, third para: s/TCP-AO not/TCP-AO is not/
Robert Sparks Former IESG member
No Objection
No Objection
()
Unknown
Russ Housley Former IESG member
(was Discuss)
No Objection
No Objection
(2010-03-10)
Unknown
The Gen-ART Review by Wassim Haddad on 2010-03-09 included some editorial comments. Please consider them if an update to this document is needed for any reason.
Tim Polk Former IESG member
No Objection
No Objection
(2010-03-11)
Unknown
I support the discuss positions regarding the conformance language ("MUST support") for
implementations of TCP.
Ron Bonica Former IESG member
Recuse
Recuse
()
Unknown