IESG Narrative Minutes

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

Narrative scribe: Barry Leiba and Susan Hares (The scribe was sometimes uncertain who was speaking.)

1 Administrivia

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

1.1 Management Issue inserted

  1. ITU Update (Adrian and Stewart)

    Telechat:

    2. Protocol Actions

    2.1 WG Submissions

    2.1.1 New Items

    1. Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry (BCP)
      draft-ietf-tsvwg-iana-ports-10
      Token: Alexey Melnikov
      Note: Gorry Fairhurst (gorry@erg.abdn.ac.uk) is the document shepherd.
      Discusses/comments (from ballot 3225):
      1. Stewart Bryant: Comment [2011-02-15]:
        I have one question which is almost a discuss discuss. Should IANA reserve/have a special request process for services that contain IETF key words that imply critical IETF services (IETF, BGP, MPLS...) so no one can pass of a proprietary design as one approved by the IETF.
      2. Adrian Farrel: Comment [2011-02-15]:
        I am worried that this document should discuss deprecation. I don't think it is important enough for a Discuss, but would appreciate the authors considering this. IMHO, it is subtly different from de-assignment.
      3. Alexey Melnikov: Comment [2011-02-15]:
        I need to check if IETF LC comments regarding anonymous reviewers should be addressed
        - as per document authors this is out of scope for this document and will be described in another document.
        (Currently internal processes of the IANA ports and services design team are not documented by any RFC. This document doesn't change that.)
      4. Tim Polk: Comment [2011-02-16]:
        (1) In section 7.2, the word "strives" and phrase "strive to" are used repeatedly in an effort to give IANA some wiggle room. While wiggle room is probably a necessity, it would be helpful to explain when the wiggle room may reasonably be required. It would probably be good to require additional information in the request whenever the submitter asks IANA to violate these principles.
        This *might* help avoid some appeals.
        (2) In 8.2, the process for de-assignment can only be initiated by the Assignee: "The Assignee of a granted port number assignment can return the port number to IANA at any time if they no longer have a need for it."
        Section 8.4, revocation, would presumably cover the case where the process was initiated by someone other than the Assignee. However, there doesn't seem to be a mechanism for a 3rd party to indicate they believed specific ports could safely be de-assigned/revoked. Should this section provide instructions (e.g., email destination, preferred subject line, required contents) for such submissions?
        [Note: the remainder of 8.4 seems entirely satisfactory to process such a request...]
        (3) Waiting to see what Alexey determines about anonymous reviewers :)
      5. Peter Saint-Andre: Discuss [2011-02-15]:
        I am strongly in favor of this document and will probably change my ballot to "Yes" once we have a chance to discuss the following two issues.
        1. [addressed by existing text, clarified through discussion]
        2. Regarding port numbers, Section 8.1.1 states:
        "Note that the applicant MUST NOT use the requested port prior to the completion of the assignment."
        This seems quite unrealistic, because developers (and developer communities) use ports all the time when designing and testing application protocols Prohibiting such experimentation strikes me as detrimental to innovation and opposed to the IETF's principles of "rough consensus and running code".
      6. Robert Sparks: Comment [2011-02-17]:
        1) I can't see how "IANA strives to" is functionally in any way different from "IANA SHOULD". What do you expect either IANA or the expert reviewers to do differently given those different phrases as guidance?
        2) This document should acknowledge that the conversation around non-anonymous expert review happened, call out the conclusion (I believe we saw community consensus that it was important), and recommend the work that would need to happen to put that in place.
      7. Sean Turner: Comment [2011-02-17]:
        (I didn't think of this but it might be a good idea)
        It would be nice to have something that would allow a 3rd party to indicate that a service name/port number can be de-assigned. For example, the assignee is unreachable and their company have gone belly up. Their protocol was never widely deployed and ten years later it's completely gone. A good netizen could inform IANA about this and then IANA could determine whether it's true and de-assign the name/number.

      Telechat:

      • Alexey: Let's quickly talk about this. Peter, do we need to discuss the second point of your discuss?
      • Peter: No.
      • Alexey: I'll try to convince Joe to change the wording.
      • Robert: I suppose Peter's sentiment on that; he's not alone.
      • Alexey: I get his point. OK, let's do this by email.
      • Lars: Maybe we can rephrase this [proposes wording].
      • Alexey: Experimenting with a port is OK as long as it doesn't leak. I think I can add some RFC-ed notes on this, but let's go to email. Other point worth mentioning is that Cullen's LC comments raise the question about scope of the doc. Among the authors, and I agree, the scope of the doc is basically to restructure and unify IANA registries. It's not talking about the specific process of the review team. It also doesn't talk about specific details about why one port is preferred to multiple. There is apparently no consensus on this point. I think a paragraph near the beginning of the doc clarifying scope would be good.
      • Lars: That sounds OK.
      • Peter: That would help, because people think it's saying more than it is.
      • Lars: There's a disconnect here, so if we can clarify it in the intro, that's good. This is meant to describe procedures for IANA with the registry. It's not meant to be a guide for the public. That's not clear to many people. This could be a never-ending doc, and I think it's good enough now.
      • Alexey: That's the major concern: if we start describing review team process, it's controversial, and it will drag on. Restructuring the registries is the important par.
      • Robert: Restructuring the registries is copping out, not talking about how IANA works with the review teams.
      • Lars: No other expert review teams have their procedures described in much detail. The reason they're called experts is that we trust their technical opinions.
      • Robert: You're talking about not putting in vast sections. I'm just talking about not even touching the anonymous review thing because it's out of scope. That particular detail should be in scope. We do, with a lot of documents, give guidance to the experts. it would be reasonable to have that in here.
      • Lars: This doc has some of that. I also want to mention about public reviewers, this is something we have to discuss in the scope of RFC 5226, in general.
      • Michelle: For all registries, the name of the reviewer is public. We had a talk about this, to say in the response "your application was reviewed by X". We're doing that for all registries. I don't think this is an issue any more.
      • Jari: I'm basically siding with Lars. There's a set of things you could say about the guidance, and I think this is saying enough, or close to it. It wouldn't help to make it too detailed. I'm in favour of letting this doc move forward.
      • Robert: I balloted "no obj", ad made comments. I think we actually lose some benefit of the energy by pretending this discussion didn't happen.
      • Lars: There were issues with insufficient information in requests, and there was some bad interaction with the reviwers as a result. That's why the reviewers want some sort of anonymity. The reviewers need to be able to be candid and not have to defend their positions in public. Opening up the information about who the reviwers are can be problematic. It's not easy to find reviewers, and we don't want to lose them because of things like this.
      • Robert: Open process is open. Discussions should happen on the lists. There are ways to mitigate the pain if we want to make this review process more open, and I think we should. But I think we don't hold up this doc to make that happen.
      • Peter: I agree that we should make this as transparent as we can.
      • Alexey: I was pushing editors to work on another doc in this area. But this will take time.
      • Peter: I don't want to hold this up, but let's note somewhere that this conversation happened, and further work is required.
      • Alexey: I can add a comment in the tracker.
      • Ralph: I thought you were talking about deleting sec 7 entirely. Is that true?
      • Alexey: We're still discussing. I don't think it will happen.
      • Robert: I would object.
      • Alexey: If a better argument is made to delete it, I'll bring it to the IESG.
      • Lars: There's been no discussion of that among the authors.
      • Alexey: We still have some discussion among editors. We have some time to get closure here in the next couple of weeks. I'll take the discussion with Peter to email, and I'll enter more RFC-ed notes based on our discussions.
      • Amy: Will this require revised ID?
      • Alexey: Not sure. I think I can do it with RFC-ed notes.
      • Amy: I'll put it in AD followup.

    2. IS-IS Extensions Supporting IEEE 802.1aq Shortest Path Bridging (Proposed Standard)
      draft-ietf-isis-ieee-aq-04
      Token: Stewart Bryant
      Note: David Ward (dward@juniper.net) is the document shepherd.
      Discusses/comments (from ballot 3660):
      1. Tim Polk: Discuss [2011-02-16]:
        The security considerations state: "If zero configuration methods are used to auto configure NNIs or UNIs there are intrinsic security concerns that should be mitigated with authentication procedures for the above cases. Such procedures are beyond the scope of this document." draft-ietf-isis-ieee-aqWhile these procedures are beyond the scope of this document, it would be helpful to identify which procedures the authors have in mind (or note that such procedure have yet to be developed).
      2. Dan Romascanu: Discuss [2011-02-14]:
        1. The following convention is defined for the document in Section
        "The lower case forms "must", "must not", "shall", "shall not", "should", "should not" and "may" in this document are to be interpreted in the sense defined in [RFC2119], but are used where the normative behavior is defined in documents published by SDOs other than the IETF."
        There are two problems here that attracted my attention:
        - should really any form of "must" or "should", etc. that appears in this document be interpreted in the sense defined in [RFC2119]? This does not seem to be the intention, and I would prefer to make clear that this interpretation applies only in the sections that deal with the IEEE 802.1 documents.
        - The keywords "recommended" and "optional" are missing from the list. Is this intentional? While I could not find any instances of "recommended" I did find a few instances of "optional" which I would think should be interpreted in the sense defined in [RFC2119] - for example in section 4.1
        2. In the IANA considerations section:
        "The MT-Capability TLV is the only TLV requiring a new sub-registry. Type value 144 (TBD) is requested, with a starting sub-TLV value of 1, and managed by Standards Action."
        Is really Standards Action necessary? Why would not Expert Review be sufficient?
      3. Peter Saint-Andre: Comment [2011-02-16]:
        I agree with Dan Romascanu's DISCUSS regarding lower-case conformance keywords -- they are confusing
      4. Sean Turner: Comment [2011-02-17]:
        I support Tim's discuss.
        Also, is this draft going to be held by the RFC editor while the 802.1aq draft goes final? The normative reference is to a DRAFT of the IEEE spec.

      Telechat:

      • Stewart: I'd like advice about one item. Dan, the authors will sort your discuss out. This is essentially an enabling doc, the twin of the trill specs. The question is how much I need to push them on a sec consid section. The second question has to do with what we do about normative dependency on the IEEE spec. I'm keen to make IEEE not get the impression that IETF is sitting on this to delay them.
      • Tim: On sec consid, I don't think there's much more for them to do. They made significant improvements based on the secdir and opsdir reviews. One issue is talking about authentication problem, where they do hand-waving. Need to be clear whether there's new engineering that needs to be done. I think we need that. But that's the only question that's raised.
      • Stewart: I'd like to get your help on that. What do we do about the normative ref to the IEEE spec?
      • Dan: What is the spec that's referenced?
      • Stewart: The rest of the AQ design itself. We only do a piece of it.
      • Tim: Is that doc not stable yet? A draft?
      • Stewart: I don't know how close to gelling it is. I don't know how the IEEE process works, I think they need an RFC number.
      • Dan: Do they need an RFC number from us?
      • Russ: Do they need IANA numbers, or RFC numbers?
      • Dan: IEEE specs have two types of ref, equivalent to ours.
      • Stewart: They need our IANA stuff before they finish.
      • Russ: We can give them that before RFC if that's sufficient.
      • Stewart: I'll talk to the authors and find out what they need. I want the IETF to be whiter than white in dealing with this.
      • Michelle: Is this doc approved already?
      • Stewart: It has discusses, but we think we can resolve quickly.
      • Michelle: IANA will assign the numbers as soon as it's approved.
      • Stewart: They can probably be OK with it in the editor queue. I'll find out when they need the RFC number. And it's "revised ID".

    3. Using 127-bit IPv6 Prefixes on Inter-Router Links (Proposed Standard)
      draft-ietf-6man-prefixlen-p2p-01
      Token: Jari Arkko
      Note: Bob Hinden (bob.hinden@gmail.com) is the document shepherd.
      Discusses/comments (from ballot 3676):
      1. Ralph Droms: Comment [2011-02-14]:
        Pedantic, editorial nits...
      2. Lars Eggert: Comment [2011-02-15]:
        Section 6., paragraph 3:
        a) Addresses with all zeros in the rightmost 64 bits SHOULD NOT be assigned as unicast addresses, to avoid colliding with the Subnet-Router anycast address [RFC4291].
        b) Addresses in which the rightmost 64 bits are assigned the highest 128 values, (i.e., ffff:ffff:ffff:ff7f to ffff:ffff:ffff:ffff), SHOULD NOT be used as unicast addresses to avoid colliding with Reserved Subnet Anycast Addresses [RFC2526].
        Any reason these are not MUST NOTs?
      3. Adrian Farrel: Comment [2011-02-17]:
        I have reduced my position from a Discuss after useful discussion with two of the authors about whether an "updates" clause would be useful/relevant.
        It would be good to find a way to dilute the language that appears to say the I-D is fixing some specific issues in a specific RFC. Maybe a way forward would be to be more positive about this document "This document provides a definitive statement on..." "This document clarifies issues in a number of previous RFCs that have led to misunderstandings..." "This document offers latest guidance / best common practice on the use of..."
        I'll leave this with the authors/shepherd/AD to think about, and if you think it is silly or wrong or impossible, then it's your document and this is only a Comment.
      4. Sean Turner: Comment [2011-02-16]:
        #1) Sec 3: s/does not apply/do not apply
        #2) Sec 5.1: s/which uses medium/which use a medium

      Telechat:

      • Amy: No issues on this. No objections: approved.

    4. IS-IS Registry Extension for Purges (Proposed Standard)
      draft-ietf-isis-reg-purge-00
      Token: Stewart Bryant
      Note: David Ward (dward@juniper.net) is the document shepherd.
      Discusses/comments (from ballot 3678):
      1. Ralph Droms: Discuss [2011-02-16]:
        Following up to get a bit of history filled in, section 3.3.1 of RFC 3563 indicates that, as of the time of publication of RFC 3563, ISO/IEC JTC1 would take over the IS-IS registry:
        "Until JTC1 provides the registry service for IS-IS, IANA is requested to temporarily maintain such a registry as described below. Upon notification from JTC1, the registry management authority (i.e., value allocation) will be transferred to JTC1. [...]"
        Has this transfer of registry service to JTC1 taken place or (as I assume) is the IANA registry still authoritative? Is there still a need to notify JTC1 of the change to the registry proposed in this document?
      2. Lars Eggert: Comment [2011-02-15]:
        Agree with Dan that this document should be on a telechat AFTER it passes IETF last call (unless this is urgent in some way?)
        Section 4., paragraph 1: "This document requests that IANA modify the IS-IS 'TLV Codepoints Registry' by adding a column in the registry for 'Purge'. A 'y' in this column indicates that the TLV for this row MAY be found in a purge. A 'n' in this column indicates that the TLV for this row MUST NOT be found in a purge."
        It would be slightly more self-explanatory if the registry column was titled "Allowed in Purge".
      3. Tim Polk: Discuss [2011-02-16]:
        This is a fine document, and I support its publication, but...
        I was surprised to find an extensive update to the purge processing and generation rules in this document. The title, abstract, and introduction gave me no clue that there would be new processing rules. Perhaps that merits a mention somewhere before section 3?
      4. Dan Romascanu: Comment [2011-02-14]:
        I have no objection with approving the document as it stands right now but I observe that there is an IETF Last Call running for it and lasting six days after the IESG telechat date. I suggest that any approval be conditional, and in case substantial comments are submitted as Last Call comments after the IESG telechat they are brought to the attention of the IESG.

      Telechat:

      • Stewart: Good dialogue between authors and ADs. I thought we were close to resolution. In the case of Ralph's, it seems that everyone knows the history and what's happening.
      • Ralph: If everyone knows the history, that might be in the category of the IPv6 document cleanup. Maybe we need a doc that says this registry belongs to IANA. I'll clear.
      • Stewart: Did authors get back to Tim on your discuss?
      • Tim: He proposed text for the abstract, which I'd like to see in the body too. I'll clear if you do that as a note.
      • Stewart: It needs to go to point raised.
      • Amy: AD follow-up.

    5. Purge Originator Identification TLV for IS-IS (Proposed Standard)
      draft-ietf-isis-purge-tlv-05
      Token: Stewart Bryant
      Note: David Ward (dward@juniper.net) is the document shepherd.
      Discusses/comments (from ballot 3679):
      1. Ralph Droms: Comment [2011-02-16]:
        Balloting no objection assuming there is an easy answer to my question (posted to draft-ietf-isis-reg-purge-00) about the IANA ISIS-TLV registry and notifying ISO JTC1.
      2. Tim Polk: Comment [2011-02-16]:
        In the Intro, this document states: "Field experience has observed several circumstances where an IS can improperly generate a purge. These are all due to implementation deficiencies or implementations that predate [ISO TC1] and generate a purge when they receive a corrupted LSP."
        In the security considerations, it is noted that: "Therefore, all implementations in a domain implementing authentication MUST be upgraded to receive the POI TLV before any IS is allowed to generate a purge with the POI TLV."
        Since you need to touch every ISIS implementation in the domain anyway, is it worth stating that implementations SHOULD be updated for consistency with [ISO TC1] (i.e., and not generate a purge when they receive a corrupted LSP) at the same time?
      3. Dan Romascanu: Comment [2011-02-14]:
        "This document requests that IANA assign code point 13 for the 'Purge Originator Identification' TLV from the IS-IS 'TLV Codepoints Registry'. The additional values for this TLV should be: IIH:n, LSP:y, SNP:n, Purge:y."
        I assume that this is OK with this document but usually an Internet-Draft cannot / should not make a request for a specific value, but just require a code point value and recommend that this value be 13.
      4. Sean Turner: Comment [2011-02-16]:
        Please add a pointer for where I can find the definition of system ID.

      Telechat:

      • Stewart: I need to go through the comments on this to make sure they're addressed properly.
      • Amy: Aproved, point raised, writeup needed.

    6. A Registry for PIM Message Types (Proposed Standard)
      draft-ietf-pim-registry-04
      Token: Adrian Farrel
      Note: Mike McBride (mmcbride@cisco.com) is the document shepherd.
      Discusses/comments (from ballot 3686):
      1. Lars Eggert: Comment [2011-02-15]:
        Section 3.2., paragraph 1: "Assignment of new message types is done according to the "IETF Review" model, see [RFC5226]."
        It'd be good to add "or IESG Approval" here - there are sometimes cases where that shortcut is needed.
      2. Tim Polk: Comment [2011-02-16]:
        I can't remember if there is a precedent for registry documents achieving PS. The decision to reserve the value 15 to support extensibility might be justification, but that seems relatively weak. So, I support discussing Robert's issue, but do not have a particularly strong position either way. If anyone can point out precedent justifying going PS that would be enough for me...
      3. Dan Romascanu: Discuss [2011-02-17]:
        3.2. Assignment of new message types: "Assignment of new message types is done according to the "IETF Review" model, see [RFC5226]."
        Adding new message types would update this document whose intended status is PS. It looks like "IETF Review" policy is not enough, as IETF Review does not mandate a standards track document, but just WG or AD-sponsored documents that go through IETF Lasc Call (but still could be Informational or Experimental). ":Standards Action" policy seems to be needed in order to update this document.
        Note that if Robert's DISCUSS is resolved by donwngrading the intended status of this document to Informational, than "IETF Review" would be sufficient.
      4. Robert Sparks: Discuss [2011-02-15]:
        Why is the intended status PS? This isn't a candidate for progression on the standards ladder (an interop report will never make sense).

      Telechat:

      • Amy: We can't discuss this with Adrian, because he's had to leave.
      • Robert: At least one is something we can start discussing, and continue on next call. I'll take the token to find the next time we can discuss it. It had to do with the intended status of docs that are just creating a registry. Things that don't have protocol don't make sense on standards track. 2026 talks about this, and this was one reason BCP was created. This particular doc would be fine as informational. Having these kinds of docs go out as PS wouldn't be terrible, but it confuses what standards track is. Dan has a discuss that refers to mine. I was planning to clear. Should I not?
      • Dan: No, hold discuss. If the status changes it will handle mine as well.
      • Robert: It looks like you're worried that if something registers a code point in this registry, it will have to update this doc.
      • Dan: Yes. This .... document that creates a new message type. An information can't update a standards track doc. If intended status stays as PS, then the policy needs to be changed to "standards action".
      • Robert: Or some text could be added to make this explicit.
      • Stewart: It does give the procedure for new entries. We have precedents for documents that create registries and are never updated.
      • Robert: Dan's objection is that there are particular code points that seem to have higher level of protection.
      • Dan: The ones that are in there are fine. 11 are allocated, and 12 to 15 are for future use. I'm concerned about the status of future docs.
      • Stewart: It says that anything that uses 12 to 15 must have gone through IETF review.
      • Dan: I don't believe that's sufficient.
      • Stewart: What else is needed?
      • Dan: I don't know.
      • Robert: As I understand it, an informational RFC that registers these might have to update this RFC.
      • Stewart: This tells you how to add new code point. We never have to update others like this.
      • Dan: It would modify the table in the registry.
      • Robert: Following the procedure that's established. The table in this doc seeds the registry, but isn't the registry.
      • Dan: OK. I would prefer more clear wording in this doc.
      • Stewart: There is precedent for this. 4446 set up initial pseudowires registries. That was a BCP.
      • Dan: I am clearing.
      • Robert: Do you want a comment that you want extra clarity that this is just a seed? I'd like Adrian to consider making this informational, but please clear my discuss.
      • Amy: I will clear for you. Adrian wants this to go to point raised, writeup needed.

    2.1.2 Returning Items

    1. (none)

    2.2 Individual Submissions

    2.2.1 New Items

    1. Metalink/HTTP: Mirrors and Cryptographic Hashes in HTTP Header Fields (Proposed Standard)
      draft-bryan-metalinkhttp-20
      Token: Alexey Melnikov
      Discusses/comments (from ballot 3640):
      1. Lars Eggert: Discuss [2011-02-15]:
        INTRODUCTION, paragraph 4: "This document specifies Metalink/HTTP: Mirrors and Cryptographic Hashes in HTTP header fields, a different way to get information that is usually contained in the Metalink XML-based download description format. Metalink/HTTP describes multiple download locations (mirrors), Peer-to-Peer, cryptographic hashes, digital signatures, and other information using existing standards for HTTP header fields. Clients can use this information to make file transfers more robust and reliable."
        DISCUSS: The document title and this summary aren't really accurate. In addition to describing how to store Metalink info in HTTP header fields, a large part of the document (Section 7) is actually specifying how Metalink clients MUST/SHOULD/MAY operate.
        Section 3.3., paragraph 1: "There are two types of mirror servers: preferred and normal. Preferred mirror servers are HTTP mirror servers that MUST share the same ETag policy as the originating Metalink server and/or MUST provide Instance Digests using the same algorithm as the Metalink server."
        DISCUSS: Section 1 said "SHOULD share the same ETag policy" - which is it?
        Section 7., paragraph 13: "If the object is large and gets delivered slower than expected, then the Metalink client MAY start a number of parallel ranged downloads (one per selected mirror server other than the first) using mirrors provided by the Link header fields with "duplicate" relation type. Metalink clients SHOULD use the location of the original GET request in the "Referer" header field for these ranged requests.
        DISCUSS: I realize that this spec doesn't really cover the client, but I find this description of permitted client operation problematic. What it basically says is "if the download is slow, open more connections." This is NOT a good general practice. There need to be limits on the number of parallel connections, ideally based on observing how the aggregate throughput changes as connections are opened - blindly opening connections once the path bottleneck is filled is pointless. (There is some text later in this section that goes in this direction, but not far enough.)
      2. Lars Eggert: Comment [2011-02-15]:
        Section 3.2., paragraph 1: "Entries for a mirror servers can have a "geo" value, which is a [ISO3166-1] alpha-2 two letter country code for the geographical location of the physical server the URI is used to access. A client can use this information to select a mirror, or set of mirrors, that are geographically near (if the client has access to such information), with the aim of reducing network load at inter-country bottlenecks."
        s/can/MAY/? The document is generally pretty sloppy in its use of RFC2119 terms; it would be very good if the authors would go over it once more.
        Section 4., paragraph 1: "Entries for metainfo files, which describe ways to download a file over Peer-to-Peer networks or otherwise, are specified with the Link header fields [RFC5988] and a relation type of "describedby" and a type parameter that indicates the MIME type of the metadata available at the URI. Since metainfo files can sometimes describe multiple files, or the filename may not be the same on the Metalink server and in the metainfo file but still have the same content, an optional name parameter can be used."
        s/optional/OPTIONAL/ and/or s/may/MAY/
        Section 4.1., paragraph 1: "Full Metalink/XML files for a given resource can be specified as shown in the example in Section 4."
        Specify-by-example isn't how things are usually done in the IETF. It would be good to have an actual specification.
      3. Alexey Melnikov: Comment [2011-02-15]:
        IETF LC ends 1 day after the assigned telechat day (i.e. on February 18th).
      4. Peter Saint-Andre: Discuss [2011-02-16]:
        Overall I don't see any insuperable problems with this specification, although the protocol introduces the possibility of several kinds of amplification attacks and denial of service attacks (see RFC 4732, which could usefully be added to the references). Robert Sparks and I chatted about those a bit today and I concur with the DISCUSS he has posted.
        In addition, I have a concern with the following text from Section 7.1.1: "ETags can not be used for verifying the integrity of the received content. But it is a guarantee issued by the Metalink server that the content is correct for that ETag. And if the ETag given by the mirror server matches the ETag given by the Metalink server, then there is a chain of trust where the Metalink server authorizes these responses as valid for that object."
        The term "chain of trust" is a bit strong here, given that "trust chain" is a synonym for "certification path" according to RFC 4949. In addition, the presence of an identical ETag does not guarantee that the mirror is truly *authorized* by the Metalink server, because a malicious mirror could simply copy whatever ETag it finds at the Metalink server (this is noted later in the section). The concepts of trust and authorization are weak here, so I suggest that we use other terms, except in cases where the client really can determine that the mirror is authorized (e.g., via a cryptographically signed Metalink XML file or HTTP header).
      5. Robert Sparks: Discuss [2011-02-16]:
        The automated handling of the Link headers by MetaLink clients suggested by this document may need some more discussion, at least in the security considerations section. Apologies if I've missed where this is already discussed.
        1) What prevents a malicious server from returning a 200 with many Link: headers, all indicating rel=duplicate, perhaps indicating non-overlapping subsets of the entity, and all pointing to a victim, driving many, possibly parallel, connection attempts?
        2) When a Link (indicating an HTTP resource) is followed, does anything prevent that referenced server from also replying with MetaLink headers in its response? If not, what prevents loops, intentionally or unintentionally created, from being followed? If a client would automatically follow these, especially in parallel, exponential attacks against the victims in item 1) are possible. At the very least, a client could be sent into an infinite ping-pong loop.
      6. Sean Turner: Discuss [2011-02-14]:
        This is a preliminary discuss (and not yet sent to anybody).
        #1) Sec 2 Says: "Valid algorithms are found in the IANA registry named "Hypertext Transfer Protocol (HTTP) Digest Algorithm Values" at <http://www.iana.org/assignments/http-dig-alg/http-dig-alg.xhtml>."
        Then, Sec 10.3 says: "Currently, some of the digest values defined in Instance Digests in HTTP [RFC3230] are considered insecure."
        This could confuse some people. Section 2 should be modified to say: "Algorithms used in the Instance Digest field are registered in the IANA registry named "Hypertext Transfer Protocol (HTTP) Digest Algorithm Values" at <http://www.iana.org/assignments/http-dig-alg/http-dig-alg.xhtml>. This document restricts the use of these algorithms."
        #2) Sec 3: Confused by the following: "[[Some organizations have many mirrors. Only send a few mirrors, or only use the Link header fields if Want-Digest is used?]]"
        Was this supposed to be removed or is additional information required?
        #3) Sec 3.2: Are there any privacy considerations that need to be addressed with the use of the geo tag?
        #4) Sec 5: Only specifies OpenPGP signatures. I'm curious why this choice? I would think you'd want to reuse existing security built in browsers based on TLS and OpenPGP isn't the mandatory to implement scheme it's X.509. Also, any reason S/MIME isn't there? ...
        #5) There are multiple schools of thought about putting requirements in the security considerations. If you're going to put them in the security considerations, then I think a pointer to the algorithm requirements from section 6 to section 10 needs to be included.
        #6) Sec 7: Need to say something about what to do if the signature is included. Does it to validate back to a trust anchor. Point to OpenPGP/RFC5280 for validation rules.
        #7) Section 10: (I wrote this before I got to section 7 - will revisit it)
        a) Because Mirrors "SHOULD" include an Instance Digest instead of "MUST" include them, then I think you need to say something about using Mirrors can lead to substitution attacks and how you might mitigate them (user performs some action). Maybe this could be worked in to the spoofing paragraph (i.e., the case when no instance digest is specified).
        b) You also need to say something about using multiple mirrors when downloading. What happens when one supports an instance digest and the other doesn't (as in the last para of Section 2). What happens when the 1st one the client connected to supports it but the second doesn't. How is this supposed to work and can the client do anything to figure out that they got something they can cryptographically verify?
      7. Sean Turner: Comment [2011-02-14]:
        #1) Sec 7: r/A Range limit is optional,/A Range limit is OPTIONAL,
        #2) Section 7: r/fieldss)/fields).
        #3) Sec 7.1.1: r/merging of ranges from multiple responses must be verified/ merging of ranges from multiple responses MUST be verified
        #4) Sec 7.1.1: r/fieldss is./fields is.

      Telechat:

      • (removed from agenda)

    2. Elliptic Curve Algorithms for Cryptographic Message Syntax (CMS) Asymmetric Key Package Content Type (Proposed Standard)
      draft-turner-akf-algs-update-03
      Token: Tim Polk
      Note: Sean Turner (turners@ieca.com) is the document Shepherd.
      IPR: Certicom's Statement of IPR Related to draft-turner-akf-algs-update-02
      Discusses/comments (from ballot 3682):
      1. Adrian Farrel: Comment [2011-02-16]:
        Can I express my considerable concern about the wasted space on page one of this document without which you would have completed it in only three pages.

      Telechat:

      • Amy: No discuss. No objection, approved.

    3. Elliptic Curve Algorithms for Cryptographic Message Syntax (CMS) Encrypted Key Package Content Type (Proposed Standard)
      draft-turner-ekpct-algs-update-03
      Token: Tim Polk
      Note: Sean Turner (turners@ieca.com) is the document Shepherd.
      IPR: Certicom's Statement of IPR Related to draft-turner-ekpct-algs-update-02
      Discusses/comments (from ballot 3683):
      1. Alexey Melnikov: Comment [2011-02-10]:
        3. SignedData: "If an implementation encapsulates an EncryptedKeyPacakge with a"
        typo: EncryptedKeyPackage

      Telechat:

      • Amy: No discuss. No objection, approved.

    4. Scalable Operation of Address Translators with Per-Interface Bindings (Proposed Standard)
      draft-arkko-dual-stack-extra-lite-05
      Token: Ralph Droms
      Discusses/comments (from ballot 3692):
      1. Stewart Bryant: Comment [2011-02-17]:
        I agree that this looks a lot more like informational that standards track.
        I also agree that the introduction should be updated to reflect the exhaustion of the IPv4 address space.
      2. Adrian Farrel: Discuss [2011-02-16]:
        I support this document, but...
        I struggled with this document to understand what there is to implement. It all seemed a bit "obvious". Is this really a BCP or Informational?
        Shouldn't section 4 talk about what to do when an interface has used up the available number of IP addresses? Creating a "parallel" virtual interface may not be a big deal, but creating the first virtual interface when a physical insterface is "full" seems like a major operational step
      3. Adrian Farrel: Comment [2011-02-16]:
        I didn't really find that Section 2 "Solution Outline" was an outline of the solution. It looks more like an overview of the problem space and the benefits of the yet-to-be-introduced solution.
        Maybe Section 3 should also say that "internal realm" and "external realm" are derived from somewhere?
        Section 3: "This document uses the term mapping as defined in [RFC4787] to refer to state at the NAT necessary for network address and port translation of sessions."
        Could you put "mapping" in quotes to stop the reader getting confused that you are refering to a process of "term mapping".
        Section 4: Strictly speaking, isn't there a limit to the "arbitrary number" of devices served by a NAT? So it isn't really arbitrary?
        Maybe take the chance to update the info about the IANA free pool?
      4. Tim Polk: Comment [2011-02-16]:
        (1) Some of the introductory material is out of date. Specifically, the IANA free pool has now been exhausted but the document states:
        "At the time of writing, the IANA "free pool" contained only 12 unallocated unicast IPv4 /8 prefixes."
        This should be corrected, since the date on the RFC will be long after the free pool was depleted.
        (2) I support Adrian's discuss. Feels like informational or BCP. Given that the free pool is exhausted I lean towards BCP, but that would require another IETF Last Call.
      5. Peter Saint-Andre: Comment [2011-02-15]:
        Thanks for this clearly written document.
        This document feels Informational (not Standards Track) to me, but I'm fine with publication as Proposed Standard.

      Telechat:

      • Amy: Will go into AD follow-up, because discuss-holder not on.
      • Jari: I will discuss by email. We have a number of documents, and this should go in the same category with those. We have three authors, and one is new. He wants to make some changes, and we're discussing that.
      • Stewart: If a new author wants to do a major edit, that needs to go for further discussion.
      • Lars: One option is that he takes his name off the doc. What he wants to do will probably need another last call.
      • Stewart: I want to see what he has to say, and would not be happy with this doing through until that happens. Would it help if someone put a defer on it?
      • Jari: Someone can hold a discuss for that. I also want to see Mark's concerns, but I might not agree with them. There's no practical action needed.
      • Stewart: I'm inclined to change mine to discuss, saying that I want to hear one of the author's comments first.
      • Amy: I'll put this in AD follow-up.

    5. Special-Use Domain Names (Proposed Standard)
      draft-cheshire-dnsext-special-names-01
      Token: Ralph Droms
      Discusses/comments (from ballot 3693):
      1. Alexey Melnikov: Comment [2011-02-14]:
        I agree with a comment that this document should register existing special names in the registry, or make a more compelling argument about why the registry is needed.
      2. Tim Polk: Discuss [2011-02-16]:
        I expected the document to seed the registry with entries (at a minimum) for the special domain names identified in the introduction:
        "Analogous to Special-Use IPv4 Addresses [RFC5735], DNS has its own concept of reserved names, such as "example.com", "example.net", and "example.org", or any name falling under the top level pseudo-domain "invalid" [RFC2606]."
        Without those entries (or a plan to create those entries), I don't quite see that this document accomplishes anything.
      3. Tim Polk: Comment [2011-02-16]:
        last sentence of section 2: "reservation of a Special-Use Domain Names" - s/Names/Name/
      4. Dan Romascanu: Discuss [2011-02-14]:
        The OPS-DIR review performed by Jouni Korhonen raised the issue bellowed. I would like to see it addressed before approving this document:
        In section 4, check step 2. Do algorithmically generated names fall into this category? If yes, these should be mentioned in the draft as well. ...
      5. Peter Saint-Andre: Comment [2011-02-14]:
        Although I do not object to publication of this document, I agree that it would be preferable for this document to seed the registry with initial registrations.
      6. Robert Sparks: Comment [2011-02-15]:
        Thanks for this effort - I expect this registry (as long as its registration policy is Standards Action) to be a very useful tool.
        Will you be updating draft-cheshire-dnsext-multicastdns to explicitly request registration of .local (pointing to section 23 of that draft?)
      7. Sean Turner: Discuss [2011-02-16]:
        The first one is a DISCUSS-DISCUSS
        #1) Is adding a new required section in an RFC done this in way? It seems like this ought to come from a WG or be part of the style guide?
        #2) Use of the word "needs" in Section 3 seems like it ought to be MUST. Is there a time when you wouldn't do the items it suggests?
        #3) Shouldn't the "Special Name Considerations Section" just be part of the IANA considerations section?
      8. Sean Turner: Comment [2011-02-16]:
        1) +1 to including values. Maybe some from http://www.ietf.org/mail-archive/web/dnsext/current/msg10557.html ?
        2) There really aren't any security considerations. Could move the last sentence to section 4.

      Telechat:

      • Amy: Some discusses here. Will we need a revised ID? Or make it AD follow-up?
      • Dan: Mine is on the way to being resolved by editing. I don't know what Ralph wants to do with that. My changes aren't heavy.
      • Sean: Mine was discuss-discuss. Do we normally specify a new section that must go into an RFC in this way, or does it just go into the style guide?
      • Russ: We do not touch the style guide. IESG is not in charge of that.
      • Sean: By approving this, are we saying we need a new section in all docs?
      • Russ: We're saying that if you specify a particular thing, you have to do it in this way.
      • Sean: OK. I was looking at it as another thing like sec consid. But this only goes into docs that are registering this. I also wonder about words like "needs", and whether they should be "MUST". We can talk about that by email.
      • Michelle: Can someone who has a discuss hold it for IANA? I want my boss to look at it.
      • Sean: I'll do that.
      • Amy: Revised ID needed.

    2.2.2 Returning Items

    1. (none)

    3. Document Actions

    3.1 WG Submissions

    3.1.1 New Items

    1. Transient Binding for Proxy Mobile IPv6 (Experimental)
      draft-ietf-mipshop-transient-bce-pmipv6-07
      Token: Jari Arkko
      Note: Vijay Devarapalli (vijay@wichorus.com) is the Document Shepherd
      IPR: NEC Europe Ltd.'s Statement about IPR related to draft-ietf-mipshop-transient-bce-pmipv6-04
      IPR: Qualcomm Incorporated's Statement about IPR related to draft-ietf-mipshop-transient-bce-pmipv6-07
      Discusses/comments (from ballot 3238):
      1. Adrian Farrel: Comment [2010-08-26]:
        Clearing my Discuss on the basis of Jari's answer: "That's a good question to ask. The answer is yes."
      2. Russ Housley: Comment [2011-02-15]:
        Do either of the IPR statements related to this document cause pause?
      3. Alexey Melnikov: Comment [2010-08-26]:
        6. IANA Considerations: "This specification also adds one status code value to the Proxy Binding Acknowledge message, the PBU_ACCEPTED_TB_IGNORED_SETTINGSMISMATCH status code. The PBU_ACCEPTED_TB_IGNORED_SETTINGSMISMATCH status code is described in Section 4.7. Its value must be assigned from the same number space used for the Mobile IPv6 Binding Acknowledgement status values, as defined in [RFC3775], and must be smaller 128."
        I am looking at <http://www.iana.org/assignments/mobility-parameters/mobility-parameters.xhtml> and I am not finding "Binding Acknowledgement status" sub-registry. Am I looking in a wrong place, or is it named differently?

      Telechat:

      • Amy: No discuss. No objection, approved.

    2. PCC-PCE Communication and PCE Discovery Requirements for Inter-Layer Traffic Engineering (Informational)
      draft-ietf-pce-inter-layer-req-15
      Token: Stewart Bryant
      Note: Julien Meuric (julien.meuric@orange-ftgroup.com) is the document shepherd.
      Discusses/comments (from ballot 3583):
      1. Russ Housley: Comment [2011-02-16]:
        (blank)
      2. Dan Romascanu: Comment [2011-02-17]:
        Section 4.6. - Impact on Network Operation seems descriptive and contains no requirements (as do sections 4.1-4.5). If this is the case it should be explicitely stated.

      Telechat:

      • Stewart: Please put this on hold so I can make sure I don't miss anything.
      • Amy: Approved, point raised, writeup needed.

    3. Issues with IP Address Sharing (Informational)
      draft-ietf-intarea-shared-addressing-issues-03
      Token: Jari Arkko
      Note: Julien Laganier (julienl@qualcomm.com) is the document shepherd.
      Discusses/comments (from ballot 3633):
      1. Ralph Droms: Discuss [2011-02-16]:
        I don't understand this sentence:
        17. IPv6 Transition Issues: "[...] Shared addresses should be drawn from space designated as such [RFC1918]. Otherwise their use will break the widely implemented assumption that public IPv4 addresses are globally unique addresses and hence break many protocols and applications, [...]"
        Which "shared addresses" are under discussion here? Isn't the motivation for this document the need to share public addresses because of IPv4 address exhaustion?
        Later in the same section: "Issues created by sharing public address space across multiple hosts are specifically addressed in [I-D.thaler-port-restricted-ip-issues].
        Isn't thaler-port-restricted-ip-issues just focused on issues with A+P addressing, not generally public address space sharing issues?
        Does address sharing affect any other transition technologies, or just 6-to-4?
      2. Ralph Droms: Comment [2011-02-16]:
        In Figure 1, while reverse DNS is affected (more precisely, broken) by NAT without address sharing, in my opinion it is affected differently (more broken) by address sharing. Might deserve "xx"?
      3. Lars Eggert: Discuss [2011-02-16]:
        I'm adding a placeholder discuss to make sure the discussion between the authors and the tsv-dir reviewer terminates and we have a version submitted that addresses all comments.
      4. Lars Eggert: Comment [2011-02-15]:
        Section 1., paragraph 1: "Authority (IANA) were completed on Feburary 3, 2011 [IPv4_Pool]."
        Nit: s/Feburary/February/
        Section 1., paragraph 3: "Over the long term, deploying IPv6 is the only way to ease pressure on the public IPv4 address pool without the need for address sharing mechanisms that give rise to the issues identified herein. In the short term, maintaining growth of IPv4 services in the presence of IPv4 address depletion will require address sharing."
        Given the huge list of issues, I find it surprising to see that the document says "In the short term (...) IPv4 address depletion will require address sharing." The document should much more strongly argue for deploying IPv6 as the solution. It does in a few places, but I think the message bears repeating. Put it in the footer! :-)
        Section 3., paragraph 3:
        >    +------------------------------------------------+--------+---------+
        >    |                   Issue                        |   1st  |   3rd   |
        >    |                                                |  party | parties |
        >    +------------------------------------------------+--------+---------+
        

        It would be good for each issue in the table below to indicate which section discusses it in more detail. This is not at all clear from the headings of the subsequent sections. Add a column for this?
        Section 5.1., paragraph 3: "A potential problem with dynamic allocation occurs when one of the subscriber devices behind such a port-shared IPv4 address becomes infected with a worm, which then quickly sets about opening many outbound connections in order to propagate itself. Such an infection could rapidly exhaust the shared resource of the single IPv4 address for all connected subscribers. It is therefore necessary to impose limits on the total number of ports available to an individual subscriber to ensure that the shared resource (the IPv4 address) remains available in some capacity to all the subscribers using it."
        Limits aren't the only way of handling this. You can also kill off established connections when the port space runs out. If you do this randomly, a user with many connections will be proportionally more likely to get hit, which is what is needed. The benefit of the "kill" scheme is that you can support a wider variety of sharing patterns compared to fixed limits.
        Section 5.2.2., paragraph 2: "For example, the use of DNS SRV records [RFC2782] provides a potential solution for subscribers wishing to host services in the presence of a shared-addressing scheme. SRV records make it possible to specify a port value related to a service, thereby making services accessible on ports other than the Well-Known ports. It is worth noting that this mechanism is not applicable to HTTP."
        HTTP as well as many other legacy protocols.
        Section 13.1., paragraph 0: "13.1. Abuse Logging and Penalty Boxes"
        An addition to this section: There are web tie-ins into different black lists that some web site owners subscribe to which redirect clients to a URL that basically says "hey, your machine is infected." Sometimes, they even prevent their site from then working for that users, in order to "give incentives" to fix the problem. With address sharing, someone else's worm can hence interfere with my ability to do stuff. (And I already see this today behind the Nokia NAT, because some clown here has an infected Windows box on the intranet...)
      5. Alexey Melnikov: Comment [2011-02-17]:
        13.6. Policing Forwarding Behaviour: "If some form of IPv6 ingress filtering is deployed in the broadband network and DS-Lite service is restricted to those subscribers, then tunnels terminating at the CGN and coming from registered subscriber IPv6 addresses cannot be spoofed. Thus a simple access control list on the tunnel transport source address is all that is required to accept traffic on the southbound interface of a CGN."
        Is "southbound" a common terminology?
        17. IPv6 Transition Issues: "Subscribers allocated with private addresses will not be able to utilise 6to4 to access IPv6, but may be able to utilise Teredo."
        This needs an Informative reference.
        The first reference to HTTP needs an Informative reference.
      6. Peter Saint-Andre: Comment [2011-02-15]:
        Section 12 on Traceability refers to "the offending activity". Given the principle of innocent until proven guilty, I suggest "a particular activity".
      7. Robert Sparks: Discuss [2011-02-15]:
        This document calls out to draft-thaler-port-restricted-ip-issues for several important discussions, but that document has not been refreshed since Feb-10, and I'm not finding any other signs of activity around it. What is the plan for moving that document forward?
      8. Robert Sparks: Comment [2011-02-15]:
        Please consider the text proposed by Richard Barnes

      Telechat:

      • Jari: I will discuss with Robert over email. Lars, I agree with some of your issues, maybe not all. How do you feel?
      • Lars: I can clear. Can Amy do it for me? I just wanted to be sure we didn't approve it while there's still discussion going on about it.
      • Jari: I also want to ensure the discussion is complete. Hold the discuss, and clear when we're done. Revised ID needed.

    4. Framework for GMPLS and PCE Control of Wavelength Switched Optical Networks (WSON) (Informational)
      draft-ietf-ccamp-rwa-wson-framework-12
      Token: Adrian Farrel
      Note: Lou Berger (lberger@labn.net) is the document shepherd.
      Discusses/comments (from ballot 3689):
      1. Russ Housley: Comment [2011-02-15]:
        Please consider the comments from the Gen-ART Review by Pete McCann on 7-Feb-2011.

      Telechat:

      • Amy: No discuss. No objection, approved. Will go into point raised, writeup needed.

    3.1.2 Returning Items

    1. (none)

    3.2 Individual Submissions Via AD

    3.2.1 New Items

    1. TOTP: Time-based One-time Password Algorithm (Informational)
      draft-mraihi-totp-timebased-07
      Token: Sean Turner
      Note: Hannes Tschofenig (Hannes.Tschofenig@gmx.net) is the document shepherd.
      IPR: VeriSign's Statement about IPR related to RFC 4226, draft-mraihi-mutual-oath-hotp-variants-08, draft-mraihi-totp-timebased-01, draft-ietf-keyprov-dskpp-07, draft-ietf-keyprov-pskc-01, and None
      IPR: VeriSign's Statement about IPR related to RFC 4226, draft-mraihi-mutual-oath-hotp-variants-08, draft-mraihi-totp-timebased-01, draft-ietf-keyprov-dskpp-07, and draft-ietf-keyprov-pskc-02
      Discusses/comments (from ballot 3571):
      1. Russ Housley: Comment [2011-02-16]:
        Please consider the questions raised on the Gen-ART Review by Ben Campbell on 14-Feb-2011. He asks about Section 5.2:
        Is there a requirement that the proover must not make a second attempt inside a given time window? If so, that was not clear from the text. If there is not such a requirement, are there security implications if the proover does send multiple messages inside the same tick? It is not really a one time pad if that happens is it?
      2. Alexey Melnikov: Discuss [2011-02-12]:
        I am generally in favor of getting this document published. However I would like to clarify a couple of things before recommending approval of this document.
        3. Algorithm Requirements: "R8 - The TOTP algorithm SHOULD be used for online application."
        Can you please explain this requirement?
        6. Resynchronization: "Also, it is important to note that the longer a prover has not sent an OTP to a validation system, the longer (potentially) the accumulated clock drift between the prover and the verifier. In such cases, the default synchronization may not be proper when the drift exceeds beyond allowed threshold. Additional authentication measures SHOULD be used for the validation system to safely authenticate the prover."
        What are these measures? I.e. how can the SHOULD be satisfied.
      3. Alexey Melnikov: Comment [2011-02-12]:
        Abstract: "This document describes an extension of one-time password (OTP) algorithm, namely the HAMC-Based"
        typo: HMAC-Based
        1.2. Background: "The default HMAC-SHA-1 function could be replaced by HMAC-SHA-256 or HMAC-SHA-512 to leverage HMAC implementations based on SHA-256 or SHA-512 hash functions."
        Missing references for SHA-256/512.
        5.1. General: "All the communications SHOULD take place over a secure channel e.g. SSL/TLS, IPsec connections."
        Missing informative references for TLS and IPSec.
      4. Dan Romascanu: Discuss [2011-02-14]:
        1. The IANA Considerations section states: "The OTP algorithm defined in this document can be referred by a URI defined in a separate document. [ALGP] is such an attempt that defines various OTP related algorithm URIs. There is no registration needed in this document."
        However [ALGP] is according to Section 9.2 draft-hoyer-keyprov-pskc-algorithm-profiles-01.txt which I could not find in the tracker. Is there some kind of mistake, maybe a typo or a change of name of the document?
        2. The Time-step size is RECOMMENDED and has a default value of 30 seconds. Are there cases when this value can be different, how is it changed if such cases exist and how can a network operator know what is the Time-step size value on a client?
      5. Peter Saint-Andre: Comment [2011-02-15]:
        I concur with with the discusses from Dan Romascanu, Robert Sparks, and Alexey Melnikov.
      6. Robert Sparks: Discuss [2011-02-15]:
        1) This document contains a sizable "Code Component" in Appendix A, but does not appear to be following the TLP recommendations for stating copyright. Is that intentional?
        2) What are the consequences of the generator and consumer of a TOTP having different system parameter values configured for X (say the recommended 30s at a generator, and 90s at a consumer)? X does not appear to be transmitted. Can this mismatch be detected? Similarly, what are the consequences of mismatched T0 values?
      7. Robert Sparks: Comment [2011-02-15]:
        Stronger rationalization for the default of 30s for X would be welcome. From the existing text, it seems to have been selected expecting that the only use will be humans logging into websites. If that's accurate, it would help to explicitly state it in the document. If it's not accurate, more explanation is needed.

      Telechat:

      • Sean: The authors are addressing the discusses by email. Revised ID needed.

    2. US Secure Hash Algorithms (SHA and SHA based HMAC and HKDF) (Informational)
      draft-eastlake-sha2b-07
      Token: Russ Housley
      Note: I agreed to sponsor this document since I was the sponsor for RFC 4634.
      Discusses/comments (from ballot 3576):
      1. Alexey Melnikov: Comment [2011-02-16]:
        id-sha224 OBJECT IDENTIFIER ::= {{ joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) csor(3) nistalgorithm(4) hashalgs(2) 4 }
        Just to double check: the last component is 4 here, right?
      2. Dan Romascanu: Comment [2011-02-15]:
        (empty)
      3. Sean Turner: Comment [2011-02-15]:
        A fine document that I'm glad is being published.

      Telechat:

      • Amy: No discuss. No objection, approved.

    3. Suite B Cryptographic Suites for Secure Shell (Informational)
      draft-igoe-secsh-suiteb-05
      Token: Tim Polk
      Note: need a shepherd... should review to see if we can go standards track even with ECC
      IPR: Certicom's Statement about IPR related to RFC 4346, RFC 5246, RFC 5289, RFC 4492, RFC 2409, RFC 4306, RFC 4754, RFC 4753, RFC 4869, RFC 4253, RFC 2633, RFC 3278, RFC 4347, RFC 4366, RFC 4109, RFC 4252, RFC 3850, RFC 3851, RFC 5008, draft-ietf-tls-rfc43...
      IPR: Certicom's Statement about IPR related to RFC 4346, RFC 5246, RFC 5289, RFC 4492, RFC 2409, RFC 4306, RFC 4754, RFC 4753, RFC 4869, RFC 4253, RFC 2633, RFC 3278, RFC 4347, RFC 4366, RFC 4109, RFC 4252, RFC 3850, RFC 3851, RFC 5008, draft-ietf-tls-rfc43...
      IPR: Certicom's Statement about IPR related to RFC 4346, RFC 5246, RFC 5289, RFC 4492, RFC 2409, RFC 4306, RFC 4754, RFC 4753, RFC 4869, RFC 4253, RFC 2633, RFC 3278, RFC 4347, RFC 4366, RFC 4109, RFC 4252, RFC 3850, RFC 3851, RFC 5008, draft-ietf-tls-rfc43...
      IPR: Certicom's Statement of IPR Related to RFC 4492, RFC 5289, RFC 5430, RFC 4754, RFC 4869, RFC 4109, RFC 5656, RFC 3278, RFC 5753, RFC 5754, RFC 5008, draft-igoe-secsh-suiteb-02
      Discusses/comments (from ballot 3601):
      1. Russ Housley: Comment [2011-02-16]:
        Please consider the comments from the Gen-ART Review by Miguel Garcia on 25-Feb-2011 (which are the same as the comments in the earlier review on 10-Jan-2011):
        - The document lacks an IANA section. If there is no action for IANA, the section should say that, e.g., including something like "This document has no actions for IANA." The author should consider whether this document requires an IANA action or not.
        - The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords and a reference to RFC 2119 exists in the Normative References section.
        - There are a number of unused references, including: AEAD, RFC4250, SSH-Auth, GCM.

      Telechat:

      • Amy: No discuss. No objection, approved.
      • Sean: Tim wants it as point raised, so he can check the comments.
      • Amy: Point raised, writeup needed.

    4. The A+P Approach to the IPv4 Address Shortage (Experimental)
      draft-ymbk-aplusp-08
      Token: Ron Bonica
      Discusses/comments (from ballot 3673):
      1. Ralph Droms: Discuss [2011-02-17]:
        Discuss-discuss, which I will clear after the telechat:
        * a+p supports and encourages the extended use of IPv4 while providing no incentive or support for the transition away from IPv4 to IPv6
        * any effort spent on correcting technical issues with a+p would be better spent on resolving issues impeding the transition to IPv6
      2. Lars Eggert: Discuss [2011-02-15]:
        DISCUSS: The last item of Pasi Sarolahti's tsv-dir review requires a response.
        INTRODUCTION, paragraph 1: "Intended status: Experimental"
        DISCUSS: The body of the document does not discuss at all in which way this technology is to be considered experimental, and in which kinds of deployments this technology may be experimented with. In fact, Section 5 is worded in way that suggests a readiness for global deployment. While I understand that this is the opinion of the authors, that is not what Experimental RFCs are for. We had several BOFs on this topic that all failed to convince the community of the value of this approach; I'm surprised to see the same content back with an Experimental label for publication on the IETF Stream.
        INTRODUCTION, paragraph 10: "This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. This document may not be modified, and derivative works of it may not be created, and it may not be published except as an Internet-Draft."
        DISCUSS: The document has an IETF Trust Provisions (28 Dec 2009) Section 6.c(ii) Publication Limitation clause. If this document is intended for submission to the IESG for publication, this constitutes an error.
        Section 5.3.4., paragraph 0: "5.3.4."Limitations of the A+P approach"
        DISCUSS: Just having reviewed draft-ietf-intarea-shared-addressing-issues, this section doesn't even begin to scratch the surface when it comes to limitations. I don't want you to duplicate all the content from draft-ietf-intarea-shared-addressing-issues here, but a reference to this document plus an upfront summary of the limitations described therein need to be added here.
      3. Adrian Farrel: Comment [2011-02-15]:
        I know the RFC Editor can fix this, but in the spirit of devolving work... You need to not describe the document as a "draft"
        It is not a requirement, but I think it is helpful if Experimental RFCs give some scope to the experiment both in terms of how it is "contained" and how the success of the experiment will be judged. This need not be a lot of text.
      4. Dan Romascanu: Discuss [2011-02-16]:
        The issues raised by Tina Tsou in her review were not addressed at the technical level. I would like to see a response on these issues before approving the document. If these were already answered please point me to the answer.
      5. Robert Sparks: Comment [2011-02-15]:
        Support Lars' discuss on providing details on evaluating the experiment
        Please consider adding the text proposed by Richard Barnes
        This example is somewhat misleading: "(e.g., VoIP clients register a public IP and a single delegated port from the CPE, and accept incoming calls on that port)".
        Most VoIP clients will ask for a separate port for the voice media from the one used for signaling.

      Telechat:

      • (updated to version -09 after "FINAL Agenda" distributed)
      • Ron: Dan, is what I wrote last night OK?
      • Dan: I think so, and I responded with a question about some of the text that needs editing. Otherwise it's fine.
      • Ron: We can clear this up in an RFC-ed note.
      • Dan: I will edit and delete all resolved comments and leave the DISCUSS for the only open issue (#5).
      • Ron: In Ralph's case there were three points. One is that this doesn't progress v6. It does use v6 as a tunneling technology between the gateways. DS-lite is in the same boat.
      • Ralph: I understand the point. I think it's a weak argument. AplusP can use a variety of tunneling techniques. It doesn't provide an impetus to go to v6. DS-lite only runs over v6.
      • Ron: If you look at sec 5.2, smap... there's important information in the v6 address.
      • Ralph: Only if you use smap. But there are ways that don't use v6.
      • Ron: If you didn't use smap, how would you get the v4 information across? The default mode does use v6. But even if it didn't promote the use of v6, if we applied that criterion to every draft, lots of things, such as nat444, would be unacceptable.
      • Ralph: Does nat444 require additional protocol spec? That's a little different. It's not something we're being asked to do protocol work on.
      • Ron: This is an experimental RFC. The question we're being asked is whether this experiment does harm to the Internet. The bar is low.
      • Ralph: My answer, personal opinion, is that promoting a technique that requires us to do some work and will extend IPv4 without an incentive to go to v6 is in my mind not good for the Internet.
      • Ron: We will see things that extend v4. 444, AplusP, we'll see it. If we set this criterion, we have good reason to put discuss on everything we see from the LISP wg. We will put discusses on lots of things. Do we want to do that?
      • Jari: Ron is basically right in this argument. The issue is not so much that we shouldn't let this go forward, but an issue of what the doc says. It's making statements about this being applicable to mobile networks -- I disagree. We need a clear label that this is really experimental.
      • Ron: We can negotiate changing the text for that.
      • Jari: There's been a lot of email, and as I understand it when I talk to these guys, they would like to have an RFC because they want to promote vendor implementations. One vendor was implementing this, and there's not huge takeup. We need to be careful about recommending many solutions for this space. Let's make clear what's an IETF recommendation and what's not. It doesn't have to be a lot of text. I can volunteer to write some.
      • Ron: That talks to Lars's and Tim's discusses.
      • Ralph: I will go along with the additional text disclaiming it as experimental. More recognition that this really is an experiment, and doesn't have consensus.
      • Ron: Lars's and Tim's are essentially the same. One part of Lars's made me read the draft again... we talked about requiring changes to the end system. Most end systems won't be changed at all. They will think they have the right to use the whole port range. They do say that if you want to have your end host be part of the AplusP system, you can, but most won't.
      • Lars: This really changes the architecture in a way that no longer when you have an IP address do you have the whole port range. That means that you now need one of the CPE deployments. You now get port-restricted Internet connectivity. That's the harm to the Internet. Ports are now being used in routing.
      • Ron: There are two pieces to the AplusP system. One is the router in the soho environment. [...missed a bunch...]
      • Lars: NATs give you the entire port range. AplusP fails silently. It's very clear that if you plug it in and you don't know that you can't use some port, there's a problem. We had two failed BoFs on this technology. There's strong consensus that this shouldn't be done in the IETF. Even experimental, I think goes against consensus. No other technology has had two failed BoFs and then became experimental. It should not be published through the IETF stream.
      • Ron: There's a big difference between "no" to a BoF and "no" to an experimental RFC. One is that there's not enough energy to work on it. We're not sure why this failed. Would this experiment cause danger to the Internet.
      • Lars: There's no limitation to this experiment.
      • [...scribe was dropped from call...]
      • Jari: [...] Do we have some feeling in the IESG as to which of the four options we should go to?
      • Ron: I would be happy with 3, to add some text that talks about the limitations and the lack of IETF consensus.
      • Dan: I prefer 3, because if case 4 comes, we have to have the discussion again. We don't solve something, but just postpone the problem.
      • Jari: There is an argument that we could have more influence on the content with option 3 than 4.
      • Lars: I see no reason to publish this doc on any stream. There's nothing that this does that we can't do with another technology, and it limits the ports. I'm willing to hold this discuss until I step down. I don't understand how we can bring this forward again as experimental. This has consistently failed when it's been brought up before.
      • Ron: One vote for throw it out completely, and some number for option 3.
      • Jari: Lars, what if this doc explains at the beginning that the experiment changes the Internet architecture in this way.
      • Lars: If the authors could describe the down-sides accurately, that might be OK. But the authors think they have a good thing here.
      • Ron: One thing I could do is join the author list myself, and write that text.
      • Lars: The entire doc reads like this is a really good idea and they suggest it for wide deployment. We can't fid that with an RFC-ed note or a paragraph in the intro. The entire tone of the doc needs to be changed.
      • Ron: I can be responsible for adding a section, and you can hold your discuss until you see that.
      • Lars: If we can agree that this is a limited experiment, lab testing, not in a production environment. If it's strongly enough phrased, it might be... I still don't get past the point that it's failed twice and we're still publishing it.
      • Ron: As long as it's possible to add some text about the experiment....
      • Lars: I'd like text that says that it failed to get IETF consensus twice. I really want to throw it out.
      • Ron: If we put text in the doc that says this is an experiment and breaks some things, then all but one discuss can be cleared.
      • Ralph: It's assumed that AplusP function will be in a CPE, but not in a host... I'd like to see some discussion on that, saying that you could put it in a host, but it would be wrong. I think that would also reduce some of the complexity in the doc. If the authors feel strongly that AplusP should go all the way out to the host, that's a different story.
      • Ron: In fact, it's assumed NOT to be in the CPE, and I'd like to add something about that. I'd be willing to ask the authors to strip out the section about it being useful in mobility.
      • Ralph: That would make me somewhat more comfortable. As I looked at the technical issues in the doc, I found that some details were described imprecisely. Separating NAT from tunneling function, and the signalling function is entirely separate, but that's not clear through the rest of the document.
      • Russ: In order to finish the agenda close to on time, we need to move on. If Ron's proposal isn't sufficient, we can talk more next week.
      • Jari: Ron, can we talk before you approach the authors?
      • Ron: OK. This one is revised ID needed.

    3.2.2 Returning Items

    1. (none)

    3.3 IRTF and Independent Submission Stream Documents

    3.3.1 New Items

    1. Design Goals for Scalable Internet Routing (Informational)
      draft-irtf-rrg-design-goals-06
      Token: Jari Arkko
      Note: Independent submission via IRTF. Joel Halpern (jmh@joelhalpern.com) is the document shepherd.
      Discusses/comments (from ballot 3700):
      1. (none)

      Telechat:

      • Amy: No discuss. No objection, approved.
      • Russ: To expedite... all seven of these docs have no overlap with IETF work and look OK to publish. I propose that we ask about all seven in one go.
      • Amy: Does anyone have any objection to any of these?
      • Russ: No objections, they're all approved.
      • Amy: No objection message will go to the IRTF on Monday.

    2. Using Self-Delimiting Numeric Values in Protocols (Informational)
      draft-irtf-dtnrg-sdnv-08
      Token: Ralph Droms
      Note: IRTF Submission. Elwyn Davies (elwynd@dial.pipex.com) is the document shepherd.
      Discusses/comments (from ballot 3701):
      1. Ralph Droms: Comment [2011-02-15]:
        I have one comment with my independent reader hat on. I was a little surprised, after several potential uses of SDNVs were described earlier in the document, to read:
        "In general, it seems like the most promising use of SDNVs may be to define the Length field of a TLV structure to be an SDNV whose value is the length of the TLV's Value field. As previously discussed, this leverages the strengths of the SDNV format and limits the effects of its weaknesses."
        I was left wishing for a little more explanation of why the authors make this statement and wondering why the other potential uses for SDNVs were judged less promising.
      2. Peter Saint-Andre: Comment [2011-02-15]:
        The introduction states: "One example of SDNVs being used outside of the DTN protocols is in Hixie's Web Socket protocol [I-D.hixie-thewebsocketprotocol], which includes a binary frame length indicator field identical to an SDNV."
        Referencing draft-hixie-thewebsocketprotocol-76 seems problematic, given that this individual I-D was superseded by draft-ietf-hybi-thewebsocketprotocol and the work of the IETF's HYBI WG. If this text is not really needed here, I would urge its removal to prevent confusion regarding the canonical documentation of the WebSocket protocol.

      Telechat:

      • (Handled with first item in 3.3.1.)

    3. Bundle Security Protocol Specification (Experimental)
      draft-irtf-dtnrg-bundle-security-17
      Token: Sean Turner
      Note: IRTF submission. Elwyn Davies (elwynd@dial.pipex.com) is the document shepherd.
      Discusses/comments (from ballot 3702):
      1. (none)

      Telechat:

      • (Handled with first item in 3.3.1.)

    4. Compressed Bundle Header Encoding (CBHE) (Experimental)
      draft-irtf-dtnrg-cbhe-08
      Token: Ron Bonica
      Note: IRTF submission. Elwyn Davies (elwynd@dial.pipex.com) is the document shepherd.
      Discusses/comments (from ballot 3703):
      1. Alexey Melnikov: Comment [2011-02-16]:
        I don't believe this document is conflicting with ongoing IETF work, so I have no objections to its publication.
        However I have a small set of mostly editorial nits I would like the document editor to consider:
        ...

      Telechat:

      • (Handled with first item in 3.3.1.)

    5. Delay-Tolerant Networking Metadata Extension Block (Experimental)
      draft-irtf-dtnrg-bundle-metadata-block-09
      Token: Peter Saint-Andre
      Note: IRTF submission. Elwyn Davies (elwynd@dial.pipex.com) is the document shepherd.
      Discusses/comments (from ballot 3704):
      1. Peter Saint-Andre: Comment [2011-02-15]:
        In accordance with RFC 5742, I recommend that the IESG take the following position regarding this IRTF-stream document:
        "The IESG has concluded that there is no conflict between this document and IETF work."
        This recommendation has been entered in the datatracker.
        In addition, and outside the scope of IESG review in accordance with RFC 5742, I have the following technical comments, which the author is free to consider or not as desired:
        1. The definition of the URI metadata type does not mention Internationalized Resource Identifiers (IRIs); is it envisioned that IRIs could be supported via transformation into URIs as specified in RFC 3987?
        2. Section 4.1 states: "Unless determined by local policy, the specific processing steps that must be performed on bundles with metadata blocks containing metadata of type URI are expected to be included as part of the URI encoding of the metadata."
        It is unclear to this reader (a) how the processing steps are to be encoded in the URI and (b) if such processing steps are intended to override or supplement the processing steps defined in RFC 3986 for URIs in general.

      Telechat:

      • (Handled with first item in 3.3.1.)

    6. Delay-Tolerant Networking Previous Hop Insertion Block (Experimental)
      draft-irtf-dtnrg-bundle-previous-hop-block-12
      Token: Tim Polk
      Note: IRTF submission. Elwyn Davies (elwynd@dial.pipex.com) is the document shepherd.
      Discusses/comments (from ballot 3705):
      1. (none)

      Telechat:

      • (Handled with first item in 3.3.1.)

    7. Delay-Tolerant Networks (DTN) Bundle Protocol IANA Registries (Informational)
      draft-irtf-dtnrg-iana-bp-registries-01
      Token: Jari Arkko
      Note: IRTF submission. Elwyn Davies (elwynd@dial.pipex.com) is the document shepherd.
      Discusses/comments (from ballot 3706):
      1. Dan Romascanu: Comment [2011-02-16]:
        (blank)

      Telechat:

      • (Handled with first item in 3.3.1.)

    4 Working Group Actions

    4.1 WG Creation

    Telechat:

    4.1.1 Proposed for IETF Review

    1. (none)

    4.1.2 Proposed for Approval

    1. (none)

    4.2 WG Rechartering

    4.2.1 Under evaluation for IETF Review

    1. (none)

    4.2.2 Proposed for Approval

    1. (none)

    5. IAB News We can use

    6. Management Issues

    1. Tracking of pending media type/charset/URI registrations (Alexey Melnikov)

      Telechat:

      • Alexey: Larry Masinter is asking if there could be a way of tracking requests, on a web page or something.
      • Michelle: I haven't looked into this. Some of these are managed on mailing lists, which we don't get involved in. I'd be interested in talking about this further to see if we can find out exactly what Larry's looking for.
      • Alexey: He wants to find out whether registration was submitted to the expert, and whether the expert has acted on it. It's not always clear what the status is.
      • Michelle: Shall I follow up with Larry and get more information?
      • Alexey: Yes, and copy me. There might be other use cases for this. And for some registrations, there are a lot of requests to track.
      • Michelle: I'll get in touch with Larry, see what cases he's referring to, and see what we can do to make it better.
      • Amy: Adding an action item for Alexey and Michelle.

    2. Add 2 TLS Aria Cipher Suites to draft (Sean Turner)

      Telechat:

      • Sean: The authors noticed that they forgot two suites in the IANA considerations. I hope that after IETF last call we can add them later. I want to verify that that's the right way.
      • ... agreement
      • Alexey: "IESG doesn't object unless there are other last-call objections."

    3. Inviting W3C XML experts to attend Sunday Reception/Apps Area meeting in Prague (Alexey Melnikov) )

      Telechat:

      • Alexey: Russ, did you think about this?
      • Russ: Yes. I'd like to understand whether the IETF will benefit by having these folks join Monday meetings?
      • Alexey: Yes, the IETF will benefit.
      • Russ: I'd like to offer them complimentary Monday passes.
      • Alexey: That's perfect, yes.
      • Russ: If one wants to stay for the week, they should register. This way, they register with the day pass procedure, and I need their names to comp them.
      • Alexey: Peter, can you send email to them and copy me and Russ?
      • Peter: We can also talk about putting something on the apparea agenda.
      • Russ: We're also shooting ourselves in the foot if we don't also put rtcweb on Monday.
      • Alexey: It's not necessarily the same people. These will be XML people.
      • Russ: Different part of W3C?
      • Alexey: Yes. We can put rtcweb on Monday, but it's not necessary.
      • Russ: We just got their proposed charter for their version of real-time web. OK, so we will offer complimentary Monday passes for our fellow standards workers.

    4. Early RFC number for martini gin spec (Gonzalo)

      Telechat:

      • Gonzalo: This is the SIP Forum, not an SDO. We told them they need to develop their specs in the IETF. They did that in the martini WG. We approved it a few weeks ago. They are having a big marketing effort, and they would like to release their specs, which reference the IETF work ASAP. They're asking for an early RFC number allocation. Or we could expedite the publication. We don't really think it's extremely urgent... they just need the number. I'd like opinions.
      • Sandy: FYI, when the IESG asks for early allocation it's the same as expedited publication request. Otherwise, people don't know how to find the document when they have the number.
      • Gonzalo: OK, then... do we want to expedite the publication of this? It would be a good signal for them. They did what we asked when we asked them to bring it to the IETF.
      • Russ: On the mail list, I asked when they need the number.
      • Gonzalo: As soon as possible. They want to publish as soon as possible to get this at the same time they publish their spec.
      • Alexey: How long will it take them to publish their spec?
      • Robert: I don't know for sure, but I think it's *very* soon after they get the number. The SIP Connect specs have been held up for martini for several months, with much angst. I'm of mixed mind on asking for expedited processing, but I fall on the side of asking to do this. it would make it easier for us to make sure they continue to do the right thing next time.
      • Russ: Sandy Right now it's in edit state. If we do nothing, how long will it take?
      • Sandy: Probably 4 to 5 weeks before auth48.
      • Russ: I agree, then, that we'd like you to turn it around in, say, two weeks.
      • Sandy: Michelle, there is IANA stuff in the doc.
      • Russ: Anyone think asking for publication by 4 March -- auth48 by then -- would be unreasonable? Anyone object? No... OK, Gonzalo, please put a ticket in to make the request.

    7. Agenda Working Group News

    1406 EST Adjourned


    Valid HTML 4.01 Strict


    Appendix: Snapshot of discusses/comments

    (at 2011-02-17 07:36:25 PST)

    draft-ietf-tsvwg-iana-ports

    1. Stewart Bryant: Comment [2011-02-15]:
      I have one question which is almost a discuss discuss. Should IANA reserve/have
      a special request process for services that contain IETF key words that imply
      critical IETF services (IETF, BGP, MPLS...) so no one can pass of a proprietary
      design as one approved by the IETF.
    2. Adrian Farrel: Comment [2011-02-15]:
      You will need to not have citations from the Abstract.
      
      ---
      
      I am worried that this document should discuss deprecation. I don't
      think it is important enough for a Discuss, but would appreciate the
      authors considering this. IMHO, it is subtly different from 
      de-assignment.
      
    3. Alexey Melnikov: Comment [2011-02-15]:
      I need to check if IETF LC comments regarding anonymous reviewers should be
      addressed
       - as per document authors this is out of scope for this document and
      will be described in another document.
      
      (Currently internal processes of the IANA ports and services design team are not
      documented by any RFC. This document doesn't change that.)
    4. Tim Polk: Comment [2011-02-16]:
      (1) In section 7.2, the word "strives" and phrase "strive to" are used
      repeatedly in an effort to give IANA some wiggle room.  While wiggle room is
      probably a necessity, it would be helpful to explain when the wiggle room may
      reasonably be required.  It would probably be good to require additional
      information in the request whenever the submitter asks IANA to violate these
      principles.
      
      This *might* help avoid some appeals.
      
      (2) In 8.2, the process for de-assignment can only be initiated by the Assignee:
      
         The Assignee of a granted port number assignment can return the port
         number to IANA at any time if they no longer have a need for it.
      
      Section 8.4, revocation, would presumably cover the case where the  process was
      initiated by someone other than the Assignee.  However, there doesn't seem to be
      a mechanism for a 3rd party to indicate they believed specific ports could
      safely be de-assigned/revoked.  Should this section provide instructions (e.g.,
      email destination, preferred subject line, required contents) for such
      submissions?
      
      [Note: the remainder of 8.4 seems entirely satisfactory to process such a
      request...]
      
      (3) Waiting to see what Alexey determines about anonymous reviewers :)
    5. Peter Saint-Andre: Discuss [2011-02-15]:
          I am strongly in favor of this document and will probably change my ballot to
      "Yes" once we have a chance to discuss the following two issues.
      
      1. [addressed by existing text, clarified through discussion]
      
      2. Regarding port numbers, Section 8.1.1 states:
      
            Note that
            the applicant MUST NOT use the requested port prior to the
            completion of the assignment.
      
      This seems quite unrealistic, because developers (and developer communities) use
      ports all the time when designing and testing application protocols Prohibiting
      such experimentation strikes me as detrimental to innovation and opposed to the
      IETF's principles of "rough consensus and running code". 
          
    6. Robert Sparks: Comment [2011-02-17]:
      1) I can't see how "IANA strives to" is functionally in any way different from
      "IANA SHOULD". What do you expect either IANA or the expert reviewers to do
      differently given those different phrases as guidance?
      
      2) This document should acknowledge that the conversation around non-anonymous
      expert review happened, call out the conclusion (I believe we saw community
      consensus that it was important), and recommend the work that would need to
      happen to put that in place.
    7. Sean Turner: Comment [2011-02-17]:
      (I didn't think of this but it might be a good idea)
      
      It would be nice to have something that would allow a 3rd party to indicate that
      a service name/port number can be de-assigned.  For example,  the assignee is
      unreachable and their company have gone belly up.  Their protocol was never
      widely deployed and ten years later it's completely gone.  A good netizen could
      inform IANA about this and then IANA could determine whether it's true and de-
      assign the name/number.

    draft-ietf-isis-ieee-aq

    1. Tim Polk: Discuss [2011-02-16]:
          The security considerations state:
          
         If zero configuration methods are used to auto configure NNIs or 
         UNIs there are intrinsic security concerns that should be mitigated 
         with authentication procedures for the above cases. Such procedures 
         are beyond the scope of this document. 
      
      While these procedures are beyond the scope of this document, it would be
      helpful to identify which procedures the authors have in mind (or note that such
      procedure have yet to be developed). 
          
    2. Tim Polk: Comment [2011-02-16]:
      
          
    3. Dan Romascanu: Discuss [2011-02-14]:
          1. The following convention is defined for the document in Section 
      
      >  The lower case forms "must", "must not", "shall", "shall not", 
         "should", "should not" and "may" in this document are to be 
         interpreted in the sense defined in [RFC2119], but are used where 
         the normative behavior is defined in documents published by SDOs 
         other than the IETF. 
      
      There are two problems here that attracted my attention: 
      
      - should really any form of "must" or "should" ,etc. that appears in this
      document be interpreted in the sense defined in [RFC2119]? This does not seem to
      be the intention, and I would prefer to make clear that this interpretation
      applies only in the sections that deal with the IEEE 802.1 documents.
      
      - The keywords "recommended" and "optional" are missing from the list. Is this
      intentional? While I could not find any instances of "recommended" I did find a
      few instances of "optional" which I would think should be interpreted in the
      sense defined in [RFC2119] - for example in section 4.1
      
      2. In the IANA considerations section: 
      
      > The MT-Capability TLV is the only TLV requiring a new sub-registry. 
         Type
      value 144 (TBD) is requested, with a starting sub-TLV value of 
         1, and
      managed by Standards Action.  
          
      Is really Standards Action necessary? Why
      would not Expert Review be sufficient? 
          
    4. Peter Saint-Andre: Comment [2011-02-16]:
      I agree with Dan Romascanu's DISCUSS regarding lower-case conformance keywords
      -- they are confusing.
      
      In Section 17, please expand "DOS" to "Denial of Service" and add a reference to
      RFC 4732.
    5. Sean Turner: Comment [2011-02-17]:
      I support Tim's discuss.
      
      Also, is this draft going to be held by the RFC editor while the 802.1aq draft
      goes final?  The normative reference is to a DRAFT of the IEEE spec.

    draft-ietf-6man-prefixlen-p2p

    1. Ralph Droms: Comment [2011-02-14]:
      Pedantic, editorial nits about this text from the introduction:
      
         address,
         except those that start with the binary value 000,
      
      s/address/addresses/
      s/those/those unicast addresses/ (to clarify that
      "those" == addresses and not IIDs)
    2. Lars Eggert: Comment [2011-02-15]:
      Section 6., paragraph 3:
      >       a) Addresses with all zeros in the rightmost 64 bits SHOULD NOT be
      >       assigned as unicast addresses, to avoid colliding with the Subnet-
      >       Router anycast address [RFC4291].
      >
      >       b) Addresses in which the rightmost 64 bits are assigned the
      >       highest 128 values, (i.e., ffff:ffff:ffff:ff7f to ffff:ffff:ffff:
      >       ffff), SHOULD NOT be used as unicast addresses to avoid colliding
      >       with Reserved Subnet Anycast Addresses [RFC2526].
      
        Any reason these are not MUST NOTs?
      
    3. Adrian Farrel: Comment [2011-02-17]:
      I have reduced my position from a Discuss after useful discussion with two of
      the authors about whether an "updates" clause would be useful/relevant.
      
      It would be good to find a way to dilute the language that appears to say the
      I-D is fixing some specific issues in a specific RFC. Maybe a way forward would
      be to be more positive about this document "This document provides a definitive
      statement on..." "This document clarifies issues in a number of previous RFCs
      that have led to misunderstandings..." "This document offers latest guidance /
      best common practice on the use of..."
      I'll leave this with the
      authors/shepherd/AD to think about, and if you think it is silly or wrong or
      impossible, then it's your document and this is only a Comment.
      
      
    4. Sean Turner: Comment [2011-02-16]:
      #1) Sec 3: s/does not apply/do not apply
      
      #2) Sec 5.1: s/which uses medium/which use a medium
      

    draft-ietf-isis-reg-purge

    1. Ralph Droms: Discuss [2011-02-16]:
          A brief DISCUSS that will be easy to clear...
      
      Following up to get a bit of history filled in, section 3.3.1 of RFC
      3563 indicates that, as of the time of publication of RFC 3563,
      ISO/IEC JTC1 would take over the IS-IS registry:
      
         Until JTC1 provides the registry service for IS-IS, IANA is requested
         to temporarily maintain such a registry as described below.  Upon
         notification from JTC1, the registry management authority (i.e.,
         value allocation) will be transferred to JTC1. [...]
      
         [...] IETF SHALL keep JTC1/SC6 informed of TLV codepoint
         values allocated, and JTC1/SC6 SHALL refer allocation requests
         arising within JTC1 constituencies to the IANA registry process.
      
      Has this transfer of registry service to JTC1 taken place or (as I
      assume) is the IANA registry still authoritative?  Is there still a
      need to notify JTC1 of the change to the registry proposed in this
      document?
       
          
    2. Lars Eggert: Comment [2011-02-15]:
      Agree with Dan that this document should be on a telechat AFTER it
      passes IETF last call (unless this is urgent in some way?)
      
      Section 4., paragraph 1:
      >    This document requests that IANA modify the IS-IS 'TLV Codepoints
      >    Registry' by adding a column in the registry for 'Purge'.  A 'y' in
      >    this column indicates that the TLV for this row MAY be found in a
      >    purge.  A 'n' in this column indicates that the TLV for this row MUST
      >    NOT be found in a purge.
      
        It would be slightly more self-explanatory if the registry column was
        titled "Allowed in Purge".
      
    3. Tim Polk: Discuss [2011-02-16]:
          This is a fine document, and I support its publication, but...
      
      I was surprised to find an extensive update to the purge processing and
      generation
      rules in this document.  The title, abstract, and introduction gave
      me no clue that
      there would be new processing rules.  Perhaps that merits a
      mention somewhere
      before section 3? 
          
    4. Dan Romascanu: Comment [2011-02-14]:
      I have no objection with approving the document as it stands right now but I
      observe that there is an IETF Last Call running for it and lasting six days
      after the IESG telechat date. I suggest that any approval be conditional, and in
      case substantial comments are submitted as Last Call comments after the IESG
      telechat they are brought to the attention of the IESG.

    draft-ietf-isis-purge-tlv

    1. Ralph Droms: Comment [2011-02-16]:
      Balloting no objection assuming there is an easy answer to my question
      (posted to draft-ietf-isis-reg-purge-00) about the IANA ISIS-TLV
      registry and notifying ISO JTC1.
    2. Tim Polk: Comment [2011-02-16]:
      In the Intro, this document states:
      
         Field experience has observed several circumstances where an IS can
         improperly generate a purge.  These are all due to implementation
         deficiencies or implementations that predate [ISO TC1] and generate a
         purge when they receive a corrupted LSP.
      
      In the security considerations, it is noted that:
      
         Therefore, all implementations in a domain implementing
         authentication MUST be upgraded to receive the POI TLV before any IS
         is allowed to generate a purge with the POI TLV.
      
      Since you need to touch every ISIS implementation in the domain anyway, is it
      worth stating that
      implementations SHOULD be updated for consistency with [ISO
      TC1] (i.e., and not generate a purge
      when they receive a corrupted LSP) at the
      same time?
    3. Dan Romascanu: Comment [2011-02-14]:
      >   This document requests that IANA assign code point 13 for the 'Purge
         Originator Identification' TLV from the IS-IS 'TLV Codepoints
         Registry'.  The additional values for this TLV should be: IIH:n,
         LSP:y, SNP:n, Purge:y.
      
      I assume that this is OK with this document but usually an Internet-Draft cannot
      / should not make a request for a specific value, but just require a code point
      value and recommend that this value be 13.
    4. Sean Turner: Comment [2011-02-16]:
      Please add a pointer for where I can find the definition of system ID.

    draft-ietf-pim-registry

    1. Lars Eggert: Comment [2011-02-15]:
      Section 3.2., paragraph 1:
      >    Assignment of new message types is done according to the "IETF
      >    Review" model, see [RFC5226].
      
        It'd be good to add "or IESG Approval" here - there are sometimes
        cases where that shortcut is needed.
      
    2. Tim Polk: Comment [2011-02-16]:
      I can't remember if there is a precedent for registry documents achieving PS.
      The decision to reserve the value 15 to support extensibility might be
      justification, but that seems relatively weak.  So, I support discussing
      Robert's issue, but do not have a particularly strong position either way.  If
      anyone can point out precedent justifying going PS that would be enough for
      me...
    3. Dan Romascanu: Discuss [2011-02-17]:
          > 3.2.  Assignment of new message types
      
      >    Assignment of new message types is done according to the "IETF
         Review" model, see [RFC5226].
      
      Adding new message types would update this document whose intended status is PS.
      It looks like "IETF Review" policy is not enough, as IETF Review does not
      mandate a standards track document, but just WG or AD-sponsored documents that
      go through IETF Lasc Call (but still could be Informational or Experimental).
      ":Standards Action" policy seems to be needed in order to update this document.
      
      Note that if Robert's DISCUSS is resolved by donwngrading the intended status of
      this document to Informational, than "IETF Review" would be sufficient. 
          
    4. Robert Sparks: Discuss [2011-02-15]:
          Why is the intended status PS? This isn't a candidate for progression on the
      standards ladder (an interop report will never make sense). 
          

    draft-turner-akf-algs-update

    1. Adrian Farrel: Comment [2011-02-16]:
      Can I express my considerable concern about the wasted space on page one of this
      document without which you would have completed it in only three pages.

    draft-turner-ekpct-algs-update

    1. Alexey Melnikov: Comment [2011-02-10]:
      3.  SignedData
      
         If an implementation encapsulates an EncryptedKeyPacakge with a
      
      typo: EncryptedKeyPackage
      
         SignedData [RFC5652], then it MAY support the signature scheme ECDSA
         [I-D.mcgrew-fundamental-ecc].

    draft-arkko-dual-stack-extra-lite

    1. Stewart Bryant: Comment [2011-02-17]:
      I agree that this looks a lot more like informational that standards track.
      
      I also agree that the introduction should be updated to reflect the exhaustion
      of the IPv4 address space.
    2. Adrian Farrel: Discuss [2011-02-16]:
          I support this document, but...
      ---
      I struggled with this document to understand
      what there is to
      implement. It all seemed a bit "obvious". Is this really a BCP
      or Informational?
      ---
      Shouldn't section 4 talk about what to do when an
      interface has used up the available number of IP addresses? Crea ting a
      "parallel" virtual interface may not be a big deal, but creating the first
      virtual interface when a physical insterface is "full" seems like a major
      operational step 
          
    3. Adrian Farrel: Comment [2011-02-16]:
      I didn't really find that Section 2 "Solution Outline" was an
      outline of the solution. It looks more like an overview of the
      problem space and the benefits of the yet-to-be-introduced
      solution.
      ---                                                   
      Maybe Section 3 should also say that "internal realm" and
      "external realm" are derived from somewhere?
      ---
      Section 3                                                  
         This document uses the term mapping as defined in [RFC4787] to refer
         to state at the NAT necessary for network address and port
         translation of sessions.
      Could you put "mapping" in quotes to stop the reader getting confused
      that you are refering to a process of "term mapping".
      ---
      Section 4
      Strictly speaking, isn't there a limit to the "arbitrary number" of
      devices served by a NAT? So it isn't really arbitrary?
      ---
      Maybe take the chance to update the info about the IANA free pool?
      
    4. Tim Polk: Comment [2011-02-16]:
      (1) Some of the introductory material is out of date.  Specifically, the IANA
      free pool has now been exhausted but the document states:
      
         At the time of writing, the IANA "free pool" contained only 12 unallocated
      unicast IPv4 /8 prefixes.
      
      This should be corrected, since the date on the RFC will be long after the free
      pool was depleted.
      
      (2) I support Adrian's discuss.  Feels like informational or BCP.  Given that
      the free pool is exhausted I lean towards BCP, but that would require another
      IETF Last Call.
    5. Peter Saint-Andre: Comment [2011-02-15]:
      Thanks for this clearly written document.
      
      This document feels Informational (not Standards Track) to me, but I'm fine with
      publication as Proposed Standard.

    draft-cheshire-dnsext-special-names

    1. Alexey Melnikov: Comment [2011-02-14]:
      I agree with a comment that this document should register existing special names
      in the registry, or make a more compelling argument about why the registry is
      needed.
    2. Tim Polk: Discuss [2011-02-16]:
          I expected the document to seed the registry with entries (at a minimum) for the
      special domain names identified in the introduction:
      
         Analogous to Special-Use IPv4 Addresses [RFC5735], DNS has its own
         concept of reserved names, such as "example.com", "example.net", and
         "example.org", or any name falling under the top level pseudo-domain
         "invalid" [RFC2606].
      
      Without those entries (or a plan to create those entries), I don't quite see
      that this document accomplishes anything. 
          
    3. Tim Polk: Comment [2011-02-16]:
      last sentence of section 2: "reservation of a Special-Use Domain Names" -
      s/Names/Name/
    4. Dan Romascanu: Discuss [2011-02-14]:
          The OPS-DIR review performed by Jouni Korhonen raised the issue bellowed. I
      would like to see it addressed before approving this document:
      
      o In section 4, check step 2. Do algorithmically generated
        names fall into this category? If yes, these should be
        mentioned in the draft as well. There are a number of cases
        and deployments where names are generated on fly (by the
        end host application) using available execution/service
        environment context awareness, other information sources like
        certain hardware dongles/smartcards and specific suffixes.
        Those are in most cases treated differently in application
        software and occasionally also by the name resolution APIs
        and libs (reference to check step 3).
      
        If algorithmically generated names fall into special names
        category I see documenting those as a big challenge.. if
        existing legacy also needs to be documented under the newly
        created IANA registry.
       
          
    5. Peter Saint-Andre: Comment [2011-02-14]:
      Although I do not object to publication of this document, I agree that it would
      be preferable for this document to seed the registry with initial registrations.
    6. Robert Sparks: Comment [2011-02-15]:
      Thanks for this effort - I expect this registry (as long as its registration
      policy is Standards Action) to be a very useful tool.
      
      Will you be updating draft-cheshire-dnsext-multicastdns to explicitly request
      registration of .local (pointing to section 23 of that draft?)
    7. Sean Turner: Discuss [2011-02-16]:
          The first one is a DISCUSS-DISCUSS
      
      #1) Is adding a new required section in an RFC done this in way?  It seems like
      this ought to come from a WG or be part of the style guide?
      
      #2) Use of the word "needs" in Section 3 seems like it ought to be MUST.  Is
      there a time when you wouldn't do the items it suggests?
      
      #3) Shouldn't the "Special Name Considerations Section" just be part of the IANA
      considerations section? 
          
    8. Sean Turner: Comment [2011-02-16]:
      1) +1 to including values.  Maybe some from http://www.ietf.org/mail-
      archive/web/dnsext/current/msg10557.html ?
      
      2) There really aren't any security considerations.  Could move the last
      sentence to section 4.

    draft-ietf-mipshop-transient-bce-pmipv6

    1. Adrian Farrel: Comment [2010-08-26]:
      Clearing my Discuss on the basis of Jari's answer:
      "That's a good question to ask. The answer is yes."
    2. Russ Housley: Comment [2011-02-15]:
        
        Do either of the IPR statements related to this document cause pause?
    3. Alexey Melnikov: Comment [2010-08-26]:
      6.  IANA Considerations
      
         This specification also adds one status code value to the Proxy
         Binding Acknowledge message, the
         PBU_ACCEPTED_TB_IGNORED_SETTINGSMISMATCH status code.  The
         PBU_ACCEPTED_TB_IGNORED_SETTINGSMISMATCH status code is described in
         Section 4.7.  Its value must be assigned from the same number space
         used for the Mobile IPv6 Binding Acknowledgement status values, as
         defined in [RFC3775], and must be smaller 128.
      
      I am looking at <http://www.iana.org/assignments/mobility-parameters/mobility-
      parameters.xhtml> and I am not finding "Binding Acknowledgement status" sub-
      registry. Am I looking in a wrong place, or is it named differently?

    draft-ietf-pce-inter-layer-req

    1. Russ Housley: Comment [2011-02-16]:
      
          
    2. Dan Romascanu: Comment [2011-02-17]:
      Section 4.6. - Impact on Network Operation seems descriptive and contains no
      requirements (as do sections 4.1-4.5). If this is the case it should be
      explicitely stated.

    draft-ietf-intarea-shared-addressing-issues

    1. Ralph Droms: Discuss [2011-02-16]:
          I don't understand this sentence:
      
      17.  IPv6 Transition Issues
      
         [...]
      
         Shared addresses should be drawn from space designated as such
         [RFC1918].  Otherwise their use will break the widely implemented
         assumption that public IPv4 addresses are globally unique addresses
         and hence break many protocols and applications, [...]
      
      Which "shared addresses" are under discussion here?  Isn't the
      motivation for this document the need to share public addresses
      because of IPv4 address exhaustion?
      
      Later in the same section:
      
         Issues created by sharing public address
         space across multiple hosts are specifically addressed in
         [I-D.thaler-port-restricted-ip-issues].
      
      Isn't thaler-port-restricted-ip-issues just focused on issues with A+P
      addressing, not generally public address space sharing issues?
      
      Does address sharing affect any other transition technologies, or just
      6-to-4?
       
          
    2. Ralph Droms: Comment [2011-02-16]:
      In Figure 1, while reverse DNS is affected (more precisely, broken) by
      NAT without address sharing, in my opinion it is affected differently
      (more broken) by address sharing.  Might deserve "xx"?
      
      
    3. Lars Eggert: Discuss [2011-02-16]:
          I'm adding a placeholder discuss to make sure the discussion between the authors
      and the tsv-dir reviewer terminates and we have a version submitted that
      addresses all comments. 
          
    4. Lars Eggert: Comment [2011-02-15]:
      Section 1., paragraph 1:
      >    Authority (IANA) were completed on Feburary 3, 2011 [IPv4_Pool].
      
        Nit: s/Feburary/February/
      
      Section 1., paragraph 3:
      >    Over the long term, deploying IPv6 is the only way to ease pressure
      >    on the public IPv4 address pool without the need for address sharing
      >    mechanisms that give rise to the issues identified herein.  In the
      >    short term, maintaining growth of IPv4 services in the presence of
      >    IPv4 address depletion will require address sharing.
      
        Given the huge list of issues, I find it surprising to see that the
        document says "In the short term (...) IPv4 address depletion will
        require address sharing." The document should much more strongly argue
        for deploying IPv6 as the solution. It does in a few places, but I
        think the message bears repeating. Put it in the footer! :-)
      
      Section 3., paragraph 3:
      >    +------------------------------------------------+--------+---------+
      >    |                   Issue                        |   1st  |   3rd   |
      >    |                                                |  party | parties |
      >    +------------------------------------------------+--------+---------+
      
        It would be good for each issue in the table below to indicate which
        section discusses it in more detail. This is not at all clear from the
        headings of the subsequent sections. Add a column for this?
      
      Section 5.1., paragraph 3:
      >    A potential problem with dynamic allocation occurs when one of the
      >    subscriber devices behind such a port-shared IPv4 address becomes
      >    infected with a worm, which then quickly sets about opening many
      >    outbound connections in order to propagate itself.  Such an infection
      >    could rapidly exhaust the shared resource of the single IPv4 address
      >    for all connected subscribers.  It is therefore necessary to impose
      >    limits on the total number of ports available to an individual
      >    subscriber to ensure that the shared resource (the IPv4 address)
      >    remains available in some capacity to all the subscribers using it.
      
        Limits aren't the only way of handling this. You can also kill off
        established connections when the port space runs out. If you do this
        randomly, a user with many connections will be proportionally more
        likely to get hit, which is what is needed. The benefit of the "kill"
        scheme is that you can support a wider variety of sharing patterns
        compared to fixed limits.
      
      Section 5.2.2., paragraph 2:
      >    For example, the use of DNS SRV records [RFC2782] provides a
      >    potential solution for subscribers wishing to host services in the
      >    presence of a shared-addressing scheme.  SRV records make it possible
      >    to specify a port value related to a service, thereby making services
      >    accessible on ports other than the Well-Known ports.  It is worth
      >    noting that this mechanism is not applicable to HTTP.
      
        HTTP as well as many other legacy protocols.
      
      Section 13.1., paragraph 0:
      > 13.1.  Abuse Logging and Penalty Boxes
      
        An addition to this section: There are web tie-ins into different
        black lists that some web site owners subscribe to which redirect
        clients to a URL that basically says "hey, your machine is infected."
        Sometimes, they even prevent their site from then working for that
        users, in order to "give incentives" to fix the problem. With address
        sharing, someone else's worm can hence interfere with my ability to do
        stuff. (And I already see this today behind the Nokia NAT, because
        some clown here has an infected Windows box on the intranet...)
      
    5. Alexey Melnikov: Comment [2011-02-17]:
      13.6.  Policing Forwarding Behaviour
      
         If some form of IPv6 ingress filtering is deployed in the broadband
         network and DS-Lite service is restricted to those subscribers, then
         tunnels terminating at the CGN and coming from registered subscriber
         IPv6 addresses cannot be spoofed.  Thus a simple access control list
         on the tunnel transport source address is all that is required to
         accept traffic on the southbound interface of a CGN.
      
      Is "southbound" a common terminology?
      
      17.  IPv6 Transition Issues
      
         Subscribers allocated with private addresses will not be able to
         utilise 6to4 to access IPv6, but may be able to utilise Teredo.
      
      This needs an Informative reference.
      
      The first reference to HTTP needs an Informative reference.
      
    6. Peter Saint-Andre: Comment [2011-02-15]:
      Section 12 on Traceability refers to "the offending activity". Given the
      principle of innocent until proven guilty, I suggest "a particular activity".
    7. Robert Sparks: Discuss [2011-02-15]:
          This document calls out to draft-thaler-port-restricted-ip-issues for several
      important discussions, but that document has not been refreshed since Feb-10,
      and I'm not finding any other signs of activity around it. What is the plan for
      moving that document forward? 
          
    8. Robert Sparks: Comment [2011-02-15]:
      Please consider the text proposed by Richard Barnes at
      <https://www.ietf.org/ibi
      n/c5i?mid=6&rid=49&gid=0&k1=933&k2=55495&tid=1297789532>

    draft-ietf-ccamp-rwa-wson-framework

    1. Russ Housley: Comment [2011-02-15]:
        Please consider the comments from the Gen-ART Review by Pete McCann
        on 7-Feb-2011.  The comments cab be found at:
      
          http://www.softarmor.com/rai/temp-gen-art/
          draft-ietf-ccamp-rwa-wson-framework-10-mccann.txt

    draft-mraihi-totp-timebased

    1. Russ Housley: Comment [2011-02-16]:
        Please consider the questions raised on the Gen-ART Review by
        Ben Campbell on 14-Feb-2011.  He asks about Section 5.2:
      
        Is there a requirement that the proover must not make a second
        attempt inside a given time window? If so, that was not clear
        from the text.  If there is not such a requirement, are there
        security implications if the proover does send multiple messages
        inside the same tick?  It is not really a one time pad if that
        happens is it?
    2. Alexey Melnikov: Discuss [2011-02-12]:
          I am generally in favor of getting this document published. However I would like
      to clarify a couple of things before recommending approval of this document.
      
      3.  Algorithm Requirements
      
         R8 - The TOTP algorithm SHOULD be used for online application.
      
      Can you please explain this requirement?
      
      6.  Resynchronization
      
         Also, it is important to note that the longer a prover has not sent
         an OTP to a validation system, the longer (potentially) the
         accumulated clock drift between the prover and the verifier.  In such
         cases, the default synchronization may not be proper when the drift
         exceeds beyond allowed threshold.  Additional authentication measures
         SHOULD be used for the validation system to safely authenticate the
         prover.
      
      What are these measures? I.e. how can the SHOULD be satisfied.
       
          
    3. Alexey Melnikov: Comment [2011-02-12]:
      Abstract
      
         This document describes an extension of one-time password (OTP)
         algorithm, namely the HAMC-Based
      
      typo: HMAC-Based
      
      1.2.  Background
      
         The default HMAC-SHA-1 function could be replaced by HMAC-SHA-256 or
         HMAC-SHA-512 to leverage HMAC implementations based on SHA-256 or
         SHA-512 hash functions.
      
      Missing references for SHA-256/512.
      
      5.1.  General
      
         All the communications SHOULD take place over a secure channel e.g.
         SSL/TLS, IPsec connections.
      
      Missing informative references for TLS and IPSec.
      
    4. Dan Romascanu: Discuss [2011-02-14]:
          1. The IANA Considerations section states: 
      
      > The OTP algorithm defined in this document can be referred by a URI
         defined in a separate document.  [ALGP] is such an attempt that
         defines various OTP related algorithm URIs.  There is no registration
         needed in this document.
      
      However [ALGP] is according to Section 9.2 draft-hoyer-keyprov-pskc-algorithm-
      profiles-01.txt which I could not find in the tracker. Is there some kind of
      mistake, maybe a typo or a change of name of the document?
      
      2. The Time-step size is RECOMMENDED and has a default value of 30 seconds. Are
      there cases when this value can be different, how is it changed if such cases
      exist and how can a network operator know what is the Time-step size value on a
      client? 
          
    5. Peter Saint-Andre: Comment [2011-02-15]:
      I concur with with the discusses from Dan Romascanu, Robert Sparks, and Alexey
      Melnikov.
    6. Robert Sparks: Discuss [2011-02-15]:
          1) This document contains a sizable "Code Component" in Appendix A, but does not
      appear to be following the TLP recommendations for stating copyright. Is that
      intentional?
      
      2) What are the consequences of the generator and consumer of a TOTP having
      different system parameter values configured for X (say the recommended 30s at a
      generator, and 90s at a consumer)? X does not appear to be transmitted. Can this
      mismatch be detected? Similarly, what are the consequences of mismatched T0
      values? 
          
    7. Robert Sparks: Comment [2011-02-15]:
      Stronger rationalization for the default of 30s for X would be welcome. From the
      existing text, it seems to have been selected expecting that the only use will
      be humans logging into websites. If that's accurate, it would help to explicitly
      state it in the document. If it's not accurate, more explanation is needed.

    draft-eastlake-sha2b

    1. Alexey Melnikov: Comment [2011-02-16]:
             id-sha224  OBJECT IDENTIFIER  ::=  {{ joint-iso-itu-t(2)
                                  country(16) us(840) organization(1) gov(101)
                                  csor(3) nistalgorithm(4) hashalgs(2) 4 }
      
      Just to double check: the last component is 4 here, right?
      
             id-sha256  OBJECT IDENTIFIER  ::=  { joint-iso-itu-t(2)
                                  country(16) us(840) organization(1) gov(101)
                                  csor(3) nistalgorithm(4) hashalgs(2) 1 }
             id-sha384  OBJECT IDENTIFIER  ::=  { joint-iso-itu-t(2)
                                  country(16) us(840) organization(1) gov(101)
                                  csor(3) nistalgorithm(4) hashalgs(2) 2 }
             id-sha512  OBJECT IDENTIFIER  ::=  { joint-iso-itu-t(2)
                                  country(16) us(840) organization(1) gov(101)
                                  csor(3) nistalgorithm(4) hashalgs(2) 3 }
    2. Dan Romascanu: Comment [2011-02-15]:
      
          
    3. Sean Turner: Comment [2011-02-15]:
      A fine document that I'm glad is being published.

    draft-igoe-secsh-suiteb

    1. Russ Housley: Comment [2011-02-16]:
        Please consider the comments from the Gen-ART Review by Miguel Garcia
        on 25-Feb-2011 (which are the same as the comments in the earlier
        review on 10-Jan-2011):
        
        - The document lacks an IANA section. If there is no action for IANA,
          the section should say that, e.g., including something like "This
          document has no actions for IANA." The author should consider
          whether this document requires an IANA action or not.
      
        - The document seems to lack the recommended RFC 2119 boilerplate,
          even if it appears to use RFC 2119 keywords and a reference to
          RFC 2119 exists in the Normative References section.
      
        - There are a number of unused references, including: AEAD,
          RFC4250, SSH-Auth, GCM.

    draft-ymbk-aplusp

    1. Ralph Droms: Discuss [2011-02-17]:
          Discuss-discuss, which I will clear after the telechat:
      
      * a+p supports and encourages the extended use of IPv4 while providing
        no incentive or support for the transition away from IPv4 to IPv6
      * any effort spent on correcting technical issues with a+p would be
        better spent on resolving issues impeding the transition to IPv6 
          
    2. Lars Eggert: Discuss [2011-02-15]:
            DISCUSS: The last item of Pasi Sarolahti's tsv-dir review requires a
        response.
      
      INTRODUCTION, paragraph 1:
      > Intended status: Experimental
      
        DISCUSS: The body of the document does not discuss at all in which way
        this technology is to be considered experimental, and in which kinds
        of deployments this technology may be experimented with. In fact,
        Section 5 is worded in way that suggests a readiness for global
        deployment. While I understand that this is the opinion of the
        authors, that is not what Experimental RFCs are for. We had several
        BOFs on this topic that all failed to convince the community of the
        value of this approach; I'm surprised to see the same content back
        with an Experimental label for publication on the IETF Stream.
      
      INTRODUCTION, paragraph 10:
      >    This Internet-Draft is submitted in full conformance with the
      >    provisions of BCP 78 and BCP 79.  This document may not be modified,
      >    and derivative works of it may not be created, and it may not be
      >    published except as an Internet-Draft.
      
        DISCUSS: The document has an IETF Trust Provisions (28 Dec 2009)
        Section 6.c(ii) Publication Limitation clause.  If this document is
        intended for submission to the IESG for publication, this constitutes
        an error.
      
      Section 5.3.4., paragraph 0:
      > 5.3.4.  Limitations of the A+P approach
      
        DISCUSS: Just having reviewed
        draft-ietf-intarea-shared-addressing-issues, this section doesn't even
        begin to scratch the surface when it comes to limitations. I don't
        want you to duplicate all the content from
        draft-ietf-intarea-shared-addressing-issues here, but a reference to
        this document plus an upfront summary of the limitations described
        therein need to be added here.
       
          
    3. Adrian Farrel: Comment [2011-02-15]:
      I know the RFC Editor can fix this, but in the spirit of devolving work...
      You need to not describe the document as a "draft"
      
      ---
      
      It is not a requirement, but I think it is helpful if Experimental RFCs give
      some scope to the experiment both in terms of how it is "contained" and how the
      success of the experiment will be judged. This need not be a lot of text.
    4. Dan Romascanu: Discuss [2011-02-16]:
          The issues raised by Tina Tsou in her review
      https://www.ietf.org/ibin/c5i?mid=6&rid=49&gid=0&k1=933&k2=55308&tid=1297852737
      were not addressed at the technical level. I would like to see a response on
      these issues before approving the document. If these were already answered
      please point me to the answer. 
          
    5. Robert Sparks: Comment [2011-02-15]:
      Support Lars' discuss on providing details on evaluating the experiment
      
      Please consider adding the text proposed by Richard Barnes at
      <https://www.ietf.
      org/ibin/c5i?mid=6&rid=49&gid=0&k1=933&k2=55496&tid=1297789602>
      
      This example is somewhat misleading:
         "(e.g., VoIP clients register a
      public IP and a single delegated port from the CPE, and accept
         incoming calls
      on that port)".
      Most VoIP clients will ask for a separate port for the voice
      media from the one used for signaling.

    draft-irtf-rrg-design-goals

    1. (none)

    draft-irtf-dtnrg-sdnv

    1. Ralph Droms: Comment [2011-02-15]:
      I have one comment with my independent reader hat on.  I was a little
      surprised, after several potential uses of SDNVs were described earlier
      in the document, to read:
      
        In general, it seems like the most promising use of SDNVs may be to
        define the Length field of a TLV structure to be an SDNV whose value
        is the length of the TLV's Value field.  As previously discussed,
        this leverages the strengths of the SDNV format and limits the
        effects of its weaknesses.
      
      I was left wishing for a little more explanation of why the authors make
      this statement and wondering why the other potential uses for SDNVs
      were judged less promising.
    2. Peter Saint-Andre: Comment [2011-02-15]:
      The introduction states:
      
         One example of SDNVs being used outside of the 
         DTN protocols is in Hixie's Web Socket protocol
         [I-D.hixie-thewebsocketprotocol], which includes 
         a binary frame length indicator field identical to an 
         SDNV.
      
      Referencing draft-hixie-thewebsocketprotocol-76 seems problematic, given that
      this individual I-D was superseded by draft-ietf-hybi-thewebsocketprotocol and
      the work of the IETF's HYBI WG. If this text is not really needed here, I would
      urge its removal to prevent confusion regarding the canonical documentation of
      the WebSocket protocol.

    draft-irtf-dtnrg-bundle-security

    1. (none)

    draft-irtf-dtnrg-cbhe

    1. Alexey Melnikov: Comment [2011-02-16]:
      I don't believe this document is conflicting with ongoing IETF work, so I have
      no objections to its publication.
      
      However I have a small set of mostly editorial nits I would like the document
      editor to consider:
      
      Was the URI registration checked by Graham Klyne (the Designated URI Expert
      Reviewer)? I doubt he will have any issues with this, but it would be better to
      check this earlier.
      
      4.  IANA Considerations
      
         URI scheme syntax:
      
         This specification uses the Augmented Backus-Naur Form (ABNF)
         notation of [RFC2234], including the core ABNF syntax rule for DIGIT
      
      This should be RFC 5234, but I think RFC Editor will fix that.
      
         defined by that specification.
      
         o  ipn-uri := "ipn:" ipn-hier-part
      
         o  ipn-hier-part := node-nbr nbr-delim service-nbr ; a path-rootless
      
         o  node-nbr := 1*DIGIT
      
         o  nbr-delim := "."
      
         o  service-nbr := 1*DIGIT
      
      s/:=/=
      
      The following field is missing from the IANA registration template:
      
         References.
            Include full citations for all referenced documents.  Registration
            templates for provisional registration may be included in an
            Internet Draft; when the documents expire or are approved for
            publication as an RFC, the registration will be updated.
      
      This field should just point to the draft itself.
      

    draft-irtf-dtnrg-bundle-metadata-block

    1. Peter Saint-Andre: Comment [2011-02-15]:
      In accordance with RFC 5742, I recommend that the IESG take the following
      position regarding this IRTF-stream document:
      
         The IESG has concluded that there is no conflict between this
         document and IETF work.
      
      This recommendation has been entered in the datatracker.
      
      In addition, and outside the scope of IESG review in accordance with RFC 5742, I
      have the following technical comments, which the author is free to consider or
      not as desired:
      
      1. The definition of the URI metadata type does not mention Internationalized
      Resource Identifiers (IRIs); is it envisioned that IRIs could be supported via
      transformation into URIs as specified in RFC 3987?
      
      2. Section 4.1 states:
      
         Unless determined by local policy, the specific
         processing steps that must be performed on bundles with metadata
         blocks containing metadata of type URI are expected to be included as
         part of the URI encoding of the metadata.
      
      It is unclear to this reader (a) how the processing steps are to be encoded in
      the URI and (b) if such processing steps are intended to override or supplement
      the processing steps defined in RFC 3986 for URIs in general.

    draft-irtf-dtnrg-bundle-previous-hop-block

    1. (none)

    draft-irtf-dtnrg-iana-bp-registries

    1. Dan Romascanu: Comment [2011-02-16]: