Original agenda:Ê - Architecture workshop - Interop openings - BCP56 revision - File metadata formatÊ - XML Schemas and modeling, YANG and NETCONF Agenda bash added: Ê -Ê IBE and email architectureÊ - NFSv4 and UTF8 issues - IESG Note takers Ê - Bar Bof announcements 1.Ê Lisa announced an Apps area Architecture workshop February 11 and 12. Participation is open to those posting position papers by Dec 14.ÊÊ 2.Ê As an experiment, we can allocate up to a full day for interoperability testing at the next IETF -- perhaps even replacing a regular day of meetings.Ê WGs or implementors need to propose subjects and call for participation in time for agenda planning for next IETF. 3.Ê NFSv4 protocol has some issues dealing with UTF-8 vs the POSIX/SUS format.Ê This might affect the file URL scheme. Patrik FŠltstrom volunteered to advise them. 4. Call for IESG meeting note taker volunteers (for the narrative minutes): no response 5.Ê IBE Auth: email architecture issues came up during IESG review of the IBE crypto stuff.Ê Email experts are asked to peek atÊdraft-ietf-smime-ibearch-06.txt.Ê Email/directory protocols already support SASL, so adding this would be easy for them.Ê Security protocols for certs however, are based on HTTP, which doesn't have SASL... 6.Ê Bar BoF announcements.Ê Is itÊtime for webauth WG? there will be bar BOF tomorrow; meet at 6pm at message board.ÊÊV-card dinner tomorrow, 8pmish @message board.ÊÊ 7.Ê BCP 56 (Mark Nottingham).Ê Is this still descriptive of our "Best Common Practices"?Ê It advises that "Substantially new services" should not reuse existing ports. and thatÊnew protocols or services should not reuse http: or other URL schemes.Ê However, many sites and systems use HTTP forÊmachine-readable data not intended for browsers.Ê Most of theseÊstill see use of http/port 80 because that goes through firewalls.Ê The document still does give useful things to think about before making choices.ÊÊ Another problem is that most applications over HTTP ignore required features like conditional gets -- interoperability and extensibility can suffer. Perhaps we should have a profile of http, or list of http features that each service should consider.Ê AlternativelyÊa survey doc may be a good thing.Ê Some discussion ensued of when HTTP fails gracefully when a feature is not supported, and when it does not. Barry Leiba, Randy, Mark and Lisa agreed to work on this.Ê 8.ÊFile metadata, Miguel Garcia: See draft-garcia-sipping-* for background, why SIP has use cases for this.Ê An XML format for not only describing a single file, but also directory relationships.Ê ÊFile properties include size, URN, MIME Type, modification date, read date etc.Ê Does the IETF need a general format like this?Ê Does it overlap with similarly purposed formats (WebDAV properties, METS, MIME, etc)? Some discussion about balancing simplicity with expressiveness, but ultimately nobody volunteered to contribute to this work to expand its scope beyond SIP use cases.Ê 9.Ê XML modelling languages, specifically YANG and Netconf use cases.ÊÊ Sharon Chisholm presentedÊdraft-chisholm-netconf-* principles: a similar approach to how MIBs are defined, using XML schema plus appinfo tags to fill in functional gaps.Ê Off-the shelf XML tools can be used. YANG proposal, Phil Schaffer: Since several implementors already wrote their own modeling languages, we got them together to do it interoperably, and YANG is the output. It uses XPATH for naming and has similar addition features to SNMP.Ê Simple XML validation is not sufficient: 5 scenarios where that isn't true. e.g., mandatory fields not present in deletes.ÊÊYANG aimed to meet the exact requirements. There is running code and the language is usable in its current form.ÊÊ Discussion covered: comparison toÊOWL; whether the use of schema languages was dismissed too easily; versioning and "getting it right the first time" is very hard in designs like this.Ê A bunch of discussion covered RelaxNG in particular, and whether it had really hit some sweet spot in schema language, or was just yet another option that didn't work for NetConf.Ê IRIS switched to RelaxNG and so have some RAI users. Beyond NetConf's needs and preferences, what is the broader IETF implication here?Ê It's no surprise that many XSD experts were not found in the netconf WG -- the apps area is where this expertise is ( e.g., crisp WG and IRIS). Ê Should the XML BCP be updated?ÊÊ Another IETF-wide issue is that many applications outside the Ops area may wish to use NetConf particularly if it's made easy, extensible and general.Ê E.g. SIP device configuration using the SIP UA Profile framework: draft-ietf-sipping-config-framework-14; configuring various Apps servers.Ê