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
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 been
'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
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
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 purposes.
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 data
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
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
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 a...@shinkuro.com wrote:
On Wed,
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 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
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
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
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 stated
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
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
-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).
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
On Wed, Nov 18, 2009 at 06:07:17AM -0800,
The IESG iesg-secret...@ietf.org wrote
a message of 23 lines which said:
- 'Multicast DNS '
draft-cheshire-dnsext-multicastdns-08.txt as an Informational RFC
I do not think that the publication of this document as it is would be
a good idea.
The
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
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
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
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. And if
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
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 was
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
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
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
The IESG has received a request from an individual submitter to consider
the following document:
- 'Multicast DNS '
draft-cheshire-dnsext-multicastdns-08.txt as an Informational RFC
The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.
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
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 '
draft-cheshire-dnsext-multicastdns-08.txt as an Informational RFC
The IESG plans to make a decision in the next few weeks,
The IESG has received a request from an individual submitter to consider
the following document:
- 'Multicast DNS '
draft-cheshire-dnsext-multicastdns-08.txt as an Informational RFC
The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please
36 matches
Mail list logo
