Resent-* oddities (was: Additional appeal against publication of draft-lyon-senderid-* [...])

Tony Finch wrote: >> the author can't say "updates 2822", how should he fix it ? >> As you said the 822 issue is mentioned in the senderid-pra >> draft. > Regarding RFC 822, the S-ID draft doesn't mention the fact > that a large proportion of software which does something > useful with Resent- h

RE: Last Call: 'Linklocal Multicast Name Resolution (LLMNR)' to Proposed Standard

[for as112 project: maybe add .local into the list of domains??] On Wed, 2005-08-31 at 14:24 -0700, Christian Huitema wrote: > > >Windows 98, Windows 2000 and Windows XP do not enable LLMNR by > default. > > > > Christian, could you please tell us, for each OS mentioned, how to > enable > > LLMNR

Re: Last Call: 'Linklocal Multicast Name Resolution (LLMNR)' to Proposed Standard

Dave Singer wrote: The whole idea that 'real DNS' can arbitrarily pre-empt local name resolution seems, well, wrong, and needs serious study for security implications for the services using those names, no? The whole idea that local names should look like DNS names and be queried through the

Re: Single DNS root

Dear Harald and Paul, May be time to stop 3683ing this issue. Major moves in the naming area are probable in the year to come (PADs - shared root under UN - National TLDs, CENTR move.); while an ICANN request of update of RFC 2826 stays unanswered or opposed for four years. On 17:25 31/08/200

IETF last call on draft-hansen-2717bis-2718bis-uri-guidelines-05: The practical case of SMS and MMS URI schemes

Hi, I did a review on 'Guidelines and Registration Procedures for new URI Schemes', draft-hansen-2717bis-2718bis-uri-guidelines-05, for which the IETF last call is on until today (sorry for leaving this so late). My main goal was to see whether the new process would make it sufficiently clear

RE: Last Call: 'Linklocal Multicast Name Resolution (LLMNR)' to Proposed Standard

I'm a by-stander on this discussion, maybe off-base or out of it -- but something other than the undesirable traffic struck me. Isn't it also true that I might *deliberately break* all sorts of things by introducing 'blocking' names into DNS responses, so that an LLMNR request is never issued.

RE: Last Call: 'Linklocal Multicast Name Resolution (LLMNR)' to Proposed Standard

> >Windows 98, Windows 2000 and Windows XP do not enable LLMNR by default. > > Christian, could you please tell us, for each OS mentioned, how to enable > LLMNR? That would enable everyone participating in this discussion to > witness for themselves exactly how it works and what it does. You woul

RE: Last Call: 'Linklocal Multicast Name Resolution (LLMNR)' to Proposed Standard

Christian Huitema wrote: >Windows 98, Windows 2000 and Windows XP do not enable LLMNR by default. Christian, could you please tell us, for each OS mentioned, how to enable LLMNR? That would enable everyone participating in this discussion to witness for themselves exactly how it works and what

Re: Last Call: 'Linklocal Multicast Name Resolution (LLMNR)' to Proposed Standard

On Tue, 30 Aug 2005, Margaret Wasserman wrote: > > The LLMNR document already includes an informative reference to > draft-cheshire-dnsext-multicastdns-05.txt, but it does so rather obscurely > (citing a need to use a TTL of 255 for "compatibility with Apple Bonjour"). That doesn't make sense. Why

RE: Last Call: 'Linklocal Multicast Name Resolution (LLMNR)' to Proposed Standard

Christian Huitema writes ("RE: Last Call: 'Linklocal Multicast Name Resolution (LLMNR)' to Proposed Standard"): > A key technical difference between LLMNR and the initial MDNS proposal > is precisely that LLMNR has no concept of a ".local" top level domain. While that is true, the ne

Re: Last Call: 'Linklocal Multicast Name Resolution (LLMNR) ' to Proposed Standard

> On 8/31/2005 12:36 PM, Ned Freed wrote: > > Section 2 states: > that's unfortunate > LLMNR clients need to make a distinction between the different kinds of > networks and then process the names accordingly. Agreed. And there are various ways to accomplish this. > The whole argument behind

