ir transport layer, and change
almost nothing else. So it's closer to a transport profile than a brand new
protocol, packet encoding, state machine, etc.
> Q_ED_1:
>
> I think the Abstract is too long. Any explanations, clarifications and details
> should be removed.
Fixed.
Ala
n only be extended by implementing the negotiation discussed
in the other specifications.
So we would like to suggest 64K packets here, but we can't mandate them,
Alan DeKok.
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
On Jan 24, 2023, at 1:35 PM, Thomas Fossati via Datatracker
wrote:
>
> Nits/editorial comments:
>
> OLD
> There remain some differences between EAP-TLS and other TLS-based EAP
> methods which necessitates this document.
> NEW
> There remain some differences between EAP-TLS and other
On Aug 13, 2018, at 8:24 PM, Tim Evens
wrote:
> Minor issues:
>
> Nits/editorial comments:
> Abstract contains "Section 3.1" which becomes an HTML reference
> link. This incorrectly links to the current draft section 3.1,
> not the intended RFC5176 Section 3.1. This is repeated in
> the
comments:
>
> 1. Section 2.1.4: The paragraph that starts with ‘The “Value” field
> should be given ….’ needs to use capitalized SHOULD to be consistent with the
> paragraph that refer to the “Name” and “Format” fields.
Fixed, thanks.
Alan DeKok.
signature.asc
Ben Campbell wrote:
I think it's reasonable to say that good administration practices involve
random key generation, and that the interface should not prevent the entry of
arbitrary hex strings. But the text says things like
When creating keys, it is RECOMMENDED that keys be derived from
.
Alan DeKok.
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
Ben Campbell wrote:
-- 3.2, last paragraph:
I'm still confused about how this is a bid down attack.
[The author replied that, when secure and insecure packets are allowed from
the same client, a
malicious or broken client can choose the insecure one. That's bad,
when the intent is to
fails to account for the fact that the
requirement only applies to clients implemented as multiple independent
instances. This could be fixed by something really simple like saying ...
such clients ... instead of ... clients... in the second paragraph.
I'll update it.
Alan DeKok
Ben Campbell wrote:
*** Major issues:
-- General:
The draft needs an overhaul of it's use of normative language. There appears
to be redundant (and possibly contradictory) language for the same
requirements sprinkled throughout. There are also cases of normative language
being used
Meral Shirazipour wrote:
Summary: This draft is ready for publication as Proposed Standard (with
some editorial comments).
Thanks. I'll fix the changes in the next revision of the document.
Alan DeKok.
___
Gen-art mailing list
Gen-art@ietf.org
and should be publicly available.
References would be helpful.
Alan DeKok.
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
more than
256 outstanding packets on one connection. However, doing so is a
violation of a fundamental part of the protocol and SHOULD NOT be
done. Making that extension here is outside of the scope of this
specification.
Agreed.
Alan DeKok
.
Thanks for the review. I'll incorporate the comments in the next
update to the document.
Alan DeKok.
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
be OK to leave it as-is.
Alan DeKok.
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
15 matches
Mail list logo
