[Ietf-dkim] Re: WG Action: Formed Mail Maintenance (mailmaint) / Commitment
Hi John, It is not that I am disparaging any individual commitment or open source - not at all. What I find bizarre is: A) to commit to anything in the dark .. meaning before adopting as WG document where the document and enclosed within itself protocol by design could drastically change B) to hold the original commit as a valuable promise and not to insist on interoperable implementations instead. Kind regards, Robert On Thu, May 23, 2024 at 9:21 PM John Scudder wrote: > Hi Robert, > > I see. What I most wanted to challenge in your message was the implication > (reinforced in your note I’m replying to now) that the only meaningful > contributions are made by “companies (vendors)”. I don't agree, nor do I > agree that open source et al should be disparaged. I guess you don’t find > that “convincing enough”; if so, we shall have to disagree on that. > > —John > > On May 23, 2024, at 3:07 PM, Robert Raszuk wrote: > > Hi John, > > Yes I recall seeing this email, but it did not sound convincing enough to > me. > > The fact that Mr X says "Oh in my spare time I will implement this" to me > does not seem to be of any measurable value. At least not so much to put > this as requirement for adoption in the WG charter. > > Much better would be what we do in IDR that the draft should not progress > to IESG unless the proposed standard has been tried out in any interop > testing and interop report has been posted on the wiki page. > > Thx a lot, > R. > > > On Thu, May 23, 2024 at 8:19 PM John Scudder wrote: > >> Hi Robert, >> >> Your comments have already been addressed, most recently in Pete’s >> message on Monday ( >> https://mailarchive.ietf.org/arch/msg/ietf/NAa6PvOvdPy8SmYtX1IxQ1Jj-pc/ >> <https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/ietf/NAa6PvOvdPy8SmYtX1IxQ1Jj-pc/__;!!NEt6yMaO-gk!GKul0z6xuuzCnKlxpocnxhnu24YTSPe-yezafWU4_EtT-3heNA9Ryz2zHMA3kexyMDBtot4BM2D-JQ$>). >> To add, relative to your final paragraph about “hold responsible", there >> are many parts of our process that rely in part on the expectation >> participants will act in good faith, this would hardly be the first. >> >> —John >> >> On May 23, 2024, at 11:52 AM, Robert Raszuk wrote: >> >> The reality in vast majority of companies (vendors) is that commitment to >> implement something or not are no longer being driven by engineers. >> >> They are driven by marketing and product management teams who >> rarely attend IETFs. >> >> And even if there some commitment today tomorrow based on new field >> requirements it may change. >> >> With that I am really puzzled what this entire discussion is all about >> and how anyone (presumably chairs) are going to hold responsible person X >> for her or his "commitment to implement" (unless we are talking about hobby >> implementations in some private code base or open source. >> >> Thx, >> R. >> >> >> >> >> >> On Thu, May 23, 2024 at 4:59 PM Dave Crocker wrote: >> >>> On 5/21/2024 9:48 AM, Murray S. Kucherawy wrote: >>> > Before diving into this thread, I think it's important to underscore >>> > that we're not taking anything away here. >>> >>> The premise of that assertion is that having this working group will not >>> alter the decision-making by those managing the other paths. Given >>> human nature, that seems optimistic, at best. >>> >>> >>> > The only constraint being established is: If you want this particular >>> > working group to process your work, there's a specific minimum you >>> > need to meet. >>> >>> And that minimum is both onerous and, as formal charter requirements, >>> lacking any historical precedence in the IETF. >>> >>> d/ >>> >>> -- >>> Dave Crocker >>> Brandenburg InternetWorking >>> bbiw.net >>> <https://urldefense.com/v3/__http://bbiw.net__;!!NEt6yMaO-gk!GFF-Xpl7WNYMmXdLazOIdEVSW9KL6Xm09CiJknmnTsLxtfXC3LtsMJQ9a9clI1i1sEcaD8iZEfE_fg$> >>> mast:@dcrocker@mastodon.social >>> >>> >> > ___ Ietf-dkim mailing list -- ietf-dkim@ietf.org To unsubscribe send an email to ietf-dkim-le...@ietf.org
[Ietf-dkim] Re: WG Action: Formed Mail Maintenance (mailmaint) / Commitment
Hi John, Yes I recall seeing this email, but it did not sound convincing enough to me. The fact that Mr X says "Oh in my spare time I will implement this" to me does not seem to be of any measurable value. At least not so much to put this as requirement for adoption in the WG charter. Much better would be what we do in IDR that the draft should not progress to IESG unless the proposed standard has been tried out in any interop testing and interop report has been posted on the wiki page. Thx a lot, R. On Thu, May 23, 2024 at 8:19 PM John Scudder wrote: > Hi Robert, > > Your comments have already been addressed, most recently in Pete’s message > on Monday ( > https://mailarchive.ietf.org/arch/msg/ietf/NAa6PvOvdPy8SmYtX1IxQ1Jj-pc/). > To add, relative to your final paragraph about “hold responsible", there > are many parts of our process that rely in part on the expectation > participants will act in good faith, this would hardly be the first. > > —John > > On May 23, 2024, at 11:52 AM, Robert Raszuk wrote: > > The reality in vast majority of companies (vendors) is that commitment to > implement something or not are no longer being driven by engineers. > > They are driven by marketing and product management teams who > rarely attend IETFs. > > And even if there some commitment today tomorrow based on new field > requirements it may change. > > With that I am really puzzled what this entire discussion is all about and > how anyone (presumably chairs) are going to hold responsible person X for > her or his "commitment to implement" (unless we are talking about hobby > implementations in some private code base or open source. > > Thx, > R. > > > > > > On Thu, May 23, 2024 at 4:59 PM Dave Crocker wrote: > >> On 5/21/2024 9:48 AM, Murray S. Kucherawy wrote: >> > Before diving into this thread, I think it's important to underscore >> > that we're not taking anything away here. >> >> The premise of that assertion is that having this working group will not >> alter the decision-making by those managing the other paths. Given >> human nature, that seems optimistic, at best. >> >> >> > The only constraint being established is: If you want this particular >> > working group to process your work, there's a specific minimum you >> > need to meet. >> >> And that minimum is both onerous and, as formal charter requirements, >> lacking any historical precedence in the IETF. >> >> d/ >> >> -- >> Dave Crocker >> Brandenburg InternetWorking >> bbiw.net >> <https://urldefense.com/v3/__http://bbiw.net__;!!NEt6yMaO-gk!GFF-Xpl7WNYMmXdLazOIdEVSW9KL6Xm09CiJknmnTsLxtfXC3LtsMJQ9a9clI1i1sEcaD8iZEfE_fg$> >> mast:@dcrocker@mastodon.social >> >> > ___ Ietf-dkim mailing list -- ietf-dkim@ietf.org To unsubscribe send an email to ietf-dkim-le...@ietf.org
[Ietf-dkim] Re: Fwd: WG Action: Formed Mail Maintenance (mailmaint) / Commitment
The reality in vast majority of companies (vendors) is that commitment to implement something or not are no longer being driven by engineers. They are driven by marketing and product management teams who rarely attend IETFs. And even if there some commitment today tomorrow based on new field requirements it may change. With that I am really puzzled what this entire discussion is all about and how anyone (presumably chairs) are going to hold responsible person X for her or his "commitment to implement" (unless we are talking about hobby implementations in some private code base or open source. Thx, R. On Thu, May 23, 2024 at 4:59 PM Dave Crocker wrote: > On 5/21/2024 9:48 AM, Murray S. Kucherawy wrote: > > Before diving into this thread, I think it's important to underscore > > that we're not taking anything away here. > > The premise of that assertion is that having this working group will not > alter the decision-making by those managing the other paths. Given > human nature, that seems optimistic, at best. > > > > The only constraint being established is: If you want this particular > > working group to process your work, there's a specific minimum you > > need to meet. > > And that minimum is both onerous and, as formal charter requirements, > lacking any historical precedence in the IETF. > > d/ > > -- > Dave Crocker > Brandenburg InternetWorking > bbiw.net > mast:@dcrocker@mastodon.social > > ___ Ietf-dkim mailing list -- ietf-dkim@ietf.org To unsubscribe send an email to ietf-dkim-le...@ietf.org
Re: Draft IESG Statement on Removal of an Internet-Draft from the IETF Web Site
Note - I don't agree that past IDs should be posted after expiration without the author's consent. They were submitted with that understanding, and post-facto changing it by the IETF is not appropriate. I would rephrase the above as whether it is appropriate to take someone's work and post it as your own or use the work. For the former, I don't think it is appropriate. For the latter, the author has given the IETF change control over the work. I'll ignore the exceptions. That does not mean that the author should not be credited for the work. If I am not mistaken it is IETF practice to do so. Actually regarding reusing the former drafts we have been discussing this in 2008 at depth when one draft reused most of the text of another draft. The end result was that technically and legally it is appropriate. Reference section 3.3 of BCP78 / RFC5378. However while the above documents do not mandate it I very much agree that it is in good taste to first ping the original authors about your intentions to extend and build on top of their idea. R.
Re: IETF 92 in Dallas!
Hi Bob, Is there any way to broaden the scope of IAOC choice and provide the candidate locations which would meet IETF criteria by any IETF member ? For example once I know the criteria I could check around in Poland to see if there is any place which would satisfy the future IETF venue. I am sure friends from South America would be glad to conduct similar local research in their neighborhood. So would others from other continents. Are the criteria for IETF meetings published or is this some sort of top secret (for example how much the venue may cost) ? Could we all contribute via a wiki page ? Could we make the IETF choice of location an open process ? Thx, R. Arturo, [Reducing the cc: list to just the IETF and IAOC lists] The IAOC seriously investigated a venue in South America for IETF92, but based on the data we collected it did not meet the criteria for IETF meetings. We are continuing to talk with the group that suggested the venue and are also looking at other venues in that region for future meetings. We have open meeting slots in 2015-2017. Bob IAOC Chair
Re: IETF 92 in Dallas!
Hotel contracts by their nature need to be negotiated under mutual NDA unless you want all the vendors in the region to mysteriously arrive at the same lower bound. All hotel rates are wide open and published on IETF web page. It's an interesting NDA which permits open disclosure ;-) Besides hotel is least worry as we do know the IETF rates for the last few years and it is quite easy to check with any hotel if they are willing to meet those targets or not. R. On 8/17/12 12:05 PM, Robert Raszuk wrote: Hi Bob, Is there any way to broaden the scope of IAOC choice and provide the candidate locations which would meet IETF criteria by any IETF member ? For example once I know the criteria I could check around in Poland to see if there is any place which would satisfy the future IETF venue. I am sure friends from South America would be glad to conduct similar local research in their neighborhood. So would others from other continents. Are the criteria for IETF meetings published or is this some sort of top secret (for example how much the venue may cost) ? Could we all contribute via a wiki page ? Could we make the IETF choice of location an open process ? Hotel contracts by their nature need to be negotiated under mutual NDA unless you want all the vendors in the region to mysteriously arrive at the same lower bound.
Re: Basic ietf process question ...
Hello Brian, That's an enormous leap that I just don't understand. Most protocols don't need that sort of configuration complexity. H I am of the opinion that most protocols requires configuration. I am also of the opinion that each vendor chooses an original way to configure their network elements. Therefor if you do not define up front a standard based of configuring given routing protocol you will end up with exactly what we have today .. zoo of various different CLI commands to enable the exact same protocol across more then one vendor box. Are you saying that this is ok ? Or are you saying that there is simpler way to enable netconf based unified way to configure protocols and services on your network other then providing per component xml schema with subsequent schema extensions as part of IETF standardization process ? To make it a bit more explicit ... do you really need to study 5 user manuals or google 5 times to enable IGP or BGP or even configure NTP across 5 different router OS running in your network ??? Again: no problem with creating XML schemata where they are useful. But making them mandatory would be just as bad as making MIB modules mandatory, IMHO. Aha .. so you are saying that MIBs are not mandatory Very interesting. So I guess SSH to the routers and box by box cli provisioning is here to stay for a while I think :( Best regards, R.
Re: [OPSAWG] Basic ietf process question ...
Hi Juergen, Many thx for the great suggestion ! However perhaps you are much more knowledgeable in that area and could recommend which model fit the best the requirement to standardize configuration of any new protocol or protocol extension at least in the space of routing and routing protocols or services being based on them ? As you know the current IRS framework driven by junisco is trying to come with common API to the routing system agreed across vendors. This is great as attempts never happened in the past. But if we are at this phase I think creating a network elements abstraction layer and be able to configure/monitor any protocol and service at the unified way is one of the building blocks we should start with. And of course I think this is very clear to everyone if it is not made mandatory in each draft as new section or appendix it is just not going to happen in practice. Best regards, R. On Fri, Aug 03, 2012 at 09:22:10AM +0200, Robert Raszuk wrote: Aha .. so you are saying that MIBs are not mandatory Very interesting. So I guess SSH to the routers and box by box cli provisioning is here to stay for a while I think :( Robert, you may want to take a closer look at the data models currently being defined in the NETMOD working group. Please review them and send any comments. /js
Basic ietf process question ...
All, IETF documents have number of mandatory sections .. IANA Actions, Security Considerations, Refs, etc ... Does anyone have a good reason why any new protocol definition or enhancement does not have a build in mandatory XML schema section which would allow to actually use such standards based enhancement in vendor agnostic way ? There is a lot of talk about reinventing APIs, building network wide OS platform, delivering SDNs (whatever it means at any point of time for one) ... but how about we start with something very basic yet IMHO necessary to slowly begin thinking of network as one plane. I understand that historically we had/still have SNMP however I have never seen this being mandatory section of any standards track document. Usually SNMP comes 5 years behind (if at all) making it obsolete by design. NETCONF is great and very flexible communication channel for provisioning. However it is sufficient to just look at number of ops lists to see that those who tried to use it quickly abandoned their efforts due to complete lack of XML schema from each vendor they happen to use or complete mismatch of vendor to vendor XML interpretation. And while perhaps this is obvious I do not think that any new single effort will address this. This has to be an atomic and integral part of each WG's document. Looking forward for insightful comments ... Best, R.
Re: Basic ietf process question ...
Hi Dan, We should be talking nowadays about a toolset rather than one tool that fits all. Just to clarify what I asked about .. I am not looking for a single tool or single protocol to be used to configure everything. I am asking for small building block like xml schema (or something similar) to be part of each new IETF proposal or protocol change. IMHO only that can allow any further more fancy abstractions and tools to be build and used in practice. Best regards, R. Hi, The OPSAWG/OPSAREA open meeting this afternoon has an item on the agenda concerning the revision of RFC1052 and discussing a new architecture for management protocols. My personal take is that no one protocol, or one data modeling language can match the operational requirements to configure and manage the wide and wider range of hosts, routers and other network devices that are used to implement IP networks and protocols. We should be talking nowadays about a toolset rather than one tool that fits all. However, this is a discussion that just starts. Regards, Dan -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Robert Raszuk Sent: Thursday, August 02, 2012 7:25 PM Cc: ietf@ietf.org Subject: Basic ietf process question ... All, IETF documents have number of mandatory sections .. IANA Actions, Security Considerations, Refs, etc ... Does anyone have a good reason why any new protocol definition or enhancement does not have a build in mandatory XML schema section which would allow to actually use such standards based enhancement in vendor agnostic way ? There is a lot of talk about reinventing APIs, building network wide OS platform, delivering SDNs (whatever it means at any point of time for one) ... but how about we start with something very basic yet IMHO necessary to slowly begin thinking of network as one plane. I understand that historically we had/still have SNMP however I have never seen this being mandatory section of any standards track document. Usually SNMP comes 5 years behind (if at all) making it obsolete by design. NETCONF is great and very flexible communication channel for provisioning. However it is sufficient to just look at number of ops lists to see that those who tried to use it quickly abandoned their efforts due to complete lack of XML schema from each vendor they happen to use or complete mismatch of vendor to vendor XML interpretation. And while perhaps this is obvious I do not think that any new single effort will address this. This has to be an atomic and integral part of each WG's document. Looking forward for insightful comments ... Best, R.
Re: Basic ietf process question ...
Hi Brian, Perhaps we understand a different thing by xml schema As example what I had in mind when asking this question was the example from Appendix A of http://tools.ietf.org/html/draft-marques-l3vpn-schema-00 where while perhaps not yet complete it does provide decent representation of one of the popular service today. That's what I had mind asking why such appendix isn't a mandatory part of each new protocol extension. It has very little to do with Web Services you may be referring to. Many thx, R. I think anyone with intimate experience of the Web Services standards experiment (trying to use XML as if it was a Turing machine) would have extreme doubts about any proposal to impose such a requirement. It was not for no reason that many people came to refer to the Web Services family of standards as WS-splat. The words small and xml schema don't really belong together, Regards Brian Carpenter On 02/08/2012 18:12, Robert Raszuk wrote: Hi Dan, We should be talking nowadays about a toolset rather than one tool that fits all. Just to clarify what I asked about .. I am not looking for a single tool or single protocol to be used to configure everything. I am asking for small building block like xml schema (or something similar) to be part of each new IETF proposal or protocol change. IMHO only that can allow any further more fancy abstractions and tools to be build and used in practice. Best regards, R. Hi, The OPSAWG/OPSAREA open meeting this afternoon has an item on the agenda concerning the revision of RFC1052 and discussing a new architecture for management protocols. My personal take is that no one protocol, or one data modeling language can match the operational requirements to configure and manage the wide and wider range of hosts, routers and other network devices that are used to implement IP networks and protocols. We should be talking nowadays about a toolset rather than one tool that fits all. However, this is a discussion that just starts. Regards, Dan -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Robert Raszuk Sent: Thursday, August 02, 2012 7:25 PM Cc: ietf@ietf.org Subject: Basic ietf process question ... All, IETF documents have number of mandatory sections .. IANA Actions, Security Considerations, Refs, etc ... Does anyone have a good reason why any new protocol definition or enhancement does not have a build in mandatory XML schema section which would allow to actually use such standards based enhancement in vendor agnostic way ? There is a lot of talk about reinventing APIs, building network wide OS platform, delivering SDNs (whatever it means at any point of time for one) ... but how about we start with something very basic yet IMHO necessary to slowly begin thinking of network as one plane. I understand that historically we had/still have SNMP however I have never seen this being mandatory section of any standards track document. Usually SNMP comes 5 years behind (if at all) making it obsolete by design. NETCONF is great and very flexible communication channel for provisioning. However it is sufficient to just look at number of ops lists to see that those who tried to use it quickly abandoned their efforts due to complete lack of XML schema from each vendor they happen to use or complete mismatch of vendor to vendor XML interpretation. And while perhaps this is obvious I do not think that any new single effort will address this. This has to be an atomic and integral part of each WG's document. Looking forward for insightful comments ... Best, R.
Re: Basic ietf process question ...
Hi Joe, Many thx for your comments. Perhaps my intentions were not very well described. Personally I am not that much stuck on plain XML schema .. it could be expressed in any language IETF would choose to use. The point is not how to do it .. but to do it at the moment of bringing new protocol extension. However for years the same functionality is completely different to configure using one vendor from other vendor (leave alone that even within single vendor there are complete different UIs to provision the same knob). If anyone is even remotely serious about some form of common network OS IMHO the first step is to create unified configuration abstraction. The xml schema for each proto extension would be just a standard based API for configuration input. Keep in mind that today routers are configured by scripts from central management clusters where there are tons of templates which in fact completely differ from vendor to vendor and their maintenance and keeping them up to date is a real pain. Regards, R. On 8/2/12 9:25 AM, Robert Raszuk rob...@raszuk.net wrote: Does anyone have a good reason why any new protocol definition or enhancement does not have a build in mandatory XML schema section which would allow to actually use such standards based enhancement in vendor agnostic way ? For docs that use XML, requiring some form of schema makes sense. However, what we're finding at the application layer is that often times using JSON (see RFC 4627) ends up with better interoperability more quickly than using XML, except in the case of human-readable content like marked-up text. See RFC 6120, Appendix A (http://goo.gl/CBv8G) for another example. For those that insist on XML, RelaxNG (http://goo.gl/MYnB1) is another language you can use to describe your XML, which is a little easier to learn than XSD. However, for implementors, if you start with the schema and blindly use it for conformance checking of real-world traffic, you are likely to have both performance and extensibility issues in practice. If folks at other layers in the stack would like input from Apps folks, I'm sure that we would be happy to share our lessons learned. Join apps-discuss (http://goo.gl/0Otjv) and ask for help.
ipad/android ietf stay current tool ...
Apologies if this is too simple question, but is there any tool for ipad and/or android which would allow me to download for offline reading all ietf/irtf drafts submitted between any two dates ? Ideally it would be great to also be able to filter by version or by string in the name to stay current on a given WG efforts or some specific document. Just checking for prior art before even considering doing it myself ;) Many thx, R.
Re: Is the IETF aging?
Hi John, Who proposes does ! Can't wait to see you in Vancouver ;) Cheers, R. Maybe we would do better if we required attendees to dress as furries. Their conventions seem to attract a younger crowd. Sent from my iPhone
Fwd: IETF attendees reengineer their hotel's Wi-Fi network
Hi Wes, Could we perhaps add a section to your draft (draft-george-travel-faq-05.txt) on how to fix wifi network in the hotel you are staying ? Pointer to set of open source wifi troubleshooting tools would be welcome too ;) Cheers, R. Original Message Subject: IETF attendees reengineer their hotel's Wi-Fi network Date: Thu, 29 Mar 2012 17:28:26 -0400 From: Russ Housley hous...@vigilsec.com To: IETF ietf@ietf.org Disgusted IETF attendees reengineer their Paris hotel's Wi-Fi network What happens when a bunch of IETF super nerds show up in Paris for a major conference and discover their hotel's Wi-Fi network has imploded? http://newsletters.networkworld.com/t/6464858/258923304/355639/0/
Re: Issues relating to managing a mailing list...
Hello Russ, IMHO this is a great idea and I fully support it's deployment asap. It is well overdue one too not only in IETF but in many other mailing lists in the community. -- The only few maybe too detailed at this point questions: - what would be (if not infinity) the expiration data of such attachment repository ? - what would be the automated interface to periodically sync such repository on a per WG group to a local space ? - would email contain full link or just a url short cut ? - would the document as attachments be google indexed and fully searchable ? - what attachment formats would be supported ? Regards, R. Some suggestions have been made about the IETF mail lists. There is a way for mailman to strip attachments and put them in a place for downloading with a web browser. This would be a significant change to current practice, so the community needs to consider this potential policy change. What do you think? Russ
Re: Last Call: draft-ietf-sidr-rpki-rtr-19.txt (The RPKI/RouterProtocol) to Proposed Standard
Steven, If the cache is within your domain the below sentence does not apply as you are not validating your IGP routes to bootstrap a router's reachability to a cache. If the cache would be outside of your domain this sentence would apply as you would require to accept and install some set of essentially NOT FOUND routes to reach the cache. Therefor if authors of draft-ietf-sidr-rpki-rtr-XX are really serious about recommending to keep the cache locally within each domian the below sentence you are quoting should be fixed or removed. Rgs, R. Let me call attention to this sentence, too: It also SHOULD be topologically close so that a minimum of validated routing data are needed to bootstrap a router's access to a cache. That is, there are other, quite important, reasons to keep the cache very close to the router(s) it serves. --Steve Bellovin, https://www.cs.columbia.edu/~smb ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-ietf-sidr-rpki-rtr-19.txt (The RPKI/RouterProtocol) to Proposed Standard
Hello Steven, The same principles apply here. Given the desire to bootstrap secure routing, we concluded that most ISPs would rely on local -- very local -- caches. In fact, I suspect that many, especially large ones, would want a cache per POP. The fact that you say we concluded is indeed very interesting. I wonder how much real ISPs and SPs have contributed to this conclusion. To the extend I was part of those discussions I saw very little to none. Given this, and given the reality of available platforms, we had to make a decision. The usage model suggests that the risk is low; the capabilities of the platforms suggest that we couldn't actually get the security we wanted, Sorry to say this today but I think that you got the deployment model wrong which directly translates into platforms you are performing the actual validation on. I recall feedback from operators in the early stages of the design which suggest that validation could be done in few places of the domain then security applied p2mp once wrong route is detected. Contrary you went and recommended upgrade of each ASBR. This is pure fantasy. There are IETF drafts by vendors who say black on white that some of their products will not get any new features in. That means that as long as this equipment is running basic origin validation will not get deployed. When I sit and look from the perspective of both vendor and operator I do wonder what is the real goal here. Last you still have not commented on the applicability of the statement you quoted. What is it actually saying considering no validation for IGP routes nor IBGP routes if anyone would like to carry it's internal reachability subnets within ibgp. Happy Holidays ! R. Let me clarify what I said (and include context that I should have put in my earlier note). Security mechanisms are not designed in a vacuum. One has to consider the users, the threats, and the usage scenarios. To take an absurd example, while I can do Caesar ciphers in my head I'm quite incapable of mental exponentiations of 2048-bit numbers; accordingly, I'm forced to trust a computer to do those for me. On the other hand, if I'm trying to protect a secret from a first grader who has just learned how to read, a Caesar cipher may be all I need. The same principles apply here. Given the desire to bootstrap secure routing, we concluded that most ISPs would rely on local -- very local -- caches. In fact, I suspect that many, especially large ones, would want a cache per POP. You're quite correct that this implies no validation of IGP routes. That's by intent -- the very first sentence of the abstract states that RPKI is intended to validate BGP routes. (If you have outsiders sending your internal routes into your IGP via BGP, you have bigger problems that RPKI can fix...) Given this, and given the reality of available platforms, we had to make a decision. The usage model suggests that the risk is low; the capabilities of the platforms suggest that we couldn't actually get the security we wanted, just like I can't do mental RSA (at least until I get that brain chip implanted). On Dec 23, 2011, at 5:44 36AM, Robert Raszuk wrote: Steven, If the cache is within your domain the below sentence does not apply as you are not validating your IGP routes to bootstrap a router's reachability to a cache. If the cache would be outside of your domain this sentence would apply as you would require to accept and install some set of essentially NOT FOUND routes to reach the cache. Therefor if authors of draft-ietf-sidr-rpki-rtr-XX are really serious about recommending to keep the cache locally within each domian the below sentence you are quoting should be fixed or removed. Rgs, R. Let me call attention to this sentence, too: It also SHOULD be topologically close so that a minimum of validated routing data are needed to bootstrap a router's access to a cache. That is, there are other, quite important, reasons to keep the cache very close to the router(s) it serves. --Steve Bellovin, https://www.cs.columbia.edu/~smb --Steve Bellovin, https://www.cs.columbia.edu/~smb ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-ietf-sidr-rpki-rtr-19.txt (The RPKI/RouterProtocol) to Proposed Standard
Hi Tom, The question of where the servers would be located, locally or somewhere out on the Internet, was raised during the development of this document and the answer was, we do not know; so I think that if you only regard it as secure when only an internal network is involved, then that needs calling out in the Security Considerations. Let me observe that significant number of internal networks these days go over third party unencrypted or unsecured to the desired level VPNs. So is it ok to state that a network which consists of N sites all with external EBGP feed while being interconnected by L3VPN could use single cache residing only in one site ? Thx, R. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-ietf-sidr-rpki-rtr-19.txt (The RPKI/Router Protocol) to Proposed Standard
Hi, I think this is great news that two vendors are shipping a pre-standard implementations and are willing to produce implementation survey on it. However I do support both Danny's and Shane's concerns. In addition I have already voiced my own concern that current scenario only discusses one particular deployment model where all edge ASBRs perform validation and that the validation data comes from local caches. IMHO this is way too limited model for any practical deployment of BGP Origin Validation. Best regards, R. Folks, I like to voice my support (on behalf of Cisco Systems) as well. Cisco Systems has recently shipped RPKI Router protocol implementation (in IOS software release). Our implementation has been tested with two different RPKI cache implementations (RIPE, RPKI.NET) and is currently going through lab tests with our customers. We are also in process of writing an implementation survey for this protocol. Regards, Keyur On 12/20/11 11:27 PM, Hannes Gredlerhan...@juniper.net wrote: hi, hereby i want to declare (by myself and on behalf of Juniper Networks Inc.), support for the the rpki-rtr protocol. Juniper Networks Inc. has got an implementation of the protocol based on, draft-ietf-sidr-rpki-rtr-19. Our implementation passed interop testing with 3 different rpki caches (BBN, RIPE, ISC) and got a exposure to a couple of our tier-1 SP customers for labe test purposes. thanks ! /hannes ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-ietf-sidr-rpki-rtr-19.txt (The RPKI/Router Protocol) to Proposed Standard
Let me observe that there could be middle ground to both sides here. While I am very well aware that few of the commercial routers support inline origin validation and rpki-rtr protocol to retrieve the abstract of RPKI data needed for validation it seems also very clear that this is just one possible deployment model. Let's observe that there are going to be orders of magnitude more BGP implementations which will never get the BGP origin validation code into their branches yet which will still happily run in many production networks for years to come which may be a significant obstacle to the deployment of this functionality. Therefor I would consider an alternative deployment model where the validation happens (even if a bit delayed) at few distributed BGP prefix validators around given AS then the outcome of such validation is distributed in the form of BGP policy configuration (via Netconf) to all legacy BGP speakers. While perhaps risking to say unpopular comment my personal preference would be for the latter deployment model. With this in mind I do agree with Shane that in general IETF should try to reuse existing protocols to accomplish the goals by recommending such deployment models which allow one to do so rather then keep inventing more and more protocols to address point solutions. Best, R. I am not sure if this is an architectural misunderstanding V a red herring. As you say, NetConf is for *configuring* routers. RPKI-rtr is not used for router configuration, but rather dynamic data, a la IS-IS or BGP. In fact, the RPKI-rtr payload data go into the same data structure as the BGP data. Of course, the configuration of the RPKI-rtr relationship to cache(s) is router configuration, similar to configuring BGP peers, and presumably can be done by NetConf on those platforms which support NetConf. Bottom line: NetConf 'replaces' the CLI, not BGP. FWIW, two or three years ago, not wanting to reinvent the wheel, we looked at NetConf-style payload packaging. After all, Bert and I chartered NetConf back in the day. I still owe a dinner to the two NetConf folk who helped try. Unfortunately the mismatch was non-trivial, though nowhere near the mismatch of DNSsec, at which we also looked (as the Tonys and I had published in 1998, Lutz in 2006, etc., of which I presume you are unaware). When we evaluated the data bloat for NetConf-style packaging we were not cheered. While probably not important for a CLI replacement, for a continuous dynamic protocol the overhead of unpacking XML and decoding the contained ASCII payload drew unhappy whining from the router hackers. NetConf is not ideal for a long-session back-and-forth protocol, with RPKI-rtr's serial number exchange which leaves the router in control of the exchanges and enables incremental update of the data. You *really* do not want the cache to send the full data set to the router every time. And you definitely do not want a cache trying to keep track of the state of O(100) router clients which may or may not still think they are its friend. And, sadly, NetConf is not available on significant platforms where RPKI-rtr is already running today. So, all in all, being lazy, of course we tried. But it was not a good fit. Of course, if you want to have a go at it, I am sure we would be willing to at least kibitz. But first you might want to talk to the vendors who have already implemented RPKI-rtr to see if they would be willing to re-code. randy ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IETF 82 Audio Streaming
Hi Martin, I was just typing the same - you have beaten me. Amazing thread btw. If your security paranoia exceeds the threshold just use local VM on your machine and get over the applet horror. The hibernated VM as a matter of fact may start faster then an applet ;) Lorenzo - great work ! Cheers, R. Randy Bush wrote: For general remote participation including meetecho support see: meetecho seems to require me to let a java applet have its way with my machine. fat frelling chance. does the ietf really want to recommend such a practice? Folks who upload slides to the datatracker for the IETF Meeting in PowerPoint format are worse than the metecho Java applet. A Java applet will work with most Linux LiveCDs within a throw-away virtual machine. PowerPoint slides regularly require a real Microsoft Windows with a PowerPoint viewer, and while the PowerPoint viewer might be free, the underlying Microsoft Windows is not free. I would really prefer when folks would be using one of those free PDF printer drivers (e.g. doPDF) to convert their slides to PDF, so that the consumer of this has more options available (preconfigured ones and license-free ones). -Martin ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Requirement to go to meetings
get real here. we want global participation. the world is big and the world is round. you gonna pay for it with jet lag, con calls at weird hours, or both. Or none ... there is simple solution like meeting recording, but for some reason IETF proceedings are very crappy in linking wg meetings to their recordings (if at all available). Example: Quebec City ISIS WG meeting http://www.ietf.org/proceedings/81/isis.html 3 drafts presented ... looking at link to audio there is zoo of mp3 without even containing the name of wg in their filename: http://www.ietf.org/audio/ietf81/ Can one perhaps take an action to improve this starting Taipei ? Best, R. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-kompella-l2vpn-l2vpn-07.txt (Layer 2 Virtual Private Networks Using BGP for Auto-discovery and Signaling) to Informational RFC
Hi, I support adoption and publishing draft-kompella-l2vpn-l2vpn-07.txt as informational RFC. Using BGP for auto-discovery and signalling of L2VPNs is by all means a right approach. The draft also makes it very clear that underlying transport is opaque and allows to use any form of encapsulation for PE-PE data exchange. In that light I would not recommend to make any references in it to RFC4447 and treat both specs as fully independent and unreleated documents. Best regards, R. Speaking as an individual, the solution in this draft has been has been operationally deployed in a number of service provider networks, and it should be documented in an informational RFC. Speaking as PWE3 co-chair, I would be happier if this draft required that routers that implement this solution also implement RFC 4447, that RFC 4447 be configured as the default mechanism for pseudowire signaling, and that RFC 4447 was moved from an informational to a normative reference. In practice, I know that routers that implement this also do implement RFC 4447, but I would like to see it in the RFC as well. Thanks, Andy Subject: Last Call: (Layer 2 Virtual Private Networks Using BGP for Auto-discovery and Signaling) to Informational RFC Date: Tue, 30 Aug 2011 10:50:05 -0700 From: The IESG iesg-secret...@ietf.orgiesg-secret...@ietf.org Reply-To: ietf@ietf.org To: IETF-Announce ietf-annou...@ietf.orgietf-annou...@ietf.org The IESG has received a request from an individual submitter to consider the following document: - 'Layer 2 Virtual Private Networks Using BGP for Auto-discovery and Signaling' draft-kompella-l2vpn-l2vpn-07.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 thei...@ietf.org mailing lists by 2011-09-27. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract Layer 2 Virtual Private Networks (L2VPNs) based on Frame Relay or ATM circuits have been around a long time; more recently, Ethernet VPNs, including Virtual Private LAN Service, have become popular. Traditional L2VPNs often required a separate Service Provider infrastructure for each type, and yet another for the Internet and IP VPNs. In addition, L2VPN provisioning was cumbersome. This document presents a new approach to the problem of offering L2VPN services where the L2VPN customer's experience is virtually identical to that offered by traditional Layer 2 VPNs, but such that a Service Provider can maintain a single network for L2VPNs, IP VPNs and the Internet, as well as a common provisioning methodology for all services. The file can be obtained viahttp://datatracker.ietf.org/doc/draft-kompella-l2vpn-l2vpn/ IESG discussion can be tracked viahttp://datatracker.ietf.org/doc/draft-kompella-l2vpn-l2vpn/ The following IPR Declarations may be related to this I-D: http://datatracker.ietf.org/ipr/1149/ ___ IETF-Announce mailing listIETF-Announce@ietf.orghttps://www.ietf.org/mailman/listinfo/ietf-announce ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] draft-ietf-v6ops-6to4-to-historic
Very well said Lorenzo. +1 Unless Ron describes exactly one by one real reasons to give up on draft-ietf-v6ops-6to4-to-historic and majority of v6ops WG agrees with those reasons IMHO the document should proceed as is. It will say that if 6-to-4 is implemented, it must be turned off by default. Last ... if something is turned on or off by default is an implementation choice and last time I checked IETF was not in business to mandate any implementation choice. Thx, R. On Sat, Jul 2, 2011 at 6:36 PM, Ronald Bonica rbon...@juniper.net mailto:rbon...@juniper.net wrote: - In order for the new draft to be published, it must achieve both V6OPS WG and IETF consensus If anyone objects to this course of action, please speak up soon. Great, back to square one. Is the reasoning behind the decision explained somewhere? My reading of the threads on the subject in v6ops was that the opposition to 6to4-historic was a small but vocal minority, and I thought that qualified as rough consensus. But perhaps I missed some discussion. Also, why do the author and the chairs think that the new draft will do any better than 6to4-historic? I would assume that the same people who spoke up against 6to4-historic will speak up against the new document, and since that level of opposition was sufficient to prevent the publication of 6to4-historic, it may be sufficient to prevent publication of the new document as well. If so, we will have spent 3-6 months arguing about it for naught. Please, nobody answer this question with welcome to the IETF :-) ___ v6ops mailing list v6...@ietf.org https://www.ietf.org/mailman/listinfo/v6ops ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] draft-ietf-v6ops-6to4-to-historic
Hi Keith, I personally don't have any objection to the notion that 6to4 should be off by default and should require explicit configuration to enable it. Is there any feature (perhaps other then netboot) on commercial or open source routers which is not off by default and which would require explicit configuration to enable it ? Thx, R. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
