IESG Narrative Minutes

Narrative Minutes of the IESG Teleconference on 2009-07-02. These are not an official record of the meeting.

Narrative scribe: John Leslie (The scribe was often uncertain who was speaking. Instances of "UserNN" are Webex IDs.)

Corrections from:

1 Administrivia

  1. Roll Call 1134 EDT Amy:
  2. Bash the Agenda
  3. Approval of the Minutes of the past telechat
  4. Review of Action Items from last Telechat

2 Protocol Actions

2.1 WG submission

2.1.1 - New Items

  1. RTCP Extensions for Single-Source Multicast Sessions with Unicast Feedback (Proposed Standard)
    draft-ietf-avt-rtcpssm-18
    Token: Cullen Jennings
    Extracted from Balloting:
    1. Jari Arkko: Comment [2009-07-01]: Is there something wrong with this sentence from the abstract:
      "The proposed extension is useful for single-source multicast not available or not desired."
    2. Ralph Droms: Comment [2009-06-29]: A couple of details about the report aggregation in section 7.2.1 are unclear to me.
      * I don't see a schedule of reporting prescribed for method (a). If the schedule is left to the discretion of the Distribution Source, it should be stated explicitly
      * In method (b), does the distribution source use just the most recent value received from each receive (as in method a) or does it use all received values in the summarization window?
    3. Lars Eggert: Comment [2009-07-01]: (blank)
    4. Alexey Melnikov: Discuss [2009-06-24]: I've skimmed the document and found 2 issues:
      In Section 7.1.1: Timestamp...
      The normative reference [4] is defined as: "[4] B. Quinn, R. Finlayson, "SDP Source-Filters", RFC 4570, July 2006." which looks wrong to me.
      In Section 7.1.8: Address: 4 octets (IPv4), 16 octets (IPv6), or n octets (DNS name)...
      I am really confused here: this is either transporting binary IPv4/IPv6 addresses or a DNS name?
      Also, why is this UTF-8 encoded? Does this mean that IDNA domain names are allowed? If yes, the document should say so. If not, use of US-ASCII is enough for DNS names.
      Comment [2009-06-24]: I couldn't find a statement saying that all fields larger than 8 bits are in network byte order.
    5. Tim Polk: Comment [2009-06-30]: (blank)

    Telechat:

  2. TCP Congestion Control (Draft Standard)
    draft-ietf-tcpm-rfc2581bis-05
    Token: Lars Eggert; Note: Document Shepherd: Wesley Eddy (wesley.m.eddy@nasa.gov); Interop Report: http://www.ietf.org/mail-archive/web/tcpm/current/msg03133.html
    Extracted from Balloting:
    1. Adrian Farrel: Discuss [2009-07-02]: Good to see this work done. Thanks.
      A couple of important things to make sure this goes through the RFC Editor correctly.
      This document should be marked obsoletes 2581. This should also be noted in the Abstract.
      The document should show an intended status.
      These can all be handled in RFC Editor notes.
      Comment [2009-07-02]: idnits is not too happy!
      - no table of contents
      - no intended status
      - references no up-to-date
    2. Cullen Jennings: Comment [2009-07-02]: The implementation report is woefully inadequate to document there are interoperable implementations of all the features from two different code bases.

    Telechat:

  3. Definitions of Managed Objects for Very High Speed Digital Subscriber Line 2 (VDSL2) (Proposed Standard)
    draft-ietf-adslmib-vdsl2-07
    Token: Dan Romascanu
    Extracted from Balloting:
    1. Adrian Farrel: Discuss [2009-07-02]:
      I would like to hear from the Ops ADs whether they think that TCs like Xdsl2TransmissionModeType should be moved to an IANA MIB module to allow the definition of new values without requiring to respin this MIB module as a new RFC.
      It is odd (and possibly non-conformant) to place the IANA Considerations section at 2.2.
      Comment [2009-07-02]: I don't understand the default value provided in the following object. Please check that it is appropriate majick.
      "xdsl2LineAlarmConfTemplate..."
    2. Tim Polk: Discuss [2009-07-02]: This is a process discuss... I would like to be sure the authors have responded to Richard Barnes review and suggested changes for the security considerations section. The issues themselves are not blocking, although I think his suggestions have merit, and I am not asking for changes to the SNMPv3 conformance language (I consider that settled by the MIB template work).

    Telechat:

  4. Locating IEEE 802.21 Mobility Servers using DNS (Proposed Standard)
    draft-ietf-mipshop-mos-dns-discovery-06
    Token: Jari Arkko; Note: Document shepherd is Vijay Devarapalli <vijay@wichorus.com>
    Extracted from Balloting:
    1. Adrian Farrel: Comment [2009-07-02]: Dan's rather thorough review seems to have caught everything I had on my list. if you address his issues and comments I shall be OK.
      But in particular,
      "Note, that the regexp field in the NAPTR example above is empty. This document discourages the use of this field as its usage can be complex and error prone; and the discovery of the MIH services do not require the flexibility provided by this field over a static target present in the TARGET field."
      Needs "discourages" to be written in RFC2119 language
    2. Cullen Jennings: Comment [2009-06-30]: support Alexey IANA discuss
    3. Alexey Melnikov: Discuss [2009-06-20]: I have 2 issues, which are probably minor:
      1). In the IANA Considerations section:
      "... New Service Fields are to be added via Standards Action as defined in [RFC5226]. New entries to the table that specify additional transport protocols for the existing Service Fields may be registered by IANA on a First Come First Served' basis [RFC5226]."
      I am confused. These 2 registration procedure seem to be in conflict.
      2). I think the following reference is Normative: "[ID.ietf-mipshop-mos-dhcp-options] DHCP Options for IEEE 802.21 Mobility Services (MoS) Discovery, Bajko et al, May 2009, work in progress"
      Comment [2009-06-20]:
      2. Discovering a Mobility Server
      "[...] When the MN needs to discover Mobility Services in a local (visited) domain, it SHOULD use DHCP as described in [ID.ietf-mipshop-mos-dhcp-options] to discover the IP address of the server hosting the desired service, and use it in SRV queries."
      My understanding is that SRV lookups are using domain names (not IP addresses) as input, so some extra steps are missing here.
      2.2 Selecting the transport protocol
      "[...] The resource record will contain an empty regular expression and a replacement value,"
      Should this "will" be a "MUST"?
    4. Dan Romascanu: Discuss [2009-07-01]: The DISCUSS and COMMENT are partly based on comments from the DNS-DIR reviewer Andrew Sullivan and from Alfred Hoenes.
      1) I would like to get some confirmation about the level of involvment or review that this document received from the IEEE 802.21 community. The PROTO write-up mentions that there is no implementation and no plans for an implementation are known. Was this document distributed for review to the IEEE 802.21 Working Group, or is a consistent subset of participants in mipshop also active in the IEEE 802.21 WG?
      2) Alfred Hoenes made a comment that I believe needs some consideration. He pointed out that Section 2.3 suggests a possibility of an IP address in TARGET and observed that the SRV definition in RFC 2782 defines "Target" as "The domain name of the target host." thus there should not be an IP address returned here.
      Indeed Section 2.3 stipulates:
      "If TARGET is a numeric IP address, the MN uses that IP address and the already chosen transport to contact the server providing the desired service."
      while RFC 2872 defines:
      Target "The domain name of the target host. There MUST be one or more address records for this name, the name MUST NOT be an alias (in the sense of RFC 1034 or RFC 2181). Implementors are urged, but not required, to return the address record(s) in the Additional Data section."
      If the text in 2.3 refers to the address records in the Additional Data section this needs to be clearly explained.
      Also in section 2.3:
      "If the result of the SRV query contains a port number, then the MN SHOULD contact the server at that port number. If the SRV record did not contain a port number then the MN SHOULD contact the server at the default port number of that particular service. A default port number for MIH services is requested from IANA in [ID.ietf-mipshop-mstp-solution]."
      However, an SRV record should always have a port number, RFC 2782 does not make the field optional. Is the idea that the port could be "0"? Wording adjustment seems to be needed here as well.
      Comment [2009-07-01]:
      1. Some terminology clarifications could improve the document. One of the issues is the notion of 'home domain' as in:
      "When the MN needs to discover Mobility Services in its home domain, the input to the First Well Known Rule MUST be the MN's home domain, which is assumed to be pre-configured in the MN."
      There seem to be an issue with the DNS-DIR about the notion of a "home domain", and how it fits into the DNS (where it's either an entirely alien notion or one of the suffixes in the search path, depending on how you feel about these things). We could not find a definition of "home domain" or "home network" there; neither was it in RFC 5164. If it's defined in the IEEE 802.21 standard it would be good ti indicate this and maybe replicate the definition here.
      2. The following text in section 2.2 is a little weak:
      "Note, that the regexp field in the NAPTR example above is empty. This document discourages the use of this field as its usage can be complex and error prone; and the discovery of the MIH services do not require the flexibility provided by this field over a static target present in the TARGET field."
      It seems that since the regexp field is previously defined to be empty then a returned NAPTR record with a populated regexp field is not just discouraged: it's undefined, and is not an instance of a NAPTR record that conforms with the specification in this draft. It would be a significant improvement to strengthen this, the document will be easier to understand if this is made plainer.
      3. The IANA considerations says that the Protocol field of the new registry contains the name and acronym for the protocol, along with a reference to a document that describes the transport protocol; but the initial values defined in the draft don't do that. They also require name, address, email address and telephone number ofr the person performing the registration - this seems too much, probably name and email address would be enough.
    5. Robert Sparks: Discuss [2009-07-01]:
      The reference to [IEEE802.21] is ambiguous. Is there a way to reference a particular document?
      Is it worth discussing the impacts of attacking DHCP to affect the inputs to this protocol?
      Comment [2009-07-01]: Support Dan's discuss on the need for clarification of "If the SRV record did not contain a port number..."
    6. Magnus Westerlund: Discuss [2009-07-02]:
      Section 3:
      As the proposal is using an SRV service name of MIHIS, MIHES, MIHCS. Those do not appear in the IANA registries for either protocol names or as a service name in the port registry. These needs to be registered to avoid future conflict attempting to use SRV with the above mention names. Also if new entries are registered for the NAPTR usage, then they also need registration in the service name registry.
      The only problem is that the service name registry rules are unclear and under revision. But, the registration needs to happen somehow. Ask IANA how they would prefer it.

    Telechat:

  5. RTP Payload Format for Elementary Streams with MPEG Surround multi- channel audio (Proposed Standard)
    draft-ietf-avt-rtp-mps-02
    Token: Cullen Jennings
    Extracted from Balloting:
    1. Tim Polk: Discuss [2009-06-30]: This is a discuss-discuss, intended to stimulate discussion on the telechat. If the discussion persuades me these changes are inapropriate for an extensions draft, I will move to comment on the call. The authors are requested to consider the issues raised in either case...
      This document updates RFC 3640, and largely depends upon 3640 for its security considerations. RFC 4855 imposed new requirements for payload registration, including a number of issues in the security considerations section (e.g., identifying whether there is active content, opportunities for steganography, and issues arising from compression techniques).
      I would like the authors to review the requireemnts in 4855 and ensure that all are addressed in either 3640 or 4855. Is this an appropriate request?

    Telechat:

  6. Quality of Service Attributes for Diameter (Proposed Standard)
    draft-ietf-dime-qos-attributes-12
    Token: Dan Romascanu
    Extracted from Balloting:
    1. Ralph Droms: Comment [2009-06-29]: Minor editorial comments:
      * In the first sentence of section 4.2.5, s/Day-of-Week-Month/Day-Of-Month-Mask/
      * In the first sentence of section 4.2.6, s/Month-of-Year-Month/Month-of-Year-Mask/
    2. Lisa Dusseault: Comment [2009-07-01]: It is hard for me to see how the general security considerations for Diameter can be sufficient for QoS. QoS features have a specific threat model, with some threats that other Diameter applications don't have and vice versa.
    3. Lars Eggert: Discuss [2009-07-01]:
      DISCUSS-DISCUSS: I fail to understand why matching on TCP options and flags (4.1.6.7.-10.) is necessary for QoS handling. QoS is meaningful for flows, not individual packets. Also, if you consider it essential for some reason to match on transport-header details, why aren't the other transport protocols included here?
      Section 5.1., paragraph 4:
      "All traffic that is met by the condition part of a rule MUST be dropped. This action implements firewalling functionality."
      DISCUSS: Firewall functionality is NOT QoS. How is this in scope of the DIME work item on QoS?
      Comment [2009-07-01]: Section 4.1.7.16., paragraph 1:
      "The Port-Start AVP (AVP Code TBD) is of type Integer32 and specifies the first port number of an IP port range."
      Ports are not IP-layer entities. They only have meaning within specific transport protocols, you can't talk about them without tying them to a transport protocol. (Also note that DCCP for example also uses service codes in addition to ports!)
    4. Adrian Farrel: Discuss [2009-07-01]: I hope this is a minor Discuss that can be addressed with a clarifying email.
      Section 4.1.8.14 through 4.1.8.23 apply to matching on Ethernet fields. It is unclear to me what this is doing in an IETF document.
      - What happens if the L2 protocol is not Ethernet?
      - Have you consulted the owning SDO for Ethernet?
      If Ethernet encapsulation really is in scope, perhaps this could be highlighted in the Abstract and Introduction.
      Comment [2009-07-01]:
      Figure 1 and figure 5 have minor alignment problems.
      Section 5 says:
      "This section illustrates the actions associated with a rule."
      But it appears to me that the subsequent subsections *define* the actions.
      It would be really nice if the IANA section named the registries from which the allocations are to be made.
    5. Magnus Westerlund: Discuss [2009-07-02]:
      Please provide a normative reference to the formal lagnuage (notation) you are using in the document to describe the rules. Two IESG statements are relevant to this:
      http://www.ietf.org/IESG/STATEMENTS/pseudo-code-in-specs.txt
      http://www.ietf.org/IESG/STATEMENTS/syntax-format-def.txt
      There are also missing references to imported definitions, like address in section 4.1.7.2
      Section 5.1:
      I can't really understand how one can define actions without actually defining what one should do and how to provide the information necesaray for the action. Both Shaping and Marking clearly needs to define how the actions are going to be carried out and what the parameters are.
      Section 10.1:
      The registry for where the registration is going to happen is not really specified: I assume that the registry intended is:
      "Authentication, Authorization, and Accounting (AAA) Parameters" : "AVP codes"
      but that is not clear. Please write out the registries names.
      Section 10.2 and 10.3: Also here the clarify of what the registration request is for is not clear. I assume that you are requesting to add a new registry for "AVP specific values" under the "Authentication, Authorization, and Accounting (AAA) Parameters" page.
      Can you make this clear so it is easier to find the correct registries in the future.

    Telechat:

  7. Considerations for Civic Addresses in PIDF-LO - Guidelines and IANA Registry Definition (BCP)
    draft-ietf-geopriv-civic-address-recommendations-02
    Token: Cullen Jennings
    Extracted from Balloting:
    1. Lars Eggert: Discuss [2009-07-01]:
      Section 5139, paragraph 0:
      "For some countries Section 3.4 of [RFC4776] already contains considerations on the use of administrative sub-division elements. It's important to note that those examples are outdated, because RFC 5139 [RFC5139] disallows the use of the 'A6' elements for street names."
      DISCUSS: Then this document should formally "Update" RFC4776 and include a subsection that makes Section 3.4 obsolete. (Since RFC5139 doesn't do so.) And also do what Tim's comment suggests (mark them in the IANA registry).
      Appendix A., paragraph 0:
      "Appendix A. Civic Address Considerations Registration for the Austrian building and habitation registry"
      DISCUSS-DISCUSS: Is this given as an example, i.e., as an informative appendix or is this appendix in fact normative, i.e, is it the RFC4776-required "civic address consideration document" for Austria?
      Comment [2009-07-01]: Section 6173, paragraph 36:
      "The element A5 holds the Katastralgemeindename (cadastral municipality), the Katastralgemeindekennziffer (the identifier), or"
      This is the only place where Katastralgemeindekennziffer appears in the document - do you mean Katastralgemeindenummer?
    2. Tim Polk: Discuss [2009-06-30]: I had a hard time deciding whether this should be a weak discuss or strong comment, but decided to err towards the discuss this time...
      "In addition to that, it has to be considered that data from certain data sources (on which the described mapping process is based) are possibly not public, so restrictions as imposed on the original data set MUST also be imposed on the resulting PIDF-LO document."
      I agree with this statement, but believe it should be addressed directly in the body of the document, with a bullet of its own in section 3.
      Comment [2009-06-30]: Updated to add a forgotten comment...
      from section 1:
      "For some countries Section 3.4 of [RFC4776] already contains considerations on the use of administrative sub-division elements. It's important to note that those examples are outdated, because RFC 5139 [RFC5139] disallows the use of the 'A6' elements for street names."
      I suggest that this document register these examples in the new IANA registry as "obsolete" for completeness.

    Telechat:

  8. Message Body Handling in the Session Initiation Protocol (SIP) (Proposed Standard)
    draft-ietf-sip-body-handling-06
    Token: Robert Sparks; Note: Theo Zourzouvillys is the document shepherd
    Extracted from Balloting:
    1. Alexey Melnikov: Comment [2009-06-23]: This is a good document. Some minor comments:
      3.1. Background on Message Body Encoding
      "[...] SIP uses S/MIME [RFC3850] to protect message bodies..."
      Here and in one other place: I think you really meant RFC 3851:
      I think explicit statement that support for multipart/signed is OPTIONAL by UAS and UAC would benefit the document.
      3.2. UA Behavior to Encode Binary Message Bodies
      I think this needs a reference to [RFC4289] where the "binary" content transfer encoding is defined.
      4.2. Mandatory Support for 'multipart' Message Bodies
      "[...] It has been observed on the field..."
      I think it should be "in the field".
      4.3. UA Behavior to Generate 'multipart' Message Bodies
      "[...] Note that UAs receiving unnecessarily nested body parts treat them as if they were not nested."
      I think this sentence is a bit ambiguous, so you should consider clarifying it.
      10. Guidelines to Authors of SIP Extensions
      s/design/designing

    Telechat:

  9. Dynamic Hostname Exchange Mechanism for OSPF (Proposed Standard)
    draft-ietf-ospf-dynamic-hostname-04
    Token: Ross Callon
    Extracted from Balloting:
    1. Ralph Droms: Comment [2009-06-30]:
      Is there any impact from name collisions if two routers use the same Dynamic Hostname. I don't think there is other than potential confusion in reading and using the mapping information.
      For completeness, it might be useful to add a couple of sentences explaining that name conflicts aren't crucial and, therefore, there is no conflict detection or resolution in the protocol.
      Editorial suggestion: expand "FQDN" on first use in section 3.1?
      I don't understand this sentence in section 3.1:
      "The content of this value is a domain name, see [RFC2181]."
      "this value" == value field in the Dynamic Hostname TLV? What does it mean for the dynamic hostname to be a "domain name"? Can't it also be an arbitrary identifier chosen by the OSPF admin or does it somehow have to relate to a name from the DNS?
    2. Lisa Dusseault: Comment [2009-07-01]: I agree with the comment that this draft should be more clear in the difference between a hostname and a display name for a router. Using the terms 'host' and "host name" imply that the node is reachable at that host name. OTOH if this was just a display name, then presumably RFC3490 wouldn't apply.
    3. Lars Eggert: Discuss [2009-07-01]:
      Section 5., paragraph 1:
      "Since the hostname-to-Router ID mapping relies on information provided by the routers themselves, a misconfigured or compromised router can inject false mapping information, including a duplicate hostname for different Router IDs. Thus, this information needs to be treated with suspicion when, for example, doing diagnostics about a suspected security incident."
      DISCUSS: That's certainly true, but I'd like the document to specify some mechanisms to prevent foot-shooting. For example, when two or more routers are (mis)configured with the same name, should a router that detects this still blindly flood this information without even a management alert? Even when someone else is using "my" name? Even ARP stacks these days raise a "MAC address foo is using my IP adress bar" alerts.
      Comment [2009-07-01]:
      INTRODUCTION, paragraph 2:
      "Dynamic Hostname Exchange Mechanism for OSPF"
      The names exchanged in this option name *routers*, not hosts. The terminology is hence pretty confusing.
      Section 2., paragraph 5:
      "This specification provides these semantics and mapping mechanisms for OSPFv2 and OSPFv3, leveraging the OSPF Router Information (RI) LSA ([RFC4970])."
      Please expand acronyms on first use (LSA, etc.)
      Section 3.1., paragraph 6:
      s/recommended/RECOMMENDED/
      Section 8.2., paragraph 4:
      "[RFC2763] Shen, N. and H. Smit, "Dynamic Hostname Exchange Mechanism for IS-IS", RFC 2763, February 2000."
      Obsolete informational reference (is this intentional?): RFC 2763 (Obsoleted by RFC 5301)
    4. Adrian Farrel: Discuss [2009-07-01]:
      I really wanted to vote "yes" notwithstanding a number of Comments, but I think the security section warrants some discussion...
      It seems to me that the FQDN potentially exposes geographic or other commercial information that may be embedded in or deduced from the hostname. Sending this information in the clear is therefore a security risk that should at least be indicated in the security section (even if you are not proposing any solution).
      Comment [2009-07-01]:
      Section 1
      "It is obvious that..."
      I *hate* being told that something is obvious. This text does not add anything to the I-D.
      Section 2
      s/DNS can be used for the same./DNS could be used for this./
      s/Routers who don't understand/Routers that don't understand/
      Section 3
      "The Dynamic Hostname TLV (see Section 3.1) is OPTIONAL. Upon receipt of the TLV a router may decide to ignore this TLV, or to install the symbolic name and Router ID in its hostname mapping table."
      Is it worth highlighting that "ignore" means "not act on, but continue to flood as part of the LSA." ?
      Section 3.1
      "... Hostname, a string of 1 to 255 octets, padded to 4-octet alignment, encoded in the US-ASCII charset."
      Do you care whether this is padded with any character?
      FQDN should be expanded on first use.
    5. Dan Romascanu: Comment [2009-07-02]: The OPS-DIR review by David Kessens raised a number of issues that make this document problematic although not enough to block it at this phase:
      1. The authors chose to overload the protocol with an option for a problem that looks more like a management problem and is solved in real life by good network management techniques. The arguments about scaling issues for a stored mapping table do not seem credible. One can expect that routers in a reasonable sized network are already configured by use of a central database and configuring an extra table should not be a problem at all. Furthermore, there are security issues with the choosen approach that a configured table doesn't have and it seems that it might be easier to avoid name conflicts with a centrally configured table. The security concerns are apprpiately identified in the document, ans it seems safer to use a configured table which does not have such problems.
      2. There are issues with the interpretation of what an ID to hostname mapping actually means, and what it should and should not be used for. The term hostname is used but there are only hints that an OSPF hostname might be the same as what one stores in the DNS as a hostname for a particular router. Eg. is the hostname just an easy human readible name or is it supposed to be the same as a real hostname that also maps to an IP address used by the router.
    6. Robert Sparks: Discuss [2009-07-01]:
      I think a little more advice in the Security Considerations section on protection from accidental misconfiguration causing problems might be in order.
      This mechanism causes routers to keep new state (adding domain names to a table). The mechanism can provide names that are large (effectively bounded by the size of an OSPF message). It's not hard to imagine someone fat-fingering a configuration file (missing a quote or the equivalent) and ending up with a very large "domain name".

    Telechat:

  10. L2TPv3 Extended Circuit Status Values (Proposed Standard)
    draft-ietf-l2tpext-circuit-status-extensions-04
    Token: Ralph Droms; Note: Ignacio Goyret <igoyret@alcatel-lucent.com> is the WG shepherd for this document
    Extracted from Balloting:
    1. Lars Eggert: Comment [2009-07-01]:
      Section 4719, paragraph 13:
      "Value Pair (AVP) to communicate more granular error states for"
      s/more granular/finer-grained/ (right?)
      Section 2., paragraph 9:
      Please expand acronyms on first use (PSN, etc.)
      Section 2., paragraph 11:
      "This document deprecates this bit as it is of little or no use, hence this bit SHOULD be ignored on receipt and is OPTIONAL to send."
      s/send/set/ (it's difficult to not send the bit...)
      Section 2., paragraph 15:
      "Reserved |S|E|I|T|R|0|A|"
      s/0/N/ (it's still permitted to set it to 1 according to the text, so making it 0 in the picture is inaccurate, I think)
    2. Adrian Farrel: Discuss [2009-07-02]:
      In section 2 the final semantics of the N bit is now unclear!
      You say...
      "This document deprecates this bit as it is of little or no use"
      But you also define the meaning of the bit, and say that it is OPTIONAL to send and only "SHOULD be ignored" implying that it "MAY be processed for logging".
      These explanations are unclear and contradictory. You need to focus on
      - new implementations
      - legacy implementations
      o A legacy implementation will always set the N bit as defined in 3931.
      o A legacy implementation will always read meaning into the N bit although it is possible that no implementation does anything except to log it.
      o A new implementation must provide some value in this bit (no bit is actually optional to send!). What value MUST it supply?
      o A new implementation presumably MUST NOT examine the N bit.
      Further down the same section you imply that the new implementations should send N=0. The table after the figure is a little confused as it shows the N bit, although the figure does not. I think you should show 'N' in the figure, and in the table you should show...
      (N) 14 0x0002 Reserved [use deprecated]
      This should also be reflected in Section 6
    3. Tim Polk: Discuss [2009-06-30]: The Security Considerations section consists of one sentence:
      "No additional security considerations exist with extending this attribute."
      I suspect this is true, but it is not helpful to the readers. Please provide references to the security considerations that have already been documented.

    Telechat:

  11. An Extension to Session Initiation Protocol (SIP) Events for Conditional Event Notification (Proposed Standard)
    draft-ietf-sipcore-subnot-etags-02
    Token: Robert Sparks; Note: Dean Willis (dean.willis@softarmor.com) is document shepherd
    Extracted from Balloting:
    1. Ralph Droms: Comment [2009-06-30]: Minor clarification: it might be useful to include the "else" condition for the condition evaluation in steps 6 and 10 in the typical message flow.
    2. Lisa Dusseault: Discuss [2009-07-01]: I support Cullen's DISCUSS -- I read in the summary that the working group has spent a year clarifying whether it's entity state or event state that's indicated by the token, but that clarity (and related understandings) didn't make it off the mailing list into the doc.
    3. Adrian Farrel: Comment [2009-07-02]: In section 5.6 you have several times...
      "before the subscription is about to expire"
      This may be a little subtle, but do you mean "slightly earlier than before the subscription expires" or do you mean "when the subscription is about to expire"?
    4. Cullen Jennings: Discuss [2009-06-30]: I really like the etag concept for subscriptions and strongly support this draft. However, I know from the etag experence in HTTP and webdav, we need to have this pretty crisp for implementors or we will have lots of problems. This document probably needs some changes.
      In particular, it seems to say in a few places that the one needs to save forever and infinite number of old entity tags. This is clearly not implementable and I doubt what anyone really wanted.
      Just to check I am on the same page with everyone else. I want to check we all agree on the following. A client device does a poll and gets ETag=123 and a entity state of foo. Later it does a poll with an etag of 123 and if the responses body is suppressed, at this point the client can use the value foo for the entity state just as if the response had actually returned foo. I want to make sure we all agree this is true that the client can rely on using the value foo in this case. If not the mechanisms seems pretty useless.
      The big issue has to do with the draft is too vague about what the properties of an etag are. Statements like "the subscriber MUST NOT assume identical entities (i.e. event state) for NOTIFYs with identical entity-tag values" leave me baffled beyond belief. That directly contradicts exactly what this draft is all about which is if you have an etag that matches you can assume that the entity value is the same. The draft needs a list of properties the ETags MUST have and them some examples ways to generate them. From the WG discussion, I'm expecting that few ways of computing them would be
      1) a sha1 hash of entity value
      2) A date time stamp of every time the resource changed or a rule/filter/auth that changed an entity changed
      3) an incrementing counter of every time the resource/entity changed and the counter was big enough to never wrap
      4) an UUID every time the resource/entify changed
      They types of properties I am assuming for an etag would be things along line of
      A) if the etags are the same, it is statistically interoperability for the entities to not be the same
      B) if two versions of an entity are the same, the etags may or may not be
      C) different subscribers may or may not get the same the same etag for the same version of a resource
      It would also be nice to know what the semantics of the etag in a request are. Does it mean the client has that version of entity? Or does it mean just don't tell me if it it has not changed since that version. This makes difference to storage and what extensions can be build on this. Section 6.4 seems to rely on the first type of description.
      We also need more information about the scoping of the etags, saying they are scoped to Entities is not really right as theses disappear with the subscriptions disappears. I think it is closer to say they are scoped to the view of the resource but that introduces the whole view concept. I'm not sure exactly how to do this but the the draft struggles with the difference of the entity from the resource.
      Comment [2009-06-30]: A bunch of these likely need to be a discuss level item but I would like to wait till we have talked about them a little in some email threads before I figure out which ones need are not just a comment level note. Much of it depends on how the previous items get resolved.
      In abstract, I don't think this system tells you if state has changed, it tells you if the state is different than a previous fetch value. It may have changed and changed back to original and this system would not necessarily tell you that.
      Need more explicitly discussion of what happens when something that would change the Entity but not the resource happens... Say a filter rule changes but the resource did not. Does this change the etag?
      Explain why we want the "*" and when to use it
      Not enough discussion of what it means for two version of an entity to be the same. I would suggest bitwise exact...
      The document says in multiple places that there is a single authoritative notifier for a given resource or words along theses lines. I'm not sure this is really true - clearly many systems allows many different UA to act in a authoritative way for a resources. One just hopes they all return the same answer. It's not even clear to me that there could not be different answers based on where in the network the request came from.
      Section 1.2 - Entity definition. Worth noting that 3256 uses entity to mean something different than this...
      Section 2.2 - "low rate of notification triggered by state changes" should be clear the state we are talking about is resource state
      Pretty much everywhere the word "unique" occurs I think it bears some careful thought about if that is right and the scope of it...
      The statement "the notifier remembers the entity-tags of all version of entities" just about made me spill my coffee. Surely not.
      The discussion of how this was not like Publish in section 3 just seemed confusing and not needed in this part of the draft.
      The first sentences in last para of section 3 seems like it would make far more sense in middle of previous paragraph.
      I found section 2.2 pretty useless and wonder if it could just be deleted...
      Figure 1 would make more sense if between 6 and 7 there was a step that indicated the resource changed value
      Figure 2 would make more sense if you deleted all the things that were not discussed...
      In section 4 where you have "a resource is identified by zero or more" - I don't see how zero works. I would have put one or more.
      When I look at the things that are part of the entity-header, I don't see how any of these can change without the body changing so I don't understand why they need to be covered by the etag. Why are they needed?
      Section 4 has a para starting about "Note that two entity tags being equal does not ....". This seems wrong to me. How would this work.
      More is needed about treatment of difference encoded data...
      Section 5.2 - first para says "MUST include" - shouldn't this be "MAY include"...
      Nothing seems to discuss how entity tags are compared...
      Section 5.4 - figure 3 - it was not clear reading this why it did a 202 instead of a 204.
      Section 5.6 make clear this is inside a subscription dialog and that is why did 204.
      Might be nice to show example that uses "*"
      The B2BUA section seems sort of wrong...
      The example of an etag that is implemented by a counter of NOTIFY generated seems very broken...
      "An entity tag is valid as long as an entity is valid" - I have no idea how long an entity is valid. Does it stay valid when the subscription terminates? what would that even mean? when would it become invalid?
      Section 6.1 - I had no idea what you are talking about of remember older etags for journal state updates until I read section 6.4. I think 6.4 is not quite right for things where the resource did not change but something else changed that would cause the entity to change. Similarly with section 6.5
      The whole established dialog stuff seems pretty arm wavy...
      Section 9 - I'm not sure I buy this does not change the security situation...
    5. Alexey Melnikov: Comment [2009-06-24]:
      In Section 2.2:
      "Some subscriber implementations may choose to operate in semi-stateless mode, in which they immediately upon receiving and processing the NOTIFY forget the resource state."
      I suggest rephrasing this for readability:
      "Some subscriber implementations may choose to operate in semi-stateless mode, in which they immediately forget the resource state upon receiving and processing the NOTIFY."
      In Section 5.3:
      "[...] The subscriber MUST NOT infer any meaning from the value of an entity-tag; specifically, the subscriber MUST NOT assume identical entities (i.e., event state) for NOTIFYs with identical entity-tag values."
      "Note that there are valid cases for which identical entity-tagvalues indeed imply identical event state. For example, it is possible to generate entity-tag values using a one-way hash function."
      I suggest deleting the Note, as it seems to contradict the MUST NOT in the previous paragraph. While I understand what you are trying to say, I think the Note text is actually not helping.
    6. Tim Polk: Comment [2009-06-29]: Section 3, paragraphs 2 and 3 should probably introduce the notion that entity tags are specific to a state for the resource. This idea doesn't surface until step 7 in the typical message flow, which is too late imho.

    Telechat:

  12. Bidirectional Forwarding Detection (BFD) for the Pseudowire Virtual Circuit Connectivity Verification (VCCV) (Proposed Standard)
    draft-ietf-pwe3-vccv-bfd-05
    Token: Ralph Droms; Note: Matthew Bocci (matthew.bocci@alcatel-lucent.com) is the document shepherd
    Extracted from Balloting:
    1. Adrian Farrel: Comment [2009-07-02]:
      Nice to remove the word "new" from the Abstract as this work will (hopefully) persist.
      I don't believe that [RFC5317] is a good reference for MPLS-TP requirements or solutions. I suggest referencing draft-ietf-mpls-tp-requirements and draft-ietf-mpls-tp-framework Maybe also, draft-ietf-mpls-tp-oam-requirements.
    2. Robert Sparks: Discuss [2009-07-02]: This is a point for discussion with the ADs at the telechat. I will clear after this discussion.
      I'd like to talk briefly about references to the PDF version of 5317
    3. Magnus Westerlund: Discuss [2009-07-02]:
      Section 6: BFD congestion control response are under discussion. However, it it clear that the VCCV congestion control and BFD's has the potential for bad interactions. That issue must be documented. Unfortuntately it can't be documented properly until the discussion for BFD has completed.
      The interaction between VCCV and BFD appears to be that any limitation of the VCCV channel will affect all VCCV traffic that will include BFD control and test messages when encapsulated in the VCCV channel. Thus the BFD congestion control might react to these external limitations in such a way BFD fails to verify the connectivity despite it existing. However, any real analysis in the behavior can't be completed until we know the BFD algorithms.

    Telechat:

2.1.2 Returning Items

  1. (none)

2.2 Individual Submissions

2.2.1 New Items

  1. Guidance on Interoperation and Implementation Reports (BCP)
    draft-dusseault-impl-reports-03
    Token: Tim Polk
    Extracted from Balloting:
    1. Lars Eggert: Discuss [2009-07-01]:
      INTRODUCTION, paragraph 14:
      "Advancing a protocol to Draft Standard requires documentation of the interoperation and implementation of the protocol."
      DISCUSS: It's not only when going PS->DS, it's also from DS->IS where we need an interop report (see the text you quoted from RFC2026 in Section 1). This entire document, however, is written with a focus on PS->DS. I'd prefer if this document were rephrased to also explicitly cover the DS->IS case. (Alternatively, it needs to be made clear that it is *not* covering that, but then what is?)
      Comment [2009-07-01]: Section 5.3., paragraph 0: 5.3. Schemas, languages and formats
      As another example for this section, you may also want to add an informative reference to draft-bradner-metricstest, which is the basis of a (to-be-submitted) work item in IPPM that will define how performance metrics advance along the standards track.
    2. Alexey Melnikov: Comment [2009-06-19]: It would be nice if the document talks about early implementations (as discussed during the IETF LC) and how they my not match the final document being progressed. But I don't think this is a blocker for the document.
    3. Dan Romascanu: Discuss [2009-07-01]: I find this document extremely useful and well written, and I plan to vote Yes after the DISCUSS issues are addressed:
      1. Neither this document nor RFC 2026 make clear whether an interoperation report is a mandatory requirement for advancing an RFC from Proposed to Draft. This document just says:
      This documentation should be submitted to the Area Director with the protocol action request.(see Section 6)"
      Are there cases when the IESG can decide that such a documentation is not needed? I think that we should be clear on this respect.
      2. Section 5.5 should mention MIB browsers used to test MIB modules. I believe that this is important because testing by means of generic SNMP clients (MIB browsers) that different agents implementations return the same set of values for objects when running in similar conditions is the common practice for implementation reports of documents that define MIB modules. Examples may be the agents implementations of RMON (RFC 2819) and RMON-2 (RFC 4502)
      3. Section 5.6:
      "Optional features need not be shown to be implemented everywhere. However, they do need to be implemented somewhere, and more than one independent implementation is required. If an optional feature does not meet this requirement, the implementation report must say so and explain why the feature must be kept anyway versus being evidence of a poor-quality standard."
      This seems to be in conflict with RFC 2026:
      The requirement for at least two independent and interoperable implementations applies to all of the options and features of the specification. In cases in which one or more options or features have not been demonstrated in at least two interoperable implementations, the specification may advance to the Draft Standard level only if those options or features are removed."
      Is this relaxation intentional? If it is than I believe that this should be called explicitly in this document and also documented by an IESG note in the respective approved Draft Standard RFC.
      Comment [2009-07-01]:
      1. Section 3 - Format
      "The format of implementation and interoperability reports MUST be ASCII text with line-breaks for readability."
      This is slightly inconsistent with the recommendation for formating text in the Internet-Drafts at http://www.ietf.org/ietf/1id-guidelines.html
      "Internet-Drafts must be in ASCII. No 8-bit characters are currently allowed.
      If you need to include code points, a suggestion might be to use the unicode convention: U+XXXX, where X is a hexadecimal digit"
      2. s/Author Identify the author of the report/Author: Identify the author of the report/

    Telechat:

  2. Nominating Committee Process: Earlier Announcement of Open Positions and Solicitation of Volunteers (BCP)
    draft-dawkins-nomcom-dont-wait-03
    Token: Russ Housley
    Extracted from Balloting:
    1. Ralph Droms: Discuss [2009-07-01]: Minor point but I think it should be fixed prior to publication.
      The doc should specify when the IETF Secretariat issues the announcement and solicitation.
      The doc should specify that the Secretariat collects the responses and delivers them to the incoming NomCom chair.
      Comment [2009-07-01]: I suggest adding the ISOC President to the outgoing NomCom chair as someone who can kick off "other clerical tasks". The ISOC President is likely to be more aware of the schedule for naming the incoming NomCom chair and of the need to get those other clerical tasks started.
    2. Cullen Jennings: Comment [2009-06-30]: I see no evidence of consensus for this document during IETF LC.

    Telechat:

2.2.2 Returning Items

  1. (none)

3 Document Actions

3.1 WG Submissions

3.1.1 New Items

  1. GEOPRIV Layer 7 Location Configuration Protocol; Problem Statement and Requirements (Informational)
    draft-ietf-geopriv-l7-lcp-ps-09
    Token: Cullen Jennings
    Extracted from Balloting:
    1. Alexey Melnikov: Comment [2009-06-25]:
      In Section 6:
      "The following requirements and assumptions have been identified: Requirement L7-1: Identifier Choice
      "The L7 LCP MUST be able to carry different identifiers or MUST define an identifier that is mandatory to implement."
      Did you mean "identifier type" here?
      Regarding the latter aspect, such an identifier is only appropriate if it is from the same realm as the one for which the location information service maintains identifier to location mapping.
    2. Dan Romascanu:Discuss [2009-07-01]:
      1. Since this document was written IEEE 802.1AB was approved and deployed. I suggest the following change in Section 5:
      OLD:
      Switch/Port Number:
      "This identifier is available only in certain networks, such as enterprise networks, typically available via proprietary protocols like CDP or, in the future, 802.1ab."
      NEW:
      Ethernet Switch (Bridge)/Port Number:
      "This identifier is available only in certain networks, such asenterprise networks, typically available via the IEEE 802.1AB protocol [xx] or proprietary protocols like the Cisco Discovery Protocol (CDP) [yy]"
      Adding informative references would also be nice for IEEE 802.1AB and CDP would also be useful.
      [xx] IEEE 802.1AB-2005 IEEE Standard for Local and Metropolitan Area Networks Station and Media Access Control Connectivity Discovery - http://standards.ieee.org/getieee802/download/802.1AB-2005.pdf
      Somebody should be able to provide a reference to CDP.
      2. The four requirements in the Security Considerations section deserve to be written with 2119 capitalized MUST.
      Comment [2009-07-01]: There are plenty of acronyms not expanded at the first occurence: USB, DSL, PPoE, etc.
    3. Robert Sparks: Comment [2009-07-01]: There are some typo/grammar issues with the Note blocks added to the start of Sections 4 and 5 that need to be corrected before publication.

    Telechat:

  2. An Architecture for Multi-Segment Pseudowire Emulation Edge-to-Edge (Informational)
    draft-ietf-pwe3-ms-pw-arch-06
    Token: Ralph Droms; Note: David Sinicrope (david.sinicrope@ericsson.com) is the Document Shepherd for this document
    Extracted from Balloting:
    1. Lars Eggert: Comment [2009-07-01]: Section 11., paragraph 2:
      "Editors note: Add reference to draft-ietf-pwe3-congestion-frmwk-01.txt, or its successor, prior to publication."
      This should be added now, I guess.
    2. Adrian Farrel: Discuss [2009-07-02]: I appreciate the work that has gone into this document, but I believe it needs some more polish.
      Section 1.1
      It is not clear to me that the first motivation (which seems the most realistic of the motivations) naturally leads to multisegment PWs when the PSN tunnels can themselves be aggregated and tunneled using standard features of MPLS-TE.
      The other motivations require some form of planning/routing decisions in what we might call the PW layer. These techniques do not yet exist and would need to be invented and developed. However, inter-domain MPLS-TE already exists and is proven in deployments. Why would you not continue to use single segment PWs while making the multi-domain and aggregation decisions within the MPLS-TE LSPs?
      (The same argument applies to IP-in-IP tunnelling.)
      The only argument I can see in favor of your technique to address these motivations is that you can support different PSN tunneling techniques in different domains. Obviously, this does not apply for the first of your three motivations as there is only one domain. In the other two cases, I suggest that the arrangement in figure 2 would normally allow tunnelling of the access technology tunnels over the core technology tunnel. That leaves only the case of peer domains with different tunnelling technologies.
      You seem to be inventing a lot or architecture for a small set of deployments
      I am concerned that you are not separating two distinct cases. Where the PSN technology is the same, and the PW encapsulation is the same, you are truly switching. You have just two layers to worry about.
      Where the PSN technology chnages and there is a change in encapsulation there is a bigger question. You are not switching PW segments, but you are ending one encapsulation and begining a new one. This is the "translation" you describe in Section 3.2. Translation or gateway functions are neither elegant nor scalable with an increase in tunneling technologies, and I note that you have hidden/ignored this problem in Figure 7.
      Architecturally, there are only two ways to handle this:
      1. You emerge from the first encapsulation into the client (i.e. payload) layer, swtich in that layer, and re-encapsulate for the next PW segment. I suspect you don;t want to do this as it requires you to install L2-capable switching equipment at the switching points.
      2. You insert a thin transport-agnostic PW layer between the client layer and the PW encapsulation layer.
      Section 1.3
      It seems that the terminology is tied in some knots! An S-PE would be the perfect term except that in motivation 1 you have stitching within a domain, and in motivation 2 you may be stitching at ABRs (which are not PEs). So, in the middle of the terminology section you use "PW Switching Point" without any definition. Indeed, the convolutions are such that you have...
      "A S-PE can exist anywhere where a PW must be processed or policy applied. It is therefore not limited to the edge of a provider network."
      That is: "A provider edge is not limited to the edge of a provider network." Clearly a problem!
      You need to introduce the term "PW Switching Point" and recast the whole document in terms of PW Switching Points and not S-PEs.
      Section 3 is very important. It is good to see that you have made the architectural separation between the PW layer and the PSN layer. You introduce a concept "The design of PW routing domains..." which is very significant, but you don't discuss it at all in the rest of the document (you vaguely touch on it in Section 9.1). Since you have introduced the concept of a PW routing domain, you must discuss its architecture and operation.
      Saying in Section 3.1 that:
      "The selection of which set of S-PEs to use to reach a given T-PE is considered to be within the scope of MS-PW solutions."
      ...is dodging the issue too much. In an architecture you must say what functions you require for operation and on parameters you expect these functions to act.
      Tucked away in the text of Section 3 is an assumption that IP reachability and tunnel reachability (e.g. MPLS-TE reachability) are synonymous. They are not.
      An "interesting" wrinkle. In RFC 3985, the PW segment is considered to run from the input interface of the ingress PE to the output interface of the egress PE. This clearly continues to apply for the T-PEs, but it is not clear in your figures what happens at S-PEs. For example, in Figure 4, it is unclear where the PW segments start and end. Obviously, this is intended to be at "the switcing point" but you don't make this clear, and extrapolation from 3985 would lead someone to assume that the first segment ended at the outgoing interface of the first S-PE.
      Section 6 says
      "Where the encapsulation format is different e.g. MPLS and L2TPv3, the payload encapsulation may be transparently translated at the S-PE.A
      But 8.2 says that an S-PE may introduce fragmentation. This is good, but is not a transparent translation of encapsulation.
      Section 9.1 is confused about "dynamically chosen" and "signaled".
      Possibly,
      "For the signaled case, there are two options for selecting the path of the MS-PW:"
      should read
      "For the case of dynamic choice of PW switching points, there are twooptions for selecting the path of the MS-PW:"
      In Section 9.2
      "Since a multi-segment PW consists of a number of concatenated PW segments, the emulated service can only be considered as being up when all of the constituting PW segments and PSN tunnels (if used) are functional and operational along the entire path of the MS-PW."
      I think this is the first time you have suggested that PSN tunnels might not be used.
      Comment [2009-07-02]:
      Introduction
      "The PW passes through a maximum of one PSN tunnel between the originating and terminating PEs."
      I'm not sure that this limitation is made in RFC 3985. I don't believe that there is anything that prohibits LSP stitching to make a "multi-segment LSP tunnel" that carries a single segment PW.
      Section 1.1
      You suggest that the solution helps to reduce the scaling issues at PEs and P nodes. But doesn't the stitching PE have a signficant scaling problem?
      Section 2
      "As well as supporting traditional L2VPNs, an MS-PW is applicable to providing connectivity within a transport network based on packet switching technology e.g. MPLS Transport profile (MPLS-TP) [6]."
      s/within/across/
      I don't think [6] is the best reference for MPLS-TP. You would do better to point at draft-ietf-mpls-tp-requirements and draft-ietf-mpls-tp-framework
      Section 4
      s/may/might/ !!!
      But this is an odd thing to say. Why do you require the S-PEs to be reciprocal, but not the tunnels? Are you sure your architecture is not being driven by your solutions?
      Section 9.2
      "RFC 3985 describes the need for failure and other status notification mechanisms for PWs. These considerations also apply to multi-segment pseudowires. In addition, if a failure notification mechanism is provided for consecutive segments of the same PW, the S-PE must be able to propagate such notifications between the consecutive concatenated segments.
      This looks like a requirement hiding in the wrong document! Is it?
      idnits says "** You're using the IETF Trust Provisions Section 6.b License Noticefrom 10 Nov 2008 rather than the newer Notice from 12 Feb 2009, which is required now. (See http://trustee.ietf.org/license-info/)"
      === Nits
      Abstract
      s/same providers PSN/same provider's PSN/
      Section 8.1
      Expand NSP on first use.
      Section 11
      "Editors note: Add reference to draft-ietf-pwe3-congestion-frmwk-01.txt, or its successor, prior to publication."
      Ready to be fixed now?
      Section 11
      s/However, this may not effective/However, this may not be effective/
      I would prefer the references section to be named "Normative References if they really are all normative.
      Your references are out of date.
    3. Tim Polk: Discuss [2009-07-02]: The authors proposed some text changes to resolve issues raised by Tom Yu's secdir review, but a new draft has not been submitted and they are not in an RFC Editor Note.
    4. Dan Romascanu: Comment [2009-07-01]: Section 10 - 'Management and Monitoring'
      "The management and monitoring as described in RFC 3985 applies here."
      Section 10 in RFC 3985 includes a MIB module layering relationship diagram (Figure 12). I am wondering whether the new M-S Peudowire and the respective emulated services defined in this document do not lead to the need of new MIB modules to be identified, added to this diagram, aa part if the management framework that complements the framework described by the document.

    Telechat:

  3. Framework for PCE-Based Inter-Layer MPLS and GMPLS Traffic Engineering (Informational)
    draft-ietf-pce-inter-layer-frwk-10
    Token: Ross Callon
    Extracted from Balloting:
    1. Ralph Droms: Comment [2009-07-01]:
      Section 2 - expand "TE" on first use.
      Section 4.2.3 - expand "NMS" on first use.

    Telechat:

  4. Remote Triggered Black Hole filtering with uRPF (Informational)
    draft-ietf-opsec-blackhole-urpf-04
    Token: Ron Bonica; Was deferred by Lars Eggert on 2009-06-16
    Extracted from Balloting:
    1. Ralph Droms: Comment [2009-06-16]:
      In the first line of the next to last paragraph of the Introduction:
      "By coupling unicast reverse path forwarding (RPF) [RFC3704]"
      I suggest s/RPF/uRPF/, as "uRPF" is the acronym used throughout this doc, although RPF is used in RFC 3704.
    2. Lars Eggert: Comment [2009-06-16]:
      Section 3.2., paragraph 4:
      "Step 1. Select your Discard Address schema. An address is chosen to become the "discard address". This is often chosen from 192.0.2.0/24 (TEST-NET [RFC3330]), or from RFC 1918 [RFC1918] space."
      Given that both RFC1918 and RFC3330 address space comes with the note that "addresses in this block should not be used on the public Internet", it may make sense to at least also mention if not recommend the option of using a chunk of the operator's assigned public address space for this purpose.
    3. Adrian Farrel: Comment [2009-07-02]: I was looking in the Security Section for something about the risk associated with source-based RTBH announcements received from customers.
      Giving up, I paged up and found immediately above...
      "As a matter of policy, operators SHOULD NOT accept source-based RTBH announcements from their peers or customers, they should only be installed by local or attack management systems within their administrative domain."
      Would it be possible either to echo this in the Security section, or provide the reason in the previous section?
    4. Cullen Jennings: Comment [2009-06-30]: I'm not real keen on using 1918 private address space for this. It is hard enough to debug when private address leak into public space and this will just make it even more confusing. Could we just allocate a /24 for this?

    Telechat:

  5. Profile for Datagram Congestion Control Protocol (DCCP) Congestion ID 4: TCP-Friendly Rate Control for Small Packets (TFRC-SP) (Experimental)
    draft-ietf-dccp-ccid4-04
    Token: Lars Eggert; Note: Document Shepherd: Pasi Sarolahti (pasi.sarolahti@iki.fi) [was Gorry Fairhurst, but he's not a DCCP chair anymore]
    Extracted from Balloting:
    1. Adrian Farrel: Discuss [2009-07-02]: I'm confused by the IANA allocation.
      The registry shows that the value 4 is available for IETF Consensus allocation, so this could be OK.
      However, the registry also shows 284-254 for Experimental use.
      Since this experiment "is not proposed for widespread deployment in the global Internet at this time" I would like to know that the choice of 4 rather than 284-254 is deliberate and with a purpose.

    Telechat:

  6. New ASN.1 Modules for CMS and S/MIME (Informational)
    draft-ietf-smime-new-asn1-05
    Token: Tim Polk; Note: Sean Turner (turners@ieca.com) is the document shepherd
    Extracted from Balloting:
    1. Cullen Jennings: Discuss [2009-06-30]: This is a DISCUSS just because I want to talk about this on the call, not because I think something needs to change in the draft. It is largely a meta issue about code fragments.
      Do all the authors of the code fragments grant us permission to publish them under the BSD?
      PS - I fully support gathering these all and updating to latest syntax.
    2. Robert Sparks: Discuss [2009-07-01]:
      1) (For discussion on the telechat) Will publishing this as Informational lead to downref problems in the future? Would there be problems with publishing it as PS?
      2) The Updates meta-data (what appears as an Updates line in the upper left information block) should be filled out. The proto writeup says updates/obsoletes - is anything actually being obsoleted?

    Telechat:

  7. Security Threats and Security Requirements for the Access Node Control Protocol (ANCP) (Informational)
    draft-ietf-ancp-security-threats-07
    Token: Ralph Droms; Note: Matthew Bocci (matthew.bocci@alcatel-lucent.com) is the document shepherd
    Extracted from Balloting:
    1. Tim Polk: Comment [2009-07-02]:
      In section 3, first paragraph after the list of components:
      "The threat model and the security requirments in this draft consider this later case."
      s/later/latter/
      In section 4, the document identifies three classes of attacks, but bullet three seems to identify two overlapping classes:
      "attacks to gain profit for the attacker (e.g., by modifying the QoS settings). Also, through replaying old packets, of another privileged client for instance, an attacker can attempt to configure a better QoS profile on its own DSL line increasing its own benefit."
      This is fine if there are no attacks that gain profit which do not involve modifying the QoS settings. Are the authors confident that there are 3 rather than 4 classes?
    2. Dan Romascanu: Discuss [2009-07-02]: The threat analysis and the resulting requirements do not cover any manageability aspects (I am not including AAA here). However the ANCP framework and WG charter include a MIB module, which can create by itself diclosure and mis-configuration related threats if the management channeld are not secured properly. I would expect the analysis to take this into consideration, and resulting requirements related to configuring and monitoring ANCP by management protocols to be added.

    Telechat:

  8. Quick-Start for Datagram Congestion Control Protocol (DCCP) (Experimental)
    draft-ietf-dccp-quickstart-05
    Token: Lars Eggert; Note: Document shepherd is Pasi Sarolahti <pasi.sarolahti@iki.fi>
    Extracted from Balloting:
    1. (none)

    Telechat:

  9. Traceable Anonymous Certificate (Experimental)
    draft-ietf-pkix-tac-04
    Token: Tim Polk
    Extracted from Balloting:
    1. Adrian Farrel: Comment [2009-07-02]: I'm pleased to see Experimental status being used for this work.
      The only thing I might ask you think about is some descriprition of the scope of the Experiment and a note on whether there is a plan to return at some point (if the results are favorable) to do further work.

    Telechat:

3.1.2 Returning Items

  1. (none)

3.2 Individual Submissions via AD

3.2.1 New Items

  1. Comcast's ISP Experiences In a P4P Technical Trial (Informational)
    draft-livingood-woundy-p4p-experiences-10
    Token: Lisa Dusseault
    Extracted from Balloting:
    1. Tim Polk: Discuss [2009-07-01]: The security considerations section of this document reads as follows:
      "7. Security Considerations There are no security considerations in this document. NOTE TO RFC EDITOR: PLEASE REMOVE THIS NULL SECTION PRIOR TO PUBLICATION."
      As noted in Scott Kelly's security directorate review, this is inconsistent with current guidelines and is probably inappropriate for the content. I would like the authors to review Scott's comments and the guidelines in 3552, and either develop a security considerations section covering their proposed approach or offer a convincing argument why such a section is not needed.
    2. Dan Romascanu: Comment [2009-07-02]: I support Tim's DISCUSS. I think that RFC 2223 requires all RFCs to have a Security Considerations sections. If security content is null for this document it should explain why.

    Telechat:

3.2.2 Returning Items

  1. (none)

3.3 Independent Submissions via RFC Editor

3.3.1 New Items

  1. (none)

3.3.2 Returning Items

  1. Mobile IPv6 Location Privacy Solutions (Experimental)
    draft-irtf-mobopts-location-privacy-solutions-15
    Token: Jari Arkko
    Extracted from Balloting:
    1. Lisa Dusseault: Discuss [2009-06-15]: I'd like to understand more about this recommendation. Did the RG already consider experimental codepoints? Is the RG they receptive to changing them? Are these codepoints really rare?
      This DISCUSS is just to talk about the specific recommendation the IESG will make to the RFC Editor.
    2. Pasi Eronen: Comment [2009-06-17]: Couple of technical comments that are not relevant for the RFC 3932 check, but may be useful for the RFC Editor and/or the authors:
      - It looks like pseudo home addresses won't work as-is when IPsec is used to protect Mobile IPv6 signalling (it looks like they assume Mobile IPv6 part modifies the IPsec Security Policy Database on-the-fly in some unspecified fashion).
      - Pseudo home addresses also seems to introduce a rather big change to Mobile IP: the home agent has to intercept and modify some reverse-tunneled payload packets between the MN and CN (at least HoTI). Currently, these are just normal payload traffic (since the Home Agent is not listed in the "Destination Address" field, it just forwards them without doing any processing). This seems like an ugly layer violation: if the MN has a Mobile IPv6 signalling packet it wants the HA to process somehow, it should put the HA in the "Destination Address" field instead of relying the HA to perform deep packet inspection and "intercept" them.
      - Despite the claim in Section 11, most of this stuff probably doesn't work DSMIPv6 because DSMIPv6 cannot use tunnel mode IPsec to protect binding updates to home agents (when using IPv4 CoA at least).
    3. Tim Polk: Comment [2009-07-02]: (Moving to NoObj)
      Section 5.1
      If I understand correctly, the encrypted home address is generated by the mobile node and accepted without re-computation by the home agent. If this is correct, there is no way to enforce use of a particular encryption algorithm (or even verify it was used...) In this case, the text describing AES as the "default" algorithm should be replaced with text recommending the use of AES, and 8.1 in security considerations should get some text explaining why it would be bad for the mobile node to select a weak algorithm.
      If I am wrong, and the home agent (or any other participant) also computes the encrypted home address we have a different problem. To have crypto agility we need a mechanism to communicate which symmetric algorithm is in use, and I didn't see any evidence of that in the new messages/payloads.
      Also in section 5.1, in the third message: should destination be "home agent" instead of "home address"?

    Telechat:

1314 EDT break

1321 EDT back

4 Working Group Actions

4.1 WG Creation

4.1.1 Proposed for IETF Review

  1. (none)

4.1.2 Proposed for Approval

  1. STORage Maintenance (storm)
    Token: Lars

    Telechat:

4.2 WG Rechartering

4.2.1 Under evaluation for IETF Review

  1. Behavior Engineering for Hindrance Avoidance (behave)
    Token: Magnus

    Telechat:

  2. IP Flow Information Export (ipfix)
    Token: Dan

    Telechat:

  3. DNS Extensions (dnsext)
    Token: Ralph

    Telechat:

4.2.2 Proposed for Approval

  1. Site Multihoming by IPv6 Intermediation (shim6)
    Token: Jari

    Telechat:

  2. Diameter Maintenance and Extensions (dime)
    Token: Dan

    Telechat:

  3. Integrated Security Model for SNMP (isms)
    Token: Pasi

    Telechat:

5. IAB News We can use

  1. Dave: not much, still working on uncoordinated-harmful; back-and-forth on RFCed, advisory committee announced, cancelling 8 and 22 July telechats
  2. Ross: on considered-harmful, what is problem of acknowledgment section
  3. Dave: got some heat, tried to reduce it by backing out; we can't include their input without acknowledgment; not sure what we'll do
  4. Magnus: think main issue is rights to use text, not "acknowledgment"
  5. Ross: perhaps something saying OK to use my text but please don't list
  6. Dave: expecting them to remain in acknowledgment section with disclaimer about supporting document

6. Management Issues

  1. Referencing RFCs from ITU-T Recommendations. (Adrian Farrel)

    Telechat:

  2. Liaison to Zigbee Alliance (Adrian Farrel)

    Telechat:

7. Agenda Working Group News

1352 EDT Adjourned