Re: Last Call: 'Distance Vector Multicast Routing Protocol' to Proposed Standard
On Fri, 11 Jun 2004, The IESG wrote: The IESG has received a request from the Inter-Domain Multicast Routing WG to consider the following documents: - 'Distance Vector Multicast Routing Protocol ' draft-ietf-idmr-dvmrp-v3-11.txt as a Proposed Standard - 'Distance Vector Multicast Routing Protocol Applicability Statement ' draft-ietf-idmr-dvmrp-v3-as-01.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 any comments to the [EMAIL PROTECTED] or [EMAIL PROTECTED] mailing lists by 2004-06-25. There was some debate about this on the routing-discussion list (among others), and there a number of people seemed to be of the opinion that the right category for DVMRP would be Informational or Historic, not Proposed Standard. I don't think going for PS is the right choice here. DVMRP is already a retired protocol, or one that operators have been retiring (or have retired) for around 5 years now. It's OK for existing deployments which don't want to change to other protocols, but not for new efforts -- and in that case, Informational would seem much more applicable. Such a category would provide guidance for interoperable implementations, but would also be a sign that DVMRP might not be good candidate for deployment. So, I suggest moving the spec to Informational. A couple of comments about the documents themselves (not a proper review, I just skimmed them for 30 minutes): - both documents fail a number of *required* nits, e.g., boilerplate, AS missing Security Considerations, old boilerplates, references not split, etc., the main spec having a line of 90 chars, references in the abstract, etc. applicability statement --- - this seems weak, especially section 1 on tradeoffs. A number of advantages seem clearly false, as of now (maybe these didn't hold 5 years ago -- Have these been updated to PIM-DM? SSM? I don't think so). This is the most important messaage of the applicability statement document, i.e., where NOT to use them and where to use them, and I don't think the message has come across very clearly. One should not also be hesitant to refer to other protocols for better operation (PIM-SM, -DM, SSM, etc.). main spec - - probably needs spelling out why this doesn't need to support IPv6? - IANA considerations seems funny, as these values have already been allocated? Is it necessary to list these here? Just say that as the numbers are already assigned this doc creates no *new* IANA considerations? However, note that as several messages use an IGMP type and this document (and the previous revisions) specify the codes for DVMRP (and that database is maintained by IANA), it might be necessary to specify the allocation criteria (based on RFC2343) for subsequent allocations? - security considerations basically only discusses the lack of anti-replay w/ DVMRP when using IPsec, and leaves out two main things: (1) everything related to security which does not befall under IPsec (i.e., what are the issues when IPsec is not used, or what are the issues even if IPsec is used?), and (2) how do you actually set up the IPsec keying to make it work in an interoperable fashion? (The security ADs are going to bite at (2) at least). - there are some old references, like to an old GRE spec. - this document does not prominently, right out in the introduction, point _loudly_ towards the applicability statement spec. This is especially important if the work goes on for PS. -- Pekka Savola You each name yourselves king, yet the Netcore Oykingdom bleeds. Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: What exactly is an internet (service) provider?
On 22-jun-04, at 21:57, Vernon Schryver wrote: If you want to buy a car and ask if it has air bags and nobody can give you a definite answer, would you buy the car if it is important to you to have an air bag? Buging a car with a feature with well defined characteristics is quite different from buying Internet services which don't even have common names. But that's just a detail. The real difference is that you can buy a car anywhere on the landmass of your choice and then bring it to whereever you want to use it on that same landmass. With IP service, you're limited to whatever is available in a certain place. Usually the choice is between too expensive and/or too slow (dial-up and GPRS and the like) and broken (most hotel broadband and wifi hotspots). It is not the job of the IETF to try to stop anyone from selling services that differ from what we used to get via NSF any more than it is the job of the IETF to prevent the sales of NAT boxes and PPPoE, I disagree. If the IETF were in the position to influence people, it should certainly do so. What good is it to standardize protocols that can't be deployed because network operators build networks that can't support them? Unfortunately, there are usually reasons for implementing breakage, and wisdom from the IETF isn't going to remove those reasons, so we shouldn't expect miracles. ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
the best point, Re: non-solution
Bill Sommerfeld wrote: Ed Gerck wrote: What I suggested is a web interface to the IETF mailboxes, such that any routing problems TO those mailboxes would cease to be an issue, allowing the IETF to be in FULL CONTROL of what is forwared to a mailbox, or not. How is this compatible with the IETF being run largely by donated labor? That's the best point of my suggestion! The IETF (and this list!) would no longer waste time with complaints about lack of access to mailboxes, while IETF-wide challenge-response (as it is done today already) and filters would be in place to prevent further wasting of donated labor. Because routing problems TO those mailboxes would cease to be an issue, the servers would either accept and forward the message or send back a message with further instructions to the sender. Of course, people could still send email as today. But there would be an alternative using the Internet, preventing the current single point of failure. ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Defining Internet services/service levels?
OK, there was some discussion about different levels of Internet services and categories. So should the IETF publish a definition? regards Hadmut ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: non-solution
From: Bill Sommerfeld Substantially similar capabilities are present in all of the SMTP MTA's I'm familiar with. If a message delivery attempt is rejected early, only envelope information is logged, but if the message was rejected in error, that's generally sufficient to identify what needs to be whitelisted. Yes, but after you've had them, you find that facilities that log the fewest few dozen KBytes of SMTP bodies are very valuable. SMTP envelope logs are unitelligible to most users, not only because they are terse but because the SMTP envelope is a mystery to the fewer users that know about it. Delaying filter rejections until the SMTP DATA command and so capturing the message body resolves a lot of complaints of the form Why did your idiotic spam filter reject that perfectly good mail message? That can significantly reduce whitelisting requirements. Logging bodies involve some obvious privacy hassles. You must keep the logs private. The logs can have only censored copies of the envelope so that recipients can't know who else was sent the same message. Vernon Schryver[EMAIL PROTECTED] ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: non-solution
On 23-jun-04, at 3:54, Ed Gerck wrote: Of course, I still believe that insisting in only using the email for communications and screaming bloody murder when it does not work for some reason, at some time, is very un-Internet. If you want only a single path, you have to live with the resulting single point of failure. Allowing web-based messages in addition to email is a simple and cost-effective way to provide redundancy and reduce the importance of problems such as reported by Anderson. The IETF has used email as its primary method of conducting its business for almost 20 years. The IETF is also in charge of all the relevant standards. So if email doesn't work, I think the IETF should fix it rather than come up with ad-hoc additional communication mechanisms that have more than enough problems of their own. Creating such a new channel only gives people with unreasonable email habits (such as rejecting replies to list messages without saying why) positive feedback so email becomes even less reliable. ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: Additional complaint about disparagement by Paul Vixie on IETFlists
Anthony DeRobertis wrote: On Mon, Jun 21, 2004 at 06:21:53PM -0400, Dean Anderson wrote: Harald, Please add __Another__ complaint to the chair about inappropriate behavior by Mr. Vixie. Altering our name from Av8 Internet to dv8 is simply more disparagement I don't see how dv8 is disparaging in any way. If that is an attempt to disparage AV8, then it's a very, very poor attempt. More likely, I suspect, is that its a mistake. I personally filter out all emails from Dean Anderson, but let's not ignore our own responsibilities. Try pronouncing dv8. Still don't understand the intended slight? Paul used it more than once, so not a mistake. The mistake was to stoop just that little bit lower (or to not filter out Dean's emails in the first place, but I digress) gja ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
M2UA help
Hi, I am confused about the following in M2UA 1. The only documentation i have is RFC 3331. Please let me know if there is more documentation. 2. I understand that the AS is a logical group of links in the SG. How does the SG group links as AS? Do all links with same opc-dpc become 1 AS? or is there some other parameter? 3. The RFC says that 1 ASP should support multiple AS. Does the client side (MGC) know all the AS information at configuration time? 4. IN load share mode do all ASPs in an AS register for all IIDs? If so is it the MGCs responsibility to sequence the messages or is it the SGs responsibility to send a sequence to the same SCTP stream? 5. Any information on what the SG and AS know at configuration time about the AS, ASP and IIDs will be useful. Thanks in advance for your help. -Vijay ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
copyright requirements clarification - please
Hello all, I am reading through RFC 3667 and RFC 3668 and have come upon what I believe is a conflict. In RFC 3667 in Section 5.4 it states: -- 5.4. Copyright Notice (required for all IETF Documents) (Normally placed at the end of the IETF Document.) Copyright (C) The Internet Society (year). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Additional copyright notices are not permitted in IETF Documents except in the case where such document is the product of a joint development effort between the IETF and another standards development organization or the document is a republication of the work of another standards organization. Such exceptions must be approved on an individual basis by the IAB. --- BUT, in both documents an additional copyright statement is included near the beginning of the documents: --- Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. --- Is this a conflict? Regards, Sal Salvatore Mangiapane ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Intellectual property clarification - please
Both RFC 3667 and RFC 3668 contain an Intellectual Property disclaimer near the end of the document as defined in Section 5 of RFC 3668. But, this appears to only be required as stated in Section 5 for specific requirements: - 5. Notice to be included in RFCs The RFC Editor will ensure that the following notice is present in all IETF RFCs and all other RFCs for which an IPR disclosure or assertion has been received prior to publication. - Is it the intention to always include the IPR statement and the RFC Editor will only ensure it when an IPR disclosure has been made? Thanks again for your guidance, Sal Salvatore Mangiapane ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: What exactly is an internet (service) provider?
On Wed, 23 Jun 2004 13:39:07 +0200, Iljitsch van Beijnum said: But that's just a detail. The real difference is that you can buy a car anywhere on the landmass of your choice and then bring it to whereever you want to use it on that same landmass. With IP service, you're limited to whatever is available in a certain place. Usually the choice is between too expensive and/or too slow (dial-up and GPRS and the like) and broken (most hotel broadband and wifi hotspots). The analogy gets much more interesting if you posit the existence of cars that run on diesel, or ethanol, or hydrogen fuel cell, or other energy sources not as widespread as 89-octane gasoline pgprAuvjUVcB6.pgp Description: PGP signature ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: Response to complaint from Dean Anderson (fwd)
[EMAIL PROTECTED] wrote: PS - Where is J. Flemming when you need him anyway, I want to get back to good old fashioned trolling be careful what you wish for ... Fred [EMAIL PROTECTED] ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: Defining Internet services/service levels?
On Wed, 23 Jun 2004 21:29:37 +0200, Hadmut Danisch [EMAIL PROTECTED] said: OK, there was some discussion about different levels of Internet services and categories. So should the IETF publish a definition? There's discussion in progress off-list. The problem is that although it's probably feasible to get a consensus on the definitions within the IETF, it's unclear how to phrase it so that the people who actually need the definitions can use them. This planet has - or rather had - a problem, which was this: most of the people living on it were unhappy for pretty much of the time. Many solutions were suggested for this problem, but most of these were largely concerned with the movements of small green pieces of paper, which is odd because on the whole it wasn't the small green pieces of paper that were unhappy -- Douglas Adams pgp9e9Cx07HKh.pgp Description: PGP signature ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: copyright requirements clarification - please
this refers to copyrights from somewhere other than the ISOC (the W3C or an individual person for example) multiple copyright notices, if all from teh ISOC, is just fine Scott ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: Defining Internet services/service levels?
At 9:29 PM +0200 6/23/04, Hadmut Danisch wrote: OK, there was some discussion about different levels of Internet services and categories. So should the IETF publish a definition? No: it's not the kind of engineering we do best. Yes: we are about the only group that can get the level of review needed to prevent such a document from being a puff piece from ISPs. No: it's about offering of protocols, not how the protocols work Yes: Having an Informational RFC (it should not be labelled best current practice) on this would be useful to the Internet community. Proposal: Create a personal Internet Draft. Create a mailing list for discussing the draft. Announce the mailing list here. Cycle a few times. Announce what you think is the last version year. Probably cycle once or twice more. Turn it in to the RFC Editor as a personal submission. --Paul Hoffman, Director --VPN Consortium ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: copyright requirements clarification - please
On Thu, 24 Jun 2004 12:46:20 EDT, Sal Mangiapane [EMAIL PROTECTED] said: 5.4. Copyright Notice (required for all IETF Documents) Copyright (C) The Internet Society (year). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. BUT, in both documents an additional copyright statement is included near the beginning of the documents: Copyright (C) The Internet Society (2004). All Rights Reserved. Is this a conflict? Agreed - the two texts *do* differ, and there is a bit of practice what you preach lurking there. However, the additional language in the 5.4 boilerplate appears to be there because the authors of RFC3667 and 3668 presumably assigned all rights to the Internet Society with the intention of the Society having *all* the rights to the RFC, whereas most RFCs the authors may wish to retain some of the rights to the document. So for the 2 RFCs, the Society keeps all the rights, but in general the intent is to assign the copyright to the Society, which then grants back to the authors all the rights except the limited subset listed in BCP 78 which it needs to do its work. As such, I don't see a conflict here. Of course, IANAL, and I presume that someone who actually is one did a double-check of all this pgpnrKAQPnxlS.pgp Description: PGP signature ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: Intellectual property clarification - please
On Thu, 24 Jun 2004 12:56:46 EDT, Sal Mangiapane [EMAIL PROTECTED] said: Is it the intention to always include the IPR statement and the RFC Editor will only ensure it when an IPR disclosure has been made? I read it as If we are aware of an IPR claim or disclosure, the RFC Editor will include the appropriate text.. I don't see any requirement that the RFC Editor add text protecting against an undisclosed submarine patent claim or similar unfriendly activities (Whether such language *should* be added to protect against that is a subject for another flame-fest, another day.. ;) pgpaiEhRfC9il.pgp Description: PGP signature ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Protocol Action: 'Finding FCIP Entities Using SLPv2' to Proposed Standard
The IESG has approved the following document: - 'Finding FCIP Entities Using SLPv2 ' draft-ietf-ips-fcip-slp-09.txt as a Proposed Standard This document is the product of the IP Storage Working Group. The IESG contact persons are Allison Mankin and Jon Peterson. Technical Summary draft-ietf-ips-fcip-slp-09.txt describes the use of the Service Location Protocol Version 2 (SLPv2) to perform dynamic discovery of participating FCIP Entities. Implementation guidelines, service type templates, and security considerations are specified. FCIP is a pure FC encapsulation protocol that transports FC frames. As defined by the IPS WG, it interconnects Fibre Channel switches over TCP/IP networks. Working Group Summary The Working Group had consensus to advance this documents to Proposed Standard. The SLPv2 and discovery aspects were given review and discussion on the mailing list by Erik Guttman and James Kempf, and this was an active discussion. This document had a revision following IESG review which was concerned about the Security Considerations and some text originally present on NAT, which was viewed as needing to be in a more general document and as not providing significant guidance. Protocol Quality The documents were reviewed for the IESG by Erik Guttman, James Kempf, Thomas Narten and Allison Mankin.David Black addressed the issues of the security review. RFC Editor Notes - Section 4.2 NAT and NAPT Considerations - delete this entire section - Section 5.2 - remove the line: # snmp://192.0.2.0 - Section 6.1. Security Implementation - section is replaced by new text: OLD: 6.1. Security Implementation Security for SLPv2 in an IP storage environment is specified in [IPS- SEC]. IPsec SHOULD be implemented for SLPv2 as specified in [IPS-SEC]. This includes ESP with a non-null transform to provide both authentication and confidentiality. SLPv2 authentication is OPTIONAL to implement and use, and SLPv2 authentication SHOULD be implemented when IPsec is not supported. NEW: 6.1. Security Implementation Security for SLPv2 in an IP storage environment is specified in [RFC3723]. IPsec is mandatory-to-implement for IPS clients and servers. Thus, all IP storage clients, including those invoking SLP, can be assumed to support IPsec. SLP servers, however, cannot be assumed to implement IPsec, since there is no such requirement in standard SLP. In particular, SLP Directory Agents (DA) may be running on machines other than those running the IPS protocols. IPsec SHOULD be implemented for SLPv2 as specified in [RFC3723]; this includes ESP with a non-null transform to provide both authentication and confidentiality. Because the IP storage services have their own authentication capabilities when located, SLPv2 authentication is OPTIONAL to implement and use (as discussed in more detail in [RFC 3723]). Change the draft's normative reference [IPS-SEC] to [RFC 3723]. ___ IETF-Announce mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf-announce
Last Call: 'Use of the SEED Encryption Algorithm in CMS' to Proposed Standard
The IESG has received a request from the S/MIME Mail Security WG to consider the following document: - 'Use of the SEED Encryption Algorithm in CMS ' draft-ietf-smime-cms-seed-01.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 any comments to the [EMAIL PROTECTED] or [EMAIL PROTECTED] mailing lists by 2004-07-07. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-smime-cms-seed-01.txt ___ IETF-Announce mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf-announce
Last Call: 'Vendor-Identifying Vendor Options for DHCPv4' to Proposed Standard
The IESG has received a request from the Dynamic Host Configuration WG to consider the following document: - 'Vendor-Identifying Vendor Options for DHCPv4 ' draft-ietf-dhc-vendor-03.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 any comments to the [EMAIL PROTECTED] or [EMAIL PROTECTED] mailing lists by 2004-07-08. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-dhc-vendor-03.txt ___ IETF-Announce mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf-announce
