Murray S. Kucherawy m...@cloudmark.com wrote:
I looked at least at the titles of all the documents that update 1035,
and none of them appear to be related to the above. So where should we
be looking?
The only thing I have found that implies NOTIMP doesn't apply to queries
for unknown RR
Martin Rex m...@sap.com wrote:
Btw. the updates metadata on rfc1035 looks like a big mess to me.
Expecting *anyone* to read all of the documents and merge them
in their heads while implementing is completely unrealistic.
http://blog.nominet.org.uk/tech/2010/05/24/436/ - DNS RFC dependency
Thanks for your feedback, John. Would a modified charter with these changes
work for you:
Jari
Locator/ID Separation Protocol (lisp)
-
Current Status: Active
Last updated: 2012-03-08
Chairs:
Joel Halpern j...@joelhalpern.com
Terry Manderson
New text:
The probability of an attacker guessing generated tokens (and other
credentials not
intended for handling by end-users) MUST be less than or equal to
2^(-128) and SHOULD be
less than or equal to 2^(-160).
Removed reference to RFC 1750.
EH
Thanks that is better.
Without knowing the lifetime of the token these are per guess probabilities.
Effectively 128bits for a random value and 256bits for a HMAC or other
signature.
For tokens intended for handling by end-users it may be useful to give some
advice.
In general you don't want an
Hi.
I realize I'm probably in the minority on this, but I think the
document overstates its case a bit and, perhaps recognizing the
actual complexity of the situation, even may contradict itself a
bit. For example, I note that it says:
(Section 1) Therefore this document deprecates the
Tony Finch wrote:
Murray S. Kucherawy m...@cloudmark.com wrote:
I looked at least at the titles of all the documents that update 1035,
and none of them appear to be related to the above. So where should we
be looking?
The only thing I have found that implies NOTIMP doesn't apply to
Martin Rex wrote:
Tony Finch wrote:
Murray S. Kucherawy m...@cloudmark.com wrote:
I looked at least at the titles of all the documents that update 1035,
and none of them appear to be related to the above. So where should we
be looking?
The only thing I have found that
I hear what you are saying. But I think the opinion in the IESG at least was,
however, that those three really are high priority, and that other documents
before them are not so useful before they are completed. I guess it is a
different perspective, whether you do things top-down or
But it's not clear to me that these (especially architecture and impacts) can
be said to have been properly analyzed until some of the lower-priority items
(I'm thinking of threats, cache, ETR sync) have been fleshed out.
I hear what you are saying. But I think the opinion in the IESG at
The id-announce mails are defective.
I thought the proposal was to ADD a URL to the HTML/tools or
datatracker versions of the I-D, rather than remove the URL
to the versioned TXT file.
While Barry Leibas suggested Greasemonkey script curiously fixes the
404 error created by the recent change to
In message 201203081845.q28ijgf0006...@fs4113.wdf.sap.corp, Martin Rex writes
:
Tony Finch wrote:
Murray S. Kucherawy m...@cloudmark.com wrote:
I looked at least at the titles of all the documents that update 1035,
and none of them appear to be related to the above. So where
Mark Andrews wrote:
Martin Rex writes:
Thanks for mentioning rfc 4074. The stuff in that document matches
the thoroughly broken behaviour of the IPv6 DNS resolver client of
Windows 2003 that I had encountered just recently.
IMO, rfc4074 exhibits a significant amount of
Martin Rex wrote:
So if the behaviour (how to exactly respond to queries for unknown
QTYPEs) is neither explicitly specified, nor likely have been part of
the usual/common interop tests performed by the vendor,
what you're left with might be ureflecteduntested guessing
on part of the
Sorry,
s/some 3-4 conditions/some 3-4 dozen conditions/
Martin Rex wrote:
Martin Rex wrote:
So if the behaviour (how to exactly respond to queries for unknown
QTYPEs) is neither explicitly specified, nor likely have been part of
the usual/common interop tests performed by the vendor,
In message 201203082359.q28nxpwu027...@fs4113.wdf.sap.corp, Martin Rex writes
:
Mark Andrews wrote:
Martin Rex writes:
Thanks for mentioning rfc 4074. The stuff in that document matches
the thoroughly broken behaviour of the IPv6 DNS resolver client of
Windows 2003 that I had
In message 201203090107.q2917cth001...@fs4113.wdf.sap.corp, Martin Rex writes
:
Martin Rex wrote:
So if the behaviour (how to exactly respond to queries for unknown
QTYPEs) is neither explicitly specified, nor likely have been part of
the usual/common interop tests performed by the
Mark Andrews wrote:
The incredibly huge base that returned NOERROR to type 28 queries
when was defined. Almost all of the offending boxes were
designed after was defined.
When was defined is marginally relevant. Since IPv6 was designed
as a completely seperate universe, it
In message 201203090223.q292nazs005...@fs4113.wdf.sap.corp, Martin Rex writes
:
Mark Andrews wrote:
The incredibly huge base that returned NOERROR to type 28 queries
when was defined. Almost all of the offending boxes were
designed after was defined.
When was
Mark Andrews wrote:
What should a _new_ recursive non-authoritative server send as response
back to the stub resolver when it encounters a NOTIMP response from the
authoritative server for an query?
Well the server should try the next server for the zone. If all of them
return NOTIMP,
Mark Andrews wrote:
not permitted would require a must not, but
I only see a should not here:
http://tools.ietf.org/html/rfc1035#section-5.2
RFC 1035 pre-dates the formalisation of MUST NOT/SHOULD NOT etc.
5.2. Use of master files to define zones
When a master file is used to
Total of 202 messages in the last 7 days.
script run at: Fri Mar 9 00:53:02 EST 2012
Messages | Bytes| Who
+--++--+
9.90% | 20 | 9.92% | 155968 | ma...@isc.org
8.42% | 17 | 7.10% | 111637 | jo...@iecc.com
In message 201203090422.q294mra2012...@fs4113.wdf.sap.corp, Martin Rex writes
:
Mark Andrews wrote:
not permitted would require a must not, but
I only see a should not here:
http://tools.ietf.org/html/rfc1035#section-5.2
RFC 1035 pre-dates the formalisation of MUST
The IESG has approved the following document:
- 'Generic Connection Admission Control (GCAC) Algorithm Specification
for IP/MPLS Networks'
(draft-ash-gcac-algorithm-spec-04.txt) as an Experimental RFC
This document has been reviewed in the IETF but is not the product of an
IETF Working
The IESG has received a request from the Behavior Engineering for
Hindrance Avoidance WG (behave) to consider the following document:
- 'Analysis of solution proposals for hosts to learn NAT64 prefix'
draft-ietf-behave-nat64-learn-analysis-03.txt as an Informational RFC
The IESG plans to make
The IESG has approved the following document:
- 'LISP Map Server Interface'
(draft-ietf-lisp-ms-16.txt) as an Experimental RFC
This document is the product of the Locator/ID Separation Protocol
Working Group.
The IESG contact persons are Jari Arkko and Ralph Droms.
A URL of this Internet
Greetings All,
Please note there will be a freeze on March 13-14 for information at
rfc-editor.org http://rfc-editor.org/ that is generated from the
database. The RFC Editor will continue to work on documents, but this
won't be reflected on rfc-editor.org http://rfc-editor.org/ (e.g.,
the queue
Greetings All,
Please note there will be a freeze on March 13-14 for information at
rfc-editor.org http://rfc-editor.org/ that is generated from the
database. The RFC Editor will continue to work on documents, but this
won't be reflected on rfc-editor.org http://rfc-editor.org/ (e.g.,
the queue
The IESG has received a request from the Audio/Video Transport Core
Maintenance WG (avtcore) to consider the following document:
- 'Explicit Congestion Notification (ECN) for RTP over UDP'
draft-ietf-avtcore-ecn-for-rtp-06.txt as a Proposed Standard
The IESG plans to make a decision in the
I am very pleased to announce that Cisco has agreed to host IETF 83 in Paris!
With the funds provided by the the host, we will be able to provide power
strips in the plenary room. I am extremely grateful to Cisco for helping the
IETF in this way.
Russ
On Mar 2, 2012, at 10:11 AM, IETF Chair
I am very pleased to announce that Cisco has agreed to host IETF 83 in Paris!
The t-shirt design contest resulted in a great design, and the period for
ordering these t-shirts is over. As planned, people that ordered a t-shirt
will receive one at the meeting. Since the design has already been
31 matches
Mail list logo