Re: Last Call: 'Linklocal Multicast Name Resolution (LLMNR)' to Proposed Standard

Margaret Wasserman writes ("Re: Last Call: 'Linklocal Multicast Name Resolution (LLMNR)' to Proposed Standard"): > Other than a few minor issues that are being dealt with in a -43 > update, I don't think that anyone has raised a blocking technical > issue with the LLMNR specification during thi

Re: Last Call: 'Linklocal Multicast Name Resolution (LLMNR)' to Proposed Standard

Paul Hoffman wrote: At 2:47 PM +0200 8/31/05, Brian E Carpenter wrote: That is about 1/3 of the total. It doesn't surprise me at all that so many bogus queries arrive - everybody who mistypes a TLD or misconfigures a default domain generates bogus queries, and this isn't going to change. The qu

Re: Last Call: 'Linklocal Multicast Name Resolution (LLMNR)' to Proposed Standard

Margaret Wasserman writes ("Re: Last Call: 'Linklocal Multicast Name Resolution (LLMNR)' to Proposed Standard"): > The .local doesn't come from either mDNS or LLMNR... The user types > it and/or an application includes it in the domain name look-up. So, > if the user tries to look up "twiki.

Re: Additional appeal against publication of draft-lyon-senderid-* in regards to its recommended use of Resent- header fields in the way that is inconsistant with RFC2822

On Mon, 29 Aug 2005, Frank Ellermann wrote: > > > incompatible with RFC2822 > > I'm still a bit lost how this could actually _break_ something. > For obvious reasons the author can't say "updates 2822", how > should he fix it ? As you said the 822 issue is mentioned in > the senderid-pra draft. R

Re: Last Call: 'Linklocal Multicast Name Resolution (LLMNR) ' to Proposed Standard

On 8/31/2005 12:36 PM, Ned Freed wrote: > Section 2 states: that's unfortunate LLMNR clients need to make a distinction between the different kinds of networks and then process the names accordingly. The whole argument behind the original distinction between LLMNR and DNS is that ad-hoc names

Re: Last Call: 'Linklocal Multicast Name Resolution (LLMNR) ' to Proposed Standard

At 2:47 PM +0200 8/31/05, Brian E Carpenter wrote: >That is about 1/3 of the total. It doesn't surprise me at all that >so many bogus queries arrive - everybody who mistypes a TLD or >misconfigures a default domain generates bogus queries, and this isn't >going to change. The question is whether .

Re: Last Call: 'Linklocal Multicast Name Resolution (LLMNR) ' to Proposed Standard

> On 8/30/2005 2:18 PM, Stuart Cheshire wrote: > > Well, in case 1 (mDNS), no, because it won't return a useful result, so > > why keep doing it? > > > > In case 3 (conventional DNS), no, because it won't return a useful > > result, so why keep doing it? > > > > In case 2 (LLMNR) the answer is ye

Re: Last Call: 'Linklocal Multicast Name Resolution (LLMNR)' to Proposed Standard

On 8/30/2005 2:18 PM, Stuart Cheshire wrote: > Well, in case 1 (mDNS), no, because it won't return a useful result, so > why keep doing it? > > In case 3 (conventional DNS), no, because it won't return a useful > result, so why keep doing it? > > In case 2 (LLMNR) the answer is yes, all the t

Re: Last Call: 'Linklocal Multicast Name Resolution (LLMNR)' to Proposed Standard

On Wed, 2005-08-31 at 15:24 +0200, Peter Dambier wrote: >> Steve Bellovin wrote. > > At the risk of starting down a tangent, the IETF does not, as a > > technical matter, accept the validity of so-called alternate roots. > > See RFC 2826. > > > > --Steven M. Bellovin, http://www.cs

Re: Last Call: 'Linklocal Multicast Name Resolution (LLMNR)' to Proposed Standard

At 2:47 PM +0200 8/31/05, Brian E Carpenter wrote: That is about 1/3 of the total. It doesn't surprise me at all that so many bogus queries arrive - everybody who mistypes a TLD or misconfigures a default domain generates bogus queries, and this isn't going to change. The question is whether .loc

