IESG Narrative Minutes

Narrative Minutes of the IESG Teleconference on 2011-03-17. These are not an official record of the meeting.

Narrative scribe: Barry Leiba and John Leslie (The scribe was sometimes uncertain who was speaking.)

Corrections from:

1 Administrivia

1. Roll Call 1135 EDT Amy:
   • Jari Arkko--- (late)
   • Ron Bonica--- y
   • Stewart Bryant--- y
   • Gonzalo Camarillo--- regrets
   • Michelle Cotton--- y
   • Ralph Droms--- y
   • Linda Dunbar--- n
   • Wesley Eddy--- (late)
   • Lars Eggert--- regrets
   • Adrian Farrel--- regrets
   • Stephen Farrell--- y
   • Sandy Ginoza--- y
   • Susan Hares--- n
   • David Harrington--- y
   • Russ Housley--- y
   • Olaf Kolkman--- regrets
   • Barry Leiba--- scribe
   • John Leslie--- scribe
   • Alexey Melnikov--- y
   • Cindy Morgan--- y
   • Ray Pelletier--- regrets
   • Pete Resnick--- y
   • Tim Polk--- y
   • Dan Romascanu--- y
   • Peter Saint-Andre--- y
   • Robert Sparks--- y
   • Hannes Tschofenig--- y
   • Sean Turner--- y
   • Amy Vezza--- y
2. Bash the Agenda
   • Barry: Notes that he can't scribe the Sunday morning meeting in Prague; will be there by noon.
3. Approval of the Minutes of the past telechat
   • March 3 minutes--- no objection, approved
   • March 3 narrative minutes--- no objection, approved
4. Review of Action Items from last Telechat
   • Jari Arkko to add guidance on multi-Area work to the wiki.
     (absent)
   • Tim Polk to draft text for the wiki regarding Last Call processes that include IPR.
     In progress.
   • Adrian Farrel and Stewart Bryant to review the -bis draft for RFC 4020 Allocation procedures.
     In progress.
   • Alexey Melnikov and Michelle Cotton to follow up with Larry Masinter regarding the tracking of pending media type/charset/URI registrations.
     Michelle: In progress; will discuss with a group in Prague.
   • Ralph Droms to generate a liaison from the IESG to IEEE 802.1 on the TRILL working group recharter.
     Done.

2. Protocol Actions

2.1 WG Submissions

2.1.1 New Items

1. Use of the Content-Disposition Header Field in the Hypertext Transfer Protocol (HTTP) (Proposed Standard)
   draft-ietf-httpbis-content-disp-08
   Token: Alexey Melnikov
   Note: Mark Nottingham (HTTPBIS chair) is the document shepherd
   Discusses/comments (from ballot 3648):
   1. Stewart Bryant: Discuss [2011-03-14]:
      "When the value contains path separator characters ("\" or "/"), recipients SHOULD ignore all but the last path segment. This prevents unintentional overwriting of well-known file system locations (such as "/etc/passwd")."
      ... or even intentionally over writing it - depending on your perspective.
      I spent a little time puzzling over the /etc/passwd case. Since /etc/ looked like the last path segment. However I think that you mean that the file will be stored in "some-default-directory-but-not-slash/etc/passwd". It would be useful to clarify this in the text with an example.
      Why is this a SHOULD and not a MUST given the security implications?
      Surely the security section (or 4.3) needs to discuss file permissions as well as well known extension types.
   2. Stewart Bryant: Comment [2011-03-14]:
      "RFC 2616 defines the Content-Disposition response header field"
      I think that you need to say the Content-Disposition response header field of what. Same for Intro.
   3. Adrian Farrel: Comment [2011-03-16]:
      I have no objection to the publication of this document. There are a couple of small points that I think would benefit from attention first.
      Section 2 says that BNF from RFC 2616 is used. Section 3 metnions "ABNF". Is this the same (in which case please use consistent terminology) or different (in which case please supply a reference for ABNF).
      (See also Peter's Discuss
      Section 4.3 contains a number of bullets. The first one uses RFC 2119 language to specify behavior, but the remaining bullets use apple-pie language. Do you need to upgrade all bullets to RFC 2119?
   4. David Harrington: Discuss [2011-03-14]:
      1) is this document meant to update or obsolete 2183 (or not)? Per appendix B, this document omits parameters specified in 2183. Is this meant to obsolete those parameters?
      2) "This specification is expected to replace the definition of Content-Disposition in the HTTP/1.1 specification, as currently revised by the IETF HTTPbis working group."
      Does this document obsolete/update the I-Ds being produced by httpbis? If so, which drafts?
      3) Does the grammar in 4.1 allow both filename and filename* to be specified?
      4) I think the statement
      "Senders MUST NOT generate Content-Disposition header fields that are invalid."
      should include a pointer to the specific rules about what is invalid.
   5. David Harrington: Comment [2011-03-14]:
      1) I agree with Stewart's DISCUSS. I found the discussion of the last segment of the filename to be confusing.
      2) I agree with Stewart's concern about some additional security considerations that are not documented.
   6. Alexey Melnikov: Comment [2011-03-16]:
      In answer to David's DISCUSS:
      1) This document doesn't need to update or obsolete RFC 2183, because RFC 2183 specifies Content-Disposition header field for email only. This draft is a standalone version for HTTP.
      2) This document is not obsoleting/updating any other HTTPBIS WG I-D.
      3) Yes, both filename and filename* are allowed. That is intentional (for backward compatibility)
      4) The editor answered this, but there was a small edit in the document to add the cross reference.
   7. Dan Romascanu: Comment [2011-03-14]:
      Why would Appendix C4 be removed at publication? I believe that it actually includes important information about the status of the implementations, and clarifies the reasons of some of the choices made by editors and the WG.
   8. Robert Sparks: Comment [2011-03-14]:
      Consider adding "At the time of publication of this document, " to the front of the sentence starting with the purl.org URL at the end of Appendix D. Using a tool like purl.org helps make it easier to manage moving content around, but won't guarantee that that the content isn't a dangling reference or that it contains relative content in 20 years.
   9. Sean Turner: Discuss [2011-03-17]:
      #1) Sec 3.1 contains the following: "Recipients MAY take steps to recover a usable field-value from an invalid header field, but SHOULD NOT reject the message outright, unless this is explicitly desirable behaviour (e.g., the implementation is a validator). As such, the default handling of invalid fields is to ignore them."
      What's the default requirement? It needs to be reworded as follows: "As such, implementations SHOULD ignore invalid field by default."
      #2) Sec 4.3 contains the following: "Thus, recipients SHOULD ensure that a file extension is used that is safe, optimally matching the media type of the received payload."
      Why isn't this MUST. An implementation that doesn't do this is then vulnerable to the attacks you just described. Under what circumstances is this a good idea?
      #3) Sec 4.1 contains the following: "Header field values with multiple instances of the same parameter name are invalid."
      Is this a new requirement on HTTP headers or is this true of all HTTP headers?
      #4) Appendix D: Need normative reference for US-ASCII.
   10. Sean Turner: Comment [2011-03-17]:
       #1) Sec 4.1 contains the following phrase: "Furthermore note that the format used for ext-value allows specifying a natural language;"
       It would greatly help to include an "natural language (e.g., <insert text here>);"
       #2) Sec 4.3 contains the following phrase: "... a natural language ..."
       Could you provide and (e.g., <fill in the blank for me>). I didn't parse what this was.
       #3) Sec 8.2: Should the registration template include: "Related information: none"
       #4) App C.4 contains a table listing browsers, without version #s this table isn't of much use it - or is it all version?
       #5) App D contains the following: "[[fallbackbug: Firefox is known to pick the wrong parameter; a bug fix is scheduled for Firefox 5. --jre]]"
       Is this supposed to be removed?

   Telechat:

   • Alexey: Stewart, have you checked the latest version? Are you happy with it?
   • Stewart: I will check it, but I will also change my discuss to a comment. I'm happy with the discussion with the authors.
   • Alexey: David, I think you should clear. The first two are non-issues, and the last has been dealt with. Will you please check?
   • Dave: I will check.
   • Alexey: Sean, a couple of issues...
   • Sean: What's the default behaviour? If the default is that the UA should try to recover, why not make the first MAY a SHOULD?
   • Alexey: I need to check with julian. I think the default is "should ignore", but servers are sending non-compliant stuff. Maybe we can discuss by email or in Prague. I think your proposed change for number 1 is OK, but I need to talk with Julian.
   • Sean: I've been exchanging email, but haven't proposed this to him yet.
   • Alexey: On the second point, the major outcome of the email discussion is that not every OS and client are using file extensions. How do we rephrase this? Can do it saying "if you are using file extensions, you MUST do this."
   • Sean: I like that.
   • Alexey: I'll add an RFC-ed note and ping you. Last point, number 3... I believe that this should be done in a document revising 2616, and this document is only making statements specific to this topic. I don't think making a general statement in this doc about all headers is right. What is the best way forward?
   • Sean: If we put something in here, you're right, it's an odd way. I think I will relent on this.
   • Alexey: I'm happy to open a tracking item in HTTPbis on this.
   • Peter StA:: [missed it]
   • Sean: If you added an introductory phrase, that would clear that up.
   • Alexey: You want... the same content-disposition parameter name?
   • Sean: Yes, that would address it.
   • Alexey: I'll do that. We'll take the first one to email, and I'll enter notes for the other two. I will try to do them all with notes, so... AD follow-up.

2. Protocol for Access Node Control Mechanism in Broadband Networks (Proposed Standard)
   draft-ietf-ancp-protocol-15
   Token: Ralph Droms
   Note: Matthew Bocci (matthew.bocci@alcatel-lucent.com) is the document shepherd.
   IPR: Deutsche Telekom AG's Statement about IPR related to draft-ietf-ancp-framework-08 and draft-ietf-ancp-protocol-05
   Discusses/comments (from ballot 3711):
   1. Adrian Farrel: Discuss [2011-03-16]:
      I have two issues related to version numbering that I would like to Discuss. Additionally, if time permits, I intend to return with a more in depth review of the protocol
      I am trying to work out how ANCP will co-exist with GSMP. It seems they both use the same port (6068) so I assume disambiguation happens on version number negotiation. But...
      A GSMP version number is an 8 bit number, with 0x03 being the current version. Since the GSMP version number is not currently tracked by IANA, there is a risk that a future version of GSMP will decide that 0x32 (i.e., version 50) will be used.
      I strongly suggest, therefore, that you need a new registry for the "GSMP and ANCP version Numbers". This will need some careful words to indicate that GSMP version 4 is allowed. You will also want to track ANCP sub-versions (but see below).
      [This point relates to part of Alexey's Discuss]
      I am really not happy about the lengths that are being gone to to support pre-standard implementations. I think this document should at least state that version 3.1 is not allowed. That is, it should not allow downward version negotiation from 3.2. Furthermore, sub-version 1 should be shown in the IANA registry as "reserved - not available for allocation".
      Furthermore, I see no reason to require the RFC Editor to make the various changes you request with respect to the version numbering. You should make these changes now.
   2. Russ Housley: Comment [2011-03-15]:
      The Gen-ART Review by Ben Campbell on 9-Mar-2011 raised a few minor points. Tom Taylor responded; he seems to agree with some of them. However, the document has not been updated yet. Please do so before approval.
   3. Alexey Melnikov: Discuss [2011-03-15]:
      [Updated: added one more issue in the DISCUSS section (look at the end of it)]
      This is a well written document and I don't have objections to its publication. However I would like to discuss the following issues before recommending its approval:
      3.1. Protocol Version: "GSMPv3 messages contain an 8-bit protocol version field. As described below, ANCP subdivides this into two 4-bit sub-fields, for version and sub-version. Implementations of this version of the ANCP specification MUST set the version sub-field to 3 and the sub-version sub-field to 1. That is, the hexadecimal representation of the value of the complete protocol version field MUST be 0x31."
      What is the meaning and semantics of version and subversion? The document is not clear on why the separation into version and subversion is needed.
      3.2. ANCP Transport: "Identifier: This 2-byte field identifies a GSMP or ANCP message. The type code for GSMP and ANCP messages is 0x880C (i.e., the same as GSMP's Ethertype)."
      Is it wise to reuse the same identifier, considering the statement elsewhere in the document that the 2 protocols are not really compatible?
      "The NAS MUST listen for incoming connections from the Access Nodes. Port 6068 is used for TCP connection."
      Does this need to be listed in the IANA Considerations section?
      4.5. Status-Info TLV: "Error Message: Human-readable string providing information about the warning or error condition. Padded with zeroes as necessary to extend to a four-byte word boundary."
      Typically human readable strings need some language tagging information. Please see <http://trac.tools.ietf.org/group/iesg/trac/wiki/TypicalAppsAreaIssues> for more details.
      8.5.1. OAM-Loopback-Test-Parameters TLV: "Byte 2: Timeout. Upper bound on the time in seconds that the NAS will wait for a response from the DSLAM. The value 0 MAY be used, but has a special meaning."
      What is the special meaning of 0?
      10. Security Considerations: "Security of the ANCP protocol is discussed in [RFC5713]. A number of security requirements on ANCP are stated in Section 8 of that document. Those applicable to ANCP itself are listed here:\..."
      This section is a bit think on TLS-specific details. In particular it doesn't describe how these requirements can be achieved with TLS (Note that TLS client authentication to the TLS server is optional, so not every ciphersuite is suitable to satisfy these requirements).
   4. Alexey Melnikov: Comment [2011-03-14]:
      5.1.1. Control Context (Informative): "Aside from its use in ANCP signalling, access line identification is also used in DHCP transactions involving hosts served by DSL. Either the AN or the NAS can serve as a DHCP relay node. [TR-101] requires the AN or NAS in this role to add access line identification in Option 82 (Information) to each DHCP request it forwards to the DHCP server. It is desirable for efficiency that the identification used in this signalling should be the same as the identification used in ANCP messages."
      An informative reference to DHCP is needed here.
   5. Dan Romascanu: Discuss [2011-03-17]:
      In section 3.6.1.4: "In addition to any suggested action in the text which follows, the Code value SHOULD be logged in a MIB."
      If I was writing the MIB module and/or the instrumentation for MIB module I would not know what to do, What needs to be logged in a MIB module? (or MIB object? which of these?). The fact that the code value is supported? Each sending of a request? Each receive of a Request? Something else?
   6. Dan Romascanu: Comment [2011-03-17]:
      I support the DISCUSSes by Adrian and Alexey concerning the version number and the DISCUSS from Peter concerning the relationship with RFC 3292.
   7. Peter Saint-Andre: Discuss [2011-03-16]:
      The relationship between this specification and RFC 3292 is unclear and confusing.
      On the one hand, this document notes that modifies the GSMPv3 adjacency message format, the base GSMPv3 message format, the GSMPv3 Event message format, and the Port Management message format; therefore it appears to update RFC 3292. However, the specification does not indicate that it updates RFC 3292.
      On the other hand, this document points implementers to Sections 3.1.1, 9, and 11 of RFC 3292 for aspects of the protocol, thus introducing a normative dependency on parts of RFC 3292 while at the same time it updates other parts; why not simply copy the relevant text to this specification so that all the documentation is in one place, thus enabling us to remove the normative dependency on RFC 3292?
   8. Peter Saint-Andre: Comment [2011-03-16]:
      I concur with the DISCUSSes posted by Adrian Farrel and Alexey Melnikov.
   9. Robert Sparks: Discuss [2011-03-16]:
      Allowing ACNP agents to use any Code values from the (about to be modified) GSMPv3 Failure Response Message Name Space registry "if they appear applicable" seems underspecified. Could some guidance about when a code would NOT be applicable be added? Would an exhaustive list of applicability of the codes already registered (in the IETF Consensus ranges) be hard to produce? I take it from Tom's responses to some of the review comments that you do not expect GSMPv3 focused codes to be added to the registry, but if one ever were added (with a value below 256) that really was targeting GSMP and not ANCP, why not ask the registrant say so and capture it in the registry?
      Can the document explain when it might be reasonable to not follow the SHOULD in 3.6.1.7?
   10. Robert Sparks: Comment [2011-03-16]:
       I found the "must" convention distracting, and am skeptical of it's effectiveness as a way to communicate requirements to another SDO (which is what I understand its purpose to be based on the author's response to the genart review). If this remains in the document, please follow up and ensure it had the desired effect before trying the convention again.
       Section 3.6.1.6 speaks of incrementing transaction IDs linearly when I think it's really trying to say "by one". (If there's ever a chance of an intermediary being introduced in the path of these messages, it would help to say something now about whether recipients should care about gaps in the sequence they receive.)
   11. Sean Turner: Discuss [2011-03-17]:
       #1) DISCUSS-DISCUSS: I have to admit I'm completely out of my element here:
       If ANCP and GSMPv3 do kind of the same thing. Has there been thought to retiring GSMPv3? Are the two protocols going to gracefully co-exist?
       #2) Sec 10 includes security considerations from RFC 5713 with an informative reference. If these are the security considerations of ANCP aren't they normative? Unfortunately, RFC 5713 is informative and this would then be a DOWNREF.
   12. Sean Turner: Comment [2011-03-17]:
       #1) I support Alexey's discuss position on TLS.

   Telechat:

   • Ralph: I don't think we need to discuss now. They're all self-explanatory, and the authors have been actively discussing them. Biggest issue is entanglement with GSMPv3, and the authors have agreed to rewrite to separate it more from that protocol. As far as we can tell, that's never been deployed anywhere. They need to accommodate previous work on that, not spending time accommodating overlaps. I think they're all straightforward and understandable. Extensive rewrite, may have to go back to WG. Revised I-D needed.
   • Stewart: I notice there's an IPR statement, and that wasn't in the IETF last call.
   • Ralph: I will check that. The IPR statement is really not very helpful. I've asked for more insight, and have't heard back. I have to follow up on that as well.

3. A Profile for X.509 PKIX Resource Certificates (Proposed Standard)
   draft-ietf-sidr-res-certs-21
   Token: Stewart Bryant
   Note: Sandra Murphy (Sandra.Murphy@sparta.com) is the document shepherd.
   Discusses/comments (from ballot 3715):
   1. Ralph Droms: Comment [2011-03-15]:
      Minor editorial suggestion: In the Abstract, s/Resources (INRs)/Internet Number Resources (INRs)/
   2. Alexey Melnikov: Discuss [2011-03-17]:
      [Updated as per Sam Hartman's SecDir review discussion and a further discussion with Sam]
      This is a well written document and I generally support its publication.
      I was originally planning to file a DISCUSS on this issue, but though that the WG knows better. However Sam's SecDir review has changed my mind:
      Sam wrote: "I do not believe the concerns I raised in my secdir review have been addressed and I still have a deep architectural concern with the decision to prevent relying parties from accepting unknown non-critical extensions."
      There seems to be agreement with several points I raised:
      1) The profile does prohibit unknown extensions.
      2) I think there is agreement that before we can start using an error correction or new feature, we have to upgrade all software in the wild that might see the certificates.
      3) Everyone including me thinks that strong restrictions on what certificates are created is good for this profile. The question is what about restrictions on what people receive. If the IETF changes the standard in the future do we want to have to upgrade issuers and consumers or just issuers before we start using the new spec in what we issue.
      4) We may find ourself in a situation where we made a mistake or need to expand what the RPKI does.
      Adding from myself:
      I think there is no disagreement that extensions not listed in this profile SHOULD NOT (or even MUST NOT) be generated. However I think the WG is shooting itself in the foot by making receivers reject certificates with unrecognized non critical extensions. A much better architectural approach would be to say that such non critical extensions "MUST be ignored". This is a pretty standard trick in the Apps Area and allows for safe extensibility.
      I also have a small list of [nearly] nit-picking items which I think need to be addressed before it is approved for publication:
      4.9.6. CRL Distribution Points: "The CRL Distribution Points (CRLDP) extension identifies the location(s) of the CRL(s) associated with certificates issued by this Issuer. The RPKI uses the URI form of object identification."
      This needs a Normative reference to the URI RFC.
      "The sequence of distributionPoint values MUST contain only a single DistributionPoint. The DistributionPoint MAY contain more than one URI value. An RSYNC URI [RFC5781] MUST be present in the"
      This makes the reference Normative (and it is a DownRef).
   3. Alexey Melnikov: Discuss [2011-03-12]:
      This is a well written document and I generally support its publication. I do however have a small list of [nearly] nit-picking items which I think need to be addressed before it is approved for publication:
   4. Alexey Melnikov: Comment [2011-03-12]:
      4.4. Issuer: "The value of this field is a valid X.501 distinguished name."
      A reference to the document defining DNs is needed here. (One of the LDAP documents might do.)
      "An Issuer name MUST contain one instance of the Common Name attribute and MAY contain one instance of the Serial Number attribute. If both attributes are present, it is RECOMMENDED that they appear as a set. The Common Name attribute MUST be encoded as a printable string."
      Similarly, a reference for printable string is needed.
      4.9.8.1. SIA for CA Certificates: "The ordering of URIs in this accessDescription sequence reflect the CA's relative preferences for access methods to be used by RPs, with he first"
      s/he/the
      6.2.1. CRMF Resource Certificate Request Template Fields: "version: This field SHOULD be omitted. If present, it MUST specify a request for a Version 3 Certificate. It"
      Unfinished sentence?
   5. Tim Polk: Comment [2011-03-17]:
      I support Alexey's discuss-discuss: the upgrade path for sidr-res-certs is not typical for IETF publications. It would be good for the IESG to discuss the merits and drawbacks of the wg's consensus approach.
      However, I should note that I personally am comfortable with the approach based on the unique attributes of its intended deployment and application. Various aspects of this problem have been actively discussed since Stockholm.
   6. Peter Saint-Andre: Comment [2011-03-17]:
      Although I am provisionally balloting "No Objection" pending discussion within the IESG, I too am concerned about the issues raised in Alexey Melnikov's DISCUSS.
   7. Sean Turner: Comment [2011-03-10]:
      Need to add normative reference to RFC 2119 as per: http://www.rfc-editor.org/policy.html#policy.2119ref
      "Valid From" should be "Not Before" and "Valid To" should be "Not After" to match the name of fields in RFC 5280.

   Telechat:

   • Stewart: I don't think we need to discuss. Tim had been dealing with Alexey on this.
   • Alexey: Not yet. I think we should discuss it.
   • Tim: Res certs is an interesting problem. It's important to discuss because while I'm comfortable with where we've ended up, this is not the typical strategy for docs. Background: the idea was that for several reasons, SIDR was going to be supported by a PKI that was purpose,built to suppose the resource PKI and do nothing else. Small community, advantages to being very prescriptive about what can appear in the certs. They made the decision to be very tightly controlled. While they're profiling X.509, this is very different. Policy they have chosen imposes significant constraints. It says that if extensions are included in the cert that are not expressly permitted by the policy, it needs to be rejected.
   • Sean: Actually, any field.
   • Tim: There are some good reasons to do this, I think. One is that they want to be sure there's no bleed-over -- they want the RPKI to be used only for this, don't want other certs to be used here. Specific design decision. Also decided they could make a decision about rolling out a new feature. Design it, deploy it, use it. Not what you would usually do for interoperability. It's what the SIDR community agreed on. Various aspects of this have been debated for quite a while. I became convinced over time that it's acceptable.
   • Russ: The issuers of these certs, the RIRs, felt that a strict profile that limited their liability was desirable.
   • Sean: There's a small number of relying party sw applications that will be written, distributed, and accepted by people below the RIR level. When it's time to roll out a new ffeature... they're going to need a new policy OID.
   • Tim: The community is aware of this, and they've bought in.
   • Sean: They're actually quite close, and when this stuff doesn't work, people get out of bed to make it work. And they will test it and make sure it does work before they issue certs. So there is a path to do this. If there are errors in their certs, this will catch it.
   • Alexey: So you're saying it is realistic that all nodes will upgrade at the same time?
   • Russ: No, there'll be a clear transition period, just as with migration of algorithms. The same can be applied to any other profile change.
   • Peter StA:: My reading was that the spec currently says that if you get a non-critical extension you don't understand, you can ignore it, but when you're generating certs, you can't put in anything that's not in the profile. Your sw doesn't have to barf on things it doesn't understand.
   • Russ: The profile should be a description of "strict for what you send."
   • Alexey: I think "MAY be ignored" is a bit week. MUST would be better.
   • Peter StA:: Then you're not breaking on things.
   • Alexey: You don't know what MAY means in this case.
   • Peter StA:: I think MUST be ignored is better. Unless there's an attack here, where someone includes a non-critical extension that would cause problems if you didn't ignore it.
   • Stewart: The critical question is whether this approach addresses Alexey's concerns.
   • Alexey: I can't say that I'm very happy about this. Can I think about it for a week, and then either clear or move to some other state?
   • Stewart: If there's a way that's within the design philosophy of the WG, we want to do it.
   • Alexey: If you change "MAY ignore" to "MUST ignore", that will certainly help. I'm trying to figure out whether there's any point in trying to convince the WG, or I should give up.
   • Russ: I guess you need to think on that. Is there a reason to continue discussion now?
   • Alexey: No. I'll get back to Stewart next week.
   • Stewart: There are enough changes... should it go to point raised, or ID needed?
   • Alexey: They can't post a new version now. I have two nits in my discuss; can you do them as RFC-ed notes?
   • Russ: Let's put it in AD follow-up.
   • Stewart: Yes, they look small; I can work with the editors for text. We'll look at what you want to do with the other one.

4. Certificate Policy (CP) for the Resource PKI (RPKI (BCP)
   draft-ietf-sidr-cp-16
   Token: Stewart Bryant
   Note: Sandra Murphy (Sandra.Murphy@cobham.com ) is the document shepherd.
   Discusses/comments (from ballot 3716):
   1. Ralph Droms: Comment [2011-03-16]:
      A few nits:
      Abstract: s/Internet resource/Internet Number Resource/
      Introduction: s/Internet number resource/Internet Number Resource/
      In section 2.4, should this text use RFC 2119 terms: "This data is supposed to be accessible to the public."
      Why are sections 5.1.*, 5.2.* listed as sections with no text?
   2. Adrian Farrel: Comment [2011-03-17]:
      I have No Objection to the publication of this document, but there are a couple of nits I hope the authors will attend to before publication.
      Missing close parenthesis in the document title.
      In the Introduction... "Note: This document is based on the template specified in the Internet Engineering Task Force (IETF) standards document RFC 3647 [RFC3647]. In the interest of keeping the document as short as reasonable, a number of sections contained in the template are omitted from this policy because they did not apply to this PKI. However, we have retained the section numbering scheme employed in the RFC to facilitate comparison with the outline in Section 6 of the RFC. Each of these omitted sections should be read as "No stipulation" in CP/CPS parlance."
      In the interests of disambiguity (for example, once this document has been published as an RFC) could you please s/the RFC/RFC 3647/ both times it shows.
      1.5.4. CP approval procedures: "The IESG MUST approve a replacement BCP that either updates or obsoletes this BCP, following the procedures of the IETF Standards Process as defined in RFC 2026 [RFC2026]."
      This is a little amusing. But I think you actually mean... "Any BCP that either updates or obsoletes this BCP, MUST be approved by the IESG following the procedures of the IETF Standards Process as defined in RFC 2026 [RFC2026].
      3.1.2. Need for names to be meaningful: "The Subject name in each certificate SHOULD NOT be "meaningful", i.e., the name is NOT intended to convey the identity of the Subject to relying parties."
      While I understnd the desire for stress, I think s/NOT/not/
      3.1.3. Anonymity or pseudonymity of subscribers: "Although Subject (and Issuer) names need not be meaningful, and may appear "random," anonymity is not a function of this PKI, and thus no explicit support for this feature is provided."
      Unless there is some special meaning of "pseudonimity" in the security community, I would suggest dropping it from the section title. The section text does not discuss the use of pseudonyms, and (to me) the use of a pseudonym is destinct from annonymity.
      3.1.5: s/Subject names/subject names/ at least twice
   3. Russ Housley: Comment [2011-03-15]:
      Please consider the minor issues raised in the Gen-ART Review by Francis Dupont on 24-Feb-2011.
   4. Alexey Melnikov: Comment [2011-03-12]:
      4.10. Certificate status services: "This PKI does not make provision for use of OCSP or SCVP, because it"
      Informative references are needed here.
   5. Peter Saint-Andre: Comment [2011-03-16]:
      Please expand "SIA" on first use and provide a reference if necessary.
      In section 4.2.1, I suggest changing "SHOULD never" to "SHOULD NOT".

   Telechat:

   • Amy: No discusses.
   • Stewart: A bunch of edits needed. I'll see about notes, or whether I need a new I-D.
   • Amy: I'll put it in point raised, and Stewart can let us know when it's ready.

5. RPKI Objects issued by IANA (Proposed Standard)
   draft-ietf-sidr-iana-objects-01
   Token: Stewart Bryant
   Note: Chris Morrow (christopher.morrow@gmail.com) is the document shepherd.
   Discusses/comments (from ballot 3727):
   1. Jari Arkko: Discuss [2011-03-17]:
      Section 8 has a MUST (see below for more details) that is not fully specified. The document should make it clear who can make exceptions on making ROAs for multicast addresses.
   2. Jari Arkko: Comment [2011-03-17]:
      What kind of change/CRL/processing load is expected from certification of unallocated space at IANA, as that space keeps changing (in the case IPv6)?
      From Ari Keränen's review:
      8. Multicast: "IANA MUST NOT issue any ROAs (AS0 or otherwise) for any other multicast addresses unless directed."
      Directed by whom? Need to have, e.g., IESG Approval?
   3. Russ Housley: Comment [2011-03-16]:
      Please consider the comment from the Gen-ART Review by Wassim Haddad on 16-Mar-2011. I believe that improved clarity is desirable.
   4. Alexey Melnikov: Discuss [2011-03-17]:
      I am planning to ballot Yes on this document once my issues are discussed. I have a couple of discussion point for IESG which might or might result in some actions for editors.
      2) DISCUSS DISCUSS: 5. Reserved Resources: "Reserved IPv4 and IPv6 resources are held back for various reasons by IETF action. Generally such resources are not intended to be globally routed. An example of such a reservation is 127.0.0.0/8 [RFC5735]. IANA SHOULD issue an AS0 ROA for all reserved IPv4 and IPv6 resources not intended to be routed."
      Is IANA clear on where (in which RFCs) all such resources are described? The reference to [RFC5735] makes me think that it is only one example.
      "There are a small number of reserved resources which are intended to be routed, for example 192.88.99.0/24 [RFC3068]."
      As above.
   5. Alexey Melnikov: Comment [2011-03-17]:
      I feel much better about approving this document after reading draft-ietf-sidr-arch-12.txt. So I am moving my DISCUSS DISCUSS # 1 to the Comment section:
      1) DISCUSS DISCUSS: This document has lots of normative references to documents, some of which are not yet in IETF LC. I do feel that all of them actually need to be reviewed before approving this document, so I find it strange that this document is in IESG review first.
      I understand that I've done similar out-of-order IESG processing for some of my documents, so I don't claim to have a high moral ground here. However I would like to hear some explanation of why such exception is Ok in this case.
   6. Dan Romascanu: Comment [2011-03-16]:
      I support Alexey's DISCUSS and I have one supplementary question concerning the following paragraph in Section 5:
      "IANA SHOULD issue an AS0 ROA for all reserved IPv4 and IPv6 resources not intended to be routed."
      Why is this a should? Why not a MUST? If there are exceptions does IANA know and understand all cases when they apply?
   7. Robert Sparks: Comment [2011-03-15]:
      A document providing "specific direction to IANA" (and for which an interop statement is never going to make sense) would fit better as a BCP - why was PS chosen instead?

   Telechat:

   • Alexey: Dan, you wrote that you agree with my discuss. Which part? I just changed one part to a comment.
   • ... [Dan is currently off the call.]
   • Stewart: You're concerned about a list of documents we need to update, and whether IANA has clear instructions.
   • Alexey: The document says "for example" in too many places. Not correct instructions. It should be the full list. Does "for example" mean the whole list? Otherwise, IANA doesn't have full instructions.
   • Stewart: You're right... this isn't a clear instruction to them. It does look like we need to clarify that.
   • Alexey: Comment from IANA was that they think they understand what the changes are, but they need to make sure.
   • Michelle: The two authors are part of IANA, happily.
   • Stewart: If they write the instructions, I can put it in as an editor note.
   • Michelle: You want more instructions in there, then. I will talk to the authors today, and see if we can clarify the text.
   • Alexey: If there is a registry that lists them, just put a pointer in.
   • Stewart: I need text from IANA, then.
   • Robert: Was there a reason you didn't do this as a BCP? PS seems weird for this.
   • Stewart: I don't know.
   • Robert: OK, don't change it. Just wondering for future.
   • Alexey: Stewart, will you take over this discuss from me?
   • Stewart: OK, I'll do that after the call.
   • Amy: Revised I-D needed?
   • Stewart: Let me see what the extent is. AD follow-up.

6. Logging recommendations for Internet facing servers (BCP)
   draft-ietf-intarea-server-logging-recommendations-03
   Token: Jari Arkko
   Note: Julien Laganier (julien.ietf@gmail.com) is the document shepherd
   Discusses/comments (from ballot 3736):
   1. Stewart Bryant: Comment [2011-03-15]:
      Please provide references for "NAT44, NAT64 or DS-Lite."
      If DS-Lite has a full name it should be used.
      NTP (need a ref) is not necessarily a traceable time source, it is certainly not a definitive source of time for legal purposes.
   2. Ralph Droms: Comment [2011-03-16]:
      I cleared my DISCUSS, based on e-mail from Alain Durand.
      For clarification, based on Alain's response, I suggest adding text explaining that the recommendations apply to current logging practice and port sharing does not require any changes in the way logging is performed; e.g., which packets are examined and logged.
      Editorial: I suggest the following minor change for clarity in section 2:
      OLD: "logging incoming IP addresses"
      NEW: "logging source IP addresses from inbound IP traffic"
   3. Russ Housley: Comment [2011-03-15]:
      Please consider the editorial comments from the Gen-ART Review by Francis Dupont on 5-Mar-2011.
   4. Alexey Melnikov: Comment [2011-03-07]:
      Various acronyms used need informational references, e.g. NTP.
   5. Sean Turner: Discuss [2011-03-15]:
      For the security area review:
      Please add a few other items to be considered out-of-scope or add additional security considerations. Since the document already mentions that record retention is out-of-scope, it would be useful to add that server security and transport security is important for the protection of logs for Internet facing systems. After stating that it is an important consideration, then state something to the effect of the service provider must consider the risks, including the data and services on the server to determine the appropriate measures.
      The protection of logs is critical in incident investigations. If logs are tampered with, evidence could be destroyed.

   Telechat:

   • Amy: Sean, do you think your discuss will get revised I-D?
   • Sean: I need new text, but we'll have to check with Jari.
   • Amy: I'll put it in AD follow-up.

7. A Quick Crash Detection Method for IKE (Proposed Standard)
   draft-ietf-ipsecme-failure-detection-06
   Token: Sean Turner
   Note: Paul Hoffman (paul.hoffman@vpnc.org) is the document shepherd.
   Discusses/comments (from ballot 3738):
   1. Jari Arkko: Discuss [2011-03-17]:
      This is a very good specification, and I would have voted Yes if it weren't for one technical issue:
      I do not understand how Section 5.2 mechanism: "TOKEN_SECRET_DATA = HASH(QCD_SECRET | SPI-I | SPI-R | IPaddr-T)"
      works in an implementation that supports multihoming (e.g., RFC 4555). Can you clarify? I would expect that the document at least has to be clearer about this, or perhaps the Section 5.2 mechanism needs to be changed or removed to accommodate for multihoming.
   2. Adrian Farrel: Comment [2011-03-16]:
      Please expand acronyms on first use (such as "SA" in the Abstract)
   3. Dan Romascanu: Discuss [2011-03-16]:
      The DISCUSS and COMMENT is based in part on the OPS-DIR review performed by Menachem Dodge.
      This is a well written and useful document and I will support its approval after the following two issues are discussed and fixed if agreed:
      1. I would have expected that the Operational Considerations section include some information about configuration. It looks at a minimum the activation of the QCD method should be configurable, and the capability to shitch it off in networks where it involves a security risk should be provided.
      2. In Section 9.2 last paragraph, it is not completely clear as to what method should be implemented in the case of a load-sharing cluster when the load balancer cannot guarantee that all "IKE packets from the same source IP address always go to the same cluster". Should QCD Token Transmission not be implemented in such a situation?
   4. Dan Romascanu: Comment [2011-03-16]:
      1. An abbreviation sub-section would have been very useful
      2. Section 9.1 "QCD Token Generation and Handling", first paragraph, second sentence: Replace 'she' with 'they'
      OLD: "because if an attacker can guess the token associated with an IKE SA, she can tear down"
      SUGGESTED: "because if an attacker can guess the token associated with an IKE SA, they can tear down"
      3. Section 9.2 "QCD Token Transmission" 3rd paragraph last sentence: Replace 'it' with 'this'
      OLD: "One way to do it is to synchronize"
      SUGGESTED: "One way to do this is to synchronize"

   Telechat:

   • Sean: We don't need to discuss this today. Authors need to respond to the comments first. I think we'll need revised I-D.

8. GRE Key Extension for Mobile IPv4 (Proposed Standard)
   draft-ietf-mip4-gre-key-extension-04
   Token: Jari Arkko
   Note: Pete McCann (mccap@petoni.org) is the document shepherd.
   Discusses/comments (from ballot 3739):
   1. Stewart Bryant: Comment [2011-03-08]:
      "In the absence of this key identifier, the data streams cannot be distinguished from each other, a significant drawback when using IP-in-IP tunneling."
      Well understated.
      FA, HA, RRP, MN, RRQ, RRP used without first expansion.
      It would be useful to the reader if the 'G' bit was called by it's proper name (GRE Encapsulation) on first used, same for the 'D' bit.
      'The FA may include a GRE key of value zero in the GRE Key Extension to signal that the HA assign GRE keys in both directions.' - Minor grammar problem.
      'Encapsulati on Unavailable' - - Minor grammar problem.
   2. Adrian Farrel: Comment [2011-03-16]:
      I have no objection to the publication of this documen, but there are a few small points that might be addressed to improve it.
      I don't think you need RFC 2119 notation in the Abstract.
      A number of acronyms are used without expansion
      Sections 4.1, 4.2, and 4.3 seem a bit confused on the use of RFC 2119 language and the cases where behavior is already defined in other specifications. Could you spend a little time to clear this up and make clear what new behavior this document is defining.
   3. Russ Housley: Comment [2011-03-16]:
      Something is wrong here:
      4.2. Home Agent Requirements for GRE Tunneling Support [RFC3344]
      The reference is misplaced. I think it belongs in the first sentence of the section.
      Please remove the extra spaces: "GRE encapsulation, it MUST send an RRP with code 'Requested Encapsulati on Unavailable (139)' [RFC3024]"
   4. Peter Saint-Andre: Comment [2011-03-16]:
      It would be nice to expand "GRE" on first use to "Generic Routing Encapsulation" and also provide a reference to RFC 2784.
   5. Sean Turner: Comment [2011-03-15]:
      1) Nits points out:
      - ** Obsolete normative reference: RFC 3344 (Obsoleted by RFC 5944)
      2) If you end up doing another revision, please:
      - a) expand GRE on 1st use in Abstract and Introduction.
      - b) add a period to the end of the 1st paragraph in Section 7.
      Otherwise, please consider these during AUTH48 (if the RFC editor doesn't catch them).

   Telechat:

   • Amy: No discuss, no objections... approved.

2.1.2 Returning Items

1. Advertising Generic Information in IS-IS (Proposed Standard)
   draft-ietf-isis-genapp-04
   Token: Stewart Bryant
   Discusses/comments (from ballot 3384):
   1. Jari Arkko: Discuss [2010-10-07]:
      I support the publication of this document and I think it is a good and proper addition to the ISIS protocol.
      However, I have a specific technical concern. Section 6 says: "The IS-IS WG of the IETF acts as the authority to determine whether information proposed to be advertised in IS-IS LSPs falls under this definition."
      But then Section 8 says: "Registration procedure is "Specification Required" as defined in [RFC5226]"
      If we are expecting to verify that the information falls under the right category, then Specification Required does not appear to be the right IANA rule. Or am I missing something?
   2. Jari Arkko: Comment [2010-10-07]:
      (blank)
   3. Ron Bonica: Comment [2011-03-16]:
      I share Lars' allergy to using routing protocols to transport generic information. Maybe we should start thinking about a generic information transport protocol.
   4. Lars Eggert: Discuss [2010-10-04]:
      I'm missing a crystal clear statement in a very visible spot that the content exchanged in GENINFO TLVs MUST NOT alter the behavior or operation of the IS-IS protocol and/or state machine. In other words, GENINFO is not a tool for a vendor to extended IS-IS in non-interoperable ways. The document does hint that this is the intent in a few places; I'm simply asking for making this very, very clear.
   5. Lars Eggert: Comment [2010-10-04]:
      (Non-actionable comment: I will likely abstain on this document even when the above change is made. The reason is that I'm allergic against the current trend of adding kitchen-sink options that turn all kinds of formerly purpose-built protocols info generic "information exchange" mechanisms.)
   6. Adrian Farrel: Comment [2010-12-12]:
      Thank you for this draft, it is a necessary addition to the IS-IS family and for your work to address my Discusses and Comments.
      I have two small, non-blocking Comments remaining that could be looked at if the authors continue to work on the document.
      I think that the RFC Editor will ask you to jiggle the content/section-headings slightly. They have a preference for seeing Section 1 named "Introduction".
      This Comment moved from the Discuss...
      I feel a bit of a lack discusion of backwards compatibility. You need to cover how a legacy implementation will react to seeing the new GENINFO TLV (a reference to an existing RFC will do), and then consider how this will apply to the utility of the extension (for example, if all speakers participating in the IS-IS instance must be upgraded - I think they will because otherwise they will not see the flags fields in the new TLV).
      It would be helpful to add a brief statement in Section 4 along the lines of: "According to the rules of [RFC4971] a legacy implementation receiving a GENINFO TLV will ..."
   7. Tim Polk: Discuss [2010-10-06]:
      The sole statement in the security considerations: "This document raises no new security issues for IS-IS."
      I don't think that is quite true, albeit in a rather cyclic manner.
      First, I believe that the use of IS-IS as a transport does have security implications that need to be considered when specifying a new geninfo application ID. It would be helpful to describe the limitations implied by this transport, and when additional security mechanisms can be employed to extend the scope. For example, the standard IS-IS cleartext password might be insufficient for some types of data, requiring deployment of RFC 5304 or 5310 authentication mechanisms.
      Second, deployment of advanced IS-IS security mechanisms (e.g., RFC 5310 authentication) is something I personally advocate. However, if an IS-IS deployment were to deploy these mechanisms solely to support advertisement of some generic information this may exacerbate any performance implications for the IS-IS deployment and could be used to launch denial of service attacks. That is, deploying IS-IS security mechanisms *because* of the generic information would be costly for the IS-IS implementation and would violate the usual precept of "security commensurate with need".
      I think a paragraph or two (total) in the security considerations that addresses both these issues would be appropriate.
   8. Tim Polk: Comment [2010-10-06]:
      I support Lars' discuss,
   9. Dan Romascanu: Comment [2011-03-15]:
      I dislike overloading protocols with exchanges of information that do not relate to the protocol functionality. However, at this phase, if the working group was chartered to do this work, I can accept such an extention as the GENINFO advertising of generic information. Separating it in a generic advertising extension rather than consuming from the expensive TLV space for each extension not related to routing is the right thing to do.
      Maybe the introduction should say something about the motivation for such a generic container within IS-IS and make possible recommendations of what future extensions using this container should include (or should not include).
   10. Peter Saint-Andre: Comment [2010-12-07]:
       (blank)
   11. Robert Sparks: Comment [2010-10-06]:
       I support Dan's discuss points.
       The document could better motivate the need for a generic container. Could it explicitly call out the existing messages that would have been candidates for the use of this mechanism if it existed at the time?
       Would it make sense to add text reinforcing that elements not understanding this TLV would ignore-but-flood?
   12. Sean Turner: Comment [2010-10-05]:
       1) Never seen 2119 language in Abstract. Is this allowed by the RFC editor?
       2) Spell out LSP on first occurrence.
       3) Sec 2: It's odd that there are requirements in the overview section. Could this be reworked?
       4) Sec 3 (and the rest of the document): RFC 5305 refers to sub-TLV not subTLV. This document should align with 5305.
       5) Sec 3.1: It would be nice if you assigned a word for the Flags: S (Scope), D (Down), I, and V. It would be nice to assign a word to for "I" and "V" too. How about Ipv4 for "I" and ipV6 for "V".
       6) Sec 3.2: RFC 5035 has to following text about ignoring unknown sub-TLVs: "Unknown sub-TLVs are to be ignored and skipped upon receipt." Does this draft want to use 2119 language to in fact require they be ignored?
       7) Sec 3.2: r/AND/and
       8) Sec 3.3: r/NOT/not
       9) Sec 7: r/IS-IS/IS-IS [RFC1195].

   Telechat:

   • Stewart: Lars isn't here, so we can't discuss. I'll send him email. AD follow-up.

2. Dynamic Host Configuration Protocol Options for Coordinate-based Location Configuration Information (Proposed Standard)
   draft-ietf-geopriv-rfc3825bis-17
   Token: Robert Sparks
   Note: The Document Shepherd for this document is Richard Barnes (rbarnes@bbn.com).
   Discusses/comments (from ballot 3481):
   1. Jari Arkko: Comment [2010-12-02]:
      Ari Keränen reviewed this specification and he had a few comments:
      The abstract should state that this document obsoletes RFC 3825 and the intro should explain why it's done (as described in the I-D checklist).
      However, instead of obsoleting 3825, wouldn't it make more sense to have a new IPv4 DHCP option for this new version given that the new encoding is not compatible with the old one and re-using the same value seems to cause a lot of problems (as described in section 2.2.1)? Or otherwise it would be good idea to mention the reason (preserving DHCP codes?) for not doing so.
      2.3. Latitude and Longitude Fields: "Latitude values encoded by the DHCP server MUST be constrained to the range from -90 to +90 degrees. Location consumers MUST be prepared to normalize values outside this range. Values outside the range are normalized by clamping [...]"
      If the values MUST be within those boundaries, doesn't it mean that a value that is out of the range is somewhat likely completely wrong (due to a broken implementation) and thus it would make sense to ignore it rather than try to normalize the value and make it appear as if it was valid? I'm not sure if I'd like to be liberal in what I accept when it comes to information that could literally be a matter of life and death.
   2. Stewart Bryant: Comment [2010-12-01]:
      PIFF-LO term used but not defined
      GML term used but not defined
      Code: GEOCONF_GEODETIC (16 bits). is "Option Code" in the fig above.
      AType: Altitude Type (4 bits). would be clearer with a ref to section 2.4 (appears in two places)
   3. Ralph Droms: Comment [2011-02-04]:
      I've cleared my DISCUSS. I have a remaining minor comment - In the descriptions of the options, sentences like: "When the Ver field = 1, this field represents latitude uncertainty. The contents of this field is undefined for other values of the Ver field."
      seem unnecessarily detailed. Why not simply: "This field represents latitude uncertainty."
      The descriptions of many fields say nothing about the version number.
   4. David Harrington: Comment [2010-11-30]:
      This document is well-written, with clear and unambiguous language.
      1) section 1, paragraph 4 says "The DHCP server could correlate the Circuit-ID with the geographic location where the identified circuit terminates (such as the location of the wall jack)."
      Would it be the job of the DHCP server to do this correlation? I would assume it was a NM application function to do such correlation.
      2) In 2.2.1.2, s/same response. This is not useful since/same response, since/
      3) When aType=2, numbering starts at ground level. How does one represent an underground parking garage level? Should 2.4.3 mention how to represent this? Should Appendix B include such an example?

   Telechat:

   • Amy: No discuss, no objections... approved.

2.2 Individual Submissions

2.2.1 New Items

1. (none)

2.2.2 Returning Items

1. (none)

3. Document Actions

3.1 WG Submissions

3.1.1 New Items

1. Mobile Networks Considerations for IPv6 Deployment (Informational)
   draft-ietf-v6ops-v6-in-mobile-networks-03
   Token: Ron Bonica
   Note: Fred Baker (fred@cisco.com) is the document shepherd.
   Discusses/comments (from ballot 3612):
   1. Ralph Droms: Comment [2011-03-16]:
      Seems like any statements like the following predicting the final allocation of IPv4 addresses are likely to be out-of-date or inaccurate. I suggest eliding text like the following from section 3.1: "The '/8' IANA blocks for Regional Internet Registries (RIRs) are projected to 'run-out' soon. Subsequently, the addressing pool available to RIRs for assignment to Internet Service Providers is anticipated to run-out in the following 2-3 years."
   2. Russ Housley: Comment [2011-03-15]:
      Following the Gen-ART Review by Kathleen Moriarty on 21-Feb-2011, several changes were agreed. However, a revised document has not been posted yet. Please make sure the revisions get included.
   3. Sean Turner: Comment [2011-03-17]:
      The tense of the 1st sentence in the abstract and intro should probably be changed because the pool is now empty.

   Telechat:

   • ... Jari has a new discuss on this.
   • Jari: The document is basically OK, we should publish, but a couple of things... A little focus on things that I think are on the sidelines, not enough material on the main default things that are being done by the operators. Deployment issues should be made clearer.
   • Ron: We can do that.
   • Jari: Arguments about how much ipv6 functions are tested or not.
   • Ron: That sounds OK.
   • Jari: There's more in the discuss, but I don't want to go through it all here. They're thinking about dual-stack, and the doc says that's the default. But most of the doc is talking about new things we should do, not enough about the default operation model. I have some suggestions in my discuss.
   • Ron: OK. Put it in revised I-D needed.

2. IMAP4 Multimailbox SEARCH Extension (Experimental)
   draft-ietf-morg-multimailbox-search-07
   Token: Peter Saint-Andre
   Note: Timo Sirainen <tss@iki.fi> is the Document Shepherd.
   Discusses/comments (from ballot 3642):
   1. Stewart Bryant: Comment [2011-03-16]:
      ID-nits reports:
      -- The draft header indicates that this document updates RFC4466, but the abstract doesn't seem to mention this, which it should.

   Telechat:

   • Amy: No discuss, no objections... approved.
   • Peter StA:: Note will be needed.
   • Amy: I'll put it in point raised.

3. Moving the Undeployed TCP Extensions RFC1072, RFC1106, RFC1110, RFC1145, RFC1146, RFC1379, RFC1644 and RFC1693 to Historic Status (Informational)
   draft-eggert-tcpm-historicize-02
   Token: David Harrington
   Note: Wesley Eddy (Wesley.M.Eddy@nasa.gov) is the document shepherd.
   Discusses/comments (from ballot 3644):
   1. Adrian Farrel: Comment [2011-03-16]:
      I am ballotting "Yes" on this document, but there are a few issues I would like the author to consider before the document is passed to the RFC Editor.
      Abstract: Please change this text from a "recommendation" to an "action"
      Surely this is a Historic RFC in its own right? I.e., RFC 1072 et al are obsoleted by a Historic RFC.
      Section 2: "The RFC Editor is requested to change the status of the following RFCs to Historic [RFC2026]"
      I'm confused. Can the status of an existing RFC be changed? I thought it could only obsoleted.
      Section 3: This says IANA should mark as "obsolete". Shouldn't you use "deprecated"?
      I think you also need to tell IANA exactly what references they should place against each deprecated option.

   Telechat:

   • Amy: No discuss, no objections... approved.
   • Wes: There's an updated reference, will need an RFC-ed note.

4. Host Identity Protocol Certificates (Experimental)
   draft-ietf-hip-cert-12
   Token: Ralph Droms
   Note: Gonzalo Camarillo (Gonzalo.Camarillo@ericsson.com) is the document shepherd.
   Discusses/comments (from ballot 3698):
   1. Adrian Farrel: Comment [2011-03-01]:
      Agree with Peter's Discuss. The update to 5201 should be noted in the document header and the Abstarct.
      Section 2: "It MAY either carry SPKI certificates or X.509.v3 certificates.
      I think lower case "may" is more appropriate. Unless you mean... "It MUST carry either SPKI certificates or X.509.v3 certificates."
   2. Russ Housley: Discuss [2011-03-15]:
      This discussion on the PKIX mail list is continuing. Today the topic of unambiguous naming is still under discussion.
   3. Tim Polk: Comment [2011-03-17]:
      I support Russ's discuss position. We need to let the PKIX discussion run its course.
   4. Peter Saint-Andre: Comment [2011-03-09]:
      (blank)
   5. Sean Turner: Comment [2011-03-16]:
      (blank)

   Telechat:

   • Ralph: Discussion about logistics. I understand the discuss. When do you want to reconsider the doc again, and how? Should I put it back on the telechat after the discussion on the PKIX mailing list is done?
   • Russ: One of the authors pushed back on my comment, saying the meat of this doc is done, and they're off on X.509 nits. Could Sean and Tim give a reading?
   • Sean: I got the impression that they're off in the weeds.
   • Russ: I will clear.
   • Sean: They started discussion, and I thought we were done, and they went off on a tangent. This is experimental, and if it falls on its face they'll change it.
   • Amy: Russ is clearing his discuss. Ralph, any notes needed?
   • Ralph: No.
   • Amy: Approved, announcement needed.

5. An Infrastructure to Support Secure Internet Routing (Informational)
   draft-ietf-sidr-arch-12
   Token: Stewart Bryant
   Note: Sandra Murphy (Sandra.Murphy@cobham.com ) is the document shepherd.
   Discusses/comments (from ballot 3717):
   1. Jari Arkko: Comment [2011-03-17]:
      From Ari Keränen's review:
      9. IANA Considerations: "This document requests that the IANA issue RPKI Certificates for the resources for which it is authoritative, i.e., reserved IPv4 addresses, IPv6 Unique Local Addresses (ULAs), and address space not yet allocated by IANA to the RIRs.
      It would be good to have explicit references to the documents where each of these "resources" are defined.
      draft-ietf-sidr-iana-objects-01 lists also AS numbers as such a resource; should that be listed here too?
   2. Adrian Farrel: Comment [2011-03-17]:
      I am balloting "Yes" for this document, but there are a few minor nits that I hope the authors will attend to before publication.
      The Introduction uses "CRL" without explanation. This does show up in the Terminology section that follows immediately, but it would be nice to clarify in the Introduction.
      CRLDP shows up in Figure 3 and nowhere else in the document. Please add a note to the text.
      Figure 1 seems to be mysteriously missing.
      Section 4.3 has a slight disconnect between the specification of access protocols and the deployment of access protocols. Thus, when you say... "each function must be implemented by at least one access protocol."
      ...I think you mean... "each function must be implemented by at least one access protocol deployed by a repository operator."
      Similarly, when you say things like... "Download: Access protocols MUST support the bulk download of "
      ...it is ambiguous whether you mean "all access protocols" or "at least one access protocol in the suite of access protocols" or "at least one access protocol deployed by the repository operator"
      Section 4.3: "To ensure all relying parties are able to acquire all RPKI signed objects, all publication points MUST be accessible via RSYNC (see [RFC 5781] and [RSYNC]), although other download protocols also be supported.
      s/also/may also/
      Section 5: Since according to this text a manifest is a signed object, and since the manifest is presumable issued by the authority, I would assume that a manifest includes itself in its listing. But perhaps you should clarify this one way or the other.
   3. Russ Housley: Comment [2011-03-15]:
      Please consider the comments from the Gen-ART Review by David Black on 24-Feb-2011.
   4. Alexey Melnikov: Discuss [2011-03-15]:
      This is a well written document and I support its publication. However I have a small pedantic DISCUSS which should be easy to address:
      1). 9. IANA Considerations: "This document requests that the IANA issue RPKI Certificates for the resources for which it is authoritative, i.e., reserved IPv4 addresses, IPv6 Unique Local Addresses (ULAs), and address space not yet allocated by IANA to the RIRs. IANA SHOULD make available trust anchor material in the format defined in [SIDR-TA] in support of these functions."
      Is this the right document? I thought that was already specified in draft-ietf-sidr-iana-objects.
      2). 11.2. Informative References: "[RFC 5781] Weiler, S., Ward, D., and Housley, R., "The rsync URI Scheme", RFC 5781, February 2010."
      This reference is Normative, because of the use of a MUST.
   5. Alexey Melnikov: Comment [2011-03-15]:
      4.2. Contents and structure: "For every certificate in the PKI, there will be a corresponding file system directory in the repository that is the authoritative publication point for all objects (certificates, CRLs, ROAs and manifests) verifiable via this certificate. A certificate's Subject Information Authority (SIA) extension provides a URI that references this directory.
      An Informative reference to the URI RFC is needed here.

   Telechat:

   • Stewart: I need to look into the first part of Alexey: 's discuss. For the second part, I sent it back for last call.
   • Alexey: This one is informational. There's no downref for this one. The same issue applies to several docs. They all got it wrong. But for this doc, you don't need another last call.
   • Stewart: Can I withdraw it from last call?
   • Russ: I don't think we should.
   • Stewart: I'll let it run, and use the time on the first discuss point. Ad follow-up.

6. PMIPv6 Localized Routing Problem Statement (Informational)
   draft-ietf-netext-pmip6-lr-ps-06
   Token: Jari Arkko
   Note: Basavaraj Patil (basavaraj.patil@nokia.com) is the document shepherd.
   Discusses/comments (from ballot 3735):
   1. Russ Housley: Comment [2011-03-15]:
      Please consider the comments in the Gen-ART Review by Joel Halpern on 7-Mar-2011. I believe the improved clarity will be helpful.
   2. Dan Romascanu: Comment [2011-03-16]:
      The comment is based in part on the OPS-DIR review performed by Nevil Brownlee.
      1) I do not think that the document needs to be blocked for this, but I think that such document should also deal with the the Operational and Manageability considerations and include a section on this respect. At a minimum I would have expected some refering or estimation on the impact on traffic parameters in the network as local routing is designed to reduce latency and backhaul load. Also do we expect any extra extensions or attributes to be needed in the interaction between MAG and RADIUS servers?
      2) Missing also is any mention of scalability. This document describes the problem of optimising routing in a Local (i.e. single provider, or maybe 2~3 providers) setting. Scaling issues will need to be considered in an actual specification (clearly it will have to handle the maximum number of active mobile nodes).

   Telechat:

   • Amy: No discuss, no objections... approved.
   • Jari: I've just joined. Time zone confusion.

3.1.2 Returning Items

1. (none)

3.2 Individual Submissions Via AD

3.2.1 New Items

