On Thu Nov 26 09:28:41 2009, W.C.A. Wijngaards wrote:
* It may be prudent to have in conflict resolution a line that says
that
if repeated conflicted announcements of unique records are observed
by
another host, then the host SHOULD consider itself to have lost (and
rename itself). Or put di
james woodyatt writes:
If it could be published as standards-track, instead of informational,
*without* *any* *further* *delay*, that would be excellent. However,
I believe there is nothing to be gained for the Internet community by
any further delay in publishing this important document.
It
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
I have reviewed draft (-08) and support it, on the Informational track.
Review comments.
* The NSEC type is used for negative responses (from a discussion in
DNSEXT). However, the draft specifies that only the bitmap for types
0-255 is to be in
On 18 Nov, 2009, at 13:30, Peter Dambier wrote:
Apple supports it.
Linux supports it (mostly).
BSD supports it (mostly).
So half the world supports it.
When Microsoft too supports it, it is a standard.
I do support it (becomming a standard).
Some additional data points:
Anyone using iTunes
On 19 Nov, 2009, at 06:14, Dave Cridland wrote:
Since people thought I was merely being amusing, instead of also
intending to make a point, let me rephrase in a dry, dull, and
serious tone, so I'm no longer told it was "very amusing, but not
much help".
There exist a few protocols based a
On 23 Nov, 2009, at 09:11, Cullen Jennings wrote:
Pretty much all the emails I have received on this have suggested
we should just go publish it now. To be clear, I was not talking
about forming a WG to go do a standards track version of this. I
was talking about clicking one flag in the da
The biggest problem I have with this document is among those pointed out by
Wouter:
> * The rule that .local names MUST be sent to mdns(port 5353). I feel
> this is a little too strong, there are sites out there that have set ups
> with .local in their unicast DNS. Propose: SHOULD.
As stat
On 25 Nov, 2009, at 01:52, W.C.A. Wijngaards wrote:
* The rule that .local names MUST be sent to mdns(port 5353). I feel
this is a little too strong, there are sites out there that have
set ups
with .local in their unicast DNS. Propose: SHOULD.
I think you may be misreading this.
A stat
On 30 Nov, 2009, at 15:23, Phillip Hallam-Baker wrote:
90% of this proposal is equally relevant to the enterprise case.
But the multicast part is not.
The document is called "Multicast DNS". Which parts of the document
do you think do *not* relate to multicast?
Stuart Cheshire
* Wizard Wi
I am not so sure that immediately going to PS is the best approach
considering the overall objective. My goal here would be to encourage
the widest possible adoption of the spec by equipment manufacturers.
The weakness I see in both the Microsoft and the Apple attempts to
simplify ease of net devi
Dear colleagues,
I have read draft-cheshire-dnsext-multicastdns-08. I have some
comments. This is not an exhaustive or complete review, although I
have shared some previous observations with the authors of the
document.
First, I must emphasise that, while I currently serve as one of the
chairs
At 14:29 01-12-2009, Andrew Sullivan wrote:
The IANA Considerations section is a little coy in the way it notes
that the document reserves .local. Moreover, the action is not merely
to IANA, but strictly to ICANN, and I worry about the procedural rules
for such an action. If there is a strong r
On Tue, Dec 01, 2009 at 04:21:02PM -0800, SM wrote:
>
> "Note that this use of the ".local." suffix falls under IETF/IANA
> jurisdiction, not ICANN jurisdiction."
>
> This draft mentions that the IETF has the authority to instruct IANA to
> reserve pseudo-TLDs as required for protocol design p
On Wed, Dec 02, 2009 at 12:35:11PM -0500, Phillip Hallam-Baker wrote:
> I want my personal machines to be part of the .hallambaker.com DNS
> domain and look for configuration data there. I want my business
> machines to be part of the .defaultdenysecurity.com domain and look
> for configuration da
If multicast worked it would be the ideal protocol for NNTP. As far as
an NNTP client is concerned, the protocol could be functioning over
multicast.
In practice of course multicast would not be a useful protocol for
NNTP because you would at a minimum need a separate multicast channel
per newsgro
I don't think the IESG or ICANN should go there, or anywhere close.
There are three options:
1) Do not reserve .local. This would effectively mean throwing out the
draft as it depends on .local
2) Reserve .local for this particular protocol. This would be
inconsistent with current legacy use and
The alternative would be to not use .local at all and insist on that
approach as a means of avoiding ICANNs perceived perogatives. I think
that would be a bad idea as the spec would not serve its intended
purpose.
On Wed, Dec 2, 2009 at 1:55 PM, Andrew Sullivan wrote:
> On Wed, Dec 02, 2009 at
At 06:27 02-12-2009, Andrew Sullivan wrote:
There is in fact a request, it's just made indirectly. That was my
complaint.
I'll second your complaint. RFC 5226 provides guidelines to authors
on what sort of text should be added to their documents in order to
provide IANA clear guidelines. I
On 2009-12-02, at 14:12, Phillip Hallam-Baker wrote:
> The alternative would be to not use .local at all and insist on that
> approach as a means of avoiding ICANNs perceived perogatives. I think
> that would be a bad idea as the spec would not serve its intended
> purpose.
Given the existing de
On 2009-12-04, at 07:38, Phillip Hallam-Baker wrote:
> 'largely semantic?'
Yes, by which I meant having little practical impact on the business of
shifting packets on the network. The other text that you couldn't see due to
the searing bright pain you apparently felt when presented with the tw
On Wed, Dec 02, 2009 at 02:12:01PM -0500, Phillip Hallam-Baker wrote:
> The alternative would be to not use .local at all and insist on that
> approach as a means of avoiding ICANNs perceived perogatives. I think
> that would be a bad idea as the spec would not serve its intended
> purpose.
I've b
'largely semantic?'
Please do not ever use that phrase again as an attempt to dismiss the
importance of an argument
SEMANTICS IS MEANING
EVERY argument in the IETF is an argument in semantics, that is the
alpha and omega of the IETF process.
Arguments over semantics are only trivial when they
Can someone walk me through the pro/cons of this being standards track
vs informational?
Thanks, Cullen
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
On Wed Nov 18 15:41:18 2009, Cullen Jennings wrote:
Can someone walk me through the pro/cons of this being standards
track vs informational?
Cons:
For one thing, it's a lot of work to make a specification like this
up to the quality of the standards-track.
Some of the 20 or so mentions
> >The IESG has received a request from an individual submitter to consider
> >the following document:
> >
> >- 'Multicast DNS '
> > as an Informational RFC
> >
> >The IESG plans to make a decision in the next few weeks, and solicits
> >final comments on this action. Please send substantive co
Cullen Jennings wrote:
>
> Can someone walk me through the pro/cons of this being standards track
> vs informational?
>
Apple supports it.
Linux supports it (mostly).
BSD supports it (mostly).
So half the world supports it.
When Microsoft too supports it, it is a standard.
I do support it (bec
On Nov 18, 2009, at 9:45 AM, Paul Vixie wrote:
>>> The IESG has received a request from an individual submitter to consider
>>> the following document:
>>>
>>> - 'Multicast DNS '
>>>as an Informational RFC
>>>
>>> The IESG plans to make a decision in the next few weeks, and solicits
>>> fin
Since people thought I was merely being amusing, instead of also
intending to make a point, let me rephrase in a dry, dull, and
serious tone, so I'm no longer told it was "very amusing, but not
much help".
There exist a few protocols based around mDNS and DNS-SD, in
particular in combinat
Hi Cullen, folks,
It seems to me ...
There have been a number of cases where things are not developed
within the IETF
but are "out there".
Whether or not folk LIKE those schemes/the companies that promulgate
them/the author(s)
/the document style/the weather is not really important.
Having
+1 to Informational. Let's get this documentation out there in a stable
reference. That doesn't preclude publishing a standards-track version in
the future...
On 11/22/09 5:17 PM, Lawrence Conroy wrote:
> Hi Cullen, folks,
> It seems to me ...
> There have been a number of cases where things are
On Mon Nov 23 00:17:45 2009, Lawrence Conroy wrote:
There have been a number of cases where things are not developed
within the IETF
but are "out there".
Agreed.
Whether or not folk LIKE those schemes/the companies that
promulgate them/the author(s)
/the document style/the weather is n
Dave Cridland writes:
So I reiterate - I see no reason not to charter a working group to
revise this specification (and dns-sd), and I would welcome such a
group being chartered such that it cannot make any incompatible
changes to the protocol.
+1
Except that I'd put the compatibility req
On 11/23/09 6:49 AM, Dave Cridland wrote:
> On Mon Nov 23 00:17:45 2009, Lawrence Conroy wrote:
>
>> Having an Informational RFC to describe these protocols or file
>> formats is useful.
>> If nothing else, it tells you what the heck is going on down the wire.
>
> Right, this much I agree with.
Pretty much all the emails I have received on this have suggested we should
just go publish it now. To be clear, I was not talking about forming a WG to go
do a standards track version of this. I was talking about clicking one flag in
the data tracker and changing it from information to standar
Hello Cullen,
I have started reading draft-cheshire-dnsext-multicastdns for an Apps
Area review. I also started asking myself the question of "standards
track vs. informational". However, this was not in the general sense,
but in regards to some very specific issues. In the general sense, I wa
On Wed, Nov 18, 2009 at 06:07:17AM -0800,
The IESG wrote
a message of 23 lines which said:
> - 'Multicast DNS '
> as an Informational RFC
I do not think that the publication of this document as it is would be
a good idea.
The main reason is that it reserves a Top-Level Domain (".local")
On Nov 19, 2009, at 06:14 , Dave Cridland wrote:
>
> There exist a few protocols based around mDNS and DNS-SD, in particular in
> combination, and the general high-level design of both protocols is
> essentially sound. These are sometimes standards-track specifications of the
> IETF - I seem to
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
I have reviewed draft (-08) and support it, on the Informational track.
(apologies for any duplicates as I tried to send this unsubscribed)
Review comments.
* The NSEC type is used for negative responses (from a discussion in
DNSEXT). However,
38 matches
Mail list logo