tocol parameters" registry. It might also be somewhat awkward to
push for a phased approach (please see Section 3.1 of RFC 8624).
Regards,
S. Moonesamy
___
DNSOP mailing list -- dnsop@ietf.org
To unsubscribe send an email to dnsop-le...@ietf.org
the list of TLDs affected:
[snip]
int.(international orgs - important)
Matters related to int. are discussed in RFC 9121. It's a good idea
to get some data. It's not a good idea to take a decision by fiat on
matters directly related treaty-based organizations.
Regards,
S.
any information in the draft about those various forms of attacks. Is
that like someone the audience (of the draft) is expected to know
after reading the eight RFCs which are referenced by the draft? :-)
Appendix C has a reference to draft-hardaker-dnsop-must-not-sha1
instead of this draft.
Regar
ovide those recommendations.
The IETF angle is that there is a Standards Track memo which
specified what to do when special handling of a DNS label is required.
Regards,
S. Moonesamy
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/lis
is well-written. It probably needs some work
before it is ready for a Last Call. I suggest consideration what to
do about RFC 5933 given that the intended status of the document.
Regards,
S. Moonesamy
1. The Security Area Directors will likely ask whether the document
was reviewed by the re
developing policies for the DNS Root Zone?
Regards,
S. Moonesamy
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
it stalled in DNSOP. There is also a 2018 draft (expired). I
vaguely recall looking at a draft. However, proposed changes were
not accepted.
Regards,
S. Moonesamy
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo
e two RFCs [1][2] as "Informational".
Regards,
S. Moonesamy
1. https://www.rfc-editor.org/info/rfc4431
2. https://www.rfc-editor.org/info/rfc5074
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
te the impact of deprecating
one signature scheme."
The sentence is not clear.
As an overall comment, I suggest considering whether the audience is
the average working group participant only. If that is not the case,
the draft could do with an editorial pass.
Regards,
S. Moonesamy
1. I ass
". I suggest taking into
consideration that RFC 1035 is part of STD 13 for errata processing.
Regards,
S. Moonesamy
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
is the IPR issue?
Regards,
S. Moonesamy
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
would you prefer? Should we add the
IPv6 bits to 6304bis in order to codify IPv6 support for the current
scheme, or should we leave the current scheme as-is?
I suggest adding the IPv6 bits in 6304bis. Please see RFC 6890 for
information about what to put in the (IANA) registries.
Regards,
S.
Hi John,
At 10:43 21-05-2014, John Levine wrote:
See RFC 1123, section 5.2.2.
Tony Finch already commented about RFC 1123. That section has been
replaced (see RFC 5321). Section 8.7 of RFC 6409 is applicable for
mail submission and CNAME.
Regards,
S. Moonesamy
ot;By automating the maintenance of the DNSSEC key information (and
removing humans from the process), we expect to decrease the number
of DNSSEC related outages, which should increase DNSSEC deployment."
What does the above have to do with Security Considerations? How
many of the DNSSEC-related outages are due to human error?
Regards,
S. Moonesamy
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Hi Ted,
At 04:56 16-05-2014, Ted Lemon wrote:
Did you feel that your comments were adequately addressed by the
working group?
I gave up on reading the first response to my comments as I did not
want to push back strongly; it's an effort and it can be viewed as
antagonistic.
Regar
menting what people are
doing. It is worthwhile to consider whether the mechanism should be
standardized by the IETF.
Regards,
S. Moonesamy
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
he working group to improve DNS. I am
not sure whether that covers DNSSEC. It is like have a mini-DNSng. :-)
Regards,
S. Moonesamy
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
ot sure if that will
happen given the track record, but that is the roadmap.
Thanks for the above information. Adding to it, 1024-bit RSA keys
are allowed until 2015. There is an explanation about that
recommendation, i.e. it's not only about packet size
EC. The requirements mentioned
by Joe Abley refers to NIST SP 800-78. That document is about
"Cryptographic Algorithms and Key Sizes for Personal Identity
Verification". Is that the NIST recommendation on which this
discussion is based?
Regards,
S. Moonesamy
_
about the outcome of the Rollover consultation.
Regards,
S. Moonesamy
1. "To date, despite huge efforts, no one has broken a regular
1024-bit key; in fact, the best completed attack is estimated to be
the equivalent of a 700-bit key. An attacker breaking a 1024-bit
signing key would
20 matches
Mail list logo