Alternative roots (was: Re: Last Call: 'Linklocal Multicast Name Resolution (LLMNR)' to Proposed Standard)

At 3:24 PM +0200 8/31/05, Peter Dambier wrote: the Public-Root is not an alternative root but a solution. makes it very clear that this set of root-like servers intends to answer affirmatively and authoritatively for TLDs that the real/generally-accepted root

RE: Last Call: 'Linklocal Multicast Name Resolution (LLMNR)' to Proposed Standard

> From the data gathered by our root-server operators at that moment we > estimate that the traffic for ".local" must have been some 25% A key technical difference between LLMNR and the initial MDNS proposal is precisely that LLMNR has no concept of a ".local" top level domain. Usage of LLMNR doe

Single DNS root (Re: Last Call: 'Linklocal Multicast Name Resolution (LLMNR)' to Proposed Standard)

--On 31. august 2005 13:08 +0200 Marc Manthey <[EMAIL PROTECTED]> wrote: i want to correct bills concern that , " peters public root server system" is an alternative for the existing ones and there are several others . Just being pedantic. of course anyone can run any service he wa

Re: Last Call: 'Linklocal Multicast Name Resolution (LLMNR)' to Proposed Standard

Steven M. Bellovin wrote: In message <[EMAIL PROTECTED]>, Marc Manthey writes: i'm going to have to raise the point that Peters "root-server" system is his private "walled-garden" and not representative of the Internet's authoritative root servers. Just for clarification. --bill

Re: Last Call: 'Linklocal Multicast Name Resolution (LLMNR)' to Proposed Standard

Brian E Carpenter wrote: Peter, Peter Dambier wrote: Russ Allbery wrote: Margaret Wasserman <[EMAIL PROTECTED]> writes: Other than a few minor issues that are being dealt with in a -43 update, I don't think that anyone has raised a blocking technical issue with the LLMNR specification d

Re: Last Call: 'Linklocal Multicast Name Resolution (LLMNR)' to Proposed Standard

Hi Bill, I am speaking of this root-server system: a.public-root.net. 900 IN A 205.189.71.2 b.public-root.net. 900 IN A 61.9.136.52 c.public-root.net. 900 IN A 68.255.182.111 d.public-root.net. 900 IN A 205.189.71.34

Re: Last Call: 'Linklocal Multicast Name Resolution (LLMNR)' to Proposed Standard

Jeroen Massar wrote: On Wed, 2005-08-31 at 13:14 +0200, Brian E Carpenter wrote: ... Check for only "K": http://k.root-servers.org/index.html#stats Interresting one here is NXDOMAIN responses: http://k.root-servers.org/stats/linx/xstats_SNXD-all.html (note, that is only the LINX node) It is a l

Re: Last Call: 'Linklocal Multicast Name Resolution (LLMNR)' to Proposed Standard

On Wed, 2005-08-31 at 13:14 +0200, Brian E Carpenter wrote: > Peter, > > Peter Dambier wrote: > > Russ Allbery wrote: > > > >> Margaret Wasserman <[EMAIL PROTECTED]> writes: > >> > >> > >>> Other than a few minor issues that are being dealt with in a -43 update, > >>> I don't think that anyone ha

Re: Last Call: 'Linklocal Multicast Name Resolution (LLMNR)' to Proposed Standard

In message <[EMAIL PROTECTED]>, Marc Manthey writes: > >> >> i'm going to have to raise the point that Peters "root-server" >> system >> is his private "walled-garden" and not representative of the >> Internet's >> authoritative root servers. Just for clarification. >> >> --bill >

Re: I-D ACTION:draft-sanz-rfc1032-historic-00.txt