1. A Survey of Mobility Support In the Internet (Informational)
   draft-zhu-mobility-survey-03
   Token: Jari Arkko
   Discusses/comments (from ballot 3668):
   1. Stewart Bryant: Discuss [2011-03-16]:
      ID-Nits says:
      ** The document seems to lack a Security Considerations section.
      ** The document seems to lack an IANA Considerations section. (See Section 2.2 of http://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.)
      ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references.
   2. Stewart Bryant: Comment [2011-03-16]:
      I can't check the reference so I can't figure out if there is any trade name issue with reference "Sony". Did the authors of the paper work for Sony?
   3. Adrian Farrel: Comment [2011-03-17]:
      Support Stewart's Discuss. There is no reason for I-Ds to turn up in evaluation without having run idnits
   4. Russ Housley: Discuss [2011-03-16]:
      The authors agreed to some changes based on the Gen-ART Review by Richard Barnes on 28-Feb-2011. Please make those changes.
   5. Dan Romascanu: Comment [2011-03-17]:
      I support Stewart's DISCUSS.
      I am wondering why was this document AD-sponsored and did not go on the Independent Stream. It obviously required quite a lot of efforts from the sponsoring AD (and the rest of the IESG) as there is a lot of information about more than a dozen of protocols whose accuracy needs to be verified. Then there will be some more as the document has obvious formatting and document structure issues. It is not clear to me what is the benefit.
      Also, if we already are approving such a broad protocols survey I would have expected some informations about operational and manageability considerations. There is a discussion about deployment issues (which is good) but this is not sufficient.
   6. Peter Saint-Andre: Comment [2011-03-16]:
      This is a fine document and I support its publication as an Informational RFC.
      I have one nit: the use of "mobile" as a noun (e.g., "A system that keeps track each mobile's reachability during the mobile's moving") is colloquial and potentially confusing (e.g., in "mobile replies" is the term a noun or an adjective?). Because you do not want to distinguish between mobile nodes and mobile subnets, I suggest "mobile entity".
      (There are also typographical errors, such as "Protocols like E2E, ILNP and BTMM fail into this design" instead of "fall into", but I assume that those will be fixed during the RFC Editor's review.)

   Telechat:

   • Jari: Discuss from Russ is straightforward, and we will make the changes. Stewart's discuss I think can be handled with an RFC-ed note that adds an empty IANA considerations section.
   • Stewart: There is a mandatory security section. You have to have something.
   • Sean: It's a survey, so you just have to say that all the security considerations are in the separate documents.
   • Jari: Do you want them to say something substantial?
   • Stewart: If the security considerations affect the outcome of any recommendations?
   • Jari: I think the security issues could deserve its own document.
   • Stewart: It's kind of unusual for us to do that isn't it? We should treat this as any other doc, and require people to think about that.
   • Jari: A lot of consideration has gone into various proposals.
   • Stewart: But did they think about it for this document? We should have them do the right thing here.
   • Jari: We can ask the authors to say something about security. I would not want to coerce them to say very much, because that's a different project.
   • Hannes: Is the title of the document correct? Survey of mobility support would talk about what id deployed, but this talks about what has been proposed.
   • Jari: It's more the IP layer, not on the Internet. I'm not prepared to complain about that particular thing, and delay the document.
   • Stewart: It would be an easy clarification to add with an editor note, no?
   • Jari: We could do that. Should that be a change in the title, or something less drastic?
   • Hannes: I was just wondering, when I read the title... I thought they really described what was deployed.
   • Stewart: So it should really be "mobility proposals for the Internet".
   • Jari: There are some things here that have been deployed. But I can try to improve that. I don't have a proposal right not, and I can work on an RFC-ed note. For the security considerations, we could say revised I-D needed, or maybe do an RFC-ed note as well.
   • Amy: Going into revised I-D needed.

2. Use of static-static Elliptic-Curve Diffie-Hellman key agreement in Cryptographic Message Syntax (Informational)
   draft-herzog-static-ecdh-06
   Token: Tim Polk
   Note: Jonathan Herzog (jherzog@ll.mit.edu) is the document Shepherd.
   Discusses/comments (from ballot 3684):
   1. Adrian Farrel: Comment [2011-03-16]:
      I have No objection to the publication of this document, but I have a couple of minor editorial points that could usefully be fixed to improve the document.
      The term "MACed" is used without explanation.
      Section 1: "All three of these types share the same basic structure. First, a fresh symmetric key is generated."
      There is a slight syntactic disconnect between these two sentances. Do you mean the second sentance to be a process description (in which case a paragraph break would be in order)? Or do you mean to describe the shared basic structure in some way?
      Section 1: "key transport: the symmetric key is encrypted using the public encryption key of some recipient,"
      To be very picky... Do you mean "encryption key of the intended recipient"?
      And Later... "In this case, the participants are the originator and one of the recipients."
      Again "the intended recipient" seems a better phrase.
      But I am somewhat worried that you have said "one of the recipients" given that in the case of multiple recipients (that is implied by your language) I don't see how the other recipients will be able to function as they will not have access to the necessary key.
      Section 2: "the RecipientInfo kari choice is used."
      Is "kari" an unexplained term or a typo?
      "ukm" is used without expansion
      Section 2.1 contains a number of MUST statements. Section 2.3 should give an indication of what the receiver does when one of these MUSTs is violated. This may be as simple as a reference to [CMS].

   Telechat:

   • Amy: No discuss, no objections... approved.

3. Multiple Attachments for EDI-INT (Informational)
   draft-meadors-multiple-attachments-ediint-11
   Token: Alexey Melnikov
   Discusses/comments (from ballot 3688):
   1. Stewart Bryant: Comment [2011-03-16]:
      There are a number of id-nits that need be fixed before the document considered ready for publication (IANA section and RFC2119 language). Also the editor should confirm that all of the lower case "should" instances are correctly set.
   2. Russ Housley: Comment [2011-03-16]:
      In the Gen-ART Review by Pete McCann on 15-Mar-2011, a concern is raised. Please consider it:
      There is a space in the declaration of boundary=" INNER-BOUNDARY"; in the example in section 3. I am not sure whether this was intentional or whether it will mess up a standard MIME parser, but you may want to remove it.
   3. Alexey Melnikov: Comment [2011-03-12]:
      Should this document be published with "no IETF consensus" boilerplate?
   4. Sean Turner: Discuss [2011-03-17]:
      update based on Alexey's RFC editor note.
      #1) In Sec 2.3, need a normative reference to the canonicalization method.
      #2) In Sec 2.5, need normative references for each content types list.
   5. Sean Turner: Comment [2011-03-16]:
      Sec 2.3 says: "If the expected MIC value differs from the calculated MIC value, all attachments MUST be considered invalid and retransmitted."
      Isn't telling the initiator that they didn't match and asking for the retransmission missing?

   Telechat:

   • Alexey: Don't need to discuss this now. I need an answer from the authors about the method that Sean asked about. I'm separately following up on missing registration for image/bmp, and may bring it up in Prague. Stays in AD follow-up.

4. IPv6-to-IPv6 Network Prefix Translation (Experimental)
   draft-mrw-nat66-12
   Token: Ron Bonica
   Discusses/comments (from ballot 3710):
   1. Stewart Bryant: Discuss [2011-03-15]:
      The purpose of this discuss is to confirm that there are no undocumented issues associated with the use prefix bits in the range 64 to 127 to fix up the checksum. These are surely real network addresses elsewhere in the net, and therefore may be destinations addresses of packets passing through the translator.
      Section 4.3 states that a node MUST support hairpinning. Does it need to say that it MUST NOT do internal route optimization?
      Does an internal router placed between a host and the translator correctly route packets in this translated range?
   2. Stewart Bryant: Comment [2011-03-15]:
      STUN, TURN, ICE should have references

   Telechat:

   • Ron: Stewart, I've seen a long email thread with the authors, and it looks like everything in the original discuss has been handled. But there's something in recent email.
   • Stewart: I can't understand how you stole ome high-order bits in order to fix up the checksum. I figured out that you could make it work when you're below /48, because you have bits you can steal for it. It'd be nice if the authors could explain that to people. But I still don't understand how it work for the /64 to /128.
   • Ron: I don't understan that. I will ask them.
   • Stewart: They just need to make it clearer to dullards like me, how it works.
   • Ron: I'll ask them to explain how it works when they go deeper than /48. Now Dave's discuss. It looks like a major part of your issue is that appendix A is only an appendix.
   • Dave: I'm not sure about having NATs in v6, but I understand the community wants it. The document is well written, and I thought I'm fine with it. In the appendix they get to GSC. Not mentioned earlier. It says that the proposal in the main part of the document is GSC addressing, and mentions that it's an old proposal that didn't get adopted by the IETF. I wonder why the appendix is here. Maybe historical, to credit the original proposal. But it struck me that this was an alternative architecture that was rejected by the IETF. I'm concerned about approving this even as experimental.
   • Ron: That was 1997, and priorities and problems have chanced since then. I thought the part on GSC wasn't adding anything.
   • Stewart: It would add some coherence to remove it. I wondered a similar thing.
   • Dave: I had no idea what this GSC thing is. I got the impression that it was to explain that they were bringing up a proposal from 1997 that was rejected.
   • Ron: Why don't we just yank the whole appendix?
   • Dave: Yes.
   • Ron: What about the other part, experimental?
   • Dave: I just want to be sure that people don't run this on the Internet and cause problems for the routing tables and so forth.
   • Ralph: You want a statement about running this on the live Internet, and make sure they've thought about it.
   • Stewart: Or "you should take the following precautions."
   • Ron: This would only affect sites behind the NAT.
   • Stewart: No, they appear to be encroaching into the IID space with some of it.
   • Ralph: A statement to that effect... this only modifies bits relative to a particular subnet, it will not affect the global routing tables.
   • Stewart: Someone really needs to explain how they can do their outbound modification. On a /49 that must affect the outbound IID.
   • Ron: It affects any checksum that's on that, and the outbound source address.
   • Dave: The document does say that only the internal addresses get modified. I'm concerned that there's some discussion about the routing tables growing. I couldn't tell by how it's written, whether that's global or internal.
   • Ron: Anyone who thinks they want a dual home or switch ISPs, gets chunks of independent space. So the global v6 routing table get just as large as v4 tables. We want to find a way that people won't have to advertise their PI space to the global internet. You get provider space and NAT to there from your internal space. So only the provider space gets advertised.
   • Stewart: ...until they start talking about /49 and above.
   • Ron: They're trying to find a way that PI space doesn't get advertised to the global Internet.
   • Stewart: Some of that's obscure in the beginning of the doc.
   • Ralph: Are you thinking that wouldn't be needed for something shorter than a /48?
   • Stewart: It's the opposite? They seem to want this to work for any address length.
   • Ron: More than likely, it will only work for the chunk an ISP would give to an enterprise.
   • Stewart: Because they made it to work with high-order address spaces, I worry. Maybe I just don't understand it.
   • Ron: The NAT doesn't interact with the routing system at all. It only changes some number of high-order bits from what you have in your internal network to what your ISP gave you.
   • Stewart: But it fixes bits in the address instead of fixing the checksum.
   • Robert: Stewart is concerned that the fixup to that would create an address that would not be appropriate for that device to use as a source address.
   • Stewart: It's outside the address space that they're using.
   • Ralph: Just the IID portion, or the whole 128-bit address?
   • Stewart: They fix up the checksum by changing an address, not changing the checksum. That works quite neatly up to /48, but they talk about going beyond that.
   • Ralph: Then they have to go into the IID to change it.
   • Stewart: And I don't fully understand how that works.
   • Ralph: The return traffic has to come through the same NAT or one with an equivalent mapping, and the IID gets inverse-mapped back to the original IID.
   • Ron: It doesn't have to be symmetrically routed, but it does have to map back.
   • Ralph: Is it provable that two different addresses will never map to the same external address?
   • Ron: I believe it is, but I can't show you the proof right now.
   • Ralph: That's a question that comes out of this conversation.
   • Stewart: The external packet needs to be perfect, including having the right top-end bit set. I don't understand how you change those, when the checksum change requires you to change the high-order bit. They talk about grabbing some bits from above 64.
   • Ralph: If the organization has been given a /56, it has the ability to change anything between 56 and 64, but it doesn't have to change anything between 56 and 0.
   • Stewart: Either I don't understand this, in which case it needs more text, and the authors couldn't point to something that describes it.
   • Dave: Need to put an operational considerations section that talks about how this affects operation.
   • Ron: That's ot enough instruction to the authors.
   • Stewart: Why don't we set up a call with the authors?
   • Ron: Tuesday.
   • Jari: I also filed a discuss, that goes back to the history on this. My position back then was that it would be useful, and it's still useful, to publish this as experimental. But we should have a warning up front that says the IETF does not recommend NATting v6. Everything up to page 6 explains how great this stuff is. I'd like to see us edit the words a bit.
   • Ron: Can you join us Tuesday morning?
   • Jari: Yes.
   • Amy: This goes into AD follow-up.

5. Understanding Apple's Back to My Mac (BTMM) Service (Informational)
   draft-zhu-mobileme-doc-05
   Token: Lars Eggert
   Discusses/comments (from ballot 3718):
   1. Lars Eggert: Discuss [2011-02-18]:
      I'm holding a discuss on my own document, because the IETF last call ends one day after the telechat date.
   2. Peter Saint-Andre: Comment [2011-03-16]:
      In Section 3 we find: "BTMM uses "_udp" to tunnel packets between the two ends to achieve NAT traversal."
      I think you mean "UDP", not "_udp".
   3. Sean Turner: Comment [2011-03-16]:
      #1) In Sec 7.1, I had trouble parsing the following:
      "When the user first signs in to MobileMe on a host, it automatically receives from KDC a digital certificate and private key for "Back to My Mac Encryption Certificate"."

   Telechat:

   • Amy: Lars is holding a discuss to keep it in AD follow-up. He will let us know when he's ready.

3.2.2 Returning Items

1. (none)

3.3 IRTF and Independent Submission Stream Documents

3.3.1 New Items

1. (none)

3.3.2 Returning Items

1. Survey of proposed use cases for the IPv6 flow label (Informational)
   draft-hu-flow-label-cases-03
   Token: Jari Arkko
   Note: ISE submission
   Discusses/comments (from ballot 3740):
   1. Stewart Bryant: Discuss [2011-03-16]:
      This is a discuss discuss that I expect to clear on the call.
      This is a fine document and I have no objection to it's publication. However I am surprised that it has not gone through a WG. Review by a WG would result in a more complete validation that all the proposals had been captured, and that the conclusion represented the wider view of the IETF.

   Telechat:

   • Jari: Stewart wants to know why it didn't go through a WG.
   • Stewart: I just want to make sure we're doing the right thing with this doc. You get a much wider review with a WG, and a better endorsement.
   • Jari: But how much do we want to spend? You can take things through the WG, or go through other channels. It depends how you want to spend your cycles. My interpretation was that the chairs and author didn't think this is important enough to take significant WG cycles. Is it important to do? In my opinion, I would have taken it to the WG myself.
   • Stewart: How much WG time would it take? You could argue that it if takes lots of WG time, it should do, and if it doesn't take much time, it doesn't matter.
   • Jari: It does require a number of people to do significant thinking.
   • Stewart: I wanted to discuss with others on the call about whether this was the right thing to put through as an individual submission.
   • Jari: I'm not pushing back too much. If the group here thinks this should go through the WG, I'm fine with that.
   • Stewart: I'm not going to sit on the discuss, if the opinion is to let it go forward.
   • Ralph: In this case, considering the subject, this is OK coming through the IRTF.
   • Stewart: This is not IRTF, it's independent.
   • Ralph: I'm OK with that too. It's a survey paper. I think it's OK in this particular case.
   • Robert: Going through a WG pay produce a stronger result. But unless we think it would be significantly different through the WG, we should let it go through.
   • Jari: Also, some people who made the proposal could be unhappy if it went through the WG, so someone stating unpleasant facts might be good.
   • Dave: Has this gone through IETF last call?
   • Russ: There is no last call for independent stream docs.
   • Dave: I would be more comfortable with a WG, more eyes on it, but I'll live with it as it is.
   • Jari: I'm getting mixed feedback, but not getting strong opinions. I lean to letting it go. [silence] OK.
   • Stewart: I'll clear, and then it can be approved.
   • Amy: The "no problem" message can go to the ISE, with the IESG note that's in the tracker now.
   • Jari: Yes.

4 Working Group Actions

4.1 WG Creation

4.1.1 Proposed for IETF Review

1. (none)

4.1.2 Proposed for Approval

1. Verification Involving PSTN Reachability (vipr)
   Token: Robert

   Telechat:

   • Amy: No objections... approved. I see no chairs, no mailing list.
   • Robert: I will send a ticket in with that information.

2. Address Resolution for Massive numbers of hosts in the Data center (armd)
   Token: Ron

   Telechat:

   • Amy: No objections... approved.

4.2 WG Rechartering

4.2.1 Under evaluation for IETF Review

1. Softwires (softwire)
   Token: Ralph

   Telechat:

   • Ralph: Refinement of existing work and milestones. I've edited the draft charter with Dan's feedback. Needs to go out for external review.
   • Amy: Objections to that?
   • Dave: Multicast: docs for softwire and for behave. We just rechartered behave, and they didn't make the cut. I feel they should be worked on hand-in-hand here. Do we need to think about rechartering behave to put multicast in scope there as well?
   • Ralph: When you say it didn't make the cut, do you mean there were proponents for working on multicast, but there wasn't enough support?
   • Dave: There's discussion on the mailing list, but it's not in the charter or deliverables. I wonder if you think the behave work should go hand-in-hand with softwire.
   • Ralph: Let's have this as a side discussion.
   • Dave: I am not objecting to sending this out.
   • Amy: Sending out, and this will go on telechat after Prague.

2. Secure Inter-Domain Routing (sidr)
   Token: Stewart

   Telechat:

   • Amy: Is external review required?
   • Stewart: This is about extending SIDR from the prefix work they've been doing, extending that to looking at the path. There's been debate in the WG. Things eventually stabilized, and it probably needs external review. We want to get it approved so the path work is legitimate discussion for the Friday meeting at the IETF.
   • Russ: The SIDR WG is about BGP security. Since BGP is clearly an IETF standard, I do not see a reason to include new-work.
   • Stewart: I thought we'd just do last call.
   • Russ: But the way we do it involves the whole thing.
   • Stewart: What's the right process?
   • Russ: The only people we really need to ask are the IETF, and even then it will likely be silent. Amy, is there a way to do the review and not do new-work?
   • Amy: Yes, just request that.
   • Russ: We should indicate this in the minutes.
   • Amy: You want it to go for review in the IETF, and not to new-work.
   • Russ: Right. This one is very clear.
   • Amy: This will be back on the telechat after Prague.
   • Russ: Yes, and we will probably formally approve it at the Friday breakfast meeting in Prague.

3. Layer 3 Virtual Private Networks (l3vpn)
   Token: Stewart

   Telechat:

   • Stewart: This is a minor course correction, to do its last piece of work. Just tidying up the charter to do the multicast work we need. Doesn't seem controversial. Hanging around in the WG for a while, but now that it's clear we won't merge l2 and l3, we need to do this. No external review needed.
   • Amy: No objections... approved.

4.2.2 Proposed for Approval

1. (none)

5. IAB News We can use

• Hannes: IAB retreat 12-13 May, Washington, DC. Managerial load/support for the IAB chair. Have IAB Ex Dir for that, a volunteer. Working on a job description to get a paid position for it.
• Hannes: NTAI NOI for the IANA contract. They are working on a response to be presented to the IAB next week.
• Hannes: Have candidate voting going for the RFC series committee. Should be finished soon.
• Hannes: W3C/IETF conference call. Some IAB and IESG were on the call. Discussed topics of mutual interest. Real-time web, and privacy topic (do not track).
• Hannes: Workshop next week... planning had problems with meeting venue this week, too expensive. Russ and Olaf got us moved to the Hilton.
• Hannes: SDO coordination program. Some of the recent discussions need more attention with respect to collaboration with ITU-T.
• Hannes: Usage of IETF credentials when speaking or writing documents. We had a discussion and are working on a response for during the IETF meeting.

6. Management Issues

1. IESG statement on MIME type registrations from other SDOs in the standards tree with no drafts (Alexey Melnikov)

   Telechat:

   • Alexey: Let's defer this to Prague or next telechat, and Pete will take it over.

2. text/n3 and text/turtle Media Type registrations from W3C (Alexey Melnikov)

   Telechat:

   • Alexey: I think these are mostly OK. They went for two-week apps mailing list review on 11 March, so the announcement shouldn't go out until 25 March.
   • Peter StA:: Should we put this on the agenda in Prague? I'm uncomfortable approving before the comment period is done.
   • Alexey: I don't expect anything.
   • Peter StA:: No, I don't either.
   • Alexey: If anything comes up, we can talk about it in Prague. These media types were actually discussed and should have been registered years ago.
   • Amy: The IESG has conditionally approved this?
   • Alexey: Yes.

3. Using "Updates" to update IANA procedure (Alexey Melnikov)

   Telechat:

   • Alexey: I filed a discuss on Sean's DTLS doc which extends the IANA registry for TLS. I think this requires "updates TLS 1.2 RFC", and Sean disagrees.
   • Sean: It's an IANA section, and it's telling IANA what to do. We don't have to update the TLS document. It seems a little weird.
   • Robert: The registry is the authoritative source, and you want to point people to the registry, not the other document.
   • Alexey: When TLS 1.2 is updated, the IANA registration should list the field for DTLS.
   • Sean: I can see that.
   • Alexey: I don't want to block Sean's doc on this, but I wanted to have a wider discussion.
   • Peter StA:: It seems that if we're updating the template and the procedure, it's good to say this doc updates the other one. Whether they will follow the updates, I don't know, but it's valuable to have the history there, so we can track the changes to the registration procedures and templates.
   • Alexey: Sean, do you want to add an RFC-ed note?
   • Sean: I think we can put "updates" in, with text explaining it. I will get it added.
   • Dave: This isn't changing the format of the registry?
   • Alexey: Not correct: it's adding fields, so it's changing format.

4. Ports & Services BCP: final RFC Editor note about use of multiple ports for related protocols (Alexey Melnikov)

   Telechat:

   • Alexey: Cullen raised this issue in IETF last call. He wanted to add text saying there's no consensus about using separate ports for secured and unsecured versions of protocols. He proposed a change, Paul Hoffman edited it, and I put in an RFC-ed note. Joe came back and said he feels uncomfortable with it because it describes how the review team should operate. I feel that this change needs to be in the document, and there's IETF consensus for that.
   • Robert: You're asking us for input on what the doc should say? I was also planning a discuss if the text weren't there, and I definitely want the text there.
   • Dave: I think the text is binding on the expert reviewers, and I don't think we should do that. Are we going to do a "bis" if we change our minds?
   • Peter StA:: We want to make sure they don't reject it JUST because they're requesting two ports.
   • Alexey: The words "sole reason" are quite important here.
   • Peter StA:: They could come back and say "we don't see a good reason to give you two ports," because you haven't justified it sufficiently.
   • Dave: The way you have this now is that they cannot reject it if the only reason for the rejection is that they asked for two ports. You have to give the expert reviewers flexibility. This text ties their hands.
   • Alexey: The top of the section says that this is not binding on IANA review.
   • Dave: I'm concerned that if we start to lay down rules, an SDO that wants something, with lawyers behind them, can come and say "if we do this, you cannot deny it to us."
   • Robert: You've looked at the front part of the document that scoping this? I would have to block this document if this is NOT there. I don't think arguing this is the healthiest thing for this document.
   • Dave: I won't block this, but I think it's stepping too far.
   • Pete R: It says SHOULD NOT reject, not MUST NOT. Given that, I'll hold my nose along with Dave
   • Peter StA: if people can come up with better text, I'm all ears
   • Alexey: time to move on, sometimes the consensus is rough...

7. Agenda Working Group News

• Ralph Droms (Internet)--- none
• Lars Eggert (Transport)--- David: Lars would have announced WGC change pending
• Adrian Farrel (Routing)--- not here
• David Harrington (Transport)--- none
• Russ Housley (General)--- none
• Alexey Melnikov (Apps)--- none
• Tim Polk (Security)--- none
• Dan Romascanu (O & M)--- organization ODVA? interested in liaison re Energy Management, will follow up
• Peter Saint-Andre (Apps)--- none
• Robert Sparks (RAI)--- none
• Sean Turner (Security)--- none
• Jari Arkko (Internet)--- INTAREA working on new WGC
• Ron Bonica (O & M)--- Brian Carpenter will chair RENUM BoF
• Stewart Bryant (Routing)--- MPLS-TP discussions this week, important to get it right
  Russ: obviously I agree, ISOC advisory council will discuss Friday at Prague (after WGs complete), working on paper
  Stewart: do I need to be there?
  Russ: I'd welcome your support
• Gonzalo Camarillo (RAI)--- not here

1411 EST Adjourned

Appendix: Snapshot of discusses/comments

(at 2011-03-17 07:28:35 PDT)

draft-ietf-httpbis-content-disp

1. Stewart Bryant: Discuss [2011-03-14]:
   

       When the value contains path separator characters ("\" or "/"),
         recipients SHOULD ignore all but the last path segment.  This
         prevents unintentional overwriting of well-known file system
         locations (such as "/etc/passwd").
   
       
    ... or even intentionally over writing it - depending on your perspective.
   
   I spent a little time puzzling over the /etc/passwd case. Since /etc/ looked
   like the last path segment. However I think that you mean that the file
   will be stored in "some-default-directory-but-not-slash/etc/passwd". It would
   be useful to clarify this in the text with an example.
   
   Why is this a SHOULD and not a MUST given the security implications.
   
   ====
   
   Surely the security section (or 4.3) needs to discuss file permissions as well
   as well known extension types. 
       

2. Stewart Bryant: Comment [2011-03-14]:
   

   "RFC 2616 defines the Content-Disposition response header field"
   
   I think that you need to say the  Content-Disposition response header field of
   what. Same for Intro.
   
   

3. Adrian Farrel: Comment [2011-03-16]:
   

   I have no objection to the publication of this document. There are a couple f
   small points that I think would benefit from attention first.
   
   ---
   
   Section 2 says that BNF from RFC 2616 is used.
   Section 3 metnions "ABNF". Is this the same (in which case please use
   consistent terminology) or different (in which case please supply a
   reference for ABNF).
   
   (See also Peter's Discuss
   
   ---
   
   Section 4.3 contains a number of bullets. The first one uses RFC 2119
   language to specify behavior, but the remaining bullets use apple-pie
   language. Do you need to upgrade all bullets to RFC 2119?
   

4. David Harrington: Discuss [2011-03-14]:
   

       1) is this document meant to update or obsolete 2183 (or not)? Per appendix B,
   this document omits parameters specified in 2183. Is this meant to obsolete
   those parameters?
   
   2) "This specification is expected to replace the definition of Content-
   Disposition in the HTTP/1.1 specification, as currently revised by
      the IETF
   HTTPbis working group."
   Does this document obsolete/update the I-Ds being
   produced by httpbis? If so, which drafts?
   
   3) Does the grammar in 4.1 allow both filename and filename*  to be specified?
   
   4) I think the statement "   Senders MUST NOT generate Content-Disposition
   header fields that are
      invalid." should include a pointer to the specific
   rules about what is invalid. 
       

