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

Hi Stuart, I'm sorry. I didn't mean to be insulting... We don't typically include statements about how we compete or don't compete with any non-IETF protocols, including de-facto standards and/or standards from other standards groups, as that is more of a marketing discussion than a technic

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

Hi Stuart, Although implementaitons are not strictly required for Proposed Standard publication, I do think that it is interesting to know whether people have implemented, or intend to implement our standards. I have received a couple of private confirmations that LLMNR is implemented in Wi

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

>It is not typical for us to make statements in our standards >regarding what proprietary mechanisms our standards are or are not >intended to compete with, nor do we typically include statements that >compare the features of our standards to proprietary protocols. Please stop calling it "propr

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

>In The Public-Root there used to exist a domain ".local". I know at least >of one ISP who complained we did break a lot of windowed PCs. > >I dont know why queries for ".local" would leave their private LANs and >reach even our root servers. They did! > >That is why we set up a dummy and returned

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

>I don't see anything in RFC 2026 criteria that hinges on whether >Microsoft intends to implement a protocol. Is doesn't have to be Microsoft. Is there *anyone* out there who has implemented this, or plans to? Or am I just being old-fashioned in thinking that the idea behind a protocol specifie

Re: Last Call: 'Tags for Identifying Languages' to BCP

On 00:40 26/08/2005, David Hopwood said: JFC (Jefsey) Morfin wrote: [...] Today, the common practice of nearly one billion of Internet users is to be able to turn off cookies to protect their anonymous free usage of the web. Once the Draft enters into action they will be imposed a conflicting

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

Hi Stuart, --On 25. august 2005 10:18 -0700 Stuart Cheshire <[EMAIL PROTECTED]> wrote: It would go a long way to ease my concerns if the LLMNR specification stated clearly in its introduction that it's NOT intended to compete with mDNS, because LLMNR doesn't have any of the functionality tha

IESG powers - was: Appeal: Publication of draft-lyon-senderid-core-01 in conflict with referenced draft-schlitt-spf-classic-02

On 21:25 25/08/2005, Stephane Bortzmeyer said: If the IESG were to refuse to publish the Sender-ID document as it is, it would not "police" everything: anyone can still do what he wants on the Internet. The only thing than the IETF can do is to "bless" or not the document, Stephane, just a rem

Re: Appeal: Publication of draft-lyon-senderid-core-01 in conflict with referenced draft-schlitt-spf-classic-02

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Douglas Otis wrote: > As with any conflict, there are two parties involved. In this case, > the SPF group has essentially ignored potential conflicts by > neglecting to include support for a subsequent version of the DNS > record. This newer record e

Re: Appeal: Publication of draft-lyon-senderid-core-01 in conflict with referenced draft-schlitt-spf-classic-02

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Harald Tveit Alvestrand wrote: > not speaking for anyone but myself. > > one matter of principle: > > are you of the opinion that the IESG should try to police which > experiments get run on the Internet by refusing to publish RFCs > documenting po

Re: Last Call: 'Tags for Identifying Languages' to BCP

JFC (Jefsey) Morfin wrote: [...] Today, the common practice of nearly one billion of Internet users is to be able to turn off cookies to protect their anonymous free usage of the web. Once the Draft enters into action they will be imposed a conflicting privacy violation: "tell me what you read

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

Keith Moore wrote: What is this document for? No one has implemented this LLMNR protocol. No one has any plans to implement this protocol. No company plans to ship products using this protocol. Even Microsoft has not even hinted at plans to use LLMNR in Longhorn/Vista. I don't see anything

regarding IETF lists using mailman: nodupes considered harmful

I'm sending this to the ietf list because mailman is widely used for IETF mailing lists. Recent versions of mailman appear to have a flaw that allows the sender of a message to send a copy to everyone in a mailing list _except_ some set of explicitly specified recipients, and there will be no in

RE: Last Call: 'Tags for Identifying Languages' to BCP

At 14:42 25/08/2005, Scott Hollenbeck wrote: > -Original Message- > From: JFC (Jefsey) Morfin [mailto:[EMAIL PROTECTED] > Sent: Wednesday, August 24, 2005 11:29 PM > To: Scott Hollenbeck; ietf@ietf.org > Cc: [EMAIL PROTECTED]; ietf@ietf.org > Subject: RE: Last Call: 'Tags for Identifying

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

> What is this document for? No one has implemented this LLMNR protocol. No > one has any plans to implement this protocol. No company plans to ship > products using this protocol. Even Microsoft has not even hinted at plans > to use LLMNR in Longhorn/Vista. I don't see anything in RFC 2026 cr

Re: Appeal: Publication of draft-lyon-senderid-core-01 in conflict with referenced draft-schlitt-spf-classic-02

On Aug 25, 2005, at 11:26 AM, Ned Freed wrote: A mail-sending domain indicates that it is participating by publishing certain DNS RR's. Crucially, a mail-sending domain cannot opt in to the SPF experiment without also opting in to the senderid experiment. This renders any claimed results o

multi-RFC BCPs [Re: Fwd: I-D ACTION:draft-carpenter-bcp101-update-00.txt]

Brian E Carpenter wrote: > I read the relevant bits of 2026 a couple of times, and I am pretty > convinced that a BCP can only exist as a single RFC (which may or may not section 5.1 of 2026 reads: A specification, or group of specifications, that has, or have been approved as a BCP is ass

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

Stuart Cheshire wrote: Putting service discovery requirements aside for a moment, the other big difference between mDNS and LLMNR is that mDNS facilitates local-scoped names, analogous to RFC 1918 addresses. LLMNR lets you look up a host name without a DNS server, but it pre-supposes that you

Re: Appeal: Publication of draft-lyon-senderid-core-01 in conflict with referenced draft-schlitt-spf-classic-02

On Thu, Aug 25, 2005 at 09:25:29PM +0200, Stephane Bortzmeyer wrote: > If the IESG were to refuse to publish the Sender-ID document as it is, > it would not "police" everything: anyone can still do what he wants on > the Internet. > > The only thing than the IETF can do is to "bless" or not the do

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

>Stuart, > >do you have a published specification of Apple's mDNS that you can point >people at, so that people can understand what functionality mDNS has that >LLMNR does not? Certainly. The framework document, describing what we need and why we need it, is: Requirements for a Protocol to Re

Re: Appeal: Publication of draft-lyon-senderid-core-01 in conflict with referenced draft-schlitt-spf-classic-02

On Thu, Aug 25, 2005 at 10:14:39AM -0700, Harald Tveit Alvestrand <[EMAIL PROTECTED]> wrote a message of 41 lines which said: > are you of the opinion that the IESG should try to police which > experiments get run on the Internet by refusing to publish RFCs > documenting possibly-conflicting ex

Re: Appeal: Publication of draft-lyon-senderid-core-01 in conflict with referenced draft-schlitt-spf-classic-02

Harald Tveit Alvestrand wrote: Julian, not speaking for anyone but myself. one matter of principle: are you of the opinion that the IESG should try to police which experiments get run on the Internet by refusing to publish RFCs documenting possibly-conflicting experments? Both of thes

Re: Appeal: Publication of draft-lyon-senderid-core-01 in conflict with referenced draft-schlitt-spf-classic-02

In any case, I support this appeal to the extent that I believe the conflicts need to be resolved prior to publication. I take no position on the means by which the conflict is resolved as long as a resolution is reached. All of this raises the obvious question of the purpose in having the I

Re: Appeal: Publication of draft-lyon-senderid-core-01 in conflict with referenced draft-schlitt-spf-classic-02

On Thu, 2005-08-25 at 14:26, [EMAIL PROTECTED] wrote: > In any case, I support this appeal to the extent that I believe the conflicts > need to be resolved prior to publication. I take no position on the means > by which the conflict is resolved as long as a resolution is reached. And I wholeheart

Re: Appeal: Publication of draft-lyon-senderid-core-01 in conflict with referenced draft-schlitt-spf-classic-02

> On Thu, 2005-08-25 at 13:14, Harald Tveit Alvestrand wrote: > > are you of the opinion that the IESG should try to police which experiments > > get run on the Internet by refusing to publish RFCs documenting > > possibly-conflicting experments? > It depends on the form of the conflict. > I beli

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

On Aug 25, 2005, at 7:39 PM, Harald Tveit Alvestrand wrote: claims that browsing and service discovery is described in this draft: [DNS-SD] Cheshire, S. "DNS-Based Service Discovery", Internet- Draft

Re: Appeal: Publication of draft-lyon-senderid-core-01 in conflict with referenced draft-schlitt-spf-classic-02

On Thu, 2005-08-25 at 13:14, Harald Tveit Alvestrand wrote: > are you of the opinion that the IESG should try to police which experiments > get run on the Internet by refusing to publish RFCs documenting > possibly-conflicting experments? It depends on the form of the conflict. I believe that t

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

--On 25. august 2005 10:18 -0700 Stuart Cheshire <[EMAIL PROTECTED]> wrote: It would go a long way to ease my concerns if the LLMNR specification stated clearly in its introduction that it's NOT intended to compete with mDNS, because LLMNR doesn't have any of the functionality that mDNS provid

Re: Appeal: Publication of draft-lyon-senderid-core-01 in conflict with referenced draft-schlitt-spf-classic-02

Julian, not speaking for anyone but myself. one matter of principle: are you of the opinion that the IESG should try to police which experiments get run on the Internet by refusing to publish RFCs documenting possibly-conflicting experments? Both of these documents were published at the

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

>I do not understand how defining a new, different service on a new >port will kill anything. Are you saying that you *REALLY* do not understand how the IETF defining a new protocol, and stating publicly that it's intended to compete with some established protocol, gives all the appearance of a

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

Hi Peter, At 12:41 PM +0200 8/25/05, Peter Dambier wrote: Stuart Cheshire wrote: The IESG has received a request from the DNS Extensions WG to consider the following document: - 'Linklocal Multicast Name Resolution (LLMNR) ' as a Proposed Standard The IESG plans to make a decision in the

Re: Revised Last Call: 'SSH Transport Layer Encryption Modes' to Proposed

--On 24. august 2005 17:24 -0400 Sam Hartman <[EMAIL PROTECTED]> wrote: iesg> It is customary to include normative references to iesg> informational documents describing cryptographic algorithms. iesg> However the procedures of RFC 3967 require that this iesg> normative referen

Re: Revised Last Call: 'SSH Transport Layer Encryption Modes' to Proposed

On Thu, 2005-08-25 at 06:48, Pekka Savola wrote: > I think there needs to be separation of two different kinds of > documents, > > 1) informational, because the normative specification is elsewhere > (usually another standards organization) and we could reference the > normative spec directly

RE: Last Call: 'Tags for Identifying Languages' to BCP

JFC, In March, 1995, when RFC 1766 was published, the BCP track did not exist. The Standards Track was being used for things that were not protocols and did not fit well into the 3-stage process. Since BCPs are subject to the same consensus judging and scrutiny as standards-track documents, it

RE: Last Call: 'Tags for Identifying Languages' to BCP

> -Original Message- > From: JFC (Jefsey) Morfin [mailto:[EMAIL PROTECTED] > Sent: Wednesday, August 24, 2005 11:29 PM > To: Scott Hollenbeck; ietf@ietf.org > Cc: [EMAIL PROTECTED]; ietf@ietf.org > Subject: RE: Last Call: 'Tags for Identifying Languages' to BCP [snip] > 3. one of these

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

Stuart Cheshire wrote: The IESG has received a request from the DNS Extensions WG to consider the following document: - 'Linklocal Multicast Name Resolution (LLMNR) ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action.