Re: Last Call: draft-cheshire-dnsext-dns-sd (DNS-Based Service Discovery) to Informational RFC
Am 20.11.2008 um 00:02 schrieb Chris Newman: --On November 4, 2008 6:28:19 -0800 The IESG iesg- [EMAIL PROTECTED] wrote: The IESG has received a request from an individual submitter to consider the following document: - 'DNS-Based Service Discovery ' draft-cheshire-dnsext-dns-sd-05.txt as an Informational RFC end user, I strongly support publication of this document, hello all, if this is the question , i would recomend that as an end- user too , just currious that mr. cheshire does not respond;) What is the title of the registry that will be listed on IANA's web page? Do you believe it would be possible to merge the new service registry with this one: http://www.iana.org/assignments/gssapi-service-names creating a single service-name registry shared by these protocols? have a great day Marc -- Marc Manthey Hildeboldplatz 1a D - 50672 Köln - Germany Tel.:0049-221-3558032 Mobil:0049-1577-3329231 web : http://www.let.de PGP/GnuPG: 0x1ac02f3296b12b4d___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [BEHAVE] Lack of need for 66nat : Long term impact to application developers
On 23 nov 2008, at 20:25, Tony Hain wrote: The fundamental problem here is that the voices of those bearing the costs in the core are being represented, while the voices of those doing application development are not being heard. Not sure that's entirely true... But in any event, compared to the backflips through flaming hoops we have to do in IPv4, the asking a remote server what our source address looks like from the outside to make address based referrals work doesn't seem too onerous. Or do you disagree? ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Gen-art review of draft-ietf-monami6-multiplecoa-10.txt
I have been selected as the General Area Review Team (Gen-ART) reviewer for this draft (for background on Gen-ART, please see _http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html_). Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-monami6-multiplecoa-10.txt Reviewer: Elwyn Davies Review Date: 24 November 2008 IETF LC End Date: 17 November 2008 IESG Telechat date: (if known) - Summary: This document is almost ready for the IESG. It has a number of minor issues plus a fair number of editorial nits. I am sending the editirial issues to the authors separately as there are lots of acronyms needing expansion and minor english improvements that woild be tedious to transcribe. Apologies for the late review. Comments: Minor Issues: Backwards compatibility: It would be helpful to explain in the introduction why this proposal is backwatds compatible with the RFC 3775 scheme. The explanations are there but are buried in the error cases of s5.7 and is easily mossed (as I did on early reading). Extension to IPv4 correspondents etc: Something about this in the ontroduction would also help. s2 and several other places (s4.2, s5.1): Use of zero as a binding ID (BID) is forbidden. It is unclear why this value is not allowed - it does not AFAICS specify reversion to RFC 3775 behaviour or anything similar: Forbidding it seems gratuitous. s2: Specifying that the BID must not be negative is sloghtly confusing because the protocol is specified so that negative values cannot be carried. s4.2 (two places), s6.2 (2nd bullet), s6.2 (6th bullet, 1st sub-bullet): The length of the Binding Address mobility option for the IPv4 case is specified inconsistently. Some places have been corrected from 12 to 8 but several others remain. s4.2: The Reserved fiels is normally specified as 'SHOULD be ignored by the receiver'. Makes it easier to cope with later changes. s4.3 (MCOA NOTCOMPLETE) and elsewhere (s6.2): I am dubious about the non-transactional nature of bulk registrations: some additional discussion of why it should be reasonable that a bulk registration can fail in part would be useful s4.3 (MCOA MALFORNED): Some indoication of the circumstances under which this can occur would be useful. s4.3 (MCOA BULK REGISTRATION PROHIBITED) and s5.3: I think there is a 'crner case' in which a bulk registration is sent to a leagcay RFC 3775 node: the node would not be capable of this response. This corner case is not described in s5.3 s5.3: What error status is sent if the user has an Alernate care-of address option with a bulk registration? s5.5.2, last para: Arguably, if the interface is shut down the node os not (IP) connected to its home link! s5.6.3 (2nd bullet) and s6.1 (para 2): Using 'ex.' is not good: It is not a standard abbreviation. I take it 'except' is meant. s5.6.3 (3rd bullet): 'The mobile node SHOULD include the Link-layer Address (LLA) Option': I do not understand how the home agent would be able to send to the mobile node if the LLA option was omitted. I think this is a 'MUST' or maybe a 'needs to'. s5.6.4 (2nd top level bullet): 'the home agent SHOULD use the link-layer address carried by the Link Layer Address option': Again I am not sure what alternative there is? Replace with either 'MUST' or 'needs to'. s5.7 (2nd bullet): s/SHOULD/needs to/: This is not something sthat is an option in the protocol. Also I think it should state that the mobile node needs to assume that none of the attempted registrations were successful. s5.7 (3rd bullet): Explain what could cause the packet to be malformed. s5.7 (4th bullet): Replace 1st instance of SHOULD with 'needs to'. Explain that the 2nd case can occur during 'bootsatrpa' (pointer to s5.9). s6.2 (para 2): If bulk registrations are not transactional (which I would have preferred) need to make it clear what happens with the vrarious multiple mobility options when some are succcessful and some fail. s6.2 (2nd bullet): 'When the Length value is either 8 or 20, the care-of address MUST be present in the Binding Identifier mobility option. If the valid care-of address is not present, the receiver MUST reject the Binding Identifier mobility option and returns the status value set to [MCOA MALFORMED].' This is poorly phrased. If the length is set to 8 or 20, then there is space in the option for an address of some sort. It sort of implies that the bit pattern can be tested to see if it is a valid address - how is this done? It strikes me tht it would simpler just to day that the address is ignored if present when not required (or, if being paranoid, must be the same as was previously registered (if present) when deleting a registration). s6.2 (1st para after lost of bullets): s/can be omitted/MAY be omitted/ Editorial: I have sent a Word document with many nits marked up to the authors. ___ Ietf mailing list Ietf@ietf.org
Re: [BEHAVE] Lack of need for 66nat : Long term impact to application developers
Iljitsch van Beijnum wrote: On 23 nov 2008, at 20:25, Tony Hain wrote: The fundamental problem here is that the voices of those bearing the costs in the core are being represented, while the voices of those doing application development are not being heard. Not sure that's entirely true... But in any event, compared to the backflips through flaming hoops we have to do in IPv4, the asking a remote server what our source address looks like from the outside to make address based referrals work doesn't seem too onerous. Or do you disagree? absolutely it's too onerous. why in the world should an application's deployability depend on the existence of a server that lives in global address space -- or for that matter, on a bank of servers that exist to do nothing but forward traffic? isn't that what the network is supposed to do? Keith ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [BEHAVE] Lack of need for 66nat : Long term impact to application developers
On Tue, 25 Nov 2008, Keith Moore wrote: Iljitsch van Beijnum wrote: On 23 nov 2008, at 20:25, Tony Hain wrote: The fundamental problem here is that the voices of those bearing the costs in the core are being represented, while the voices of those doing application development are not being heard. Not sure that's entirely true... But in any event, compared to the backflips through flaming hoops we have to do in IPv4, the asking a remote server what our source address looks like from the outside to make address based referrals work doesn't seem too onerous. Or do you disagree? absolutely it's too onerous. why in the world should an application's deployability depend on the existence of a server that lives in global address space -- or for that matter, on a bank of servers that exist to do nothing but forward traffic? isn't that what the network is supposed to do? Actually, he did not say the server forwarded traffic, just that it provided a way to learn how 'my' address was mapped through 'my' nat. A ip-ip mapping lookup service, probably not all that different than DNS or the service the telcos use to map 8xx numbers to actual phones, or phone numbers to specific terminal devices on specific carriers. I don't know if that is a good approach or not but I find it quite a bit less onerous than routing all traffic via an intermediate server. And it seemed the question wasn't understood. Dave Morris ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [BEHAVE] Lack of need for 66nat : Long term impact to application developers
David Morris wrote: Actually, he did not say the server forwarded traffic, just that it provided a way to learn how 'my' address was mapped through 'my' nat. I understand. But in practice just knowing your external address is often insufficient. You need an intermediate server that will forward traffic as well as maintain the bindings in both (nay, all) endpoints' NATs. If we're going to standardize NATs of any kind, they need to be defined in such a way that no external server is necessary - not to determine one's external IP address, nor to forward traffic between hosts that are all behind NATs, nor to maintain state in the NAT, nor to determine a host's 'external' IP address or port, nor to listen for traffic intended for a host behind a NAT. All of this functionality (and more) needs to be built in to the NAT itself. Furthermore it's not sufficient to just define a NAT with a bidirectional, algorithmic mapping (in order to avoid some of these problems) because what people have come to expect from NAT (and to rely on) is that incoming connections are denied by default. So really, to be viable, any NAT standard needs to include some amount of firewall functionality. And the firewall needs to be able to keep working even if the NAT function is turned off. Keith ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [BEHAVE] Lack of need for 66nat : Long term impact to application developers
Keith == Keith Moore [EMAIL PROTECTED] writes: Keith I understand. But in practice just knowing your external Keith address is often insufficient. You need an intermediate Keith server that will forward traffic as well as maintain the Keith bindings in both (nay, all) endpoints' NATs. Keith If we're going to standardize NATs of any kind, they need Keith to be defined in such a way that no external server is Keith necessary - not to determine one's external IP address, nor Keith to forward traffic between hosts that are all behind NATs, Keith nor to maintain state in the NAT, nor to determine a host's Keith 'external' IP address or port, nor to listen for traffic Keith intended for a host behind a NAT. All of this Keith functionality (and more) needs to be built in to the NAT Keith itself. Keith, would the NAT-66 proposal plus some mechanism for a server inside the NAT to ask the NAT for its global address be sufficient to meet the needs described above? How about the existing proposal plus an IPV6 anycast address for a stun-like protocol? If not, why not? I'm a bit concerned about adding requirements that would involve solving the NAT discovery problem. We've already had a lot of bad luck with that approach in protocols like midcom, nsis, etc. In contrast, in environments where it works, stun has been quite successful. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: [BEHAVE] Lack of need for 66nat : Long term impact to application developers
Iljitsch van Beijnum wrote: ... But in any event, compared to the backflips through flaming hoops we have to do in IPv4, the asking a remote server what our source address looks like from the outside to make address based referrals work doesn't seem too onerous. Or do you disagree? Who do you ask??? Your note assumes there is only one 'outside', so any server could answer the question. There is absolutely no restriction on where and how topology warts are deployed, so asking a server in network A what your address will appear to be to network B is fundamentally absurd. I have heard similar comments from the document authors recognizing this problem, but hand-waving something about asking a service before populating DNS, while completely ignoring the fact that there is no way to predict in advance who will want to know or where they will be attached. Essentially a server is not reachable until it guesses that network B exists, someone wants to contact it from there, and where the service is to ask about the address that the server appears to be. There is no valid reason for 66nat. The only justifications being given are 'people will do it anyway', and 'we have to move quickly because vendors are trying to build it'. This is called railroading in any other context, and absolutely no long term thought is going into the impact and inability to remove this once it is unleashed. Tony ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [BEHAVE] Lack of need for 66nat : Long term impact to application developers
Tony, On Nov 25, 2008, at 2:10 PM, Tony Hain wrote: There is no valid reason for 66nat. Then it will die in the marketplace and any standardization efforts will simply fade away. The only justifications being given are 'people will do it anyway', and 'we have to move quickly because vendors are trying to build it'. This is called railroading in any other context, and absolutely no long term thought is going into the impact and inability to remove this once it is unleashed. So, if vendors are trying to build it, it would seem to me that an industry group focused on standardizing its functionality would be a good thing, otherwise we get into the same mess we got into with IPv4. If vendors aren't trying to build it, no significant harm is done (other than the waste of time for folks participating in the standardization). Putting our fingers in our ears and singing la la la because we don't think a particular technology should exist is unlikely to be particularly beneficial. Regards, -drc ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Gen-ART LC Review of draft-ietf-mpls-te-scaling-analysis-03
Document: draft-ietf-mpls-te-scaling-analysis-03 Reviewer: Ben Campbell Review Date: 2008-11-25 IETF LC End Date: 2008-11-30 IESG Telechat date: (if known) Summary: This draft is ready for publication as an informational RFC. Nits: -- Don't forget the new IPR boilerplate. -- Abstract, paragraph 3: Section 8 talks about MP2P, so it is not strictly true that this document only considers P2P . (Repeated at end of introduction). -- Section 2, 1st paragraph: Please expand LSR on first mention. -- Section 2.4, 2nd paragraph: Please expand NMS and EMS on first mention. -- Section 3.3, paragraph 2: The consideration must be... Is there a word missing? I assume you don't mean The consideration to mean the _only_ consideration, since you mention others below. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [BEHAVE] Lack of need for 66nat : Long term impact to application developers
Sam Hartman wrote: Keith == Keith Moore [EMAIL PROTECTED] writes: Keith I understand. But in practice just knowing your external Keith address is often insufficient. You need an intermediate Keith server that will forward traffic as well as maintain the Keith bindings in both (nay, all) endpoints' NATs. Keith If we're going to standardize NATs of any kind, they need Keith to be defined in such a way that no external server is Keith necessary - not to determine one's external IP address, nor Keith to forward traffic between hosts that are all behind NATs, Keith nor to maintain state in the NAT, nor to determine a host's Keith 'external' IP address or port, nor to listen for traffic Keith intended for a host behind a NAT. All of this Keith functionality (and more) needs to be built in to the NAT Keith itself. Keith, would the NAT-66 proposal plus some mechanism for a server inside the NAT to ask the NAT for its global address be sufficient to meet the needs described above? How about the existing proposal plus an IPV6 anycast address for a stun-like protocol? If not, why not? I don't think so in either case. The reason I don't think so is that I suspect the NAT traversal problem is really a firewall traversal problem in disguise. People say they want NATs when what they mostly want is stateful firewalls and maybe some topology hiding. We might get them to move to stateless NATs with bidirectional algorithmic mapping and a STUN-like protocol, but they'll still want a statefull firewall to be bundled in to block incoming connections. And if there's a statefull firewall that denies incoming connections by default, there will still be a need for an intermediary in the network core that can arrange for traffic to be forwarded between two hosts that are behind firewalls. And there will be little incentive for any network admin to get rid of NAT, because as long as those firewalls are in the way, doing so won't enable many more applications. So if we really want to get rid of NAT, I think we have to resolve a tussle between users and application developers on one hand, and enterprise network operators on the other. The tussle is over two things: (1) how to restrict the kinds of traffic that can be sent over the network, how to communicate those restrictions to apps, and what kind of behavior is reasonable for apps that are presented with such restrictions. (2) to what extent network admins can control what programs are used on hosts that attach to their networks. Hey, I didn't say it was easy. But I don't think anything less will get rid of the need for the kinds of workarounds apps currently have to use to deal with NATs. Even if we got rid of NAT, we wouldn't solve the problem (and NATs wouldn't matter too much) if apps still have to use those workarounds. Keith ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: [BEHAVE] Lack of need for 66nat : Long term impact to application developers
David Conrad wrote: Tony, On Nov 25, 2008, at 2:10 PM, Tony Hain wrote: There is no valid reason for 66nat. Then it will die in the marketplace and any standardization efforts will simply fade away. No it won't, because people will have deployed it in default configurations without realizing they didn't need it. The only justifications being given are 'people will do it anyway', and 'we have to move quickly because vendors are trying to build it'. This is called railroading in any other context, and absolutely no long term thought is going into the impact and inability to remove this once it is unleashed. So, if vendors are trying to build it, it would seem to me that an industry group focused on standardizing its functionality would be a good thing, otherwise we get into the same mess we got into with IPv4. If vendors aren't trying to build it, no significant harm is done (other than the waste of time for folks participating in the standardization). Putting our fingers in our ears and singing la la la because we don't think a particular technology should exist is unlikely to be particularly beneficial. This is not about ignoring the technology, it is about blindly legitimizing short-term money making for a few box vendors at the long term expense to the entire Internet application development and end user community. If it were simply a stand-alone technology, it would have to show value before being deployed. It is not, because the IPv4 version of it became mandatory, and due to marketing crap synonymous with firewall. This ensures people will deploy it a) without awareness as a default 'security' config, or b) because they have completely drowned in the nat==security kool-aid. Either way the app developers will have to rely on topology awareness crutches to deal with the resulting nonsense. A reasonable standards development effort would not blindly endorse something known to be detrimental, simply because one constituency plans to make a quick buck. We do have an Architecture Board, and a Steering Group, so one would think we have reason to be thoughtful about the long term impacts of what we publish. Instead all we get is complaints that anyone not helping detail how to ship the broken architecture is ignoring reality and off in a fantasy land, when the exact opposite is closer to the truth. Rushing to restock the drug dealers while claiming we have no hand in the outcome is about as far from reality as one can get. Tony ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [BEHAVE] Lack of need for 66nat : Long term impact to application developers
james woodyatt wrote: On Nov 25, 2008, at 15:11, Sam Hartman wrote: Keith, would the NAT-66 proposal plus some mechanism for a server inside the NAT to ask the NAT for its global address be sufficient to meet the needs described above? No. RFC 3424 is the IAB Considerations document covering that problem. I'm tempted to copy and paste highlights from that ancient scripture here, but I don't think I'd know where to stop. As the kiddies say, Read The Whole Thing. The basic problem with NAT66 is that it introduces the possibility of more than one global IPv6 address realm. Where there is more than one, there is *any* number, not just the current realm and the single realm on the other side of the relevant NAT66 box. I'm not sure about that. Conflicting use of address space is probably the biggest single source of NAT-related pain that network operators experience. If enterprise network operators can still NAT without reusing the same addresses in different realms, I think they'll mostly do so. And regardless of what else happens with NAT66, I think it's reasonable for IETF to make it really clear that apps aren't expected to deal with conflicting address assignment in IPv6. Fixing your self-address in whatever address realm any given communications peer happens to reside is the canonical problem that NAT causes for applications developers, and NAT66 is no exception to that. No, it's only one of several canonical problems that NAT causes for applications developers. If we narrow the focus to that one problem, we'll miss the boat - we won't produce a solution that makes life any easier for apps developers. If we're going to go very far down this road toward standardizing on a NAT66 solution, then I would humbly suggest that it doesn't make much sense for there to be a single global DNS horizon where we have multiple global address realms. If we were going down that road, I'd agree with you. But I'll make a stronger statement - any solution to NATxx (for any value of xx) that requires split DNS should be considered a non-starter. It doesn't make much sense to improve consistency at the IP naming layer if you're going to degrade consistency at the DNS naming layer. Keith ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [BEHAVE] Lack of need for 66nat : Long term impact to application developers
Tony Hain wrote: There is no valid reason for 66nat. The only justifications being given are 'people will do it anyway', and 'we have to move quickly because vendors are trying to build it'. Okay, let's try to be a tad more precise. There is a subtle but important difference between: A) There is no valid reason for 66nat and B) There are obvious ways to solve the problems that people want to solve with 66nat that are both easier to understand and technically superior The two statements should have equivalent truth values, but the second one is more illuminating. It follows that if we want people to avoid using 66nat, we need to (a) identify or provide technically superior solutions that are easy to understand and (b) make them obvious to people. Keith ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Last Call: draft-ietf-dkim-ssp (DomainKeys Identified Mail (DKIM) Author Domain Signing Practices (ADSP)) to Proposed Standard
Recent changes did not correct concerns described in: http://tools.ietf.org/id/draft-otis-dkim-adsp-sec-issues-03.txt --o-- Changes meaning of DKIM's on-behalf-of: A highly detrimental aspect of this draft is its change to the meaning of RFC 4871's signature header's i= (on-behalf-of) value. It uses Alleged Author as a term being checked by this mechanism, although DKIM is not to confirm the identity of the author. As such, ADSP is in conflict with the DKIM WG charter! Compliance with either all or discardable requires an Author Signature. This means the on-behalf-of value MUST match against the From header field's email-address (the Author), either explicitly or by being left blank. This differs from RFC 4871 that specifies this field as containing the identity of the user or agent on behalf of which this message is signed. RFC 4871 also requires this identity to be within the key reference domain. RFC 4871's definition allows this field to indicate, even opaquely, the entity or account authenticated when the message was accepted for signing. Being able to associate signatures with authenticated identities is essential in controlling abuse. This ability is _absolutely_ essential if DKIM's 'i=' and 'd=' is to form a reputational basis for IPv6 messages. Abuse problems are commonly caused by compromised systems. ADSP efforts at preventing forgery, even affirming the identity of the author, remains possible while also allowing the on- behalf-of value to _always_ represent an authenticated identity within the key reference domain. Instead, the ADSP Author Signature definition requires that a signing domain pretend to have authenticated the Author, even when it may have been the Sender's email-address or some other account. Compliance should only require a signature to use a key that is referenced at or above the email- address domain of the From header field. Those domains that always indicate the identity, even opaquely, that was authenticated will earn trust. Authenticated identifiers can be used to mitigate replay abuse caused by any problematic domain granted access. This approach also allows a provider a simple means to rehabilitate their problematic accounts. --o-- Advising against wildcards for applications unrelated to ADSP: This draft uses _adsp._domainkey to prefix a TXT records. This is problematic for a few reasons. Whenever a domain wishes to defend against unauthorized use, publishing _domainkey sub-domains at ever existing DNS node becomes required. As such, every node will appear to possibly contain DKIM public keys. DKIM uses arbitrarily defined key selectors, where use of enterprise or carrier NATs may impair the protection of DNS cache. By placing the _adsp. prefix below the _domainkey sub-domain, presence of the _domainkey sub-domain no longer indicates possible cache poisonings. Scanning for possible poison using _domainkey as the only known domain becomes impossible. :^( The reason Dave Crocker gave for placing _adsp sub-domains below the _domainkey sub-domains used for keys was to facilitate domain delegations to DKIM email providers. However, ADSP protection must be applied against every _existing_ node, where a delegation benefit therefore lacks merit. This draft should instead depend upon the presence of discovery records defined by RFC 5321, and specify specific resource record types that contain the ADSP assertions, and not utilize prefixed TXT records to assert domain-wide policies. This draft advises against use of wildcards, especially for publishing (_adsp._domainkey.)*. TXT records. However, not using wildcards represents a greater administrative effort. Dependence upon NXDOMAIN versus NOERROR has also been problematic in the past. These issues occur where ANY or cached records erroneously override the desired response. The ADSP draft not only depends upon DNS, it mandates specific API error codes that potentially can impact email from any domain. --o-- Prevents message addressing within From header field where the domain does not have records published within DNS: Section 4.3's non-existence of email-addresses within DNS must be treated as a non-compliance with all, or ADSP serves no purpose. --o-- Anti-phishing protection requires loss of delivery status notifications: The term discardable and its definition clearly indicates that RFC 5321's concept of reliable delivery is to be ignored. However, if this mechanism performs its intended function, there should be little reason to relinquish NDNs. --o-- Section 3.2 includes a factual error: This section states that a valid signature by an Author Domain is known to be compliant with any possible ADSP for that domain. Compliance with ADSP requires an Author Signature, not just a signature by the Author domain (as it should have been
Re: [BEHAVE] Lack of need for 66nat : Long term impact to application developers
Tony, On Nov 25, 2008, at 4:41 PM, Tony Hain wrote: Either way the app developers will have to rely on topology awareness crutches to deal with the resulting nonsense. Stuff they presumably already have to deal with because they'd like their applications to be used in the real (IPv4+NAT) world... A reasonable standards development effort would not blindly endorse something known to be detrimental, Standards development effort != endorsement. I considered NetBIOS to be wildly offensive and actively detrimental, but RFC 1001 and 1002 were appropriate codifications of NetBIOS over TCP/UDP/IP. Instead all we get is complaints that anyone not helping detail how to ship the broken architecture is ignoring reality and off in a fantasy land, when the exact opposite is closer to the truth. The architecture is _ALREADY_ broken. 66NAT is merely another symptom of the underlying disease. Regards, -drc ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [BEHAVE] Lack of need for 66nat : Long term impact to application developers
David Conrad wrote: Tony, On Nov 25, 2008, at 4:41 PM, Tony Hain wrote: Either way the app developers will have to rely on topology awareness crutches to deal with the resulting nonsense. Stuff they presumably already have to deal with because they'd like their applications to be used in the real (IPv4+NAT) world... Yeah, but we're trying to get rid of that stuff, or at least considerably reduce the cost and complexity, because (among other things) it presents a huge barrier to adoption of new multiparty apps. A reasonable standards development effort would not blindly endorse something known to be detrimental, Standards development effort != endorsement. According to RFC 2026, IETF standardization is a kind of an endorsement, because it's a statement of both protocol quality and community consensus. The architecture is _ALREADY_ broken. 66NAT is merely another symptom of the underlying disease. Just because a disease exists does not mean we have to encourage its spread. The only reason for IETF to standardize some kind of 66NAT is to significantly improve the situation over what would happen in the absence of standardization. There are several ways that we could probably do that. But one of them is NOT to standardize NATs like they exist in IPv4. We already know that that sucks really badly, and it would never meet the criteria defined in RFC 2026. Nor would it achieve community consensus. Keith ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Last Call: draft-ietf-pkix-ecc-subpubkeyinfo (Elliptic Curve Cryptography Subject Public Key Information) to Proposed Standard
The IESG has received a request from the Public-Key Infrastructure (X.509) WG (pkix) to consider the following document: - 'Elliptic Curve Cryptography Subject Public Key Information ' draft-ietf-pkix-ecc-subpubkeyinfo-10.txt as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the [EMAIL PROTECTED] mailing lists by 2008-12-09. Exceptionally, comments may be sent to [EMAIL PROTECTED] instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-pkix-ecc-subpubkeyinfo-10.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_iddTag=16782rfc_flag=0 ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Last Call: draft-ietf-dkim-ssp (DomainKeys Identified Mail (DKIM) Author Domain Signing Practices (ADSP)) to Proposed Standard
The IESG has received a request from the Domain Keys Identified Mail WG (dkim) to consider the following document: - 'DomainKeys Identified Mail (DKIM) Author Domain Signing Practices (ADSP) ' draft-ietf-dkim-ssp-07.txt as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the [EMAIL PROTECTED] mailing lists by 2008-12-09. Exceptionally, comments may be sent to [EMAIL PROTECTED] instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-dkim-ssp-07.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_iddTag=16183rfc_flag=0 ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Last Call: draft-raj-dhc-tftp-addr-option (VoIP Configuration Server Address Option) to Informational RFC
The IESG has received a request from an individual submitter to consider the following document: - 'VoIP Configuration Server Address Option ' draft-raj-dhc-tftp-addr-option-04.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 send substantive comments to the [EMAIL PROTECTED] mailing lists by 2008-12-23. Exceptionally, comments may be sent to [EMAIL PROTECTED] instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-raj-dhc-tftp-addr-option-04.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_iddTag=12769rfc_flag=0 ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Document Action: 'Suite B Profile for Transport Layer Security (TLS)' to Informational RFC
The IESG has approved the following document: - 'Suite B Profile for Transport Layer Security (TLS) ' draft-rescorla-tls-suiteb-11.txt as an Informational RFC This document has been reviewed in the IETF but is not the product of an IETF Working Group. The IESG contact person is Tim Polk. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-rescorla-tls-suiteb-11.txt Technical Summary The United States Government has published guidelines for NSA Suite B Cryptography, which defines cryptographic algorithm policy for national security applications. This document defines a profile of TLS which is conformant with Suite B. Working Group Summary This document is not the product of any IETF working group. Document Quality This document explains the requirements for a TLS implementation to be considered Suite B conformant. There is strong consensus from the people that are defining that term. Personnel Russ Housley is the Document Shepherd. Tim Polk is the Responsible Area Director. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
RFC 5373 on Requesting Answering Modes for the Session Initiation Protocol (SIP)
A new Request for Comments is now available in online RFC libraries. RFC 5373 Title: Requesting Answering Modes for the Session Initiation Protocol (SIP) Author: D. Willis, Ed., A. Allen Status: Standards Track Date: November 2008 Mailbox:[EMAIL PROTECTED], [EMAIL PROTECTED] Pages: 24 Characters: 59839 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-ietf-sip-answermode-07.txt URL:http://www.rfc-editor.org/rfc/rfc5373.txt This document extends SIP with two header fields and associated option tags that can be used in INVITE requests to convey the requester's preference for user-interface handling related to answering of that request. The first header, Answer-Mode, expresses a preference as to whether the target node's user interface waits for user input before accepting the request or, instead, accepts the request without waiting on user input. The second header, Priv-Answer-Mode, is similar to the first, except that it requests administrative-level access and has consequent additional authentication and authorization requirements. These behaviors have applicability to applications such as push-to-talk and to diagnostics like loop-back. Usage of each header field in a response to indicate how the request was handled is also defined. [STANDARDS TRACK] This document is a product of the Session Initiation Protocol Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to [EMAIL PROTECTED] Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team USC/Information Sciences Institute ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
RFC 5391 on RTP Payload Format for ITU-T Recommendation G.711.1
A new Request for Comments is now available in online RFC libraries. RFC 5391 Title: RTP Payload Format for ITU-T Recommendation G.711.1 Author: A. Sollaud Status: Standards Track Date: November 2008 Mailbox:[EMAIL PROTECTED] Pages: 14 Characters: 26304 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-ietf-avt-rtp-g711wb-03.txt URL:http://www.rfc-editor.org/rfc/rfc5391.txt This document specifies a Real-time Transport Protocol (RTP) payload format to be used for the ITU Telecommunication Standardization Sector (ITU-T) G.711.1 audio codec. Two media type registrations are also included. [STANDARDS TRACK] This document is a product of the Audio/Video Transport Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to [EMAIL PROTECTED] Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team USC/Information Sciences Institute ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