5. David Harrington: Comment [2011-03-14]:
   

   1) I agree with Stewart's DISCUSS. I found the discussion of the last segment of
   the filename to be confusing.
   
   2) I agree with Stewart's concern about some additional security considerations
   that are not documented.

6. Alexey Melnikov: Comment [2011-03-16]:
   

   In answer to David's DISCUSS:
   
   1) This document doesn't need to update or obsolete RFC 2183, because RFC 2183
   specifies Content-Disposition header field for email only. This draft is a
   standalone version for HTTP.
   
   2) This document is not obsoleting/updating any other HTTPBIS WG I-D.
   
   3) Yes, both filename and filename*  are allowed. That is intentional (for
   backward compatibility)
   
   4) The editor answered this, but there was a small edit in the document to add
   the cross reference.

7. Dan Romascanu: Comment [2011-03-14]:
   

   Why would Appendix C4 be removed at publication? I believe that it actually
   includes important information about the status of the implementations, and
   clarifies the reasons of some of the choices made by editors and the WG.

8. Robert Sparks: Comment [2011-03-14]:
   

   Consider adding "At the time of publication of this document, " to the front of
   the sentence starting with the purl.org URL at the end of Appendix D. Using a
   tool like purl.org helps make it easier to manage moving content around, but
   won't guarantee that that the content isn't a dangling reference or that it
   contains relative content in 20 years.

9. Sean Turner: Discuss [2011-03-17]:
   

       (updated based on exchanges with author)
   
   #1) Sec 3.1 contains the following:
   
     Recipients MAY take steps to recover a usable field-value from an
     invalid header field, but SHOULD NOT reject the message outright,
     unless this is explicitly desirable behaviour (e.g., the
     implementation is a validator).  As such, the default handling of
     invalid fields is to ignore them.
   
   What's the default requirement?  It needs to be reworded as follows:
   
     As such, implementations SHOULD ignore invalid field by default.
   
   #2) Sec 4.3 contains the following:
   
     Thus, recipients SHOULD ensure
     that a file extension is used that is safe, optimally matching the
     media type of the received payload.
   
   Why isn't this MUST.  An implementation that doesn't do this is then vulnerable
   to the attacks you just described.  Under what circumstances is this a good
   idea?
   
   #3) Sec 4.1 contains the following:
   
      Header field values with multiple instances of the same parameter
      name are invalid.
   
   Is this a new requirement on HTTP headers or is this true of all HTTP headers? 
       

10. Sean Turner: Comment [2011-03-17]:
    

    #1) Sec 4.1 contains the following phrase:
    
       Furthermore note that the format used for ext-value allows specifying
       a natural language;
    
    It would greatly help to include an "natural language (e.g., <insert text
    here>);"
    
    #3) Sec 8.2: Should the registration template include:
    
       Related information: none
    
    #5) App D contains the following:
    
         [[fallbackbug: Firefox is known to
          pick the wrong parameter; a bug fix is scheduled for Firefox 5.
          --jre]]
    
    Is this supposed to be removed?

draft-ietf-ancp-protocol

1. Adrian Farrel: Discuss [2011-03-16]:
   

       I have two issues related to version numbering that I would like to
   Discuss. Additionally, if time permits, I intend to return with a more
   in depth review of the protocol
   
   ---
   
   I am trying to work out how ANCP will co-exist with GSMP. It seems they
   both use the same port (6068) so I assume disambiguation happens on
   version number negotiation. But...
   
   A GSMP version number is an 8 bit number, with 0x03 being the current 
   version. Since the GSMP version number is not currently tracked by IANA,
   there is a risk that a future version of GSMP will decide that 0x32
   (i.e., version 50) will be used.
   
   I strongly suggest, therefore, that you need a new registry for the 
   "GSMP and ANCP version Numbers". This will need some careful words to
   indicate that GSMP version 4 is allowed. You will also want to track
   ANCP sub-versions (but see below).
   
   [This point relates to part of Alexey's Discuss]
   
   ---
   
   I am really not happy about the lengths that are being gone to to 
   support pre-standard implementations. I think this document should at
   least state that version 3.1 is not allowed. That is, it should not 
   allow downward version negotiation from 3.2. Furthermore, sub-version
   1 should be shown in the IANA registry as "reserved - not available for
   allocation".
   
   Furthermore, I see no reason to require the RFC Editor to make the
   various changes you request with respect to the version numbering. You
   should make these changes now.
    
       

2. Russ Housley: Comment [2011-03-15]:
   

     The Gen-ART Review by Ben Campbell on 9-Mar-2011 raised a few minor
     points.  Tom Taylor responded; he seems to agree with some of them.  
     However, the document has not been updated yet.  Please do so before
     approval.

3. Alexey Melnikov: Discuss [2011-03-15]:
   

       [Updated: added one more issue in the DISCUSS section (look at the end of it)]
   
   This is a well written document and I don't have objections to its publication.
   However I would like to discuss the following issues before recommending its
   approval:
   
   3.1.  Protocol Version
   
      GSMPv3 messages contain an 8-bit protocol version field.  As
      described below, ANCP subdivides this into two 4-bit sub-fields, for
      version and sub-version.  Implementations of this version of the ANCP
      specification MUST set the version sub-field to 3 and the sub-version
      sub-field to 1.  That is, the hexadecimal representation of the value
      of the complete protocol version field MUST be 0x31.
   
   What is the meaning and semantics of version and subversion? The document is not
   clear on why the separation into version and subversion is needed.
   
   3.2.  ANCP Transport
   
      Identifier:  This 2-byte field identifies a GSMP or ANCP message.
         The type code for GSMP and ANCP messages is 0x880C (i.e., the same
         as GSMP's Ethertype).
   
   Is it wise to reuse the same identifier, considering the statement elsewhere
   in the document that the 2 protocols are not really compatible?
   
      The NAS MUST listen for incoming connections from the Access Nodes.
      Port 6068 is used for TCP connection.
   
   Does this need to be listed in the IANA Considerations section?
   
   4.5.  Status-Info TLV
   
         Error Message:  Human-readable string providing information about
            the warning or error condition.  Padded with zeroes as
            necessary to extend to a four-byte word boundary.
   
   Typically human readable strings need some language tagging information.
   Please
   see <http://trac.tools.ietf.org/group/iesg/trac/wiki/TypicalAppsAreaIssues> for
   more details.
   
   8.5.1.  OAM-Loopback-Test-Parameters TLV
   
            Byte 2: Timeout.  Upper bound on the time in seconds that the
            NAS will wait for a response from the DSLAM.  The value 0 MAY
            be used, but has a special meaning.
   
   What is the special meaning of 0?
   
   10.  Security Considerations
   
      Security of the ANCP protocol is discussed in [RFC5713].  A number of
      security requirements on ANCP are stated in Section 8 of that
      document.  Those applicable to ANCP itself are listed here:
   
      o  The protocol solution MUST offer authentication of the AN to the
         NAS.
   
      o  The protocol solution MUST offer authentication of the NAS to the
         AN.
   
   This section is a bit think on TLS-specific details. In particular it doesn't
   describe how these requirements can be achieved with TLS (Note that TLS client
   authentication to the TLS server is optional, so not every ciphersuite is
   suitable to satisfy these requirements). 
       

4. Alexey Melnikov: Comment [2011-03-14]:
   

   5.1.1.  Control Context (Informative)
   
      Aside from its use in ANCP signalling, access line identification is
      also used in DHCP transactions involving hosts served by DSL.  Either
      the AN or the NAS can serve as a DHCP relay node.  [TR-101] requires
      the AN or NAS in this role to add access line identification in
      Option 82 (Information) to each DHCP request it forwards to the DHCP
      server.  It is desirable for efficiency that the identification used
      in this signalling should be the same as the identification used in
      ANCP messages.
   
   An informative reference to DHCP is needed here.
   

5. Dan Romascanu: Discuss [2011-03-17]:
   

       In section 3.6.1.4: 
   
   > In addition to any suggested action in the text which follows, the
      Code value SHOULD be logged in a MIB.  
   
   If I was writing the MIB module and/or the instrumentation for MIB module I
   would not know what to do, What needs to be logged in a MIB module? (or MIB
   object? which of these?). The fact that the code value is supported? Each
   sending of a request? Each receive of a Request? Something else? 
       

6. Dan Romascanu: Comment [2011-03-17]:
   

   I support the DISCUSSes by Adrian and Alexey concerning the version number and
   the DISCUSS from Peter concerning the relationship with RFC 3292.

7. Peter Saint-Andre: Discuss [2011-03-16]:
   

       The relationship between this specification and RFC 3292 is unclear and
   confusing.
   
   On the one hand, this document notes that modifies the GSMPv3 adjacency message
   format, the base GSMPv3 message format, the GSMPv3 Event message format, and the
   Port Management message format; therefore it appears to update RFC 3292.
   However, the specification does not indicate that it updates RFC 3292.
   
   On the other hand, this document points implementers to Sections 3.1.1, 9, and
   11 of RFC 3292 for aspects of the protocol, thus introducing a normative
   dependency on parts of RFC 3292 while at the same time it updates other parts;
   why not simply copy the relevant text to this specification so that all the
   documentation is in one place, thus enabling us to remove the normative
   dependency on RFC 3292? 
       

8. Peter Saint-Andre: Comment [2011-03-16]:
   

   I concur with the DISCUSSes posted by Adrian Farrel and Alexey Melnikov.

9. Robert Sparks: Discuss [2011-03-16]:
   

       Allowing ACNP agents to use any Code values from the (about to be modified)
   GSMPv3 Failure Response Message Name Space registry "if they appear applicable"
   seems underspecified. Could some guidance about when a code would NOT be
   applicable be added? Would an exhaustive list of applicability of the codes
   already registered (in the IETF Consensus ranges) be hard to produce?  I take it
   from Tom's responses to some of the review comments that you do not expect
   GSMPv3 focused codes to be added to the registry, but if one ever were added
   (with a value below 256) that really was targeting GSMP and not ANCP, why not
   ask the registrant say so and capture it in the registry?
   
   Can the document explain when it might be reasonable to not follow the SHOULD in
   3.6.1.7? 
       

10. Robert Sparks: Comment [2011-03-16]:
    

    I found the "must" convention distracting, and am skeptical of it's
    effectiveness as a way to communicate requirements to another SDO (which is what
    I understand its purpose to be based on the author's response to the genart
    review). If this remains in the document, please follow up and ensure it had the
    desired effect before trying the convention again.
    
    Section 3.6.1.6 speaks of incrementing transaction IDs linearly when I think
    it's really trying to say "by one". (If there's ever a chance of an intermediary
    being introduced in the path of these messages, it would help to say something
    now about whether recipients should care about gaps in the sequence they
    receive.)

11. Sean Turner: Discuss [2011-03-17]:
    

        #1) DISCUSS-DISCUSS
    
    I have to admint I'm completely out of my element here:
    
    If ANCP and GSMPv3 do kind of the same thing. Has there been thought to retiring
    GSMPv3?  Are the two protocols going to gracefully co-exist?
    
    #2) Sec 10 includes security considerations from RFC 5713 with an informative
    reference.  If these are the security considerations of ANCP aren't they
    normative?  Unfortunately, RFC 5713 is informative and this would then be a
    DOWNREF. 
        

12. Sean Turner: Comment [2011-03-17]:
    

    #1) I support Alexey's discuss position on TLS.

draft-ietf-sidr-res-certs

1. Ralph Droms: Comment [2011-03-15]:
   

   Minor editorial suggestion: In the Abstract,
   s/Resources (INRs)/Internet Number Resources (INRs)/

2. Alexey Melnikov: Discuss [2011-03-17]:
   

       [Updated as per Sam Hartman's SecDir review discussion and a further discussion
   with Sam]
   
   This is a well written document and I generally support its publication. 
   
   I was originally planning to file a DISCUSS on this issue, but though that the
   WG knows better. However Sam's SecDir review has changed my mind:
   
   Sam wrote:
   
   I do not believe the concerns I raised in my secdir review have been
   addressed and I still have a deep architectural concern with the
   decision to prevent relying parties from accepting unknown non-critical
   extensions.
   
   There seems to be agreement with several points I raised:
   
   1) The profile does prohibit unknown extensions.
   
   2) I think there is agreement that before we can start using an error
   correction or new feature, we have to upgrade all software in the wild
   that might see the certificates.
   
   3) Everyone including me thinks that strong restrictions  on what
   certificates are created is good for this profile. The question is what
   about restrictions on what people receive. If the IETF changes the
   standard in the future do we want to have to upgrade issuers and
   consumers or just issuers before we start using the new spec in what we
   issue.
   
   4) We may find ourself in a situation where we made a mistake or need to
   expand what the RPKI does.
   
   Adding from myself:
   
   I think there is no disagreement that extensions not listed in this profile
   SHOULD NOT (or even MUST NOT) be generated. However I think the WG is shooting
   itself in the foot by making receivers reject certificates with unrecognized non
   critical extensions. A much better architectural approach would be to say that
   such non critical extensions "MUST be ignored". This is a pretty standard trick
   in the Apps Area and allows for safe extensibility.
   
   I also have a small list of [nearly] nit-picking items which I think need to be
   addressed before it is approved for publication:
   
   4.9.6.  CRL Distribution Points
   
      The CRL Distribution Points (CRLDP) extension identifies the
      location(s) of the CRL(s) associated with certificates issued by this
      Issuer.  The RPKI uses the URI form of object identification.
   
   This needs a Normative reference to the URI RFC.
   
      The sequence of distributionPoint values MUST contain only a single
      DistributionPoint.  The DistributionPoint MAY contain more than one
      URI value.  An RSYNC URI [RFC5781] MUST be present in the
   
   This makes the reference Normative (and it is a DownRef).
   
      DistributionPoint, and reference the most recent instance of this
      Issuer's CRL.  Other access form URIs MAY be used in addition to the
      RSYNC URI, representing alternate access mechanisms for this CRL.
    
       

3. Alexey Melnikov: Comment [2011-03-12]:
   

   4.4.  Issuer
   
      The value of this field is a valid X.501 distinguished name.
   
   A reference to the document defining DNs is needed here. (One of the LDAP
   documents might do.)
   
      An Issuer name MUST contain one instance of the Common Name attribute
      and MAY contain one instance of the Serial Number attribute.  If both
      attributes are present, it is RECOMMENDED that they appear as a set.
      The Common Name attribute MUST be encoded as a printable string.
   
   Similarly, a reference for printable string is needed.
   
      Issuer names are not intended to be descriptive of the identity of
      Issuer.
   
   4.9.8.1.  SIA for CA Certificates
   
      The ordering of URIs
      in this accessDescription sequence reflect the CA's relative
      preferences for access methods to be used by RPs, with he first
   
   s/he/the
   
      element of the sequence being the most preferred by the CA.
   
   6.2.1.  CRMF Resource Certificate Request Template Fields
   
         version
            This field SHOULD be omitted.  If present, it MUST specify a
            request for a Version 3 Certificate.  It
   
   Unfinished sentence?
   

4. Tim Polk: Comment [2011-03-17]:
   

   I support Alexey's discuss-discuss: the upgrade path for sidr-res-certs is not
   typical for IETF publications.  It would be good for the IESG to discuss the
   merits and drawbacks of the wg's consensus approach.
   
   However, I should note that I personally am comfortable with the approach based
   on the unique attributes of its intended deployment and application.  Various
   aspects of this problem have been actively discussed since Stockholm.

5. Peter Saint-Andre: Comment [2011-03-17]:
   

   Although I am provisionally balloting "No Objection" pending discussion within
   the IESG, I too am concerned about the issues raised in Alexey Melnikov's
   DISCUSS.

6. Sean Turner: Comment [2011-03-10]:
   

   Need to add normative reference to RFC 2119 as per: http://www.rfc-
   editor.org/policy.html#policy.2119ref
   
   "Valid From" should be "Not Before" and "Valid To" should be "Not After" to
   match the name of fields in RFC 5280.

draft-ietf-sidr-cp

1. Ralph Droms: Comment [2011-03-16]:
   

   A few nits:
   
   Abstract: s/Internet resource/Internet Number Resource/
   
   Introduction: s/Internet number resource/Internet Number Resource/
   
   In section 2.4, should this text use RFC 2119 terms:
   
      This data is supposed to be accessible to the public.
   
   Why are sections 5.1.*, 5.2.* listed as sections with no text?

