Re: WG Review: NETCONF Data Modeling Language (netmod)
--On April 15, 2008 13:30:01 -0700 IESG Secretary [EMAIL PROTECTED] wrote: NETCONF Data Modeling Language (netmod) I support the creation of this WG. 2. The YANG data modeling language and semantics (proposed standard) ... 5. Mapping rules of YANG to DSDL data modeling framework (ISO/IEC 19757), including annotations for DSDL to preserve top-level semantics during translation (proposed standard). A great deal of effort has been put into designing standard XML data modeling languages over many years and given that both DTD and XML Schema have significant weaknesses (particularly in the area of extensibility), a DML for XML is clearly difficult and requires special expertise. (5) is critical to demonstrating that YANG has learned from the mistakes of past XML-DMLs with respect to extensibility and other areas. The simpler (5) happens to be, the more confident I will become that YANG is following best practices for XML DMLs. 4. YIN, a semantically equivalent fully reversible mapping to an XML-based syntax for YANG. YIN is simply the data model in an XML syntax that can be manipulated using existing XML tools (e.g., XSLT) (proposed standard) If 5 is as simple as I think it should be, then I suspect there will be little semantic difference between 4 5 and much additional utility in 5. I'd prefer if the WG was free to drop work item 4 in the event I'm correct. If 2 provides the human-friendly form and 5 provides the form that best leverages existing standard XML tools and parsers then I see no value in 4 which is both less human-friendly than 2 and less XML-tool-friendly than 5. In the event I'm wrong and there are significant semantic differences between 2/4 and 5 that are well justified, then I don't object to continued work on 4. I suggest adding a sentence to the charter: In the event work items 4 and 5 are semantically similar, the WG may choose to omit work item 4. I'm interested in other opinions on this topic. - Chris ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Weekly posting summary for ietf@ietf.org
Andrew G. Malis wrote: Thomas, I would personally find this more useful if it were measured by subject line rather than by sender. At the time when these summaries started, it was obvious from some summaries that some participants seemed to be spending more time typing answers than reading the responses (when one person had two to three times as many postings as #2 on the list). That behaviour has largely disappeared, so it may be less obvious why it's a good thing to see this metric. Personally, I'm for keeping the weekly posting as-is. Harald Thanks, Andy On Fri, Apr 18, 2008 at 12:53 AM, Thomas Narten [EMAIL PROTECTED] wrote: Total of 103 messages in the last 7 days. script run at: Fri Apr 18 00:53:01 EDT 2008 Messages | Bytes| Who +--++--+ 6.80% |7 | 5.33% |37130 | [EMAIL PROTECTED] 5.83% |6 | 6.08% |42351 | [EMAIL PROTECTED] 5.83% |6 | 5.17% |35998 | [EMAIL PROTECTED] ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Useful summary for ietf@ietf.org
On Fri, Apr 18, 2008 at 09:41:33PM +0300, Hannes Tschofenig [EMAIL PROTECTED] wrote a message of 46 lines which said: Rather than providing these types of summaries it would make more sense to provide a conclusion of the individual discussions. This, btw, often does not happen in working groups either. As a consequent nobody knows (after a long discussion) whether there was a conclusion or what the conclusion could have been. Before trying to summarize the (very open) discussions on the IETF general mailing list, a good start would be to summarize IESG evaluations... I would be interested to know, for instance, why draft-ietf-mboned-addrarch or draft-michaelson-4byte-as-representation were not approved by IESG (there is certainly a good reason, but to extract it from datatracker is not obvious). ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [NGO] WG Review: NETCONF Data Modeling Language (netmod)
Chris Newman writes: The simpler (5) happens to be, the more confident I will become that YANG is following best practices for XML DMLs. My guess is the opposite: many of the more useful features of XSD and DSDL require distinct and uncomfortable layout of the schema material. For example, the XSD substitution group mechanism allows for extensibility, but requires the schema to include substitution group information pervasively throughout the schema and to make a very shallow hierarchy through the use of types and indirection. This gives a format that I believe non-validating consumers of the schema will find difficult to read and use. By contrast, YIN is a straight-forward conversion of the textual data from a YANG module into an XML format that can be easily and directly used by the consumer. The conversion is trivia and the information is in a state identical to the YANG module's layout. The encoding is changed (to XML) but the content is untouched. So if (5) is simple, we've either chosen not to use significant but uncomfortable features in the low-level output language, or we've lost the conciseness, hierarchical view, and other high-level features that makes YANG worthwhile. This isn't to say that (5) shouldn't be fairly mechanical, something that a perl or xslt script could handle, but it shouldn't be called simple, nor should the complexity of that transformation a basis for judging YANG. Thanks, Phil ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Weekly posting summary for ietf@ietf.org
Harald, My thinking is that many of us (well, at least me) don't have enough time to read everything single email or thread on the ietf list ... but if it turns out that a particular thread that I've been ignoring has generated a lot of mail this past week, then maybe it's worth it to go back to check it out. Just a thought ... Cheers, Andy On Mon, Apr 21, 2008 at 10:58 AM, Harald Alvestrand [EMAIL PROTECTED] wrote: Andrew G. Malis wrote: Thomas, I would personally find this more useful if it were measured by subject line rather than by sender. At the time when these summaries started, it was obvious from some summaries that some participants seemed to be spending more time typing answers than reading the responses (when one person had two to three times as many postings as #2 on the list). That behaviour has largely disappeared, so it may be less obvious why it's a good thing to see this metric. Personally, I'm for keeping the weekly posting as-is. Harald Thanks, Andy On Fri, Apr 18, 2008 at 12:53 AM, Thomas Narten [EMAIL PROTECTED] wrote: Total of 103 messages in the last 7 days. script run at: Fri Apr 18 00:53:01 EDT 2008 Messages | Bytes| Who +--++--+ 6.80% |7 | 5.33% |37130 | [EMAIL PROTECTED] 5.83% |6 | 6.08% |42351 | [EMAIL PROTECTED] 5.83% |6 | 5.17% |35998 | [EMAIL PROTECTED] ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Proposed IESG Statement Regarding RFC Errata for IETF Sream RFCs
All three categories are absolutely needed. It is self evident, although unfortunate, that the accepted category will be used. Even after WG, IESG, IETF LC, and the RFC editor, some errors make it through. From my experience with RFC errata, the rejected category will also definitely be used. I have seen some entirely erroneous comments (for example claiming that pseudocode for packet processing could not be correct since the loop over packets never terminates - the proposed fix was to decrement the packet size each time and terminate when the packet size reached zero!), and some pretty useless rewordings. Although we can quibble over the nomenclature, the archived category has several uses. One example is when the erratum submitter was not a WG participant, and truly could not understand what was intended (at least without the authors explaining what they meant). If the RFC is ever obsoleted by a newer one, this will serve as a reminder to rewrite that passage. Another example is when the RFC suggests a method to handle an exception, while a simpler method is inherent in the protocol itself. Y)J(S ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Useful summary for IESG [was [EMAIL PROTECTED]
Stephane, On 2008-04-22 03:04, Stephane Bortzmeyer wrote: On Fri, Apr 18, 2008 at 09:41:33PM +0300, Hannes Tschofenig [EMAIL PROTECTED] wrote a message of 46 lines which said: Rather than providing these types of summaries it would make more sense to provide a conclusion of the individual discussions. This, btw, often does not happen in working groups either. As a consequent nobody knows (after a long discussion) whether there was a conclusion or what the conclusion could have been. Before trying to summarize the (very open) discussions on the IETF general mailing list, a good start would be to summarize IESG evaluations... I would be interested to know, for instance, why draft-ietf-mboned-addrarch or draft-michaelson-4byte-as-representation were not approved by IESG (there is certainly a good reason, but to extract it from datatracker is not obvious). https://datatracker.ietf.org/idtracker/draft-michaelson-4byte-as-representation/comment/62414/ seems pretty clear to me; you might disagree, but that's another matter. However, what you say is why the IESG started its narrative minutes at http://www.ietf.org/IESG/iesg-narrative.shtml but they depend on volunteer effort. I find them useful. Brian ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-snell-atompub-bidi (Atom BidirectionalAttribute) to Experimental RFC
The dir= is not really intended to specify that the direction is not known but that the direction has not been specified explicitly. For instance, in an aggregate feed containing entries from multiple sources, the original entries may or may not have contained the bidi attribute. Because of the inheritance of direction from the feed, entries that do not have a dir=... attribute will inherit the direction of the parent, which will change the context of the original entry and could potentially lead to the context being improperly or at least unexpectedly displayed relative to the original. - James Frank Ellermann wrote: Stephane Bortzmeyer wrote: as I said, otherwise, you could not express the fact that the direction of the text in the bar element above is Not Known. Without dir=, you could not cancel the directionality of foo in its nested elements. Well, yes, but so far the Web with all its (X)HTML pages never needed an unknown direction feature, why is this necessary in ATOM ? And how would you implement an unknown direction, toss a coin ? Frank ___ 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: Last Call: draft-snell-atompub-bidi (Atom Bidirectional Attribute) to Experimental RFC
My apologies for not getting back to this sooner. Comments below. Frank Ellermann wrote: James M Snell wrote: If another version of the draft is needed based on last-call comments, I can make the name change then. Leave it alone, please. Various tools have problems with tracking changed names. Changing the name to RFC at some point in time is IMO good enough. Understood. I don't find dir= in the HTML 4.01 spec., why does Atom need dir= ? I answered this is another note that I just sent. The main issue is one of inheritance. With Atom, it is possible to construct aggregate feeds from multiple sources, each of which may or may not explicity specify the base directionality. The dir= option is provided to prevent children from inheriting the parent's directionality while preserving the lack of an explicitly set direction. - James Frank ___ 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
P2P Infrastructure Workshop Announcement, May 28, 2008
The Real-time Applications Infrastructure (RAI) Area Directors, Jon Peterson and Cullen Jennings, would like to announce an IETF workshop on P2P Infrastructure to be held on May 28, 2008 at 50 Vassar St, Room 34-101 on the MIT campus in Cambridge, MA USA. Several large ISPs have encountered issues with P2P traffic. The transfer of static, delay-tolerant data between nodes on the Internet is a well-understood problem, but traditional management of fairness at the transport level has largely been circumvented by applications designed to achieve the best end-user transfer rates. This results, at peak times, in networks running near absolute capacity, and in which all traffic incurs delays; the applications that bear the brunt of this additional latency are real-time applications like VoIP and Internet gaming. This has led to need for further discussion of the proper approaches to P2P application development, and infrastructure management in environments where P2P is commonly used. This workshop intends to discover where additional IETF standards work is needed, or existing work might be reapplied, to alleviate these difficulties. In particular, the workshop will draw on the experiences of Comcast and BitTorrent, representatives of both of whom will present their perspectives on the problem space. Example solution discussions might include, but are not limited to: deployment of application servers or caches to reduce network load; new rendez-vous mechanisms to optimize P2P network topology; enabling applications to signal their bandwidth needs (and priority or lack thereof) to networks; enabling networks to signal bandwidth constraints to elastic and inelastic applications; and, new approaches to fairness that are coupled with incentives for applications. Contributions from subject matter experts in the problem and solution space are welcome. The primary outcome should be a direction for one or more IETF efforts exploring the best practices for addressing these challenges. The organizers would like to stress that this is a technical workshop exploring engineering issues and practices. The public policy implications of P2P applications are not in the scope of this workshop. Position papers are requested from all attendees by May 9. Contact the RAI ADs for a waiver if it is inappropriate for you to submit a position paper. These should constitute one to five pages on the problem or solution space of P2P architectures, with a particular emphasis on areas that the IETF should address or revisit. Position papers will be made publicly available. On the basis of the position papers, a number of invited speakers will be asked to present at the workshop. A final agenda with timeslots will be published by May 16th. Potential attendees for whom it is not appropriate to supply a position paper may contact the RAI ADs for a waiver. Evaluation of the position papers will be performed with the assistance of a program committee consisting of the RAI ADs, Lars Eggert (Transport AD), Danny Weitzner (MIT), John Morris (CDT), and Dave Clark (MIT). Further information about position paper submission procedures are forthcoming. Interested parties are advised to subscribe to the [EMAIL PROTECTED] mailing list for discussion and announcements related to the workshop. Additional information will be available at http://www3.tools.ietf.org/area/rai/trac/wiki/PeerToPeerInfrastructure. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
