+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ IETF 74, NETMOD WG Monday, March 23, 2009 17:40-19:40 David Kessens, David Partain About 25 attendees WG status and Agenda Bashing (David Partain) The working group will have two sessions so there will be lots of time to address any issues and to make good progress. Drafts are available for all work items, but not quite following the proposed time line. The NETMOD architecture draft is rather late so that one needs to get special attention. Notes: Phil Shafer, Alan Luchuk, David Reid, and Balazs Lengyel Jabber: Will Ivancic ------------------------------------------------------------- NETMOD architecture document discussion: Phil Shafer David Kessens: Who read architecture? 15 hands. Ca. 1/2 the attendees have read the draft. Phil Shafer: Comments mainly to remove stuff. Is this good enough? Andy Bierman: Happy with the document. I am missing a NETCONF architecture, but for current scope fine. It doesn't say things that are out of scope. No unreasonable assumptions. Balazs Lengyel: It is in good condition. Mehmet Ersue: looks good. General consensus is that the new document is much improved. General consensus is that the new doc is ready for last call, after minor edits. Balazs Lengyel, David Partain, and Dan Romascanu have comments on the draft. Several people asked for a NETCONF architecture document also. David Harrington would like to petition the NETCONF WG for such a document. ?? (sorry, missed the name): I am interested in writing NETCONF architecture. This is fine for NETMOD, but would like something with a wider scope. David Harrington: NETCONF WG should write NETCONF architecture. Dan Romascanu: NETCONF architecture should be done in the NETCONF working group. NETMOD architecture is needed to show why YANG is needed and how YANG should work together the other components. We can start discussions for a bigger document in NETCONF WG. David Partain: How many people who read it think it is OK to go to WG last call. Most of them. (13?) ---------------------------------------------------------------- Common YANG Data Types document discussion: Martin Bjorklund for Juergen Schoenwaelder (who was on jabber) How many have read the document: about 10 Summary of changes was presented. --------------------------- Discussion of XPATH type and versioning Ladislav Lhotka suggested xpath1, matter a preference; suspects there will not be more than 2 versions for quite a long time. Wes Hardaker suggested xpath1.0 because it is easier to extract and compare numerically. Ladislav Lhotka: There won't be any XPath 1.1 so there is need for xpath1.0. David Harrington: How does XPath define version number Martin Bjorklund: 1.0 David Harrington suggested following an existing standard numbering scheme Consensus: Show of hands 6/4 for Xpath1.0 -------------------------------------------------------------- Canonical form of an XPATH expression? Proposal: Don't define a canonical form. Some concern about whether the lack of a canonical form will result in interoperability issues. Several people did not think it would be a problem. Phil Shafer: When is this needed? What does canonical mean for xpath? Rewriting axis? Martin Bjorklund: namespaces. Martin Bjorklund: Filtering, keys in the database - problem is with prefixes, dependent on context. Andy Bierman: no axis in our uses of xpath (?). No win in canonicalization. The reason to canonicalize it is the agent needs to resolve the namespaces in the context of the config. David Harrington: If we don't have a canonical form, what about interoperability? Can't depend on the agent and manager coming from the same vendor. Could define crappy little rules that everyone should follow. David Harrington: XPath might be used for access control. If we don't have a canonical format will access control work? Ladislav Lhotka: It is not an interoperability problem. The XPath spec guarantees interoperability. Martin Bjorklund: Filtering keys, might not work? Andy Bierman: What about whitespace normalisation, tokens, self or descendant? Phil Shafer: is there a real use case? Martin Bjorklund: It is used mostly in protocol RPCs not in configuration datastore. In the PDU context. Andy Bierman: NETCONF monitoring uses it. This is no different than string identifiers. The problem is not worse than a simple string. Phil Shafer: Namespace mappings should be explicit, not contained in the context. David Partain: we have a use case, since it's in documents that are already written. Martin Bjorklund: could be generated differently on each . In theory you could generate different prefixes for every call. Ladislav Lhotka: Prefixes are not stable, they should not be used. Martin: Yes, but this datatype is better than nothing. Balazs Lengyel: could we specify/suggest prefixes that aren't 100% but will help in many cases? We need to explicitly say the prefix mappings (the prefix strings themselves) may changed. Ladislav Lhotka: the prefix means nothing, just represents the URI string. Against prescribing a fixed prefix. Wes Hardaker: make two different datatypes, one for string and one where canonicalization matters. Datatypes are cheap. David Harrington: can xpath expressions be interpreted differently? Martin Bjorklund: nope Ladislav Lhotka: discussion is moot because the xpath datatype is derived from string so there's no difference between xpath and string. David Partain: An engine can do something smart if it knows it is an XPath. Andy Bierman: Disagrees. It helped in implementation. The type is needed because trying to guess if it's xpath is expensive. Andy Bierman: The context and prefixes are a problem, and so canonical form is not needed/possible. Wes Hardaker: WG should not define canonical XPath, but if there is a definition use it. Most of the time we don't care for the exact match. A search for 'canonical xpath' yields multiple matches. Proposed looking for a canonical XPATH definition, and reuse if possible, otherwise we cannot solve the problem. David Partain: Anyone for working on a canonical form? None. Consensus in the room: Look for an existing canonical XPATH definition and reuse it if such exists. Otherwise, we do nothing. Put the canonical form (if found) in a separate data type. -------------------------------------------------------------- IPv6 Address Pattern? Which pattern should be used? Do we need a pattern at all? Ladislav Lhotka/Juergen Schoenwaelder came up with a pattern that seems to work. Ladislav Lhotka: new revision works in Ladislav Lhotka and Juergen Schoenwaelder tests; others should test it also. -------------------------------------------------------------- Do we have to support all IPv6 address writing styles, or can we just use the canonical IPv6 address format? (Slide 5) Ladislav Lhotka: If we allow it for IP address we should allow it here. Ladislav Lhotka referred to an RFC standard. David Harrington: how does it affect interoperability? Martin Bjorklund: should have the same rules for addresses and prefixes. Ladislav Lhotka: allow both David Kessens as contributor: suggested a single format makes for simpler, more interoperable code. Martin: We are not inventing it here. Phil Shafer: Should be just as flexible for prefixes as for addresses. People use the shorthand, so we should support them. Juergen Schoenwaelder: would like the flexibility. Hands for supporting all: 8 against: 1 Rough consensus: Support all IPv6 writing styles. -------------------------------------------------------------- DNS expert advice is needed so we get the restrictions on the DNS label right and future proof. People already discussing this. Once the DNS experts have had their say, Juergen will propose the relevant change. -------------------------------------------------------------- URI expert advice is needed to answer the question if it is safe to use the regular expression from RFC 3986. Currently the uri type is defined as a string with restrictions in the description clause only David Partain will ask for expert review from apps area. (Editor note: This process is underway.) Juergen Schoenwaelder: question is whether the regular expression in Appendix B of RFC 3986 can be used? Ladislav Lhotka: Using it in his code, and it seems to work. -------------------------------------------------------------- IEEE Port List (slide 8) Suggestion to add a port list type (Juergen Schoenwaelder) Suggestion to use a comma separated list of port ranges: e.g. 1-5,8,10-22. Ranges may not overlap and may not be consecutive. Andy Bierman: do not add type right now Martin Bjorklund: also do not add too much stuff Dan Romascanu: did not see a reason to add David Harrington remembers textual conventions for SMI to use standard formats. Suggested defining a type consistent with other definitions, such as IEEE or SNMP to promote standardization. David Harrington: came from TC; don't know where it came from; people were defining VLAN lists and came up with multiple alternatives. Juergen Schoenwaelder: TC is in the qbridge MIB but the TC uses a binary stream, each bit representing a port. David Harrington: a great deal of work was done; we should be consistent with that work; don't recall the bit stream stuff, but we can always add it later. David Partain: doesn't mind adding it as long as there is not extensive debate. Phil Shafer: This opens a lot of other issues, integer ranges, number of ranges. David Harrington: remembers a lot of effort and interoperability problems due to the lack of something defined for SNMP. Lobbied for adding this to YANG, but could come later. Dan Romascanu: discussion of bridge MIBs. Suggested defining later in YANG bridge modules. Dan Romascanu: some confusion, because this is trying to mirror work in bridge MIB but that MIB uses these as an index for tables. More general concern: we are trying to sync with ietf MIBs but IEEE has extended those. This should be postponed to bridge YANG basic module. I see bridge as an early customer for YANG, but we can do more work then. Juergen Schoenwaelder: Phil's questions are easy to address. Qbridge MIB. no definition, should be deferred, can define using port list TCs David Partain: consensus: defer until needed -------------------------------------------------------------- Add Other VLAN types (Slide 9) Juergen Schoenwaelder: defer David Partain: consensus: defer until needed -------------------------------------------------------------- Other comments/questions Phil Shafer: do not leave room until all open issues resolved, not all issues resolved. David Partain: two issues are open for expert review: 1. URI (uri datatype) (editor: underway) 2. DNS (domain-name datatype) (editor: underway) Also XPath canonicalization standards; if we find one we like, we'll define a new type "xpath-canonicalized" ((editor: discussion already on mailing list) Balazs Lengyel: customers want a port number of 0, meaning "wildcard". Change explanation of port type, or define a new type? Phil Shafer: isn't this a perfect use for unions? Juergen Schoenwaelder: port number 0 is not valid, a union might be a good solution. YANG draft: Martin Bjorklund How many people have read -04: 10 Summary of changes since draft 02 -------------------------------------------------------------- Order of XML elements Currently the draft specifies that all XML elements are encoded in the same order as specified in the YANG model Proposal: remove this restriction, and specify that XML elements can encoded in any order. This maps nicely nicely in RelaxNG. Andy Bierman: in NETMOD only, or in also in NETCONF? NETCONF keeps the same ordering. Martin Bjorklund: perhaps only for application or layer 4. David Reid: why make the change? Martin Bjorklund: allow any order unless there is a good reason for the order to be specified David Harrington: why allow any way? Why not require a specified order? How will it affect interoperability. Andy Bierman: it's harder to enforce the order than to ignore it. Martin Bjorklund: single agent, multiple NETMOD modules, each has top level, why require forced order? Juergen Schoenwaelder: most XML servers do not enforce an order, why should NETMOD? Phil Shafer: RPC input? Martin Bjorklund: Andy Bierman pointed out that it only matters at the "content" layer, not the "operation" layer. David Partain: consensus. do not enforce order (10 for, 0 against) -------------------------------------------------------------- Float vs. decimal A number of problems with the floating point datatypes have been identified on the mailing list. Specifically, how are they handled by XPath, and the canonical type. Proposal: Replace the float types with a (fixed point) decimal type. Examples/alternatives shown on slide David Partain: Should we have floats or this other alternative (or both)? Wes Hardaker: If not needed now, why define it now? Integer operations are always faster. Jeff Case liked doing things this way. But datatypes are cheap, so adding it now may be cheap. But if there are no use cases, we could delay it. Andy Bierman: supports having integer type only, did not see a need for floating point. David Partain: question: omit float for now? David Reid: Drop both? 1 for, 8 against. David Partain: consensus. Use decimal64 (10 to 0) Martin Bjorklund - what should canonical form be? David Harrington: is the proposed canonical form standard Xpath? David Partain: vote : consensus (9 to 0): must be one digit on both sides of the decimal point. David Harrington: Is the 3.0 standard XSD/XPath Martin Bjorklund: 3.0 is standard -------------------------------------------------------------- Other open issues? Andy Bierman: canonical version XML applies to Xpath (comment on Xpath discussion). David Reid: list with "foo", augmented with "foo" is clearly illegal. But if augmented with something from another module, this is in a separate module, and so is OK. Martin Bjorklund proposed a rule which is fine. Andy Bierman: My code up to date with draft 04. Ladislav Lhotka: reserve "augment" to augmenting other modules Martin Bjorklund: discussion with use cases. Submodules can augment submodules. Useful for distributed software development. Balazs Lengyel: We have use cases for submodules augmenting other submodules. We need the modularity without the namespaces. Ladislav Lhotka: another comment about augmenting David Reid: why wouldn't you want to augment something in the same module? Ladislav Lhotka: there are simpler ways, can't imagine a use case; becomes unreadable. Martin Bjorklund: submodules are to allow distributed authorship. Ladislav Lhotka: limit augments to something from another module. Balazs Lengyel: we put parts into different submodules and use augment to connect them. Andy Bierman: I sympathize with Ladislav, on the complexity side, but limiting augment didn't change the complexity. David Partain: vote: rough consensus: keep as is +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ IETF 74, NETMOD WG Wednesday, March 25, 2009, 0900 - 1130 Agenda Reviewed ------------------------------------------------------------------ YANG Types (revisited) Juergen Schoenwaelder suggestion: Remove IEEE types from the documents, doesn't make sense to standardize a small set of types. Dan Romascanu: agrees with Juergen Balazs Lengyel: The MAC address is needed immediately Dan Romascanu: move mac address to another document? Consensus: (unanimous) move mac address to different document and stop working on ieee-types.yang for now. ------------------------------------------------------------------ Mapping YANG to DSDL: Ladislav Lhotka Notes on recent publications 00 in Feb, 01 on mar 8, many changes David Partain: How many people have read the draft? note taker missed the count; David Partain: 5-6 Presentation on the draft (see slides) Open Issues: 1) if-feature Martin Bjorklund: Question: couldn't the features be supplied as arguments as an alternative way of doing this? Ladislav Lhotka: put as annocation to the conceptual tree schema. Martin Bjorklund: I thought that would be simplier, it wouldn't generate nodes for features not available. Ladislav Lhotka: it could be done also. Martin Bjorklund: In the first step you specify modules a device implements and you know which features a device implements. David Partain: are you trying to create something that is useful across multiple systems? Ladislav Lhotka: Features will be fixed; same set of input modules that are transformed via the schema. David Partain: input is at second stage rather than the first. 2) deviations Martin Bjorklund: I agree with Ladislav. David Partain: anyone else have opinions? (no response) David Partain: consensus is then called as being what Martin Bjorklund and Ladislav want. Andy Bierman: has questions about naming, but will send mail. 3) instance-identifier type Ladislav Lhotka: options: EXSLT or XPATH 2.0, proposes EXSLT Martin Bjorklund: in xpath you can define your own functions, can you do that in EXSLT? Ladislav Lhotka: yes you can, but it only makes sense if the validator supports the functions. I have to check the EXSLT specification but it is also supported by the libxml tools. 4) Other targets for validation Ladislav Lhotka: certain document types can be validated; are there other types to be validated for the DSDL schemas? Martin Bjorklund: I think edit-config is a missing one in the list and possibly copy-config; copy config is difficult because there is no standard way of what the copy-config would be so unless we define one. It will be hard to define a schema for it. Ladislav Lhotka: discusses biggest thing to validate is output from get-reply. Phil Shafer: when you say data store I think configuration data. Ladislav Lhotka: get-config means config data, get means all. David Partain: anyone else want something other than edit-config/copy-config? (silence) Ladislav Lhotka: change in order of elements in data from Monday's meeting needs to be added to draft. Next version of draft will be complete and resolved all open issues. Martin Bjorklund: require-instance and instance identifier missing. David Partain: you're writing and implementing at the same time; excellent! Your plan is getting a new rev during April? Ladislav Lhotka: yes David Partain: plenty of time for people to read by Stockholm. Perhaps we can even do a last-call about then. Andy Bierman: how are you doing naming? you're putting module name as a type name or element name. Is that really needed? Ladislav Lhotka: yes. multiple reasons talked about (including "you can have clashes between different modules") Andy Bierman: is that why there is a top container and a container for notifications? Why all the extra containers? do you just like that better? Ladislav Lhotka: It's just easy to translate between schemas and is easier to implement in the tool. Andy Bierman: what about local typedefs embedded inside lists, etc. Ladislav Lhotka: these types defs have both the module name and the name of the container nodes. Andy Bierman: keep registry of names used and then add a new one (like a .1) to deal with conflicts Ladislav Lhotka: that could be used too. ------------------------------------------------------------------ netmod-usage-guidelines: Andy Bierman Documents guidelines for writing YANG modules intended for IETF usage. Proposing writing a YANG usage guidelines to improve quality of YANG documents, and result in quicker passage of YANG modules. To avoid issues at "Last Call". David Partain: How many have read it? 7-8 Minor issues: the language is not constrained in places it may be helpful for tool support (e.g., identifier length). Andy Bierman: Options: 1) do nothing 2) published as a BCP Dan Romascanu: what "Last Call" issues are you thinking about when dealing with issues raised? Andy Bierman: there are lots of things (stated examples) Dan Romascanu: I'm very much in favor of this document. Suggest start by doing as Informational. Come back after 1-2 years of operational experience and revise it as a BCP. Andy Bierman: my approach was to include guidelines that had strong consensus. Dan Romascanu: we may get to the point to revise them because we may learn things down the road, certainly. Andy Bierman: we have experience to draw on from SMIv2 that will make some of these back by experience now. Phil Shafer: is the 63 chars really an issue? Should that be solved in YANG, or is it ietf specific? Andy Bierman: you run the risk that the YANG module won't be accepted by the tools. YANG says that 63 must be accepted, which means more can be dropped. Phil Shafer: but what about vendor module. Let's fix in the YANG module. Andy Bierman: I want a fixed length identifier. Phil Shafer: I'd rather fix it in YANG. Andy Bierman: my fix is that it must be 63 chars or less. Martin Bjorklund: is your proposal to add to the main doc? Andy Bierman: I don't have a problem with YANG docs; I want this to deal with interop with the IETF documents not globally. Phil Shafer: does there need to be a bound? Andy Bierman: yes, so tools can be written that will work. Phil Shafer: what's the issue? Andy Bierman: buffering and memory. Wes Hardaker: tries to clarify discussion and agrees with Andy. Language should not be constrained, but should IETF have more tight restrictions within IETF for all tool writers. Phil Shafer: would this be something willing to do in an extension (eg: strict: true). Andy Bierman: I would rather not; I'd rather have a set that defines what the lower bound is. Phil Shafer: What about adding a YANG extension to add restrictions? David Partain: first step is to decide if we're going to have the rules, standardize the rules. Sharon Chisholm: (on jabber) I'm voting not to bake into YANG a length restriction and I don't like Phil's suggestion. Whether we do an IETF-module practice of shorter length that we can change in 5 years is different. I don't mind that. The extension just seemed to complicated than we needed. Andy Bierman: to my knowledge the 63 char limit is SMIv2 isn't a problem. David Partain: how many think we should work on this document? *count:* many hands for yes, none for no. David Partain: How do we do this? recharter? Andy Bierman: what is the IESG going to do with a 50 page YANG document? Skip it? Create a yang-doctors group? Dan Romascanu: probably create a experts group Dan Romascanu: To issue of recharter: I'm not sure you need to recharter, especially if you go for Informational. David Partain: should this be a WG document straight away: *count:* many hands for yes, none for no We'll talk to Dan Romascanu about how to do it (informational vs ...) Andy will continue editing; anyone else can offer to help. Martin Bjorklund: There is a section called YANG registry section, do you want to keep that? Andy Bierman: no, I'm going to drop it. The top level module needs a RFC number for each revision. Martin Bjorklund: does the top need to be published in an RFC or can it be IANA contained? Andy Bierman: no, conformance is tied to an RFC number not to a dynamic IANA registry. ------------------------------------------------------------------ netconf-module-00 (Editor's note: This discussion was started in a previous NETCONF WG meeting, but was continued with the consent of both NETCONF WG chairs.) David Partain: Do we want to consider talking about YANG NETCONF module? Andy ran out of time yesterday, can we consider discussing it now? NETCONF Chairs: Yes, that's fine. David Partain: last slide of NETCONF agenda. (http://www.ietf.org/proceedings/09mar/slides/netconf-6.pdf) Andy Bierman: surprised to see consensus for normative YANG going forward. Phil Shafer: I was suggesting adding an extension that says "this element supports these two attributes" and that's the meaning of this extension statement. YANG:this-container-supports-these-two-attributes:true Andy Bierman: I only want to support it for RPC elements and not in the data at all. So that would be acceptable to me. David Partain: 3 options: use XSD, use YANG with attributes (change YANG to support XML attributes), use YANG with an extension for 2 specific attributes. Bert Wijnen: would there be a 4th option to remove it from the base spec? Andy Bierman: you're the code chair, it might open the box of other non-compatible changes. I've got a ton of them. Bert Wijnen: how seriously would it get existing implementations in trouble? Martin Bjorklund: I'd rather not change it because it would affect existing implementations. Balazs Lengyel: we have a statement that any other elements can be added to an attribute. Andy Bierman: the proposal is this would only be used for Balazs Lengyel: But we keep the XSD for the RPC layer? Andy Bierman: that needs to be looked at, what happens to the XSD? Mehmet Ersue: I think we need to keep the attributes in NETCONF and we can not skip them. David Partain: what are the options we're taking to the mailing list? Ladislav Lhotka: I think the schema can't be used by any tools. It will claim a number of things are valid that aren't (gives examples). Some of the problems can't be solved in XSD. (RelaxNG is better) Martin Bjorklund: if we do YANG, we have a standard mapping to DSDL so we get DSDL as well. Ladislav Lhotka: yes of course. Long explanation followed by I don't think it's appropriate to use YANG for David Partain: unless we have an extension for the relevant attributes. Martin Bjorklund: it is appropriate to use for operations layer. Ladislav Lhotka: I see it as a natural way of using NETCONF modeling language for definition for NETCONF base module. that's better than introducing a third modeling language. Andy Bierman: if we don't have a YANG module, we can't augment it with YANG. [stuff missed] David Partain: someone needs to write down what the options are and send to list. Bert Wijnen: Yes that's what we want; Andy will do it. If we want to use it for RPC layer and not operations layer then make that clear. Make clear that we will not do YANG for RPC layer. Andy Bierman summary: if RPC element is in YANG module then all elements are mirrored back. For the agent it's not used at all. Having a particular attribute called msgid in the PDU is a CLR. Martin Bjorklund: I really think we should not do the RPC layer in the YANG module. Andy Bierman: You're right. I do that with an extension. it'll be removed in the next version and add an extension for the filter-element-thing. Phil Shafer: what's left in the XSD? barely anything? (yep) David Partain: do we want to do choices now? Phil Shafer: YANG will have all the guts. XSD or RelaxNG will just have an element that will contain everything. can we just write it as text? The XSD is so small and has no value. Martin Bjorklund: it's easy to write and has a small value, so do it. Ladislav Lhotka: XSD is generic but RelaxNG can be much more helpful. Sharon Chisholm (jabber): considering this is a normative update, then keeping this as an XSD will help us determine what has changed. Phil Shafer: one of the things that has changed has is that we have YANG. Martin Bjorklund: we're not doing it for the fun of it, we're doing it because the original XSD has problems. Phil Shafer: one of the problems with XSD is that we didn't know what it did. I have an issue with RelaxNG as well, I couldn't tell if it was right or not? Bert Wijnen: should we consider RelaxNG as a 4th or 5th option? Only two hands. Mehmet Ersue: we should think of future NETCONF modules that are trying to augment. Phil Shafer: which means that YANG has to own it. David Partain: how many think YANG has to be normative, or how many thing XSD has to be normative: YANG: 10 XSD: 1 Andy Bierman: we need to think in a new way. We need to understand that people pull these documents out of documents and use them in applications in new ways. Phil Shafer: will the YANG module be part of 4741bis? Andy Bierman and Martin Bjorklund: yes ------------------------------------------------------------------ Plans after this IETF? David Partain: Are we ready for WG last call on YANG/YANG data types? Seems things are stable and believe we'll do a WG last call. Martin Bjorklund will publish a -05 in the next few weeks. Juergen Schoenwaelder will publish types documents as well. Usage guidelines will be added as a WG document. David Partain: do people use XSD produced from YANG? Two tools do that, should we have a document that defines that? Andy Bierman: Martin Bjorklund and I have been converging on a similar solution. David Partain: is there a chance of people actually writing that down? Andy Bierman: if we have enough people to work on it, it would be valuable. I can't do it myself (there is a lot to write down). Ladislav Lhotka: also option of using auto-translation of RelaxNG to XSD, which would save cycles for this work. It would be valuable for customers that want to do validation. David Partain: the mapping isn't standardized but there are tools that are industry standardized. Ladislav Lhotka: there are WWW tools that use RelaxNG Martin Bjorklund: I'd prefer that as well. Andy Bierman: the use case would be xmlspy that would construct the PDU contents based on the schema? but xmlspy already uses RelaxNG, so... Martin Bjorklund: most people that want to do validation don't care which they have. The DSDL schema is much more precise than the XSD. David Partain: so we don't need to do this (audience fails to say otherwise). ------------------------------------------------------------------ Open Microphone: SMIv2 to YANG David Reid: previous agenda had it on it. can we talk about it? David Partain: yes, but Juergen Schoenwaelder isn't here. Andy Bierman: I read the draft and really support it as at least an informational RFC. David Partain: how many have read it? *Count: 8-people* David Partain: how many think we should consider publishing it and work on it *Count: 10-people yes, 0-no* David Partain: anything for today? David Reid: there are a number of issues, maybe the mailing list would be better? David Reid: one particular topic of interest: In mapping a MIB table, he translates the entry to a list and drops the table (the "extra" container). What I do is translate the list and put the list in a container. Andy Bierman: we should keep the "extra" container due to least astonishment. David Reid: I don't know of reasons beyond that, but there could be more. Ladislav Lhotka: I think list items should always be in a container and not loose. David Partain: David Reid, please send comments to the list. David Reid: what I do is similar so there aren't huge issues. Floats revisited David Perkins: wants floats discussed Wes Hardaker: tries to summarize why David Perkins wants floats (+/- inf and NaN). Andy Bierman: doesn't like +/- inf and would rather return an error anyway. David Partain: bring it up on the list at this point after the minutes are posted. Meeting concluded ------------------------------------------------------