can not do much at all.
Yes.
Regards,
-sm
1. I actually looked into it some time back.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
on applications work
than work in other areas. My guess is that things won't get any
better if DNS is in the Applications Area. The issue is cross-area
reviews. It is a problem when reviews are not being done [1].
Regards,
-sm
1. There are likely good reasons
, and certainly not insurmountable.
I was not thinking of the IETF process. Mark Andrews covered what I
was thinking of in a message at
http://www.ietf.org/mail-archive/web/dnsop/current/msg11173.html
Regards,
-sm
___
DNSOP mailing list
DNSOP
matter.
Regards,
-sm
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
that it is not a good idea to push the boundary.
Regards,
-sm
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
; then discuss the draft within the IETF.
Regards,
-sm
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
prior notice to all involved
parties, including vendors, implementors, TLD operators, and end-users.
I think we can be fairly confident *that* isn't going to happen... :-)
My guess is that it won't happen in 2013.
Regards,
-sm
___
DNSOP mailing list
only via
TCP - I'm hoping more people will put up TCP-only open resolvers,
especially with:
RFC 5358 has a SHOULD NOT for open resolvers.
Regards,
-sm
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
-known newspaper which had a
problem at the registrar end. It's doubtful whether the entity
responsible for the well-known domain has assessed the threats correctly.
Regards,
-sm
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman
to look into whether anything could be done?
Thanks,
-sm
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
an opportunity to cross that
threshold. That tends to fail when there isn't adequate socialization.
Regards,
-sm
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Hi Russ,
At 12:19 04-01-2013, White, Russell wrote:
We have reviewed and Verisign believes that no change to its IPR
disclosure is required at this time.
Thanks.
Regards,
-sm
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman
not
mention RFC 4641. As draft-ietf-dnsop-rfc4641bis-13 is based on RFC
4641, does the submitter believe that an IPR disclosure is required
for RFC 4641?
Regards,
-sm
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
At 06:58 08-10-2012, Tony Finch wrote:
Prior art:
http://tools.ietf.org/html/draft-koch-dnsop-dnssec-operator-change-01
Does this affect draft-ietf-dnsop-rfc4641bis (currently in the RFC
Editor queue)?
Regards,
-sm
___
DNSOP mailing list
DNSOP
that and for the work.
Regards,
-sm
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
.
Regards,
-sm
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
into a RFC number.
Regards,
-sm
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
://trustee.ietf.org/ and choose the appropriate copyright license
for the draft. That would facilitate the timely publication.
Regards,
-sm
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
is waiting for Write-Up.
Regards,
-sm
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
which was used in an update of a
RFC which predates RFC 3647. This draft is a different and unusual
case. BTW, it is easier to let the previous versions of the draft to expire.
Regards,
-sm
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org
and text/dns.
Regards,
-sm
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
. There are different angles to the problem discussed in
draft-livingood-negative-trust-anchors-01. I could look at it as follows:
A Negative Trust Anchor should be considered even though the tactic is
not particularly scalable.
Regards,
-sm
___
DNSOP
, ADDITIONAL: 4
;; WARNING: recursion requested but not available
;; QUESTION SECTION:
;local. IN A
;; ANSWER SECTION:
local. 10800 IN A [removed]
Is there any survey about ISP DNS servers returning an answer for such queries?
Regards,
-sm
. RFC
6265 does not contain that text.
Regards,
-sm
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
wildcards to get
around DNS redirects.if the practice of DNS redirects by ISPs is
widespread. TLDs without DNS wildcards might resort to it too. The
authors of this document may wish to consider the long term effects.
Regards,
-sm
___
DNSOP
Standard with a BCP. There
was a discussion about the fallback to A/ RRs (implicit MX) last
year during a Last Call. The consensus was to keep it in the SMTP
standard. I doubt that any further discussion on the subject will
result in a different outcome.
Regards,
-sm
the message instead of retrying.
Regards,
-sm
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
?SM5uZXM=?= wrote:
That list has been used for the development of RFC 5321 and it is
going to be used for the desired Full Standard successor of it,
No, that's going to be done on another mailing list once the WG is chartered.
Regards,
-sm
___
DNSOP
in the
document where DNS service is used.
In Section 2.1.2
Finding and managing large quantities of name servers would be a useful
feature of the resulting management solution.
I suggest a large number instead of large quantities.
Regards,
-sm
requirements.
I couldn't find such a directive. The question might have been
raised due to some confusion with the directive about data
protection. The draft is about the requirements for a management
system for DNS name servers instead of country-specific policy requirements.
Regards,
-sm
/privacy/eudirective/EU_Directive_.html#HD_NM_2 - the
You could at least use a source of information from the European
Union if you are going to paint pictures about Europe.
Regards,
-sm
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org
.
There is ongoing work in the IDNAbis Working Group on
IDNA. draft-ietf-idnabis-protocol-10 proposes to obsolete RFC 3490.
Regards,
-sm
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
operator or user,
but this dubious benefit comes at the expense of others in the Internet
community.
Replace IP addresses with publish suffix and you'll see why your
proposal generated so much controversy on this mailing list.
Regards,
-sm
33 matches
Mail list logo