2. Adrian Farrel: Comment [2011-03-17]:
   

   I have No Objection to the publication of this document, but there are
   a couple of nits I hope the authors will attend to before publication.
   
   ---
   
   Missing close parenthesis in the document title.
   
   ---
   
   In the Introduction...
   
      Note: This document is based on the template specified in the
      Internet Engineering Task Force (IETF) standards document RFC 3647
      [RFC3647].  In the interest of keeping the document as short as
      reasonable, a number of sections contained in the template are
      omitted from this policy because they did not apply to this PKI.
      However, we have retained the section numbering scheme employed in
      the RFC to facilitate comparison with the outline in Section 6 of
      the RFC. Each of these omitted sections should be read as "No
      stipulation" in CP/CPS parlance.
   
   In the interestes of disambiguity (for example, once this document
   has been published as an RFC) could you please
   s/the RFC/RFC 3647/
   both times it shows.
   
   ---
   
   1.5.4. CP approval procedures
   
      The IESG MUST approve a replacement BCP that either updates or
      obsoletes this BCP, following the procedures of the IETF Standards
      Process as defined in RFC 2026 [RFC2026].
   
   This is a little amusing. But I think you actually mean...
   
      Any BCP that either updates or obsoletes this BCP, MUST be approved
      by the IESG following the procedures of the IETF Standards Process as
      defined in RFC 2026 [RFC2026].
   
   ---
   
   3.1.2. Need for names to be meaningful
   
      The Subject name in each certificate SHOULD NOT be "meaningful",
      i.e., the name is NOT intended to convey the identity of the Subject
      to relying parties.
   
   While I understnd the desire for stress, I think s/NOT/not/
   
   ---
   
   3.1.3. Anonymity or pseudonymity of subscribers
   
      Although Subject (and Issuer) names need not be meaningful, and may
      appear "random," anonymity is not a function of this PKI, and thus
      no explicit support for this feature is provided.
   
   Unless there is some special meaning of "pseudonimity" in the security
   community, I would suggest dropping it from the section title. The 
   section text does not discuss the use of pseudonyms, and (to me) the
   use of a pseudonym is destinct from annonymity.
   
   ---
   
   3.1.5
   
   s/Subject names/subject names/ at least twice
   

3. Russ Housley: Comment [2011-03-15]:
   

     Please consider the minor issues raised in the Gen-ART Review by
     Francis Dupont on 24-Feb-2011.

4. Alexey Melnikov: Comment [2011-03-12]:
   

   4.10. Certificate status services
   
      This PKI does not make provision for use of OCSP or SCVP, because it
   
   Informative references are needed here.
   
      is anticipated that the primary RPs (ISPs) will acquire and validate
      certificates for all participating resource holders.

5. Peter Saint-Andre: Comment [2011-03-16]:
   

   Please expand "SIA" on first use and provide a reference if necessary.
   
   In section 4.2.1, I suggest changing "SHOULD never" to "SHOULD NOT".

draft-ietf-sidr-iana-objects

1. Jari Arkko: Discuss [2011-03-17]:
   

       Section 8 has a MUST (see below for more details) that is not fully specified.
   The document should make it clear who can make exceptions on making ROAs for
   multicast addresses. 
       

2. Jari Arkko: Comment [2011-03-17]:
   

   What kind of change/CRL/processing load is expected from certification of
   unallocated space at IANA, as that space keeps changing (in the case IPv6)?
   
   From Ari Keränen's review: 
   
   8.  Multicast
   
      IANA MUST NOT issue any ROAs (AS0 or otherwise) for any other
      multicast addresses unless directed.
   
   Directed by whom? Need to have, e.g., IESG Approval?
   

3. Russ Housley: Comment [2011-03-16]:
   

     Please consider the comment from the Gen-ART Review by
     Wassim Haddad on 16-Mar-2011.  I believe that improved clarity
     is desirable.

4. Alexey Melnikov: Discuss [2011-03-17]:
   

       I am planning to ballot Yes on this document once my issues are discussed.
   
   I have a couple of discussion point for IESG which might or might result in some
   actions for editors.
   
   2) DISCUSS DISCUSS
   
   5.  Reserved Resources
   
      Reserved IPv4 and IPv6 resources are held back for various reasons by
      IETF action.  Generally such resources are not intended to be
      globally routed.  An example of such a reservation is 127.0.0.0/8
      [RFC5735].
   
      IANA SHOULD issue an AS0 ROA for all reserved IPv4 and IPv6 resources
      not intended to be routed.
   
   Is IANA clear on where (in which RFCs) all such resources are described?
   The reference to [RFC5735] makes me think that it is only one example.
   
      There are a small number of reserved resources which are intended to
      be routed, for example 192.88.99.0/24 [RFC3068].
   
   As above.
   
      IANA MUST NOT issue any ROAs (AS0 or otherwise) for reserved
      resources that are expected to be globally routed.
    
       

5. Alexey Melnikov: Comment [2011-03-17]:
   

   I feel much better about approving this document after reading draft-ietf-sidr-
   arch-12.txt. So I am moving my DISCUSS DISCUSS # 1 to the Comment section:
   
   1) DISCUSS DISCUSS:
   
   This document has lots of normative references to documents, some of which are
   not yet in IETF LC. I do feel that all of them actually need to be reviewed
   before approving this document, so I find it strange that this document is in
   IESG review first.
   
   I understand that I've done similar out-of-order IESG processing for some of my
   documents, so I don't claim to have a high moral ground here. However I would
   like to hear some explanation of why such exception is Ok in this case.

6. Dan Romascanu: Comment [2011-03-16]:
   

   I support Alexey's DISCUSS and I have one supplementary question concerning the
   following paragraph in Section 5:
   
   >    IANA SHOULD issue an AS0 ROA for all reserved IPv4 and IPv6 resources
      not intended to be routed.
   
   Why is this a should? Why not a MUST? If there are exceptions does IANA know and
   understand all cases when they apply?

7. Robert Sparks: Comment [2011-03-15]:
   

   A document providing "specific direction to IANA" (and for which an interop
   statement is never going to make sense) would fit better as a BCP - why was PS
   chosen instead?

draft-ietf-intarea-server-logging-recommendations

1. Stewart Bryant: Comment [2011-03-15]:
   

   Please provide references for  "NAT44, NAT64 or DS-Lite."
   
   If DS-Lite has a full name it should be used.
   
   NTP (need a ref)  is not necessarily a traceable time source, it is certainly
   not a definitive source of time for legal purposes.

2. Ralph Droms: Comment [2011-03-16]:
   

   I cleared my DISCUSS, based on e-mail from Alain Durand.
   
   For clarification, based on Alain's response, I suggest adding
   text explaining that the recommendations apply to current
   logging practice and port sharing does not require any changes
   in the way logging is performed; e.g., which packets are
   examined and logged.
   
   Editorial: I suggest the following minor change for clarity in section 2:
   
   OLD:
   
      logging incoming IP addresses
   
   NEW:
   
      logging source IP addresses from inbound IP traffic

3. Russ Housley: Comment [2011-03-15]:
   

     Please consider the editorial comments from the Gen-ART Review by
     Francis Dupont on 5-Mar-2011.

4. Alexey Melnikov: Comment [2011-03-07]:
   

   Various acronyms used need informational references, e.g. NTP.
   

5. Sean Turner: Discuss [2011-03-15]:
   

       For the security area review:
   
   Please add a few other items to be considered out-of-scope or add additional
   security considerations.  Since the document already mentions that record
   retention is out-of-scope, it would be useful to add that server security and
   transport security is important for the protection of logs for Internet facing
   systems.    After stating that it is an important consideration, then state
   something to the effect of the service provider must consider the risks,
   including the data and services on the server to determine the appropriate
   measures.
   
   The protection of logs is critical in incident investigations.  If logs are
   tampered with, evidence could be destroyed. 
       

draft-ietf-ipsecme-failure-detection

1. Jari Arkko: Discuss [2011-03-17]:
   

       This is a very good specification, and I would have voted Yes if it weren't for
   one technical issue:
   
   I do not understand how Section 5.2 mechanism:
   
            TOKEN_SECRET_DATA = HASH(QCD_SECRET | SPI-I | SPI-R | IPaddr-T)
   
   works in an implementation that supports multihoming (e.g., RFC 4555). Can you
   clarify?
   I would expect that the document at least has to be clearer about this,
   or perhaps the
   Section 5.2 mechanism needs to be changed or removed to
   accommodate for 
   multihoming. 
       

2. Adrian Farrel: Comment [2011-03-16]:
   

   Please expand acronyms on first use (such as "SA" in the Abstract)

3. Dan Romascanu: Discuss [2011-03-16]:
   

       The DISCUSS and COMMENT is based in part on the OPS-DIR review performed by
   Menachem Dodge.
   
   This is a well written and useful document and I will support its approval after
   the following two issues are discussed and fixed if agreed:
   
   1. I would have expected that the Operational Considerations section include
   some information about configuration. It looks at a minimum the activation of
   the QCD method should be configurable, and the capability to shitch it off in
   networks where it involves a security risk should be provided.
   
   2. In Section 9.2 last paragraph, it is not completely clear as to what method
   should be implemented in the case of a load-sharing cluster when the load
   balancer cannot guarantee that all "IKE packets from the same source IP address
   always go to the same cluster". Should QCD Token Transmission not be implemented
   in such a situation? 
       

4. Dan Romascanu: Comment [2011-03-16]:
   

   1. An abbreviation sub-section would have been very useful
   
   2.   Section 9.1 "QCD Token Generation and Handling", first paragraph, second
   sentence:
   
   Replace 'she' with 'they'
   
   OLD                  
   
   because if an attacker can guess the token associated with an IKE SA, she can
   tear down
   
   SUGGESTED 
   
   because if an attacker can guess the token associated with an IKE SA, they can
   tear down
   
   3. Section 9.2 "QCD Token Transmission" 3rd paragraph last sentence:
   
   Replace 'it' with 'this'
   
   OLD                 
   
   One way to do it is to synchronize
   
   SUGGESTED   
   
   One way to do this is to synchronize
   
    

draft-ietf-mip4-gre-key-extension

1. Stewart Bryant: Comment [2011-03-08]:
   

   "In the absence of this key identifier, the data streams cannot be distinguished
   from each other, a significant
    drawback when using IP-in-IP tunneling."
   
   Well understated.
   
   FA, HA, RRP, MN, RRQ, RRP used without first expansion.
   
   It would be useful to the reader if the 'G' bit was called by it's proper name
   (GRE Encapsulation) on first used, same for the 'D' bit.
   
   'The FA may include a GRE key of value zero in the GRE Key Extension to signal
   that the HA assign GRE keys in both directions.' - Minor grammar problem.
   
   'Encapsulati on Unavailable' - - Minor grammar problem.

2. Adrian Farrel: Comment [2011-03-16]:
   

   I have no objection to the publication of this documen, but there are a few
   small points that might be addressed to improve it.
   
   ---
   
   I don't think you need RFC 2119 notation in the Abstract.
   
   ---
   
   A number of acronyms are used without expansion
   
   ---
   
   Sections 4.1, 4.2, and 4.3 seem a bit confused on the use of RFC 2119 
   language and the cases where behavior is already defined in other 
   specifications. Could you spend a little time to clear this up and make
   clear what new behavior this document is defining.
   

3. Russ Housley: Comment [2011-03-16]:
   

     Something is wrong here:
     >
     > 4.2.  Home Agent Requirements for GRE Tunneling Support
     >    [RFC3344]
     >
     The reference is misplaced.  I think it belongs in the first
     sentence of the section.
   
     Please remove the extra spaces:
     >
     >    GRE encapsulation, it MUST send an RRP with code 'Requested
     >    Encapsulati on Unavailable (139)' [RFC3024] .

4. Peter Saint-Andre: Comment [2011-03-16]:
   

   It would be nice to expand "GRE" on first use to "Generic Routing Encapsulation"
   and also provide a reference to RFC 2784.

5. Sean Turner: Comment [2011-03-15]:
   

   1) Nits points out:
   
    -  ** Obsolete normative reference: RFC 3344 (Obsoleted by RFC 5944)
   
   2) If you end up doing another revision, please:
   
   a) expand GRE on 1st use in Abstract and Introduction.
   
   b) add a period to the end of the 1st paragraph in Section 7.
   
   Otherwise, please consider these during AUTH48 (if the RFC editor doesn't catch
   them).

draft-ietf-isis-genapp

1. Jari Arkko: Discuss [2010-10-07]:
   

       I support the publication of this document and I think it is a good
   and proper addition to the ISIS protocol.
   
   However, I have a specific technical concern. Section 6 says:
   
      The IS-IS WG of the IETF acts as the authority to determine whether
      information proposed to be advertised in IS-IS LSPs falls under this
      definition.
   
   But then Section 8 says:
   
      Registration procedure is "Specification Required" as defined
      in [RFC5226]
   
   If we are expecting to verify that the information falls under the
   right category, then Specification Required does not appear to be
   the right IANA rule. Or am I missing something? 
       

2. Jari Arkko: Comment [2010-10-07]:
   

3. Ron Bonica: Comment [2011-03-16]:
   

   I share Lars' allergy to using routing protocols to transport generic
   information. Maybe we should start thinking about a generic information
   transport protocol.

4. Lars Eggert: Discuss [2010-10-04]:
   

       I'm missing a crystal clear statement in a very visible spot that the content
   exchanged in GENINFO TLVs MUST NOT alter the behavior or operation of the IS-IS
   protocol and/or state machine. In other words, GENINFO is not a tool for a
   vendor to extended IS-IS in non-interoperable ways. The document does hint that
   this is the intent in a few places; I'm simply asking for making this very, very
   clear. 
       

5. Lars Eggert: Comment [2010-10-04]:
   

   (Non-actionable comment: I will likely abstain on this document even when the
   above change is made. The reason is that I'm allergic against the current trend
   of adding kitchen-sink options that turn all kinds of formerly purpose-built
   protocols info generic "information exchange" mechanisms.)

6. Adrian Farrel: Comment [2010-12-12]:
   

   Thank you for this draft, it is a necessary addition to the IS-IS family and for
   your work to address my Discusses and Comments.
   
   I have two small, non-blocking Comments remaining that could be looked at if the
   authors continue to work on the document.
   
   I think that the RFC Editor will ask you to jiggle the content/section-
   headings slightly. They have a preference for seeing Section 1 named
   "Introduction".
   
   ---
   
   This Comment moved from the Discuss...
   
   I feel a bit of a lack discusion of backwards compatibility.
   You need to cover how a legacy implementation will react to seeing the
   new GENINFO TLV (a reference to an existing RFC will do), and then 
   consider how this will apply to the utility of the extension (for 
   example, if all speakers participating in the IS-IS instance must be
   upgraded - I think they will because otherwise they will not see the
   flags fields in the new TLV).
   
   It would be helpful to add a brief statement in Section 4 along the lines of:
   
   "According to the rules of [RFC4971] a legacy implementation receiving a GENINFO
   TLV will ..."

7. Tim Polk: Discuss [2010-10-06]:
   

       The sole statement in the security considerations:
   
     This document raises no new security issues for IS-IS.
   
   I don't think that is quite true, albeit in a rather cyclic manner.
   
   First, I believe that the use of IS-IS as a transport does have security
   implications that need to be considered
   when specifying a new geninfo
   application ID. It would be helpful to describe the limitations implied by this
   transport,
   and when additional security mechanisms can be employed to extend the
   scope.  For example, the standard IS-IS
   cleartext password  might be
   insufficient for some types of data, requiring deployment of RFC 5304 or 5310
   authentication mechanisms.
   
   Second, deployment of advanced IS-IS security mechanisms (e.g., RFC 5310
   authentication) is something I
   personally advocate.   However, if an IS-IS
   deployment were to deploy these mechanisms solely to support
   advertisement of
   some generic information this may exacerbate any performance implications for
   the IS-IS
   deployment and could be used to launch denial of service attacks.
   That is, deploying IS-IS security mechanisms
   *because* of the generic
   information would be costly for the IS-IS implementation and would violate the
   usual 
   precept of "security commensurate with need".
   
   I think a paragraph or two (total) in the security considerations that addresses
   both these issues would be appropriate. 
       

8. Tim Polk: Comment [2010-10-06]:
   

   I support Lars' discuss,

9. Dan Romascanu: Comment [2011-03-15]:
   

   I dislike overloading protocols with exchanges of information that do not relate
   to the protocol functionality. However, at this phase, if the working group was
   chartered to do this work, I can accept such an extention as the GENINFO
   advertising of generic information. Separating it in a generic advertising
   extension rather than consuming from the expensive TLV space for each extension
   not related to routing is the right thing to do.
   
   Maybe the introduction should say something about the motivation for such a
   generic container within IS-IS and make possible recommendations of what future
   extensions using this container should include (or should not include).

10. Peter Saint-Andre: Comment [2010-12-07]:
    

11. Robert Sparks: Comment [2010-10-06]:
    

    I support Dan's discuss points. 
    
    The document could better motivate the need for a generic container. Could it
    explicitly call out the existing messages that would have been candidates for
    the use of this mechanism if it existed at the time?
    
    Would it make sense to add text reinforcing that elements not understanding this
    TLV would ignore-but-flood?

12. Sean Turner: Comment [2010-10-05]:
    

    1) Never seen 2119 language in Abstract.  Is this allowed by the RFC editor?
    
    2) Spell out LSP on first occurrence.
    
    3) Sec 2: It's odd that there are requirements in the overview section.  Could
    this be reworked?
    
    4) Sec 3 (and the rest of the document): RFC 5305 refers to sub-TLV not subTLV.
    This document should align with 5305.
    
    5) Sec 3.1: It would be nice if you assigned a word for the Flags: S (Scope), D
    (Down), I, and V.  It would be nice to assign a word to for "I" and "V" too.
    How about Ipv4 for "I" and ipV6 for "V".
    
    6) Sec 3.2: RFC 5035 has to following text about ignoring unknown sub-TLVs:
    "Unknown sub-TLVs are to be ignored and skipped upon receipt."  Does this draft
    want to use 2119 language to in fact require they be ignored?
    
    7) Sec 3.2: r/AND/and
    
    8) Sec 3.3: r/NOT/not
    
    9) Sec 7: r/IS-IS/IS-IS [RFC1195].
    