--On 31. august 2005 03:08 -0700 "william(at)elan.net" <[EMAIL PROTECTED]> wrote: As such if RFC1032 is being considered for moving to historic (which may need to happen but I see no reason to do it right now and I think it would be difficult because many other non-historic RFCs depend on it

Re: Last Call: 'Linklocal Multicast Name Resolution (LLMNR)' to Proposed Standard

Peter, Peter Dambier wrote: Russ Allbery wrote: Margaret Wasserman <[EMAIL PROTECTED]> writes: Other than a few minor issues that are being dealt with in a -43 update, I don't think that anyone has raised a blocking technical issue with the LLMNR specification during this IETF LC. If you (

Re: Last Call: 'Linklocal Multicast Name Resolution (LLMNR)' to Proposed Standard

On Aug 31, 2005, at 12:50 PM, Bill Manning wrote: On Aug 31, 2005, at 2:25, Peter Dambier wrote: Russ Allbery wrote: Margaret Wasserman <[EMAIL PROTECTED]> writes: Other than a few minor issues that are being dealt with in a -43 update, I don't think that anyone has raised a blocking tech

Re: Last Call: 'Linklocal Multicast Name Resolution (LLMNR)' to Proposed Standard

On Aug 31, 2005, at 2:25, Peter Dambier wrote: Russ Allbery wrote: Margaret Wasserman <[EMAIL PROTECTED]> writes: Other than a few minor issues that are being dealt with in a -43 update, I don't think that anyone has raised a blocking technical issue with the LLMNR specification during this

Re: I-D ACTION:draft-sanz-rfc1032-historic-00.txt

On Wed, 31 Aug 2005, Stephane Bortzmeyer wrote: Every TLD has its own X. X should not be provided by the IETF. It is completely outside of its technical standards-setting mission. FWIW, the IETF mission statement (a BCP) (RFC3935) includes more than setting standards. This was a very consciou

Re: I-D ACTION:draft-sanz-rfc1032-historic-00.txt

On Wed, 31 Aug 2005, Frank Ellermann wrote: It is completely outside of its technical standards-setting mission. With that idea you could also claim that RfCs should not talk about postmaster@ or [EMAIL PROTECTED] This cannot work. I don't care who publishs / maintains these RfCs, maybe ICA

Re: I-D ACTION:draft-sanz-rfc1032-historic-00.txt

Stephane Bortzmeyer wrote: >> But the really dubious part from my POV was the intent to >> get rid of the critical X in "954 - X = 3912". Some users >> want this X, > Every TLD has its own X. Not limited to TLDs, IIRC 1591 proposes to apply X recursively. So when I type 'rxwhois fr' I get the l

Re: Is it necessary to go through Standards Track to Get to Historic?

Bruce Lilly wrote: ... Aside from the label -- and that's not a clear benefit because Historic is ambiguous -- I don't see much difference between Historic and an Informational RFC with a suitable IESG note (a "warning label" if you will). There's a difference. For example, imagine a media typ

Re: Last Call: 'Linklocal Multicast Name Resolution (LLMNR)' to Proposed Standard

Russ Allbery wrote: Margaret Wasserman <[EMAIL PROTECTED]> writes: Other than a few minor issues that are being dealt with in a -43 update, I don't think that anyone has raised a blocking technical issue with the LLMNR specification during this IETF LC. If you (or anyone else) has intended to

Re: I-D ACTION:draft-sanz-rfc1032-historic-00.txt

On Wed, Aug 31, 2005 at 10:00:41AM +0200, Frank Ellermann <[EMAIL PROTECTED]> wrote a message of 44 lines which said: > But the really dubious part from my POV was the intent to get rid of > the critical X in "954 - X = 3912". Some users want this X, Every TLD has its own X. X should not be p

Re: I-D ACTION:draft-sanz-rfc1032-historic-00.txt

Harald Tveit Alvestrand wrote: > 3912 was published in order to make it clear that the IETF > is not making policy requirements Some people incl. me consider NICNAME as an essential asset of "the Net" (whatever that might be), like mail. Perfectly okay if somebody doesn't support mail, but many

Re: Last Call: 'Linklocal Multicast Name Resolution (LLMNR) ' to Proposed Standard

on 2005-08-31 05:40 Jeffrey Hutzelman said the following: > > On Tuesday, August 30, 2005 15:55:56 -0700 Ned Freed > <[EMAIL PROTECTED]> wrote: > >> IMO this needs major work even before being approved as experimental. The >> overlapped namespace approach in particular seems hugely problematic a