Re: Last Call: draft-cheshire-dnsext-multicastdns (Multicast DNS) to Informational RFC
-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, the draft specifies that only the bitmap for types 0-255 is to be included. I feel this is overly constrained. The restriction may prove burdensome, also since those types are not really in use anyway (except DLV), the effect of the rule is very low. Is this for backwards compatibility? If it is for packet size, well, TXT records can be large too and are not disallowed either. * The document is verbose, but well written. * 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. * The mdns resolver is highly integrated into the device it is on, with an 'active interest and notification API'-recommended, with interface changes (up down netmasks) and sleep-wake cycle information used. Thus this is very different from unicast DNS, whose servers are more independent. The rule to do punycode (unicast) to utf8 (multicast) conversion does not make the codebase smaller. * There is a line about the use of DNSSEC when mdns is used during a unicast DNS outage. The sentiment about protecting against forged answers is fine (this issue is handled well in general), but I think building a chain of trust towards DNSSEC-attested data is going to be very hard when unicast DNS is down. * I noted that the TC flag on unicast still means TCP fallback but this does not work in all cases. It is of course very useful to get large replies to legacy (unicast) queriers. Case: the other hosts can see a multicast query, and the full answer cannot be sent on multicast (due to size, even with TC=1 on multicast for message concatenation), the other hosts conclude there is no answer after timeout. The unicast response to the querier does have the required effect, but only for the original querier. This is probably not an issue since such large (9kb RR rdata) records are not common. A response that would trigger TCP connections from all multicast hosts on the network is probably not such a good idea :-) Some multicast error response, SERVFAIL for that query, so the other hosts do not modify their cache? (since existing code ignores rcode!=0, this is probably backwards compatible) * 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 differently: if a particular host on the network keeps causing conflicts, get out of the way, even if the spec says you should have won, because this avoids packet-chatter on the network. Best regards, Wouter -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAksOSkkACgkQkDLqNwOhpPg5PACfaUMmPV/IB5+AzDQ2rDlmQsnc nBkAnAv3WG5fdRoi41EKIWcyx/3oQblB =k2RH -END PGP SIGNATURE- ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: rfc3848 (ESMTP and LMTP Transmission Types Registration) to Draft Standard
At 11:34 AM 11/25/2009, The IESG wrote: The IESG has received a request from an individual submitter to consider the following document: - 'ESMTP and LMTP Transmission Types Registration ' RFC 3848 as a Draft Standard I support this move. Implementation Report can be accessed at http://www.ietf.org/iesg/implementation.html That's a 404. Regards, -sm ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: rfc3848 (ESMTP and LMTP Transmission Types Registration) to Draft Standard
SM wrote: At 11:34 AM 11/25/2009, The IESG wrote: [...] Implementation Report can be accessed at http://www.ietf.org/iesg/implementation.html That's a 404. It was working yesterday. But the implementation report for RFC 3848 is not there yet, it is in the datatracker. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-cheshire-dnsext-multicastdns (Multicast DNS) to Informational RFC
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 differently: if a particular host on the network keeps causing conflicts, get out of the way, even if the spec says you should have won, because this avoids packet-chatter on the network. Wouldn't this lead to a potential attack by deliberately introducing a conflict and taking over a name? Currently, it's possible to take over a name by advertising, for example, an A record for a name with a higher IP address - since you can easily advertise a name with an arbitarily high IP address, this is fairly easy to do, but it'd be far simpler just to ignore the probe protcol entirely, as that leads to a more seamless takeover of a particular name in most circumstances. Of course, DNSSEC might help here, but presumes that either a participant has the ability to sign RRs online, or else is a silent partner with a preconfigured trust anchor. (In general, I find the comments in the document about DNSSEC somewhat hand-wavy, but I admit I lack much knowledge about DNSSEC). Still, if all participants have access to the private key for DNSSEC, that provides a significant number of possible attack points, I'd have thought - I'm assuming here that things like your network printer need to be configured with the private key, which may not be the case. Dave. -- Dave Cridland - mailto:d...@cridland.net - xmpp:d...@dave.cridland.net - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: rfc3848 (ESMTP and LMTP Transmission Types Registration) to Draft Standard
On 25 Nov 2009, at 19:34, The IESG wrote: The IESG has received a request from an individual submitter to consider the following document: - 'ESMTP and LMTP Transmission Types Registration ' RFC 3848 as a Draft Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. This is good. Sendmail's covered with the standard cf rules, except that LMTP only works without extensions (I haven't checked whether that's relevant for Sendmail, or indeed how one might change it without rewriting the header lines by hand, but I'll say it's probably possible). I still can't think what use the keywords are, actually, for receivers. Perhaps somebody could explain it to me? Cheers, Sabahattin ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [Gen-art] Gen-ART LC review of draft-dusseault-http-patch-15.txt
Roy T. Fielding wrote: On Nov 17, 2009, at 11:53 AM, Brian E Carpenter wrote: These are the sort of changes that would, I believe, give sufficient indication to a would-be user of PATCH of how to make it somewhat safe. Personally I'd prefer to see it made more prominent by starting with something like: Clients requiring to verify the consistent application of a patch document to a known entity SHOULD first acquire an ETag... Rationale: the use of a normative keyword will draw the attention of implementors who might otherwise not think about this issue. It would also be wrong, because it is neither a requirement for interoperation nor a potential for causing harm (RFC 2119). Aside from which, it makes the original purpose of PATCH non-compliant with its own specification. The purpose of PATCH is to request that the server apply a set of changes to the current state of the target resource. The assumption that these changes will be dependent on a specific prior representation of that resource is false. The server is fully capable of detecting and reporting conflicts when they occur with the current state, as only truly known by the server. In other words ... If the client wants to prevent the PATCH method from being applied to a resource for which the state has changed since the last state known by the client, then it SHOULD use one or more of the conditional request mechanisms of HTTP (If-Match and If-Unmodified-Since request headers [RFC2616]) or WebDAV (If request header [RFC4918]) with the associated metadata from that prior resource state. However, if the patch media type contains its own mechanism for detecting conflicts, such as embedded context or metadata designed to allow non-overlapping changes to be safely applied, then the conditional request mechanisms SHOULD NOT be used with PATCH because they would interfere with collaborative applications, such as shared editors and whiteboards. FTR, the prior sentence, that PATCH is somehow more likely to result in corrupted state than a PUT, is simply false for any patch format that contains context or post-application integrity checks. The only reason it was in the spec is because earlier versions assumed a patch format that contains nothing but byte-vector manipulations. It should be removed, or at least altered to be factual. Roy In the meantime, a new draft was published, see http://tools.ietf.org/html/draft-dusseault-http-patch-16 and http://tools.ietf.org/rfcdiff?url2=draft-dusseault-http-patch-16.txt for the diffs. The new text is: A PATCH request can be issued in such a way as to be idempotent, which also helps prevent bad outcomes from collisions between two PATCH requests on the same resource in a similar timeframe. Collisions from multiple PATCH requests may be more dangerous than PUT collisions, because some patch formats need to operate from a known base point or else corrupt the resource. Clients using this kind of patch application SHOULD acquire a strong ETag [RFC2616] for the resource to be modified, and use that ETag in the If-Match header on the PATCH request to verify that the resource is still unchanged. If a strong ETag is not available for a given resource, the client can use If-Unmodified-Since as a less-reliable safeguard. This text is still problematic, in that 1) It suggests that the client is in control of the etag (...acquiere a strong etag...); however, the client has no control over this at all; it's the server who decides, and also it's the server who's in charge in deciding what type of etags it accepts in which operations. 2) It doesn't mention that WebDAV defines another conditional header which doesn't have the limitations of If-Match (per RFC2616, not HTTPbis). I found Roy's proposal both easy to understand and correct, and like to see it (or something more similar to it than the current text) being used. Best regards, Julian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: silly legal boilerplate, was Regarding RIM's recent IPR disclosures
A better response would be to send the stupid boilerplate (and only the boilerplate, not the real message, or its headers) to the CEO (or corporate lawyer, or similar) of the organisation that sent the message, along with text something like... I thank an employee of your organisation for the message sent to me. This note is to inform you that I do not accept, and will not cooperate with your organisation's non disclosure request (as shown herein). If you did not intend the information contained in the message to become available to the public, your organisation should not have sent it to me. While I respect your copyright of the message itself, I will use the information I learned from the message to my own advantage, and that of anyone else I feel will be able to profit from its contents. Once again, thanks again for supplying me with this valuable information. and nothing else. A far better strategy would be to pick a law journal or other publication directed at the legal industry, and then send the above in a letter to the editor, prefixed with a question as to whether anyone believes that such disclaimers carry any legal weight. Choose a publication that is in the same legal jurisdiction as the company whose email messages carry the disclaimer. If enough people do that, eventually a few of these letters to the editor will get published, and the whole thing will get more discussion within the legal industry. I suppose it would also work to choose prominent newspapers that are typically read by lawyers, in the USA, New York Times or Washington Post, in the UK, The Times, or The Guardian, in Australia, the Sydney Morning Herald. --Michael Dillon ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: rfc3848 (ESMTP and LMTP Transmission Types Registration) to Draft Standard
On Thu, 26 Nov 2009, Sabahattin Gucukoglu wrote:
On 25 Nov 2009, at 19:34, The IESG wrote:
The IESG has received a request from an individual submitter to consider
the following document:
- 'ESMTP and LMTP Transmission Types Registration '
RFC 3848 as a Draft Standard
This is good.
Yes.
I still can't think what use the keywords are, actually, for receivers.
Perhaps somebody could explain it to me?
SpamAssassin uses it to identify message submission hops.
Exim uses these protocol names in its logs, which is convenient for
statistics gatherers.
Tony.
--
f...@exim.org d...@dotat.at http://dotat.at/ ${sg{\N${sg{\
N\}{([^N]*)(.)(.)(.*)}{\$1\$3\$2\$1\$3\n\$2\$3\$4\$3\n\$3\$2\$4}}\
\N}{([^N]*)(.)(.)(.*)}{\$1\$3\$2\$1\$3\n\$2\$3\$4\$3\n\$3\$2\$4}}
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
Re: [rfc-i] Important: do not publish draft-iab-streams-headers-boilerplates-08 as is!
Jim Schaad wrote: Let's just get this published and go with what we have even if it does not necessarily read real pretty. The text of the strings can be updated at a later point by a modification of the RFC Style Guide if there are enough complaints about how the text looks. Given that it is boilerplate, I personally don't care that it does not flow. Jim Jim, Understood, but the RFC Editor does care how it flows. We would like to get it as nearly right as possible, going out of the gate. Bob Braden ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [rfc-i] Important: do not publish draft-iab-streams-headers-boilerplates-08 as is!
Bob Braden wrote: Jim Schaad wrote: Let's just get this published and go with what we have even if it does not necessarily read real pretty. Ready Fire Aim has characterized the pattern of IPR work on this topic in recent years, and the results have been exactly as messy as one would predict. This is a running system. Changes need to be made cautiously, with an eye towards safe and correct operations. We -- the part of the IETF that has been imposing changes -- haven't been doing that very well. We should fix that, before we blast out more problematic changes. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Weekly posting summary for ietf@ietf.org
Total of 73 messages in the last 7 days. script run at: Fri Nov 27 00:53:01 EST 2009 Messages | Bytes| Who +--++--+ 9.59% |7 | 9.39% |48092 | hal...@gmail.com 6.85% |5 | 6.99% |35775 | julian.resc...@gmx.de 5.48% |4 | 3.86% |19770 | jo...@iecc.com 2.74% |2 | 6.27% |32095 | stpe...@stpeter.im 4.11% |3 | 3.90% |19983 | d...@cridland.net 4.11% |3 | 3.58% |18342 | agma...@gmail.com 4.11% |3 | 2.80% |14324 | d...@dcrocker.net 1.37% |1 | 5.05% |25835 | rfc-edi...@rfc-editor.org 2.74% |2 | 3.16% |16170 | a...@tr-sys.de 2.74% |2 | 3.08% |15756 | b...@estacado.net 2.74% |2 | 3.06% |15648 | j...@joelhalpern.com 2.74% |2 | 2.33% |11908 | si...@josefsson.org 2.74% |2 | 2.26% |11572 | hous...@vigilsec.com 2.74% |2 | 2.17% |11126 | jorge.contre...@wilmerhale.com 2.74% |2 | 2.00% |10252 | k...@munnari.oz.au 2.74% |2 | 1.91% | 9766 | flu...@cisco.com 2.74% |2 | 1.87% | 9552 | m...@sabahattin-gucukoglu.com 1.37% |1 | 2.76% |14131 | gash5...@yahoo.com 1.37% |1 | 2.66% |13606 | t...@americafree.tv 1.37% |1 | 2.38% |12168 | e...@hueniverse.com 1.37% |1 | 2.00% |10237 | magnus.westerl...@ericsson.com 1.37% |1 | 1.77% | 9046 | lisa.dussea...@gmail.com 1.37% |1 | 1.73% | 8883 | lars.egg...@nokia.com 1.37% |1 | 1.47% | 7533 | cwall...@cygnacom.com 1.37% |1 | 1.43% | 7344 | nar...@us.ibm.com 1.37% |1 | 1.39% | 7115 | wou...@nlnetlabs.nl 1.37% |1 | 1.31% | 6683 | thierry.mor...@connotech.com 1.37% |1 | 1.27% | 6497 | j...@apple.com 1.37% |1 | 1.24% | 6368 | bortzme...@nic.fr 1.37% |1 | 1.24% | 6358 | jari.ar...@piuha.net 1.37% |1 | 1.22% | 6249 | wavetos...@googlemail.com 1.37% |1 | 1.20% | 6127 | p...@cisco.com 1.37% |1 | 1.17% | 6005 | scott.b...@gmail.com 1.37% |1 | 1.04% | 5331 | due...@it.aoyama.ac.jp 1.37% |1 | 1.00% | 5105 | f...@cisco.com 1.37% |1 | 0.99% | 5065 | t...@att.com 1.37% |1 | 0.98% | 5014 | lcon...@insensate.co.uk 1.37% |1 | 0.95% | 4862 | d...@dotat.at 1.37% |1 | 0.92% | 4701 | s...@cs.columbia.edu 1.37% |1 | 0.90% | 4613 | s...@resistor.net 1.37% |1 | 0.87% | 4434 | a...@gulbrandsen.priv.no 1.37% |1 | 0.85% | 4365 | bra...@isi.edu 1.37% |1 | 0.85% | 4353 | ned+i...@mauve.mrochek.com 1.37% |1 | 0.76% | 3893 | alexey.melni...@isode.com +--++--+ 100.00% | 73 |100.00% | 512052 | Total ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
