Last Modified: 2004-09-07
| RFC | Status | Title |
|---|---|---|
| RFC3291 | PS | Textual Conventions for Internet Network Addresses |
| RFC3419 | PS | Textual Conventions for Transport Addresses |
| RFC3595 | PS | Textual Conventions for IPv6 Flow Label |
|
OPS Area Meeting at IETF 61: Nov. 10, 2004
Thanks to Andy Bierman for taking notes on which these minutes are based. - agenda: see OpsAreaAgenda61.ppt - no changes to agenda - added Management Considerations to agenda - OPSEC BOF: WG has been formed; will work on operational requirements to run a secure network - AAA WG not meeting at this IETF because they are almost done - aaa-eap on IESG plate - aaa-sip-application and aaa-uri drafts are not done - Possibly form a new Diameter Maintenance WG - focus on maintenance - possibly advance Diameter to DS - should this WG be formed? - no questions or comments, probably because the people in the room are not familiar enough with the details - comment on what maintenance scope really means - could it mean adding features left out of last update? - see details in: OpsAreaAgenda61.ppt - CAPWAP - initial work completed - CAP == Control and Provisioning - scope does not include other non-mgmt WAP issues - aggressive deadline for objectives document - this work will be done in coordination with IEEE 802.11 - Bridge - WG will close down and transfer work to the IEEE 802.1 WG - Improve timeliness of MIB modules by reducing delay between protocol and MIB definition - Distribute the work load - Work will be done by the technology experts - Cross SDO coordination is improving - default liasons identified - cross-org review of new work - IETF MIB Doctors will review IEEE MIB modules, at least initially - MIB modules will be available in ASCII, not just PDF - no questions or comments from room - Bert: could be MIB Doctor resource issue; may need to prioritize IETF MIBs over IEEE MIBs - Dave Harrington: IEEE may assign a MIB coordinator to oversee progress and quality - Request to read and comment on I-D: draft-klessin-ip-service-terms-04.txt This is an Interesting document that IESG approved recently You might want to take a look. It defines standard terminolgy for different kind of Internet services. - NGN Network Management - ITU-T focus group consists of 7 or 8 WGs - do not have a NM WG in this focus group - ITU-SG4 has accepted new work for a NM focus group - informal conf. call was held 11/1 between ITU, ETSI, TMF, and IETF people on the possiblity of working together - mailing list and FTP site will be created - participation will be on an individual basis - want people familiar with IETF NM work to participate OPS Area mailing list archive: http://ops.ietf.org/lists/ops-nm/ops-nm.2004 - Sharon Chisholm: goals are to reduce operational costs for networks and reduce the duplication of effort across SDOs - Bert: they are starting out on terminology; they are top-down; we are bottom-up, so may not get to protocol detail right away - National Light Rail is another group that could be involved - Brain Carpenter: need a roadmap for better coordination so SDOs can plan their own work better and not duplicate efforts - Collaboration for Data Modeling - WEB Services Based NM (GGF, DMTF, OASIS, W3C, IETF) - had informal meeting between leadership of different SDOs - want to avoid duplicate work - MoU (Memorandum of Understanding) being worked out - goal is coordination and encourage information sharing - they want pre-planned conf calls and f2f meetings - possible issue wrt/ impact on NETCONF data modeling - initial work: - landscape doc - definitions and taxonomy - white paper, FAQ - they want a governance panel executive, technical, and liason - Sharon: this is the right group of people; could be the same type of effort as NGN; this could be a good thing - Eugene G:concerns about slowing down our work if we get really involved with industry consortiums and other SDOs - Brian C:value in knowing what else is going on but we don't want to be too dependent on schedules of other SDOs - Management Considerations section: - draft-farrel-rtg-manageability-requirements-00.txt - Better to consider NM early; can discover problems with the protocol early if this done - Dave Meyer: this section is not authoritative; this should not be a replacement for detailed documents - Avri (co-author): need some input to finish the details in the draft - David Perkins:this is a good idea; may not know what needs to be managed at first; may need operational experience to finalize these requirements - Andy B: this helps a lot to consider NM at the start; doesn't get cheaper over time; should identify what is manageable, but don't need details at this phase - NETCONF status update - WG charter covers just the protocol - use XML - network-wide protocol - extensible enough so vendors can provode access to all configuration data on the device - need PI, not screen-scraping interface - data model support in charter - need to identify principals (e.g., user names) - mechanism needed to distinguish config from other data - (missed last 2 points) - all NETCONF drafts in WG Last Call - comment: Is there an issue tracker that identifies that an operator made a suggestion that was rejected? No. - Is the WG done? - possible next steps: - NETCONF WG charter extended - close NETCONF and start new WG (i.e., NETMOD) - big issue is the scope of the work - stop netmod work and let vendors or other SDOs continue this work - low hanging fruit - USe XSD, but not universal agreement on using XSD - standard data types (like InetAddress) - leverage existing frameworks like SMIv2 - request to read RFC 3535 (justification to do NETCONF) - not a big issue if there is no SMI or framework - Andy B: need an SMI and data types right away to have consistency - Dave H: Problem is the vendors not implementing enough MIBs. Why are MIBs too difficult; need building blocks to create an API that allows better alignment with CLI; need a standard CLI; - Juergen: look at Relax NG instead of XSD because it is more readable; no compliance; no info-modeling - set of guidelines on using Relax NG - set of data types - interworking with SMI - Steve W: this is first step; agreed at start that this work is needed but it was deferred to make progress in steps. need to continue work so we get interoperability - Bert: post to netmod mailing list on this topic, not ops or netconf WGs - MULTI6 WG status - most items are almost finished (in WGLC) - design team formed in San Diego IETF - approach is an "L3 shim" - below fragmentation, IPSEC - this shim is needed to provide connection survivability for multi-homing independent of the transport protocol. - no new DNS namespace - AAAA records contain same thing as today - applications use upper-layer ID - hash based address scheme to prevent redirection attacks when host has a fixed set of addresses, then hash (e.g., SHA-1) can be used for verification - Issues from the design team - handle ingress filtering - DT did not specify packet formats - David K: WG agreed to consider new work when documents are near completion (which it is now) - IPv6 OPS - slimmed down charter will be defined - new WG in Internet area for tunnel protocol work - no comments (MBONED chair) - Dave Meyer: cross area coordination between PIM, IPv6 who owns P2P LSP problem? - general issue: how to do these cross-area coordination efforts - protocol work in OPS area? - should protocol work be moved in general to other areas? - Dave M: operation needs, but can't find a home in a protocol WG so don't have a very strict rule about this - Bert: NM and OPS merged together; NM has always done protocol work in NM (SNMPv3, NETCONF); This will continue; Need to be aware of other work going on and not duplicate. - ???: OPS WGs should not be competing with a protocol WG if such a WG exists; minor work okay in OPS if no protocol WG exists - Curtis: not worried about OPS area doing protocol work worried about all the other documents being produced. - ???: Not clear what is "Operations" work - Dave M: if protocol WG exists but doesn't want some new work then this should be considered carefully - ???: transition work falls between the gaps; - ???: missed some comments on details for protocol work that was done in OPS; transition evaluation, etc. - David K: If it makes sense, or there is a strong need it will be chartered in OPS area - Bert: need to consider how much agreement there is on solution approaches; little or no agreement means little chance of success - Curtis: missed most comments; bar is not high enough for non-protocol work in the OPS area - Dave M: criteria for Informational documents not clear; not that the bar is too low but there is too much variance - Do people share this opinion (no response) - Randy P: which statement are you asking about? Variance in quality is across IETF, not just OPS - ???: Informational documents do not get as much review comments as STD track documents - ???: not so clear that this variance is a big problem; maybe an IETF-wide document is needed - Randy P: Maybe have an "Operations Considerations" section. Maybe OPS has all this work to do because protocol WGs are not considering OPS well enough in their work - open mike: no comments |