On Jun 19, 2013, at 9:29 AM, joel jaeggli joe...@bogus.com wrote:
Given that this document was revved twice and had it's requested status
change during IETF last call in response to discussion criticism and new
contribution I am going to rerun the last call.
I reviewed this version and I
Olafur,
Based on reviewing the current draft and the handling of my
objections and other of others to the prior ones, I agree that
the document is ready for publication.
However, I feel a need to comment on one of your observations
below because it seems to lie at the core of why this
On Thu, Jun 20, 2013 at 11:17:16AM -0400, John C Klensin wrote:
So some review of the DNSEXT-specified procedures and
expectations may be in order.
I encourage you, then, to organize the BOF session that will spin up
the WG to achieve this. DNSEXT is only still alive because our last
On 06/20/2013 09:36 AM, Andrew Sullivan wrote:
On Thu, Jun 20, 2013 at 11:17:16AM -0400, John C Klensin wrote:
So some review of the DNSEXT-specified procedures and
expectations may be in order.
I encourage you, then, to organize the BOF session that will spin up
the WG to achieve this.
On Jun 20, 2013, at 1:04 PM, Doug Barton do...@dougbarton.us wrote:
Perhaps we could have a non-WG mailing list so that people could submit
proposals for review prior to the expert review process. Even some of the
get off my lawn crowd offered good suggestions for this EUI case (make 1
On 6/20/13 10:04 AM, Doug Barton wrote:
I agree with at least a little of what each of Olafur, John, and
Andrew have said; but I think there's a middle ground between throw
the doors wide open and everything we have tried before didn't
work. At least I hope there is.
Well recall that we
On Thu, Jun 20, 2013 at 10:04:54AM -0700, Doug Barton wrote:
Perhaps we could have a non-WG mailing list so that people could
submit proposals for review prior to the expert review process.
The WG list isn't going away with the WG. The list is explicitly
called out as a good place to try out
On Thu, Jun 20, 2013 at 05:10:20PM +, Ted Lemon wrote:
You mean like namedroppers?
If only we still had that list. Alas, it was the victim of politics.
Perhaps Randy Bush will bring it back to life.
A
--
Andrew Sullivan
a...@anvilwalrusden.com
On 06/20/2013 10:27 AM, Andrew Sullivan wrote:
On Thu, Jun 20, 2013 at 10:04:54AM -0700, Doug Barton wrote:
Perhaps we could have a non-WG mailing list so that people could
submit proposals for review prior to the expert review process.
The WG list isn't going away with the WG. The list is
You mean like namedroppers?
If only we still had that list.
any reports of its death are from questionable sources
it was the victim of politics.
like much of life
randy
--On Thursday, June 20, 2013 12:36 -0400 Andrew Sullivan
a...@anvilwalrusden.com wrote:
On Thu, Jun 20, 2013 at 11:17:16AM -0400, John C Klensin wrote:
So some review of the DNSEXT-specified procedures and
expectations may be in order.
...
But more generally, as a practical matter it is
Given that this document was revved twice and had it's requested status
change during IETF last call in response to discussion criticism and new
contribution I am going to rerun the last call.
Thanks
joel
On 5/20/13 6:44 AM, The IESG wrote:
The IESG has received a request from an individual
Given that this document was revved twice and had it's requested status
change during IETF last call in response to discussion criticism and new
contribution I am going to rerun the last call.
the recent changes resolved my issue. thanks joe and joel.
randy
In message m2mwqlyglu.wl%ra...@psg.com, Randy Bush writes:
Given that this document was revved twice and had it's requested status
change during IETF last call in response to discussion criticism and new
contribution I am going to rerun the last call.
the recent changes resolved my
I am told that draft has been revved again in response to discussion on
the list.
http://www.ietf.org/rfcdiff?url2=draft-jabley-dnsext-eui48-eui64-rrtypes-05
Please direct your attention to the security considerations section. If
it turns out that informational documentation of the two
I am told that draft has been revved again in response to discussion on
the list.
http://www.ietf.org/rfcdiff?url2=draft-jabley-dnsext-eui48-eui64-rrtypes-05
Please direct your attention to the security considerations section. If
it turns out that informational documentation of the two
while i appreciate joe's listening to my other comments on the draft, i
still strongly object to publication of this draft as an rfc for the
reasons made very clear in the sec cons. please read the summary
section of rfc 2804.
While the RFC should not be materially misleading, I don't
Hi Donald,
At 21:09 27-05-2013, Donald Eastlake wrote:
While the RFC should not be materially misleading, I don't think there
is a requirement for Informational RFCs to guarantee any particular
level or security or privacy.
Yes. In my opinion a best effort is preferable or else the Security
On 2013-05-28, at 3:38, SM s...@resistor.net wrote:
In theory the IETF does not publish RFCs to suit the regulations of one
country (see use-case in draft-jabley-dnsext-eui48-eui64-rrtypes-04). In
practice, the IETF has published a RFC to suit the requirements (it was a
voluntary measure
Hi Joe,
At 03:12 28-05-2013, Joe Abley wrote:
Note that there's no suggestion that these RRTypes are required by the
CRTC. The example given was for a situation where Interop would have
been beneficial (so that cable resellers have an obvious, stable and
supported way of encoding this kind of
On 5/28/13 9:41 AM, SM wrote:
Hi Joe,
At 03:12 28-05-2013, Joe Abley wrote:
Note that there's no suggestion that these RRTypes are required by the
CRTC. The example given was for a situation where Interop would have
been beneficial (so that cable resellers have an obvious, stable and
supported
On 5/20/13 6:44 AM, The IESG wrote:
The IESG has received a request from an individual submitter to consider
the following document:
- 'Resource Records for EUI-48 and EUI-64 Addresses in the DNS'
draft-jabley-dnsext-eui48-eui64-rrtypes-03.txt as Proposed Standard
I would direct the
while i appreciate joe's listening to my other comments on the draft, i
still strongly object to publication of this draft as an rfc for the
reasons made very clear in the sec cons. please read the summary
section of rfc 2804.
randy
On Mon, May 27, 2013 at 7:54 PM, Randy Bush ra...@psg.com wrote:
while i appreciate joe's listening to my other comments on the draft, i
still strongly object to publication of this draft as an rfc for the
reasons made very clear in the sec cons. please read the summary
section of rfc 2804.
With respect to the question of proposed standard. What changes if the
requested status is informational?
I think just get rid of the normative language - SHOULDs, MUSTs, etc.
that is orthogonal to info/ps
next unnecessary rathole, please
randy
joe,
i spent time actually reading the document and commenting on it, one was
a substantive comment, at least to me.
any chance you could pull yourself away from the exemplary
anti-productive nitpicking maelstrom for a few minutes and respond?
thanks.
randy
Hi Randy,
On 2013-05-21, at 11:23, Randy Bush ra...@psg.com wrote:
i have read the draft. if published, i would prefer it as a proposed
standard as it does specify protocol data objects.
Noted, thanks.
It does seem that the main objection to the standards track for this document
is that I
From: John C Klensin john-i...@jck.com
My problem here, which I hope was clear from
the note from which you quoted, is that a request/document in
the second category was proposed for Standards Track and then
that comments that would be entirely appropriate for a Last Call
on a Standards
From: Keith Moore mo...@network-heretics.com
On 05/21/2013 10:04 AM, Joe Abley wrote:
With respect, *my* question as the author of this document is
simply whether the specification provided is unambiguous and
sufficient. It was my understanding that this was the question
before the
On Wed, May 22, 2013 at 10:03 PM, Dale R. Worley wor...@ariadne.com wrote:
...
Coming into this from the outside, the issues are interesting.
I originally thought RRTYPEs are scarce, since all the ones I was
aware of are less than 256. But it turns out that RRTYPEs are 16 bit
integers, and
On 5/20/13 6:42 PM, Brian E Carpenter wrote:
On 21/05/2013 13:06, John C Klensin wrote:
--On Monday, May 20, 2013 19:49 -0400 Rob Austein
s...@hactrn.net wrote:
At Mon, 20 May 2013 10:18:21 -0400, John C. Klensin wrote:
This is not my primary (or even secondary) area of expertise
but, given
On 05/20/2013 04:08 PM, Brian E Carpenter wrote:
Publication of EUI-48 or EUI-64 addresses in the global DNS may
result in privacy issues in the form of unique trackable identities.
This might also result in such MAC addresses being spoofed, thereby allowing
some sort of direct attack.
On 2013-05-21, at 09:36, Keith Moore mo...@network-heretics.com wrote:
Publishing EUI-XX addresses in the DNS is a bad idea.
With respect, *my* question as the author of this document is simply whether
the specification provided is unambiguous and sufficient. It was my
understanding that
On 05/21/2013 10:04 AM, Joe Abley wrote:
On 2013-05-21, at 09:36, Keith Moore mo...@network-heretics.com wrote:
Publishing EUI-XX addresses in the DNS is a bad idea.
With respect, *my* question as the author of this document is simply whether
the specification provided is unambiguous and
On 2013-05-21, at 10:18, Keith Moore mo...@network-heretics.com wrote:
Perhaps Informational or Experimental would be a better label for this
document, then.
Informational was my original plan; I was persuaded by Some People that the
standards track was more appropriate. As I mentioned, my
--On Tuesday, May 21, 2013 10:04 -0400 Joe Abley
jab...@hopcount.ca wrote:
...
There has been very little review of the actual specification
in this thread to date.
RRType assignments are made based on expert review, not IETF
consensus, document published, or any other criteria. In this
joe,
i have read the draft. if published, i would prefer it as a proposed
standard as it does specify protocol data objects.
where you goin' with that gun in your hand?
i am not at all sanguine about the issues raised in the in sec cons. i
accept that NTRE038D may have asked that these be in
Not related to the draft as such (whose publication, incidentally, I
support):
On Tue, May 21, 2013 at 10:23:03PM +0700, Randy Bush wrote:
1 - intro - do we have a standard way to refer to the dns specs as tuned
in 42 subsequent rfcs since 1035?
Alas, no. Some time ago, DNSEXT was
On 5/21/13 8:06 AM, John C Klensin wrote:
All I'm asking for is that, if you
want this as a Proposed Standard you carefully and convincingly
describe your design rationale. I want that both because it
seems generally appropriate in this case and because, if someone
comes along and wants to
On 05/21/2013 11:46 AM, joel jaeggli wrote:
With respect to the question of proposed standard. What changes if the
requested status is informational?
I think just get rid of the normative language - SHOULDs, MUSTs, etc.
Given that the RR types have already been assigned, documenting them
On 2013-05-21, at 11:50, Keith Moore mo...@network-heretics.com wrote:
On 05/21/2013 11:46 AM, joel jaeggli wrote:
With respect to the question of proposed standard. What changes if the
requested status is informational?
I think just get rid of the normative language - SHOULDs, MUSTs,
On 05/21/2013 11:52 AM, Joe Abley wrote:
On 2013-05-21, at 11:50, Keith Moore mo...@network-heretics.com wrote:
On 05/21/2013 11:46 AM, joel jaeggli wrote:
With respect to the question of proposed standard. What changes if the
requested status is informational?
I think just get rid of the
On 2013-05-21, at 11:56, Keith Moore mo...@network-heretics.com wrote:
On 05/21/2013 11:52 AM, Joe Abley wrote:
On 2013-05-21, at 11:50, Keith Moore mo...@network-heretics.com wrote:
On 05/21/2013 11:46 AM, joel jaeggli wrote:
With respect to the question of proposed standard. What changes
On 05/21/2013 11:57 AM, Joe Abley wrote:
On 2013-05-21, at 11:56, Keith Moore mo...@network-heretics.com wrote:
2119 language is intended to describe requirements of standards-track
documents.Informational documents cannot impose requirements.
Then I think we've just identified a reason
Keith == Keith Moore mo...@network-heretics.com writes:
Keith 2119 language is intended to describe requirements of
Keith standards-track documents. Informational documents cannot
Keith impose requirements.
i think using 2119 language in informational documents is often
On May 21, 2013, at 8:56 AM, Keith Moore mo...@network-heretics.com wrote:
2119 language is intended to describe requirements of standards-track
documents.
Can you support that statement with a reference to an RFC or an IESG statement
that supports it?
Informational documents cannot
On 2013-05-21, at 12:02, Keith Moore mo...@network-heretics.com wrote:
Actually I think that what we need is a BCP that says that DNS is not
intended, not designed, and SHOULD NOT be used for dissemination of any
information that is not deemed acceptable for widespread public distribution.
The scope of RFC 2119 is clearly standards-track documents. Documents that
aren't standards should not be worded as if they were; this is likely to cause
confusion about the status of the document.
Sent from my iPhone
On May 21, 2013, at 12:08 PM, Paul Hoffman paul.hoff...@vpnc.org wrote:
On May 21, 2013, at 9:23 AM, Keith Moore mo...@network-heretics.com wrote:
The scope of RFC 2119 is clearly standards-track documents.
I'll take that as a no. The scope is mentioned exactly once, in the
abstract but not in the body of the document.
Documents that aren't standards should
--On Tuesday, May 21, 2013 08:46 -0700 joel jaeggli
joe...@bogus.com wrote:
On 5/21/13 8:06 AM, John C Klensin wrote:
All I'm asking for is that, if you
want this as a Proposed Standard you carefully and
convincingly describe your design rationale. I want that
both because it seems
(Changing Subject lines -- this is about a set of general
principles that might affect this document, not about the
document)
--On Tuesday, May 21, 2013 22:23 +0700 Randy Bush
ra...@psg.com wrote:
joe,
i have read the draft. if published, i would prefer it as a
proposed standard as it does
On 5/21/13 9:02 AM, Keith Moore wrote:
On 05/21/2013 11:57 AM, Joe Abley wrote:
On 2013-05-21, at 11:56, Keith Moore mo...@network-heretics.com wrote:
2119 language is intended to describe requirements of
standards-track documents.Informational documents cannot impose
requirements.
Then
On 05/21/2013 01:35 PM, joel jaeggli wrote:
On 5/21/13 9:02 AM, Keith Moore wrote:
On 05/21/2013 11:57 AM, Joe Abley wrote:
On 2013-05-21, at 11:56, Keith Moore mo...@network-heretics.com
wrote:
2119 language is intended to describe requirements of
standards-track documents.
On 05/21/2013 12:30 PM, Paul Hoffman wrote:
Documents that aren't standards should not be worded as if they were; this is
likely to cause confusion about the status of the document.
I'm pretty sure that you as AD approved Informational RFCs that used 2119
language, and that this was discussed
On May 21, 2013, at 1:32 PM, John C Klensin john-i...@jck.com wrote:
(Changing Subject lines -- this is about a set of general
principles that might affect this document, not about the
document)
--On Tuesday, May 21, 2013 22:23 +0700 Randy Bush
ra...@psg.com wrote:
joe,
i have read
--On Tuesday, May 21, 2013 15:42 -0400 Olafur Gudmundsson
o...@ogud.com wrote:
...
John,
There are basically 3 different kinds of DNS RRtypes,
- types that affect the behavior of the DNS protocol and are
cached by resolvers,
- types that have DATA and are cached by resolvers
--On Monday, May 20, 2013 06:44 -0700 The IESG
iesg-secret...@ietf.org wrote:
The IESG has received a request from an individual submitter
to consider the following document:
- 'Resource Records for EUI-48 and EUI-64 Addresses in the DNS'
draft-jabley-dnsext-eui48-eui64-rrtypes-03.txt
On 5/20/13 7:18 AM, John C Klensin wrote:
--On Monday, May 20, 2013 06:44 -0700 The IESG
iesg-secret...@ietf.org wrote:
The IESG has received a request from an individual submitter
to consider the following document:
- 'Resource Records for EUI-48 and EUI-64 Addresses in the DNS'
--On Monday, May 20, 2013 07:53 -0700 joel jaeggli
joe...@bogus.com wrote:
...
This is not my primary (or even secondary) area of expertise
but, given that the RR space is not unlimited even though it
is large, wouldn't it be better to have a single RRtype for
IEEE-based EUIs with a flag or
On May 20, 2013, at 8:56 AM, John C Klensin john-i...@jck.com wrote:
However, if
(i) the expert review consists largely of making sure
that the template contains the right information and the
ducks are not obviously out of line rather than a
design/architectural review
Hi John,
On Mon, May 20, 2013 at 11:56 AM, John C Klensin john-i...@jck.com wrote:
--On Monday, May 20, 2013 07:53 -0700 joel jaeggli
joe...@bogus.com wrote:
...
This is not my primary (or even secondary) area of expertise
but, given that the RR space is not unlimited even though it
is
Just on the writeup tooling question:
p.s. I've tried reading your shepherd writeup now in three
different browsers. It appears to be formatted for extremely
long (paragraph-length) lines, with no provision for automatic
wrapping to fit the page frame. That means that trying to read
and
On 5/20/13 8:56 AM, John C Klensin wrote:
--On Monday, May 20, 2013 07:53 -0700 joel jaeggli
joe...@bogus.com wrote:
...
This is not my primary (or even secondary) area of expertise
but, given that the RR space is not unlimited even though it
is large, wouldn't it be better to have a single
At 06:44 20-05-2013, The IESG wrote:
The IESG has received a request from an individual submitter to consider
the following document:
- 'Resource Records for EUI-48 and EUI-64 Addresses in the DNS'
draft-jabley-dnsext-eui48-eui64-rrtypes-03.txt as Proposed Standard
The IESG plans to make a
People were already storing MAC addresses in DNS for the reason given
in the draft and perhaps others, it is just that they were doing so in
a variety of proprietary ways.
Thanks,
Donald
=
Donald E. Eastlake 3rd +1-508-333-2270 (cell)
155 Beaver Street, Milford, MA
--On Monday, May 20, 2013 09:55 -0700 joel jaeggli
joe...@bogus.com wrote:
I don't know who the current expert is and, for the moment, am
glad I don't and don't intend to check. I believe there is
broad consensus in the community that having something as
significant as an RRTYPE documented
Publication of EUI-48 or EUI-64 addresses in the global DNS may
result in privacy issues in the form of unique trackable identities.
This might also result in such MAC addresses being spoofed, thereby allowing
some sort of direct attack. So it isn't just a privacy concern.
...
These
--On Tuesday, May 21, 2013 08:08 +1200 Brian E Carpenter
brian.e.carpen...@gmail.com wrote:
These potential concerns can be mitigated through
restricting access to zones containing EUI48 or EUI64 RRs
or storing such information under a domain name whose
construction requires
At Mon, 20 May 2013 10:18:21 -0400, John C. Klensin wrote:
This is not my primary (or even secondary) area of expertise
but, given that the RR space is not unlimited even though it is
large, wouldn't it be better to have a single RRtype for
IEEE-based EUIs with a flag or other indicator in
Hi Donald,
At 12:10 20-05-2013, Donald Eastlake wrote:
People were already storing MAC addresses in DNS for the reason given
in the draft and perhaps others, it is just that they were doing so in
a variety of proprietary ways.
Thanks for the explanation. I'll make a general comment.
From
--On Monday, May 20, 2013 19:49 -0400 Rob Austein
s...@hactrn.net wrote:
At Mon, 20 May 2013 10:18:21 -0400, John C. Klensin wrote:
This is not my primary (or even secondary) area of expertise
but, given that the RR space is not unlimited even though it
is large, wouldn't it be better to
On 21/05/2013 13:06, John C Klensin wrote:
--On Monday, May 20, 2013 19:49 -0400 Rob Austein
s...@hactrn.net wrote:
At Mon, 20 May 2013 10:18:21 -0400, John C. Klensin wrote:
This is not my primary (or even secondary) area of expertise
but, given that the RR space is not unlimited even
Hi,
On Mon, May 20, 2013 at 9:06 PM, John C Klensin john-i...@jck.com wrote:
...
...
The discussion in 3.1 clearly applies to relatively complex
schemes like NAPTR, but it is not clear that it has anything to
do with this case. In particular, if I correctly understand the
IEEE's allocation
--On Tuesday, May 21, 2013 13:42 +1200 Brian E Carpenter
brian.e.carpen...@gmail.com wrote:
...
I'm not opposed to having two separate RRTYPEs -- I just want
to see the rationale. And what passes for use cases in the
draft appears to me to be completely silent on that issue.
Especially
At Mon, 20 May 2013 21:06:53 -0400, John C. Klensin wrote:
I've reread 5507 and did so again before writing my second note
today. I don't see that it helps.
I was mostly referring to the discussion in section 3.1.
The discussion in 3.1 clearly applies to relatively complex
schemes like
75 matches
Mail list logo
