Re: DNSEXT WGLC Summary: AXFR clarify
On Wed, Dec 18, 2002 at 02:14:16PM -0800, Bill Strahm [EMAIL PROTECTED] wrote a message of 64 lines which said: Saying that WG chairs can not work for companies that need the efforts of the WG seems like setting up a big failure, Valdis did not suggest that we *forbid* people to work for companies involved in the work of the WG they chair. Just that we ask them to *disclose* such potential conflicts of interest. (BTW, in the present case, I do not think it has anything to do with a real conflict of interest and everything to do with Bernstein's madness.) To me, it is a very reasonable idea: it goes toward more transparency, which is a good thing. The Internet is a big business now. We can no longer assume that all IETF members are benevolent and disinterested academics working only for the common good. Disclaimer :-) I work for the French registry. We are members of the BIND forum and therefore linked with ISC.
Re: Last Call: Traffic Engineering Extensions to OSPF Version 2 to Proposed Standard
Suresh, As for the comment from John Moy (circa July 2001) about the availability of an inter-area OSPF draft, I do recall responding that the inter-area draft was assuming additive properties to TE metrics to advertise summary info. It is a mistake to assume that all TE metrics can be additive. Below is a pointer to the response I sent. http://discuss.microsoft.com/SCRIPTS/WA-MSD.EXE?A2=ind0108L=ospf; T=0F=S=P=5937 Please look at draft-kompella-mpls-multiarea-te-03.txt, as at least some of the approaches described in that draft do *not* assume additive properties of TE metrics (and do not advertise summary info). Yakov. Yakov - You are right. The draft does talk about different mechanisms the MPLS signaling protocols could use to setup LSPs in an AS spanning multiple areas. However, the draft is not about inter-area OSPF TE. The draft is about multi-area TE, as it describes how to solve the problem of supporting TE in a multi-area environment. Clearly, there is interplay between signalling protocols and the extent of TE link state data base (TE-LSDB) a node has. I believe, scenario-3 is where the inter-area OSPF-TE is in place and all nodes in an area have the same information as their ABRs do. This scenario presents the signalling protocols with fast convergence in settign up an LSP, right. Just to point out that quite a few scenarios described in draft-kompella-mpls-multiarea-te-03.txt are supported with the TE extensions that are subject to this Last Call. To repeat what Kireeti said already There is work going on to address multi-area TE *that builds on this draft*. Yakov.
URI application
Topic: Object-Oriented Database Management System Query Language using URI syntax. Let me tell about this task in brief. My co-workers and I develop Object-Oriented DBMS and network protocol for it. It is not usual DBMS because it is based not so much on the data storage as on the network data representation. It has allowed to minimize data transformations in a chain between the disk file and the end-client screen. I want to tell that this DBMS is very integrated with network technologies. And so there was an idea to develop a query language on a basis of URI syntax instead of SQL-like syntax. It will be much more convenient for object-oriented tasks. However there were difficulties in the definition of such URI scheme. Probably, there are similar decisions and already developed query construction rules. If you know about good ideas, please, give me references. If this theme is interesting to you, I shall pass to technical details. According to URI Generic Syntax (RFC-2396) there would be a following suitable format: scheme://authority/alias/path?conditions#fields The meaning of scheme and authority components are determined in the specified document; alias - specifies a database name; path - masks a path to object on a hierarchical key; conditions - specifies a selecting conditions; fields - defines a set of fields. Let's consider path component. For object identification in the database a hierarchical key are used. It allows to build a tree as we usually do with filesystem pathnames. In object-oriented languages it is common way to separate the path components by . delimiter. URI gives certain freedom in scheme-specific-part definition, however it is accepted to use / for components separating. The character . is used in URI to separate a hierarchical authority name components. It would be necessary to know your opinion of this conflict solution. Fore example, URI may look like: uod://hostname.com/DatabaseName/Root.Node.Object The primary applicability of the scheme is OODBMS queries. On this, it is necessary to describe masking rules and conditions representation format. It is convenient to use * for any character sequence masking (including empty), and ** for masking any path component sequence. Traditionally the masking symbol for one character is ? but this symbol is used for query (or conditions in this case) component separating in URI string. Examples (it is obvious without explanation, i suppose): /Root.*.Object1 /Root.**.Object1 /Root.abc!def.* /Root.**.abc*def I shall notice that masked path may satisfy a set of objects (or empty set). How it will be represented in reply message is the task of certain protocol. Each object in OODBMS can be also masked by Class name. For Class specification we can use usual structure Object:Class. Using name and class mask together it is possible to create such complex expressions: /Root.*:Class1.Object1 /Root.ab!!25*:*A /Root.Node1.**.A*:Class1 /Root.A*:C,*A:D.Node1,Node7,Node8.Object1 For conditions specification it is possible to use any expression after ?. The following examples demonstrate simple and complex conditions using mathematical operations, masking, enumeration, etc.: /Root.Path.Object?Field1 /Root.Path.Object?Field1=Value1 /Root.Path.Object?(Field1+Field2)Value1 /Root.Path.Object?Field1=Value1Field2=Value2 /Root.Path.Object?Field1=Value1,Value2 /Root.Path.Object?Field1=Value1..Value2 /Root.Path.Object?Field1=ab*cd!ef Here it is necessary to think about realization of complex conditions, for example, if it is necessary to select objects on a logical condition: ( A5 and B=8 and C=3 ) or ( A5 and B=2 and C=100 ) In http URI it is accepted to express so: ...?A5B=8C=3+A5B=2C=100 Various WEB searching systems converts a logical operation and into character and logical or into +. But a operation order can not be expressed so. Furthermore, the + in this example can confuse a user because 3+A is looked as a first priority operation. Using brackets it is possible to writ out something like: ...?(A5B=8C=3)+(A5B=2C=100) or ...?((A5)(B=8)(C=3))+((A5)(B=2)(C=100)) This example can be also written down using words and, or: ...?((A5)and(B=8)and(C=3))or((A5)and(B=2)and(C=100)) There is another variant of and coding using ;, for example A=2;B=3. And if it is necessary to unite some conditions together through or operation we can write them so: ...?Condition1?Condition2?Condition3 For example: ...?A5;B=8;C=3?A5;B=2;C=100 If using of ? is not desirable, it is possible to replace it with /, for example: ...?Condition1/condition2/condition3 If you want to receive a table or a report form with listed fields instead of a objects set as a query result, is possible is specify a fields list. For example: /Root.Object1#Field1,Field2,Field3 Using all URL components together: /Root.**.Name!mask*:Class#Field1,Field2,Field3?Field45;Field5=ABCD I purposely use # before ?
Re: DNSEXT WGLC Summary: AXFR clarify
On Thursday, Dec 19, 2002, at 06:12 America/Montreal, 'Stephane Bortzmeyer' wrote: Valdis did not suggest that we *forbid* people to work for companies involved in the work of the WG they chair. Just that we ask them to *disclose* such potential conflicts of interest. (BTW, in the present case, I do not think it has anything to do with a real conflict of interest and everything to do with Bernstein's madness.) To me, it is a very reasonable idea: it goes toward more transparency, which is a good thing. The Internet is a big business now. We can no longer assume that all IETF members are benevolent and disinterested academics working only for the common good. Disclaimer :-) I work for the French registry. We are members of the BIND forum and therefore linked with ISC. I agree with the notion that all folks in positions of perceived power (e.g. IAB, IESG, WG Chairs, IRTF Chair) should be required to disclose publicly all of their relationships (e.g. employment, presence on other Internet-related positions such as board of a registry, technical advisory board memberships, and so forth) that might possibly be conflicts of interest. The goal should be to err on the side of too much disclosure, rather than too little. Marshall Rose did a good job of this when on IESG, though unfortunately his precedent has not often been followed. Lack of such disclosure is currently a problem with the current IETF/IESG/IAB structure. I'm not generally a fan of more process or more rules, but I think this one should be required not optional. Ran [EMAIL PROTECTED] PS: None of this is related to any claims by djb. PPS: Practicing what I preach, I'll note that I work for Extreme Networks and am on the TABs of NetVMG and STV.
Re: DNSEXT WGLC Summary: AXFR clarify
I agree with the notion that all folks in positions of perceived power (e.g. IAB, IESG, WG Chairs, IRTF Chair) should be required to disclose publicly all of their relationships (e.g. employment, presence on other Internet-related positions such as board of a registry, technical advisory board memberships, and so forth) that might possibly be conflicts of interest. The goal should be to err on the side of too much disclosure, rather than too little. I like that we have individuals at the ietf meetings rather than company representatives, in the long run it creates less politics. I don't think anyone who attempts to move drafts for financial gain will ever gain much; these documents we develop here (less the informational track) stand on their own. -rick
RE: Last Call: Traffic Engineering Extensions to OSPF Version 2 to Proposed Standard
... snip Please look at draft-kompella-mpls-multiarea-te-03.txt, as at least some of the approaches described in that draft do *not* assume additive properties of TE metrics (and do not advertise summary info). Yakov. Yakov - You are right. The draft does talk about different mechanisms the MPLS signaling protocols could use to setup LSPs in an AS spanning multiple areas. However, the draft is not about inter-area OSPF TE. The draft is about multi-area TE, as it describes how to solve the problem of supporting TE in a multi-area environment. OK. Clearly, there is interplay between signalling protocols and the extent of TE link state data base (TE-LSDB) a node has. I believe, scenario-3 is where the inter-area OSPF-TE is in place and all nodes in an area have the same information as their ABRs do. This scenario presents the signalling protocols with fast convergence in settign up an LSP, right. Just to point out that quite a few scenarios described in draft-kompella-mpls-multiarea-te-03.txt are supported with the TE extensions that are subject to this Last Call. To repeat what Kireeti said already There is work going on to address multi-area TE *that builds on this draft*. Yakov - My comment on the katz-yeung draft concerning multi-area is that it supports TE in a single OSPF area; and hence to rename the draft as TE extensions to an OSPFv2 area. My recommendation against using this draft as the basis for building further TE-extensions to inter-area and mixed networks was in the context of OSPF Autonomous System (AS). I also mentioned the draft has scalability limitations in extending this to inter-area and mixed networks - also in the context of OSPF AS. Without going into the details of the Multi-area MPLS Traffic Enginering draft - The work cited in this draft as going on to address multi-area TE is in the MPLS signalling context, not in the OSPF. Yakov. regards, suresh
Re: Last Call: Traffic Engineering Extensions to OSPF Version 2 to Proposed Standard
Suresh, Please look at draft-kompella-mpls-multiarea-te-03.txt, as at least some of the approaches described in that draft do *not* assume additive properties of TE metrics (and do not advertise summary info). Yakov. Yakov - You are right. The draft does talk about different mechanisms the MPLS signaling protocols could use to setup LSPs in an AS spanning multiple areas. However, the draft is not about inter-area OSPF TE. The draft is about multi-area TE, as it describes how to solve the problem of supporting TE in a multi-area environment. OK. Clearly, there is interplay between signalling protocols and the extent of TE link state data base (TE-LSDB) a node has. I believe, scenario-3 is where the inter-area OSPF-TE is in place and all nodes in an area have the same information as their ABRs do. This scenario presents the signalling protocols with fast convergence in settign up an LSP, right. Just to point out that quite a few scenarios described in draft-kompella-mpls-multiarea-te-03.txt are supported with the TE extensions that are subject to this Last Call. To repeat what Kireeti said already There is work going on to address multi-area TE *that builds on this draft*. Yakov - My comment on the katz-yeung draft concerning multi-area is that it supports TE in a single OSPF area; and hence to rename the draft as TE extensions to an OSPFv2 area. Let's be precise. The katz-yeung draft defines certain TE-related information, and specifies how to distribute this information within a single area. That is it. My recommendation against using this draft as the basis for building further TE-extensions to inter-area and mixed networks was in the context of OSPF Autonomous System (AS). I also mentioned the draft has scalability limitations in extending this to inter-area and mixed networks - also in the context of OSPF AS. Without going into the details of the Multi-area MPLS Traffic Enginering draft - The work cited in this draft as going on to address multi-area TE is in the MPLS signalling context, not in the OSPF. As I said in my previous e-mail quite a few scenarios described in draft-kompella-mpls-multiarea-te-03.txt are supported with the TE extensions that are subject to this Last Call. That is precisely while quite a few scenarios in the Multi-area MPLS Traffic Engineering draft do not require any additions to what is already defined in the katz-yeung draft. Yakov.
Re: URI application
At 07:43 PM 12/19/02 +0200, Timur Shemsedinov wrote: Using all URL components together: /Root.**.Name!mask*:Class#Field1,Field2,Field3?Field45;Field5=ABCD I purposely use # before ? because field list specification is logically follows path component. I suggest you review this: http://www.w3.org/DesignIssues/Fragment.html #g --- Graham Klyne [EMAIL PROTECTED]
Re: DNSEXT WGLC Summary: AXFR clarify
Hi - Date: Thu, 19 Dec 2002 10:03:34 -0800 (PST) From: Rick Wesson [EMAIL PROTECTED] To: RJ Atkinson [EMAIL PROTECTED] Cc: 'Stephane Bortzmeyer' [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: Re: DNSEXT WGLC Summary: AXFR clarify In-Reply-To: [EMAIL PROTECTED] Message-ID: [EMAIL PROTECTED] ... I like that we have individuals at the ietf meetings rather than company representatives, in the long run it creates less politics. ... At best, this is a useful fiction. My limited experience has been that the politics in the IETF are much thicker and less transparent than in ANSI-accredited technical committees or in the ISO/ITU collaborative work I've seen. On the other hand, some industry consortia seem far more opaque. YMMV, but I've found that even when folks truly believe they are speaking as individuals, their thinking may nonetheless be influenced by their company's business model and technology focus. Our knowledge of requirements is strongly influenced by the customers we talk to. I think this is particularly true in small technology companies, where it is all but impossible to separate the company view from the perspective of its key technical people. Potential conflicts of interest worry me most in the process of deciding whether a WG will work on something, since this is what most directly affects business models and licensing strategies of organizations that may have an interest in something *not* being standardized, or in letting the market drive a particular implementation into the position of de facto standard. Once the decision has been made to permit a WG to work on a particular problem, I think our normal technical review processes should be trusted to ensure that the solution chosen is fairly reasonable. One of the ironies of disclosure is that sometimes others will read ulterior motives into the actions of someone who is going out of their way to avoid blocking or interfering with work that, for whatever reason, they do not chose to actively support. -- Randy Presuhn BMC Software, Inc. SJC-1.3141 [EMAIL PROTECTED] 2141 North First Street Tel: +1 408 546-1006 San José, California 95131 USA -- My opinions and BMC's are independent variables. --
Re: DNSEXT WGLC Summary: AXFR clarify
On Thu, 19 Dec 2002, RJ Atkinson wrote: ... I agree with the notion that all folks in positions of perceived power (e.g. IAB, IESG, WG Chairs, IRTF Chair) should be required to disclose publicly all of their relationships (e.g. employment, presence on other Internet-related positions such as board of a registry, technical advisory board memberships, and so forth) that might possibly be conflicts of interest. The goal should be to err on the side of too much disclosure, rather than too little. I am opposed to such a radical change. The goal should be that, when necessary, actual problems demonstrated by actions are addressed, not to indulge in the usual ever spiraling increase in paperwork load and bureaucratic nonsense. No normal human being can ever make a disclosure complete enough to withstand a denial-of-service attack though the endless nit-picking of trivial errors and omissions nor would any normal human being ever want to wade through any of the diarrheal too much disclosure documents you advocate. They would, presumably, have to include details of all amorous relationships and sexual acts performed with anyone who has any opinion on matters before the IETF, since such acts can produce conflicts of interest between sound technical judgment and a desire to please such partners. And shouldn't they also be required to disclose all relationships that might be a conflict of interest for all of their relatives by blood or marriage? After all, they might be indirectly influence by such connections. This is the same nonsense as demands that transcripts of all communications on items before the IETF be made public, including hallway conversations, telephone calls, etc., etc., etc. Lack of such disclosure is currently a problem with the current IETF/IESG/IAB structure. I'm not generally a fan of more process or more rules, but I think this one should be required not optional. Members of the IESG and IAB are selected by the IETF community and specifically undertake to act in the best interests of the IETF community. If they were proven not to be acting so, based on specific actions, not vague handwaving about conflicts, they can be removed. That's enough for me. Someone who was a fan of more process, paperwork, and rules would certainly advocate total disclosure, which is only an inviation to add endless debate about the completeness, details, and timeliness of the disclosure while failing to eliminate any of the complaints about conflicts. People with good technical arguments make technical arguments. Some people who have lost technically wave their hands about conflicts of interest. Some people who have lost techncially and can't even find a conflict would love to slow everything down and create a burden of paperwork so they can then complain about nits in the paperwork, and there will always be nits in the paperwork. Lets not give them that pleasure. Ran [EMAIL PROTECTED] Donald PS: For real examples of the problems I suggest with this idea, see the past proceedings of the FCC where radio broadcast licneses are being decided between applicants. Its routine for applicants to hire detectives to dig up any dirt they can on the other applicant's people and then to argue that their application should be rejected because they didn't reveal the dirt voluntarily in public filings with the FCC even when, as is almost always the case, there is no regulation prohibiting applicants with that particular dirt. Vague complete disclosure rules are routinely used as weapons in this manner. Do we really want to eliminate the privacy of all persons in responsible IETF positions? == Donald E. Eastlake 3rd [EMAIL PROTECTED] 155 Beaver Street +1-508-634-2066(h) +1-508-851-8280(w) Milford, MA 01757 USA [EMAIL PROTECTED]
Re: DNSEXT WGLC Summary: AXFR clarify
YMMV, but I've found that even when folks truly believe they are speaking as individuals, their thinking may nonetheless be influenced by their company's business model and technology focus. Our knowledge of requirements is strongly influenced by the customers we talk to. I don't think we're expected to be omniscient. I think we're expected to try to understand the diversity of interests that might be affected by a protocol and to try to work for the greater good. Keith