draft-ietf-geopriv-rfc3825bis

1. Jari Arkko: Comment [2010-12-02]:
   

   Ari Keränen reviewed this specification and he had a few comments:
   
   The abstract should state that this document obsoletes RFC 3825 and the 
   intro should explain why it's done (as described in the I-D checklist).
   
   However, instead of obsoleting 3825, wouldn't it make more sense to have 
   a new IPv4 DHCP option for this new version given that the new encoding 
   is not compatible with the old one and re-using the same value seems to 
   cause a lot of problems (as described in section 2.2.1)? Or otherwise it 
   would be good idea to mention the reason (preserving DHCP codes?) for 
   not doing so.
   
   2.3.  Latitude and Longitude Fields
   
       Latitude values encoded by the DHCP server MUST be constrained to the
       range from -90 to +90 degrees.  Location consumers MUST be prepared
       to normalize values outside this range.  Values outside the range are
       normalized by clamping [...]
   
   If the values MUST be within those boundaries, doesn't it mean that a 
   value that is out of the range is somewhat likely completely wrong (due 
   to a broken implementation) and thus it would make sense to ignore it 
   rather than try to normalize the value and make it appear as if it was 
   valid? I'm not sure if I'd like to be liberal in what I accept when it 
   comes to information that could literally be a matter of life and death.

2. Stewart Bryant: Comment [2010-12-01]:
   

   PIFF-LO term used but not defined
   GML term used but not defined
   Code:
   GEOCONF_GEODETIC (16 bits). is "Option Code" in the fig above.
   AType:
   Altitude Type (4 bits). would be clearer with a ref to section 2.4 (appears in
   two places)
   
   

3. Ralph Droms: Comment [2011-02-04]:
   

   I've cleared my DISCUSS.  I have a remaining minor
   comment - In the descriptions of the options, sentences like:
   
                 When the Ver field = 1, this field represents
                 latitude uncertainty.  The contents of this field is
                 undefined for other values of the Ver field.
   
   seem unnecessarily detailed.  Why not simply:
   
                 This field represents
                 latitude uncertainty.
   
   The descriptions of many fields say nothing about the version number.

4. David Harrington: Comment [2010-11-30]:
   

   This document is well-written, with clear and unambiguous language. 
   
   1) section 1, paragraph 4 says "The DHCP server could correlate the Circuit-ID
   with the geographic location where the
      identified circuit terminates (such as
   the location of the wall jack)." Would it be the job of the DHCP server to do
   this correlation? I would assume it was a NM application function to do such
   correlation. 
   2) In 2.2.1.2, s/same response. This is not useful since/same
   response, since/
   3) When aType=2, numbering starts at ground level. How does one
   represent an underground parking garage level?
   Should 2.4.3 mention how to
   represent this? Should Appendix B include such an example?

draft-ietf-v6ops-v6-in-mobile-networks

1. Ralph Droms: Comment [2011-03-16]:
   

   Seems like any statements like the following predicting the final
   allocation of IPv4 addresses are likely to be out-of-date or
   inaccurate.  I suggest eliding text like the following from section 3.1:
   
      The '/8' IANA blocks for Regional Internet
      Registries (RIRs) are projected to 'run-out' soon.  Subsequently, the
      addressing pool available to RIRs for assignment to Internet Service
      Providers is anticipated to run-out in the following 2-3 years.

2. Russ Housley: Comment [2011-03-15]:
   

     Following the Gen-ART Review by Kathleen Moriarty on 21-Feb-2011,
     several changes were agreed.  However, a revised document has not
     been posted yet.  Please make sure the revisions get included.

3. Sean Turner: Comment [2011-03-17]:
   

   The tense of the 1st sentence in the abstract and intro should probably be
   changed because the pool is now empty.

draft-ietf-morg-multimailbox-search

1. Stewart Bryant: Comment [2011-03-16]:
   

   ID-nits reports:
     -- The draft header indicates that this document updates RFC4466, but the
        abstract doesn't seem to mention this, which it should.
   

draft-eggert-tcpm-historicize

1. Adrian Farrel: Comment [2011-03-16]:
   

   I am ballotting "Yes" on this document, but there are a few issues I
   would like the author to consider before the document is passed to 
   the RFC Editor.
   
   ---
   
   Abstract
   
   Please change this text from a "recommendation" to an "action"
   
   ---
   
   Surely this is a Historic RFC in its own right? I.e., RFC 1072 et al
   are obsoleted by a Historic RFC.
   
   ---
   
   Section 2
   
      The RFC Editor is requested to change the status of the following
      RFCs to Historic [RFC2026]:
   
   I'm confused. Can the status of an existing RFC be changed? I thought
   it could only obsoleted.
   
   ---
   
   Section 3
   
   This says IANA should mark as "obsolete". Shouldn't you use 
   "deprecated"?
   
   I think you also need to tell IANA exactly what references they should
   place against each deprecated option.
   

draft-ietf-hip-cert

1. Adrian Farrel: Comment [2011-03-01]:
   

   Agree with Peter's Discuss. The update to 5201 should be noted in the document
   header and the Abstarct.
   
   ---
   
   Section 2
   
      It MAY either carry SPKI certificates or X.509.v3
      certificates.
   
   I think lower case "may" is more appropriate. Unless you mean...
   
      It MUST carry either SPKI certificates or X.509.v3
      certificates.
   

2. Russ Housley: Discuss [2011-03-15]:
   

       
     This discussion on the PKIX mail list is continuing.  Today the topic
     of unambiguous naming is still under discussion. 
       

3. Tim Polk: Comment [2011-03-17]:
   

   I support Russ's discuss position.  We need to let the PKIX discussion run its
   course.

4. Peter Saint-Andre: Comment [2011-03-09]:
   

5. Sean Turner: Comment [2011-03-16]:
   

draft-ietf-sidr-arch

1. Jari Arkko: Comment [2011-03-17]:
   

   From Ari Keränen's review:
   
   9. IANA Considerations
   
      This document requests that the IANA issue RPKI Certificates for the
      resources for which it is authoritative, i.e., reserved IPv4
      addresses, IPv6 Unique Local Addresses (ULAs), and address space not
      yet allocated by IANA to the RIRs. 
   
   It would be good to have explicit references to the documents where each of
   these "resources" are defined.
   
   draft-ietf-sidr-iana-objects-01 lists also AS numbers as such a resource; should
   that be listed here too?

2. Adrian Farrel: Comment [2011-03-17]:
   

   I am balloting "Yes" for this document, but there are a few minor nits
   that I hope the authors will attend to before publication.
   
   ---
   
   The Introduction uses "CRL" without explanation. This does show up in
   the Terminology section that follows immediately, but it would be nice
   to clarify in the Introduction.
   
   ---
   
   CRLDP shows up in Figure 3 and nowhere else in the document.
   Please add a note to the text.
   
   ---
   
   Figure 1 seems to be mysteriously missing.
   
   ---
   
   Section 4.3 has a slight disconnect between the specification of access
   protocols and the deployment of access protocols. Thus, when you say...
   
      each function must be implemented by at least one access protocol.
   
       
    ...I think you mean...
   
      each function must be implemented by at least one access protocol
      deployed by a repository operator.
   
   Similarly, when you say things like...
   
     Download: Access protocols MUST support the bulk download of  
   
       
    ...it is ambiguous whether you mean "all access protocols" or "at least
   one access protocol in the suite of access protocols" or "at least one
   access protocol deployed by the repository operator"
   
   ---
   
   Section 4.3
   
      To ensure all relying parties are able to acquire all RPKI signed 
      objects, all publication points MUST be accessible via RSYNC (see 
      [RFC 5781] and [RSYNC]), although other download protocols also be 
      supported.
   
   s/also/may also/
   
   ---
   
   Section 5
   
   Since according to this text a manifest is a signed object, and since
   the manifest is presumable issued by the authority, I would assume that
   a manifest includes itself in its listing. But perhaps you should 
   clarify this one way or the other.
   

3. Russ Housley: Comment [2011-03-15]:
   

     Please consider the comments from the Gen-ART Review by
     David Black on 24-Feb-2011.

4. Alexey Melnikov: Discuss [2011-03-15]:
   

       This is a well written document and I support its publication. However I have a
   small pedantic DISCUSS which should be easy to address:
   
   1). 
   9. IANA Considerations 
   
      This document requests that the IANA issue RPKI Certificates for the 
      resources for which it is authoritative, i.e., reserved IPv4 
      addresses, IPv6 Unique Local Addresses (ULAs), and address space not 
      yet allocated by IANA to the RIRs. IANA SHOULD make available trust 
      anchor material in the format defined in [SIDR-TA] in support of 
      these functions. 
   
   Is this the right document? I thought that was already specified in draft-ietf-
   sidr-iana-objects.
   
   2).
   11.2. Informative References 
   
      [RFC 5781] Weiler, S., Ward, D., and Housley, R., "The rsync URI 
                 Scheme", RFC 5781, February 2010. 
   
   This reference is Normative, because of the use of a MUST. 
       

5. Alexey Melnikov: Comment [2011-03-15]:
   

   4.2. Contents and structure 
   
      For every certificate in the PKI, there will be a corresponding file 
      system directory in the repository that is the authoritative 
      publication point for all objects (certificates, CRLs, ROAs and 
      manifests) verifiable via this certificate. A certificate's Subject 
      Information Authority (SIA) extension provides a URI that references 
      this directory.
   
   An Informative reference to the URI RFC is needed here.

draft-ietf-netext-pmip6-lr-ps

1. Russ Housley: Comment [2011-03-15]:
   

     Please consider the comments in the Gen-ART Review by Joel Halpern
     on 7-Mar-2011.  I believe the improved clarity will be helpful.

2. Dan Romascanu: Comment [2011-03-16]:
   

   The comment is based in part on the OPS-DIR review performed by Nevil Brownlee. 
   
   1) I do not think that the document needs to be blocked for this, but I think
   that such document should also deal with the the Operational and Manageability
   considerations and include a section on this respect. At a minimum I would have
   expected some refering or estimation on the impact on traffic parameters in the
   network as local routing is designed to reduce latency and backhaul load. Also
   do we expect any extra extensions or attributes to be needed in the interaction
   between MAG and RADIUS servers?
   
   2)  Missing also is any mention of scalability. This document describes the
   problem of optimising routing in a Local (i.e. single provider, or maybe 2~3
   providers) setting. Scaling issues will need to be considered in an actual
   specification (clearly it will have to handle the maximum number of active
   mobile nodes).

draft-zhu-mobility-survey

1. Stewart Bryant: Discuss [2011-03-16]:
   

       ID-Nits says: 
   
    ** The document seems to lack a Security Considerations section.
   
     ** The document seems to lack an IANA Considerations section.  (See Section
        2.2 of http://www.ietf.org/id-info/checklist for how to handle the case
        when there are no actions for IANA.)
   
     ** The document seems to lack separate sections for Informative/Normative
        References.  All references will be assumed normative when checking for
        downward references.
   
       

2. Stewart Bryant: Comment [2011-03-16]:
   

   I can't check the reference so I can't figure out if there is any trade name
   issue with reference "Sony". Did the authors of the paper work for Sony?

3. Adrian Farrel: Comment [2011-03-17]:
   

   Support Stewart's Discuss. There is no reason for I-Ds to turn up in evaluation
   without having run idnits

4. Russ Housley: Discuss [2011-03-16]:
   

       
     The authors agreed to some changes based on the Gen-ART Review by
     Richard Barnes on 28-Feb-2011.  Please make those changes. 
       

5. Dan Romascanu: Comment [2011-03-17]:
   

   I support Stewart's DISCUSS. 
   
   I am wondering why was this document AD-sponsored and did not go on the
   Independent Stream. It obviously required quite a lot of efforts from the
   sponsoring AD (and the rest of the IESG) as there is a lot of information about
   more than a dozen of protocols whose accuracy needs to be verified. Then there
   will be some more as the document has obvious formatting and document structure
   issues. It is not clear to me what is the benefit.
   
   Also, if we already are approving such a broad protocols survey I would have
   expected some informations about operational and manageability considerations.
   There is a discussion about deployment issues (which is good) but this is not
   sufficient.

6. Peter Saint-Andre: Comment [2011-03-16]:
   

   This is a fine document and I support its publication as an Informational RFC. 
   
   I have one nit: the use of "mobile" as a noun (e.g., "A system that keeps track
   each mobile's reachability during the mobile's moving") is colloquial and
   potentially confusing (e.g., in "mobile replies" is the term a noun or an
   adjective?). Because you do not want to distinguish between mobile nodes and
   mobile subnets, I suggest "mobile entity".
   
   (There are also typographical errors, such as "Protocols like E2E, ILNP and BTMM
   fail into this design" instead of "fall into", but I assume that those will be
   fixed during the RFC Editor's review.)

draft-herzog-static-ecdh

1. Adrian Farrel: Comment [2011-03-16]:
   

   I have No objection to the publication of this document, but I have a
   couple of minor editorial points that could usefully be fixed to
   improve the document.
   
   ---
   
   The term "MACed" is used without explanation.
   
   ---
   
   Section 1
   
      All three of these types share the same basic structure.  First, a
      fresh symmetric key is generated.
   
   There is a slight syntactic disconnect between these two sentances. Do
   you mean the second sentance to be a process description (in which case
   a paragraph break would be in order)? Or do you mean to describe the
   shared basic structure in some way?
   
   ---
   
   Section 1
   
      o  key transport: the symmetric key is encrypted using the public
         encryption key of some recipient,
   
   To be very picky...
   Do you mean "encryption key of the intended recipient"?
   
   And Later...
   
      In this case, the participants are the originator and
      one of the recipients.
   
   Again "the intended recipient" seems a better phrase.
   
   ButI am somewhat worried that you have said "one of the recipients" 
   given tat in the case of multiple recipients (that is implied by your
   language) I don't see how the other recipients will be able to function
   as they will not have access to the necessary key.
   
   ---
   
   Section 2
   
      the RecipientInfo kari choice is used.
   
   Is "kari" an unexplained term or a typo?
   
   ---
   
   "ukm" is used without expansion
   
   ---
   
   Section 2.1 contains a number of MUST statements. Section 2.3 should 
   give an indication of what the receiver does when one of these MUSTs
   is violated. This may be as simple as a reference to [CMS].
   

draft-meadors-multiple-attachments-ediint

1. Stewart Bryant: Comment [2011-03-16]:
   

   There are a number of id-nits that need be fixed before the document considered
   ready for publication (IANA section and RFC2119 language). Also the editor
   should confirm that all of the lower case "should" instances are correctly set.

2. Russ Housley: Comment [2011-03-16]:
   

     In the Gen-ART Review by Pete McCann on 15-Mar-2011, a concern is
     raised.  Please consider it:
   
     There is a space in the declaration of boundary=" INNER-BOUNDARY";
     in the example in section 3.  I am not sure whether this was
     intentional or whether it will mess up a standard MIME parser, but
     you may want to remove it.

3. Alexey Melnikov: Comment [2011-03-12]:
   

   Should this document be published with "no IETF consensus" boilerplate?
   

4. Sean Turner: Discuss [2011-03-17]:
   

       update based on Alexey's RFC editor note.
   
   #1) In Sec 2.3, need a normative reference to the canonicalization method.
   
   #2) In Sec 2.5, need normative references for each content types list.
    
       

5. Sean Turner: Comment [2011-03-16]:
   

   Sec 2.3 says: 
   
      If the expected MIC value differs from the calculated MIC value, all
      attachments MUST be considered invalid and retransmitted.
   
   Isn't telling the initiator that they didn't match and asking for the
   retransmission missing?

draft-mrw-nat66

1. Stewart Bryant: Discuss [2011-03-15]:
   

       The purpose of this discuss is to confirm that there are no undocumented issues
   associated with the use prefix bits in the range 64 to 127 to fix up the
   checksum. These are surely real network addresses elsewhere in the net, and
   therefore may be destinations addresses of packets passing through the
   translator.
   
   Section 4.3 states that a node MUST support hairpinning. Does it need to say
   that it MUST NOT do internal route optimization?
   
   Does an internal router placed between a host and the translator correctly route
   packets in this translated range?
   
       

2. Stewart Bryant: Comment [2011-03-15]:
   

   STUN, TURN, ICE should have references

draft-zhu-mobileme-doc

1. Lars Eggert: Discuss [2011-02-18]:
   

       I'm holding a discuss on my own document, because the IETF last call ends one
   day after the telechat date. 
       

2. Peter Saint-Andre: Comment [2011-03-16]:
   

   In Section 3 we find:
   
      BTMM uses "_udp" to tunnel packets between the
      two ends to achieve NAT traversal.
   
   I think you mean "UDP", not "_udp".
   

3. Sean Turner: Comment [2011-03-16]:
   

   #1) In Sec 7.1, I had trouble parsing the following:
   
      When the user first signs in to MobileMe on a host, it automatically
      receives from KDC a digital certificate and private key for "Back to
      My Mac Encryption Certificate".

draft-hu-flow-label-cases

1. Stewart Bryant: Discuss [2011-03-16]:
   

       This is a discuss discuss that I expect to clear on the call.
   
   This is a fine document and I have no objection to it's publication. However I
   am surprised  that it has not gone through a WG. Review by a WG would result in
   a more complete validation that all the proposals had been captured, and that
   the conclusion represented the wider view of the IETF.