IESG Narrative Minutes

Narrative Minutes of the IESG Teleconference on 2008-04-24.

Narrative scribe: John Leslie

Corrections from Russ, Tim


1133 EDT telechat started
Amy: with Cindy Morgan, who will moderate today

1 Administrivia

  1. Roll Call
  2. Bash the Agenda

    Cindy: Add?

  3. Approval of the Minutes of the past telechat

    Apr 10 approved, will post
    Narrative. will post

  4. Review of Action Items from last Telechat

    Cindy: 3 for Cullen
    Cullen: 3rd in progress
    Cindy: Chris, TMDA
    Chris: finished as of last telechat (minutes OK)

2 Protocol Actions

2.1 WG submission

2.1.1 - New Items

  1. OSPF Multi-Area Adjacency (Proposed Standard)
    draft-ietf-ospf-multi-area-adj-08.txt
    Token: David Ward
    Discuss:

    Telechat:
    Cindy: no discusses, approved

  2. OSPFv3 Graceful Restart (Proposed Standard)
    draft-ietf-ospf-ospfv3-graceful-restart-07.txt
    Token: David Ward
    Discuss:
    1. Russ Housley: In her SecDir Review, Hilarie Orman pointed out that the message described in this document seems to give attackers a new method obscuring network configuration changes. If it is possible to send bogus messages, the adjacency of a dead router could be preserved indefinitely.
      In response, Acee Lindem indicated that this attack is much more difficult than the obvious replay of a normal OSPFv3 hello packets to keep the adjacency up. Since hello packets are sent more predictably and knowledge of the key is not required, the risk added by OSPFv3 graceful restart is insignificant.
      I would like to see this information added to the Security Considerations.
    2. Chris Newman: The IANA considerations section does not properly name the registry that is used by this document. While it appears IANA was able to discern the correct registry as the "OSPFv3 LSA Function Codes" sub-registry of the "Open Shortest Path First v3 (OSPFv3) Parameters" registry, the document should actually include the precise names so readers of the document without in-depth knowledge of IANA can find the registry.

    Telechat:
    Dave: ask Russ
    Russ: add a sentence or two, then fine
    Cindy: AD followup

  3. NFS Direct Data Placement (Proposed Standard)
    draft-ietf-nfsv4-nfsdirect-08.txt
    Note: Document Shepherd: Spencer Shepler (spencer.shepler@sun.com)
    Token: Lars Eggert
    Discuss:

    Telechat:
    Cindy positions pending from folks on telechat
    Lisa: no position
    Pasi: no position
    Cullen: no position
    Cindy: any objections, approved

  4. Remote Direct Memory Access Transport for Remote Procedure Call (Proposed Standard)
    draft-ietf-nfsv4-rpcrdma-08.txt
    Note: Document Shepherd: Spencer Shepler (spencer.shepler@sun.com)
    Token: Lars Eggert
    Discuss:
    1. Lisa Dusseault:
      I am getting an early DISCUSS in to see if some answers can clear this up quickly. I hope to revise this DISCUSS even before the call as I understand it better.
      Is the applicability of RDMA, RPC and NFS as described in this document limited to trusted situations where an administrator explicitly sets up a data transfer or a synchronization relationship between two servers?
      I can see this being useful in contexts where you basically want superuser access to a file system.
      If the applicability is not limited, how is this appropriate for Internet or end-user usage, especially considering the limited authentication mechanisms and lack of information on mapping to NFS ACEs?

    Telechat:
    Cindy: positions pending from folks on telechat
    Pasi: no position
    Cullen: no position
    Chris: not at this time
    Lisa: expect to require revised ID

  5. Hierarchical Mobile IPv6 Mobility Management (HMIPv6) (Proposed Standard)
    draft-ietf-mipshop-4140bis-02.txt
    Note: Document shepherd is Vijay Devarapalli
    Token: Jari Arkko
    Discuss:
    1. Lars Eggert: Appendix A. Appendix A - Fast Mobile IPv6 Handoers and HMIPv6
      DISCUSS: Has the experiment with RFC4140 covered Fast Hierarchical MIPv6 at all? There are zero technical changes between this appendix in RFC4140 and this document, and with the text below referring to SEAMOBY as if it was still around, I wonder if this appendix isn't outdated and should simply be removed for PS.
      Appendix B., paragraph 5:
      RFC 4140 was implemented and interop tested by at least two different organisations. A test suite including test cases for RFC 4140 was also developed by Ericsson and run against both implementations. No major issues were found. The scalability of Dynamic MAP discovery defined in RFC 4140 was seen as inappripriate for large scale deployments and prone to loops. It was removed from this specification.
      DISCUSS-DISCUSS: This rationale for going from Experimental to PS is weak. OK, so two implementations interoperated, some minor things were removed, but the open question is whether the protocol actually works as advertised and is useful?Comment [2008-04-19]:
      Section 14., paragraph 0:
      14. References
      Document contains a six or so unused references, suggest to remove them.
      Section 14.2., paragraph 3:
      [RFC4068] Koodli, R., "Fast Handovers for Mobile IPv6", RFC 4068, July 2005.
      I think this should cite draft-ietf-mipshop-fmipv6-rfc4068bis.
    2. David Ward:
      In section 7.1 there is a mention of options (e.g. preference) that are associated with MAP IP addrs but, there is a very limited encoding (e.g. no flags, or other attributes) in the MAP option. In addition, the definition of a Dist is limited to 4 bits. Is that enough? Is it reasonable to assume that no semantics are to be associated with distance?
      Later, in the selection algorithm for distributed MAPs (9.1) it appears that DIST and PREF are directly comparable. Although DIST is used as a sorting (akin to hop count although earlier not required), the pref is then used to bias selection. The problem with no strict semantics for DIST to be hop count (e.g. it could be used as inverse hop count) then you'd get a non-optimal selection algorithm. In addition, the PREF variable alone only allows for a very weak application of operational policy (since all this has to be hand configured - no dynamic specified). Given what we know about policy selection requirements from other protocols, something should be mentioned what the RESV space is for or allow at this time greater operational options (via more attrs, flags, etc).
      Bottomline, the definition of the options (DIST, PREF) appear to not have strict enough semantics to meet the requirements of the default selection algorithm.
      Next, the section on failure detection and recovery from MAP failures is unfortunately not useful because it describes possible failure detection methods but, nothing to be standardized. Either something has to be specified, referenced or the section has to be removed as an implementor has nothing to specified to detect failures.
    3. Russ Housley: Section 11 says: Confidentiality may be needed for payload traffic, but is not required for binding updates to the MAP.
      Under what circumstances is confidentiality desired? When it is desired, is ESP used to provide it?
      Comment [2008-04-24]: s/Figure 1: Figure 1:/Figure 1:/
    4. Tim Polk: In general, I thought this was a good document. However, there are some problems that need to be remedied before publication. Most of the issues involve the Security Considerations section, but some changes to the body might also be helfpul. (This is in part a follow-on to Lakshminath Dondeti's secdir review and highlights the issues I consider blocking.)
      (1) The document introduces the Mobility Anchor Point (MAP) into the mobile IPv6 architecture, but the requirements/assumptions regarding the relationship between the mobile node and the MAP are not clear enough. These assumptions/requirements have a number of implications for the protocols that should be stated. In particular, there is an implication that the trust relationship is so limited that authentication as a group member is generally sufficient. For example, a MAP may authenticate a mobile node based on a certificate issued by a known CA, rather than the specific identity in the certificate. Similarly, the mobile node may authenticate the MAP based on a cert from a known CA, even though the specific MAP was previously unknown. (Examples from 11.1) I believe this is okay, based on my understanding of the requirements, but I would feel more confident if the trust relationship was fleshed somewhere.
      Note that this is confused somewhat by the discussion of "security relationship" between the mobile node and the MAP in section 11. "mutual authentication, integrity protection and protection against replay attack" are necessary features, not a relationship.
      (2) Authentication and authorization are conceptually related but they are different. Authentication is generally the precursor, where we determine another party's identity, and authorization follows based on that identitty. Just because a party's identity has been authenticated does not mean they are authorized to access anything. The examples cited above blur the lines between these steps. Hopefully, this will be addressed as a side effect of addressing (1), but please revise with an eye towards clarity on authentication vs. authorization.
      (3) The security considerations section focuses on the expected deployment architecture, but several alternatives are specified in the document. Tehse should be addressed in teh security considerations as well - either to describe differences in teh security considerations or to state that they are unchanged.
      For example, It is noted in the introduction that the mobile node can operate in a nomadic manner (no permanent home address). Section 6.5 notes that the RCoA address can be used as the source address without a Home Address option. In these kinds of cases, are there additional constraints or limitations imposed on the trust relationship between the MAP and the mobile node?
    5. Mark Townsley: The introduction describes that without the mipshop optimization, MNs have on average 1.5 signaling round-trips when the node moves... Then makes a fairly wild leap of conclusion that:
      These round trip delays will disrupt active connections every time a handoff to a new AR is performed. Eliminating this additional delay element from the time-critical handover period will significantly improve the performance of Mobile IPv6.
      What connections are being disrupted for each and every AR? Also, I see no analysis here that shows that there will be a significant performance improvement to the Mobile IPv6 user.
      There is language in this document stating the optional nature of this feature, but if the above claims are true then I cannot see how this could be optional. So, the document is rather inconsistent here.
      I think that probably the right thing to do is to tone down some of the claims of what this optimization does and does not do.
    6. Magnus Westerlund: The tunneling between the MAP and the mobile node introduces an extra layer of tunneling that may effect (will unless the path between the MN and the MAP has a MTU that is at least tunnel overhead larger than the real MTU bottelnek) the path MTU between the CN and the MN. There needs to be some discussion of this impact on the traffic between the CN and the MN. Especially as this is dynamic and can change due to the choices of the MN or changing the used MAP.
      Comment [2008-04-24]: I found one acronym in Section 6.1 that isn't explained nor used again: DAD

    Telechat:

  6. Datagram Transport Layer Security (DTLS) over the Datagram Congestion Control Protocol (DCCP) (Proposed Standard)
    draft-ietf-dccp-dtls-06.txt
    Note: Document Shepherd: Gorry Fairhurst (gorry@erg.abdn.ac.uk) - DCCP WG Chair
    Token: Lars Eggert
    Discuss:

    Telechat:
    Cindy: no positions pending (among callers)
    Russ: approve pending Lars review of comments

  7. The OSPF Opaque LSA Option (Proposed Standard)
    draft-ietf-ospf-rfc2370bis-02.txt
    Token: David Ward
    Discuss:
    1. Pasi Eronen: RFC 2370 said "the O-bit is not set in packets other than Database Description packets"; this sentence has been changed to "the O-bit SHOULD NOT be set and SHOULD be ignored when received in packets other than Database Description packets." SHOULD implies that there may exist "valid reasons in particular circumstances" to ignore this; the document should briefly explain what that reason could be, if the situation has indeed changed from RFC 2370 times.
    2. Chris Newman: The IANA considerations section requires review of standards track OSPF extensions by a designated expert once the OSPF WG has disbanded. I would like to understand how this procedure will work and how we can be sure the requirement is not lost between now and when the OSPF WG is disbanded.
      In addition, the IANA considerations section refers to IANA registries without giving the precise name of the registry. Please fix that.

    Telechat:

2.1.2 Returning Items

2.2 Individual Submissions

2.2.1 New Items

  1. A Registry for SMTP Enhanced Mail System Status Codes (BCP)
    draft-hansen-4468upd-mailesc-registry-04.txt
    Note: Harald Alvestrand is document shepherd
    Token: Chris Newman
    Discuss:
    1. Cullen Jennings:
      The early registration procedures don't work for a document that is not a WG document. I think the easiest way to fix this would be just to use AD Approval for these.
    2. Russ Housley:IANA has questions:
      Extended code X.7.8 is defined in both RFC4468 and RFC4954. Which one should go into the registry? It APPEARS you want the RFC4954 version and NOT the RFC4468 version?
      Also, IANA usually calls it a "Reference", not "Defined". The registry entries have been updated appropriately but the document should get updated to match.
      Who will fill in the "not given" information?
    3. Magnus Westerlund: Section 2.1: Change Controller: "This will be "IESG" in the case of IETF-produced documents." >br>Shouldn't this actually be IETF? If I compare this to media types that also have a change controller field, we are generally very hesitant to specify anything else than IETF. After all IETF means that we need consensus on the change which will be judged by IESG. I think of two negative things of saying IESG. First that IESG may disappear and it would be unclear where this power goes. Secondly, that it may be interpreted that IESG has the right to say no over the community about updates.
      Section 2.3:" Standards-track registrations may be updated if the relevant standards are updated as a consequence of that action. Non-standards-track entries may be updated by the listed responsible party."
      There is an inconsistency here. Shouldn't this text refer to the listed "change controller"?
    4. Jari Arkko: Comment [2008-04-23]: A lot of draft-hansens, draft-klensins, draft-melnikovs, etc. Documents that are discussed on specific mailing lists around a topic. I counted over 60% individual submission rate over WG submission rate on the APPS area. Good documents. Necessary documents. Stuff that should be done. But are you sure you don't need more WGs? I do a lot of individual submissions too, but I also find that WG documents do get more review, more exposure from the IETF community, easier to delegate work to chairs, etc. Is there something that blocks us from having more WGs to look at these things, e.g., around e-mail? Are the updates too spread out to define a useful WG for them? Or does our process of starting up a WG have a too high bar?

    Telechat:

  2. Sieve Email Filtering: Environment Extension (Proposed Standard)
    draft-freed-sieve-environment-05.txt
    Note: Alexey Melnikov is document shepherd
    Token: Chris Newman
    Discuss:
    1. Pasi Eronen: The document goes much beyond providing information about the Sieve interpreter environment; it also provides information about the SMTP (or similar) connection used for delivering a particular message. This is really a property associated with the message, not the interpreter.
      Even if both of these features are provided in the same document, the abstract, introduction, and other places should more accurately describe the scope. Defining two separate test names would clarify the situation considerably; at the very least, Section 4.1 should be split to two subsections, one for each type of information.
    2. Magnus Westerlund: Comment [2008-04-24]: Section 6: Contact address: Sieve discussion list <ietf-mta-filters@imc.org>
      Shouldn't this say: IETF, Sieve WG mailing list <ietf-mta-filters@imc.org>
      To make it clear that it is an activity of the IETF? So that one knows where to go when this address doesn't work.

    Telechat:

2.2.2 Returning Items

3 Document Actions

3.1 WG Submissions

3.1.1 New Items

  1. Policy-Enabled Path Computation Framework (Informational)
    draft-ietf-pce-policy-enabled-path-comp-03.txt
    Token: Ross Callon
    Discuss:
    1. David Ward: It would be very helpful to put a listing of policy attributes that are under consideration in a section before the scenarios. The scenarios are very helpful as examples but, they are limited in their usefulness to understand what attributes and constraints are to be used to create policy. The doc is theoretical enough on the discussion of policy that it becomes unclear the actions that are to be taken.
      There is also little discussion on the policy distribution mechanism when the PCC is separated from the PCE. It would seem an important part of the framework and some more text is required to understand what is necessary.
      There are statements that COPS is not required but, it is referred to throughout the doc. If it is not required what is another technique that could be used, recommended or is going to be followed in the WG?
    2. Jari Arkko: Comment [2008-04-24]: I am concerned of a number of things with this document. The main issue is that it introduces a level of generality that I'm not sure is called for and brings along with significant complexity. Policy can be applied and fetched from either clients or servers. Policy can apply to actual PC decisions, but also to selection of PCEs. The components necessary to implement this architecture are going to be numerous. Does the industry really need all this, or was the inclusion of all of these options part of some compromise?
      Also, I was earlier under the impression that COPS is dead, and as a result it might not be such a good idea to build on it. Maybe that is not the case?

    Telechat:

3.1.2 Returning Items

3.2 Individual Submissions via AD

3.2.1 New Items

  1. Memorandum for multi-domain Public Key Infrastructure Interoperability (Informational)
    draft-shimaoka-multidomain-pki-12.txt
    Token: Russ Housley
    Discuss:
    1. Jari Arkko: I found this document useful, and a surprisingly easy read. Like Chris I wonder how practical the more complicated architectures are. But that is not something we can ask to be fixed in the document. In any case, I wanted to correct a specific few issues:
      Definition: A system of CAs that perform some set of certificate management, archive management, key management, and token management functions for a community of users in an application of asymmetric cryptography and share trust relationships, operate under the same Certificate Policy Document specifying a shared set of policy OID(s), and are either operated by a single organization or under the direction of a single organization.
      What is the term that is being defined here? No term is listed above. The title of the section, PKI Architectures, also does not seem to be something that matches the above definition. Please clarify/reword.
      PKI Domain: A set of two or more PKIs that have chosen to enter into trust relationships with each other through the use of cross-certificates. Each PKI that has entered into the PKI Domain is considered a member of that PKI Domain.
      ...
      o Two or more PKI Domains may enter into a trust relationship with each other. In this case, they may combine into a single PKI Domain or retain the existing PKI Domains and define a new PKI Domain with the existing PKI Domains as members.
      These two definitions seem contradictory. The first one says that a trust relationship between two PKIs implies a PKI Domain. The latter says that its something you can choose to have, but do not have to. I think the confusion comes from what Section 3 specifies about DPOIDs. Is a PKI domain definition dependent on (a) existence of a trust relationship and cross certs, or (b) common DPOIDs? Suggest either modifying the latter definition or taking the existence of a domain specific DPOID as a requirement in the first definition.
      In order for a PKI to participate in one or more PKI Domains, that PKI must have the following:
      o One or more Policy OID(s) defined in the Certificate Policy Document that are also asserted in all certificates issued by that PKI.
      Given a statement from start of Section 3: "A domain Policy Object Identifier (OID) is a policy OID which is shared across a PKI Domain. Each CA in the PKI Domain must be operated under the domain policy OID.", I would have expected to see a requirement on DPOIDs, too.
      Comment [2008-04-24]:
      Prior to establishing the trust relationship, each PKI determines the level of trust of each external PKI by reviewing external PKI Certificate Policy Document(s) and any other PKI governance documentation through a process known as policy mapping.
      This seems to forget the business and real-world aspects that appear to be in far greater role in determining whether to enter a relationship. Suggest edit: s/Prior to establishing the trust relationship/In addition to making a business decision to consider a trust relationship/
      PKI Domain: A set of two or more PKIs that have chosen to enter into trust relationships with each other through the use of cross-certificates. Each PKI that has entered into the PKI Domain is considered a member of that PKI Domain.
      NOTE: This definition specifies a PKI Domain recursively in terms of its constituent domains and associated trust relationships; this is different to the definition in RFC 4949 [RFC4949] that gives PKI Domain as synonym for CA domain and defines it in terms of a CA and its subject entities.
      Personally, I find the terminology domain unfortunate in this context. A federation, group or some other term would perhaps be more appropriate.
      I found it amusing that on Page 27 there is a small section that defines the used acronyms, such as "PKI". I'm almost certain that this acronym occurred earlier in the document :-) Perhaps this section should have been merged with the terms section in the beginning of the document.
      I fear that no one will in practice be able to get what Section 3.2.3 says quite right. Managing these is going to be extremely difficult for everyone except perhaps a few of the most devoted organizations. Assuming there are domains and membership in multiple domains. Do implementations typically get policy mapping and name constraint correctly? I wonder...
    2. Chris Newman: Comment [2008-04-23]: The true security of these models depends heavily on the diligence of the humans applying policy and operations as well as the people writing the software. PKI software has a long history of introducing security bugs into deployed systems simply as a side effect of the complexity of standards such as ASN.1 and PKIX. I find myself skeptical that humans can actually implement and apply the policies necessary to make the more complex PKI structures reasonably secure in practice. While these concerns could be better captured in the security considerations and that would result in a minor improvement to the document, at the root this is not an actionable concern absent significant research into practices necessary to make security policy operations actually effective.
      Editorial nits:
      Section 2.2.1: 4949 [RFC4949]. The first definition (context for PKI) is specifically used to 'Trust Anchor CA' in this document.
      I'm not sure what this means, perhaps you meant to say:
      4949 [RFC4949]. The first definition (context for PKI) is referred to by the terminology 'Trust Anchor CA' in this document.
      or
      4949 [RFC4949]. This document uses the terminology 'Trust Anchor CA' for the first definition (context for PKI) of 'Root CA' in RFC 4949.
      Section 2.3.2.3: appropriate certification path to a subscriber if they chooses an
      s/chooses/choose/

    Telechat:

  2. EAP Tunneled TLS Authentication Protocol Version 0 (EAP-TTLSv0) (Informational)
    draft-funk-eap-ttls-v0-04.txt
    Note: Laksminath Dondeti is the Document Shepherd
    Token: Jari Arkko
    Discuss:
    1. Pasi Eronen: Section 9.2.1 or 14 needs to describe downgrade attacks against version negotiation (since the EAP-TTLS header is not integrity-protected).
      Section 10 says "Specifically, the AVP Codes used in EAP-TTLS are semantically equivalent to those defined for Diameter, and, by extension, RADIUS. Also, the representation of the Data field of an AVP in EAP-TTLS is identical to that of Diameter."
      This statement should be updated to reflect the last paragraph of Section 16. Something like this:
      "Specifically, although EAP-TTLS uses the same AVP Codes and syntax as Diameter, the semantics may differ, and most Diameter AVPs do not have any well-defined semantics in EAP-TTLS. A separate "EAP-TTLS AVP Usage" registry lists the AVPs that can be used within EAP-TTLS and their semantics in this context (see Section 16 for details)."
      The document also should explicitly say that an EAP-TTLS server MUST NOT copy AVPs from EAP-TTLS to RADIUS/Diameter messages unless the server understands that AVP, and its semantics within EAP-TTLS have been defined. (Copying unknown AVPs could lead to security problems.)
      There seems to be two different ways to encode vendor-specific AVPs (such as MS-CHAP-Response): setting the V bit and placing Vendor-ID in the AVP header, or clearing the V bit and using AVP code 26. Although Section 10.3 seems to say something about this, it falls short of actually saying which format(s) MUST be used or supported when e.g. implementing MS-CHAP/MS-CHAPv2 in Sections 11.2.3/11.2.4. (What do existing implementations do?)
      The document should say something about EAP-Message attributes and fragmentation. Diameter doesn't use >253 byte EAP-Message attributes; it has a separate EAP-Payload AVP. Does EAP-TTLS inherit the 253-byte restriction from EAP-Message RADIUS attribute? Is the recipient required to support reassembly? Or is the EAP-TTLS server required to do fragmentation/reassembly if passing this to RADIUS backend? (What do existing implementations do?)
      Section 11.2.1 needs some additional text, since EAP (as defined in RFC 3748) cannot be initiated by the client sending an EAP Response. You could specify e.g. that an EAP Identity Request (with identifier 0 and empty contents) is sent, but it's "compressed" to zero bytes on the wire, but the client behaves as if it had received this packet.
      Section 11.3 probably needs some more details, since RFC 3748 does not describe how a sequence of EAP methods would work (and explicitly forbids such sequences outside tunnels). For example, will there be several EAP Identity exchanges? Are you required to run a method to a well-defined point (where normal EAP would allow you to return EAP Failure and/or EAP Success), or can you abandon a method in a middle of an exchange?
    2. Chris Newman: I believe this proposal would be significantly improved by adding support for channel bindings (RFC 5056), and that doing so would not require a great deal of effort. Basically, this would define the rules for extracting channel binding information from EAP-TTLS so that an EAP mechanism with channel bindings could then use that information.
    3. Tim Polk: The client initiated EAP authentication described in 11.2.1 would seem to break the EAP state machine. At a minimum, the document needs to describe how an eap-ttls implementation affects the state machine and (hopefully) why this is safe in the given context/environment.
    4. Russ Housley: Comment [2008-04-24]: Section 9.2 indicates that AVPs may be sent in the clear in the initial Start packet from the server. Possible uses are indicated in the text. However, it is unclear which AVPs are allowed to appear here.
      Joel Halpern suggested in his Gen-ART review an additional sentence at the end of the first paragraph of section 11.3: "Multiple authentication is only supported by this protocol in conjunction with EAP."

    Telechat:

  3. PKCS #8: Private-Key Information Syntax Standard Version 1.2 (Informational)
    draft-kaliski-pkcs8-00.txt
    Token: Russ Housley
    Discuss:
    1. Pasi Eronen: This is a "discuss" discuss; I expect to clear or change to normal discuss after the telechat.
      If this was a normal IETF document, I'd have a list of things that need to be fixed, mostly of semi-editorial nature. For example,
      - split references to normative and informative
      - say something about file formats (how you store PKCS#8 objects in a file in interoperable way)
      - explain better how attributes are supposed to be used
      - give some more concrete recommendations about encryption (to achieve interoperability)
      - say something about I18N when the encryption key is a character string typed in by the user
      - explain relationship to other standards or de-facto conventions for storing private keys
      However, since this document attempts to be a word-by-word republication of an existing document, and the intent of transferring change control is to update the document relatively soon in IETF, perhaps these changes could be done in that update.
      Should there be e.g. in IESG note saying that the document is known to be lacking in some areas, and an update is expected to improve it?

    Telechat:

1246 EDT break
1252 EDT back
Cindy: Russ text in jabber

3.2.2 Returning Items

3.3 Individual Submissions via RFC Editor

3.3.1 New Items

3.3.2 Returning Items

4 Working Group Actions

4.1 WG Creation

4.1.1 Proposed for IETF Review

4.1.2 Proposed for Approval

  1. NETCONF Data Modeling Language (netmod)
    Token: Dan

    Telechat:
    Cindy: do we postpone
    [postponed to end of meeting, hoping Ron will become available; see "Agenda Item Continued" below]

4.2 WG Rechartering

4.2.1 Under evaluation for IETF Review

4.2.2 Proposed for Approval

5. IAB News We can use

6. Management Issues

  1. Can milnet-parameters be made historic? [IANA #164095] (MichelleCotton)

    Telechat:

  2. IESG Note for RFC 5000 (Russ Housley)

    Telechat:

Agenda Item Added:

7. Working Group News

Agenda Item Continued:

1323 EDT Adjourned