IESG Narrative Minutes

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

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

Corrections from: Pete

1 Administrivia

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

2. Protocol Actions

2.1 WG Submissions

2.1.1 New Items

  1. RaptorQ Forward Error Correction Scheme for Object Delivery (Proposed Standard)
    draft-ietf-rmt-bb-fec-raptorq-05
    Token: David Harrington
    Note: Brian Adamson (adamson@itd.nrl.navy.mil) is the document shepherd.
    IPR: QUALCOMM Incorporated's Statement about IPR related to draft-ietf-rmt-bb-fec-raptorq-02
    IPR: QUALCOMM Incorporated's Statement about IPR related to draft-ietf-rmt-bb-fec-raptorq-05
    Discusses/comments (from ballot 3572):
    1. Stewart Bryant: Discuss [2011-04-13]:
      I could not see an IPR disclosure in the Last Call text.
      I am by no means an IPR expert, but the IPR claim seems to imply different terms depending on whether packets containing this protocol are sent over different types of network. That seems contra to the IETF position of wanting to be able to send our protocols over any link type. It therefore seems particularly important that the community's attention be draft to the IPR statement when deciding whether to proceed with the Standard.
      Presumably if there is a single a digit error in any one of the number of very large tables of numbers there will be at the very least an interoperability issue with existing implementations, or even a broken protocol. Is it possible to make the generator polynomials for these tables normative, and the tables themselves informative? This would substantially reduce the scope for a process error somewhere between the original compilation of these tables and the final publication of the RFC.
    2. Stephen Farrell: Discuss [2011-04-13]:
      (1) Its not clear to me that an implementer of this would understand whether or not they'd be covered by the IPR declaration which only seems to call out specific uses. One solution might be to add an applicability statement to the draft that matches the conditions under which the IPR situation is well-defined.
      (2) Is there a reason to prefer sha-1 in the security considerations section? sha-256 may be better as an algorithm that will have a longer shelf-life. If you want to stick with sha-1 then you should make it clear what properties of the hash algorithm are required (collision resistance, pre-image resistance...)
    3. Peter Saint-Andre: Discuss [2011-04-12]:
      Given that various fields are longer than 8 bits (e.g., the Encoding Symbol ID (ESI), Transfer Length (F), and Symbol Size (T) elements), please specify the network byte order (probably it is network byte order, but it needs to be specified).

    Telechat:

  2. Export of Structured Data in IPFIX (Proposed Standard)
    draft-ietf-ipfix-structured-data-05
    Token: Dan Romascanu
    Note: Nevil Brownlee is the document shepherd
    Discusses/comments (from ballot 3719):
    1. Stewart Bryant: Comment [2011-04-12]:
      The following are minor nits that I noticed during my review
      In Section 2: "However, the amount of information has become so important..."
      I think you mean "....so large...."
      2.4. The Proposal:This is a standards track doc - therefore this is no longer a proposal.
    2. Adrian Farrel: Discuss [2011-04-14]:
      This is a fine document, and I have no objection to it. However, in reading it I discovered a question about the three-octet length encoding. This shows in this document through text such as:
      If the subTemplateMultiList is encoded as a Variable-Length Information Element in 255 or more octets, it is encoded with the Length field per Section 7 of [RFC5101] as follows:
            0                   1                   2                   3 
             0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
            +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
            |      255      |      Length (0 to 65535)      |   Semantic    | 
            +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      
      On examination of RFC 5101 I find this to be ambiguous. In particular, it is not clear what would be meant by the length encoding ff,0,0. Is that invalid, or does it mean a length of zero? I suspect it means a length of zero, and that 255 means "use extended length encoding", and does not mean "length is >= 255".
      I am querying this with the editor of RFC 5101 and if we can agree a clarification, I will raise an Erratum and request that the text in this document is clarified.
    3. Stephen Farrell: Comment [2011-04-13]:
      With the additional rfc editor note added to the security considerations this is fine.
    4. Russ Housley: Comment [2011-04-13]:
      The Gen-ART Review by Suresh Krishnan on 12-Apr-2011 shows two places where the document is not clear. Please address these two places.
      Section 2 says: "However, the amount of information has become so important that, when dealing with highly granular information such as Flow information, a push mechanism (as opposed to a pull mechanism, such as SNMP) is the only solution for routers whose primary function is to route packets."
      Did you mean that "the amount of information is so large" or did you mean that "collecting this information has become so important" or did you mean something else?
      Section 2 also says: "Furthermore, in order to reduce the export bandwidth requirements, the network elements have to integrate mediation functions to aggregate the collected information, both in space and time."
      What does aggregation based on space mean?
    5. Peter Saint-Andre: Discuss [2011-04-12]:
      Appendix A appears to redefine or extend the XML (and XML schema) first provided in RFC 5102. At a minimum, this document therefore should say that it "Updates RFC 5102" (in the first-page header and in the Abstract). Furthermore, it's messy to just place some additional XML elements and XML schema definitions in Appendix A -- it would be cleaner to provide the complete (updated) XML and XML schema to make processing and testing easier. Finally, it is unclear what things like elementId="XXX" are supposed to mean -- are the three characters placeholders for values to be assigned by the IANA, or are they literal strings?

    Telechat:

  3. Port Mapping Between Unicast and Multicast RTP Sessions (Proposed Standard)
    draft-ietf-avtcore-ports-for-ucast-mcast-rtp-01
    Token: Robert Sparks
    Note: Roni Even (Even.roni@huawei.com) is the document shepherd.
    Discusses/comments (from ballot 3725):
    1. Jari Arkko: Comment [2011-04-14]:
      One comment from Ari Keränen who helped me with some of the reviews:
      Section 7.2. says: "The use of SDP for the port mapping solution normatively requires the support for [...] Multiplexing RTP and RTCP on a single port on both endpoints in the unicast session [RFC5761]".
      Isn't this a requirement for the whole mechanism (if RTP and RTCP are used on the same ports as defined in section 3), not just with SDP? Perhaps the RFC5761 requirements should already be mentioned in section 3?
    2. Stephen Farrell: Discuss [2011-04-13]:
      The max token size is 1024 bits - right? If so, that would not be enough to allow use of many public key encryption schemes and would also prevent inclusion of more complex data within a token (e.g. additional client or session attributes). I can understand that you might not want that now but it seems a bit arbitrary to limit token size like that. Did (or would) the WG consider a two byte length field?
    3. Stephen Farrell: Comment [2011-04-13]:
      (1) s/If there is no NAT devices/If there are no NAT devices/
      (2) p20 says: key-id || hash-alg (client-ip | nonce | abs-expiration) but since you're recommending HMAC-SHA1 that should be mac-alg rather than hash-alg.
      (3) Since the client controls all the inputs to the recommended HMAC calculation, except the expiration time, which may be guessable, it really had better not be the case that that same secret key is used for something else that could get fooled if presented with a token. This is perhaps an unlikely cross-protocol attack (though with manual key management, perhaps not that unlikely) but I'd suggest a sentence in the security considerations saying servers MUST NOT use the same secret from the recommended scheme for other purposes.
    4. Pete Resnick: Comment [2011-04-14]:
      I don't object to this document being published, but I must say for someone outside of the area, this is rather dense and difficult to comprehend. In particular, getting through section 3 is nearly impossible without a lot of forward-reference looking. It took me reading through all of sections 4 and 5 to finally figure out
      (a) that the Token is simply a server-generated hash of the client's IP address, a time-to-live, and some random data generated by the client (section 3 says that "The Token is essentially an opaque encapsulation", and I have no idea what that is supposed to mean); and
      (b) that the client is told of the Token's expiration when it requests the Token. I would really like that first part of section 3 to lay out the basic principles in easier to understand language.
    5. Peter Saint-Andre: Comment [2011-04-12]:
      Please expand "SSM" on first use, and consider adding an informational reference to RFC 4607.
    6. Sean Turner: Discuss [2011-04-12]:
      #1) Section 5 contains the following text: "An example way for constructing Tokens is to perform HMAC-SHA1 [RFC2104] on the concatenated values of the information listed above. The HMAC key needs to be at least 160 bits long, and generated using a cryptographically secure random source [RFC4086]. While HMAC-SHA1 is the RECOMMENDED procedure, implementations might adopt different approaches."
      The paragraph starts off saying HMAC-SHA1 is an example. It then later says it's the recommended way. It would be much clearer if the paragraph said initially that HMAC-SHA1 is the recommended approach. And, then maybe spin "needs to be" as "MUST be": if HMAC-SHA1 is used then the HMAC key MUST be 160 bits long, and generated using ...

    Telechat:

  4. The Profile for Algorithms and Key Sizes for use in the Resource Public Key Infrastructure (Proposed Standard)
    draft-ietf-sidr-rpki-algs-05
    Token: Stewart Bryant
    Note: Sandra Murphy (sandra.murphy@sparta.com) is the document shepherd.
    Discusses/comments (from ballot 3730):
    1. Sean Turner: Comment [2011-04-13]:
      (blank)

    Telechat:

  5. Resource Certificate PKI (RPKI) Trust Anchor Locator (Proposed Standard)
    draft-ietf-sidr-ta-07
    Token: Stewart Bryant
    Note: Sandra Murphy (sandra.murphy@sparta.com) is the document shepherd.
    Discusses/comments (from ballot 3731):
    1. Gonzalo Camarillo: Comment [2011-04-13]:
      Introductions do not typically contain normative language.
    2. Ralph Droms: Comment [2011-04-12]:
      In section 3, s/as deem appropriate/as deemed appropriate/
    3. Wesley Eddy: Comment [2011-04-12]:
      I think in section 2.1 "A TA in the RPKI TA" is supposed to be just "A TA in the RPKI".
    4. Adrian Farrel: Comment [2011-04-14]:
      Two piddly nits that are worth addressing only if you have the document open for other reasons...
      X.509 on the second line of section 2.1 could use a reference.
      The definition of a TAL that appears in the first paragraph of 2.1 is great and could be greater if it appeared in Section 1. Actually, I am not sure that the first 2 to 2.5 paragraphs of section 2.1 don't belong in section 1.
    5. Russ Housley: Comment [2011-04-11]:
      Please consider the editorial comments from the Gen-ART Review by Wassim Haddad on 16-Mar-2011.

    Telechat:

  6. Signed Object Template for the Resource Public Key Infrastructure (Proposed Standard)
    draft-ietf-sidr-signed-object-03
    Token: Stewart Bryant
    Note: Sandra Murphy (sandra.murphy@sparta.com) is the document shepherd.
    Discusses/comments (from ballot 3732):
    1. Adrian Farrel: Comment [2011-04-14]:
      Section 3 nit: "If the all of the conditions above are true, then the signed object may be valid."
      s/the all/all/
    2. Stephen Farrell: Discuss [2011-04-13]:
      Overall this is a fine document but it seems odd that the signed object types that will use this require a standards track RFC, but yet there are no IANA considerations? I'd have thought that having an IANA registry for those would be useful for implementers. Put another way: should section 4 be turned into an IANA considerations section?

    Telechat:

  7. Sender RTT Estimate Option for DCCP (Proposed Standard)
    draft-ietf-dccp-tfrc-rtt-option-05
    Token: Wesley Eddy
    Note: Pasi Sarolahti (pasi.sarolahti@iki.fi) is the document shepherd.
    Discusses/comments (from ballot 3742):
    1. Gonzalo Camarillo: Discuss [2011-04-13]:
      This document updates RFC 5622. However, the reference to RFC 5622 was made Informative because RFC 5622 is Experimental. I believe the reference should be a Normative one because the document is actually updating RFC 5622. However, if the reference is made normative , it would be count as a downref. Let's discuss this issue in the telechat.
    2. Gonzalo Camarillo: Comment [2011-04-13]:
      This document, which is in the Standards Track, updates RFC 5622, which is an experimental RFC. The authors may want to point out the fact that RFC 5622 is Experimental somewhere in the document.
    3. Wesley Eddy: Comment [2011-03-31]:
      The document looks technically solid to me, and to the TSVDIR reviewer (Mark Allman). The authors can consider whether any minor editorial changes could help with some of Mark's editorial comments, at their perogative.
    4. Lars Eggert: Comment [2011-03-26]:
      Authors, please see if you want to incorporate the suggestion from Brian Carpenter's gen-art review in a revision.
    5. Adrian Farrel: Discuss [2011-04-06]:
      A fine document. I have no issue with its publication, but there is a small finge case, that seems to be a little hole.
      3.2.1: "A value of 0 indicates the absence of a valid RTT sample. The sender MUST set the value to 0 if it does not yet have an RTT estimate."
      How do you indicate a RTT estimate of less than 1 microsecond? You should at lea st say that this document assumes that RTTs of less than 1 microsecond will not be observed in the type of network in which this option is run. An alternative would be to say that RTT estimates of less than 1 microsecond MUST be reported as 1 microsecond. You might cover this second case, by saying that estimates MUST be rounded up to the nearest microsecond.

    Telechat:

2.1.2 Returning Items

  1. (none)

2.2 Individual Submissions

2.2.1 New Items

  1. The 'tn3270' URI Scheme (Proposed Standard)
    draft-yevstifeyev-tn3270-uri-18
    Token: Peter Saint-Andre
    Discusses/comments (from ballot 3667):
    1. Jari Arkko: Comment [2011-04-13]:
      I support Ron's discuss.
    2. Ron Bonica: Discuss [2011-04-12]:
      This is probably a DISCUSS-DISCUSS. Considering:
      - the security vulnerabilities associated with TN3270
      - that most applications supporting TN3270 also support HTTP
      should we consider capping TN3270 and one day converting all of the 3270 drafts to historic. Recall that 3270 terminal production was discontinued many years ago.
    3. Peter Saint-Andre: Comment [2011-04-12]:
      Robert Sparks and I had a conversation via IM about the lack of good security in the telnet protocol. As a result I have provisionally added the following RFC Editor Note to the tracker:
      "Please add the following paragraph at the end of the Security Considerations:
      "The telnet protocol is inherently insecure. Those needing remote login access and related services are encouraged to use a more secure technology, such as Secure Shell [RFC4251]."

    Telechat:

2.2.2 Returning Items

  1. (none)

3. Document Actions

3.1 WG Submissions

3.1.1 New Items

  1. Overview of the Internet Multicast Addressing Architecture (Informational)
    draft-ietf-mboned-addrarch-07
    Token: Ron Bonica
    Note: Lenny Giuliano (lenny@juniper.net) is the Document Shepherd
    Discusses/comments (from ballot 1846):
    1. Adrian Farrel: Comment [2011-04-14]:
      Section 6 says: "This memo includes no request to IANA.
      "IANA considerations in sections 4.1.1 and 4.1.2 of obsoleted and now Historic [RFC2908] were never implemented in IANA registry. No update is necessary.
      "(RFC-editor: This section may be removed prior to publication; alternatively, the second paragraph may be left intact.)"
      Please do keep the second paragraph at least for Historians, but also for clarity.
    2. Russ Housley: Comment [2011-04-12]:
      Please consider the improvements suggested in the Gen-ART Review by Mary Barnes 7-Apr-2011.
    3. Robert Sparks: Comment [2011-04-12]:
      The abstract doesn't capture the last sentence of the introduction: "This memo obsoletes and re-classifies to Historic RFC 2908, and re-classifies to Historic RFCs 2776 and 2909."

    Telechat:

  2. Requirements for Internet-Draft Tracking by the IETF Community in the Datatracker (Informational)
    draft-ietf-genarea-datatracker-community-07
    Token: Russ Housley
    Discusses/comments (from ballot 3721):
    1. Adrian Farrel: Comment [2011-04-14]:
      There were three requirement-oriented thoughts I had on this most recent reading...
      As a requirement for an implementor, I found 2.1.1. "Requirement: Lists of I-Ds and RFCs can be large" to be too vague. Is it saying that a hard coded limit is OK provided it supports "hundreds of I-Ds and dozens of RFCs"?
      Would it not be better to specifically reuqire "no implementation limit" to list size?
      I don't find 2.1.2 sufficiently clear. It says "Every Datatracker user can create a list." It does not say whether the limit is one list per user. I have no feeling either way, but I feel the document should be clear as it will significantly impact implementation.
      Did I miss notification of changes to a list (not of changes to I-Ds in a list)? I can consider:
      - I-D / RFC added to list
      - I-D / RFC removed from list
      - list deleted
    2. Dan Romascanu: Comment [2011-04-12]:
      1. Section 1.1: "This would include not only I-Ds that are in the many WGs that directly are changing the DNS (DNSEXT, DNSOP, BEHAVE, and so on), but also individual submissions, IAB I-Ds, and even IRTF research."
      s/IRTF research/IRTF I-Ds/
      2. Section 1.2: "the ability to get notifications when individual I-Ds from a list changes state"
      s/changes/change/
      3. Section 1.3: What is the difference between "Approved" and "Sent to the RFC Editor"?
      4. Section 2.3.2: "Associated WG or RG"
      I think this needs to be: "Associated WG or RG or IAB or IES"
    3. Sean Turner: Comment [2011-04-12]:
      Sec 1: r/sixTestVM/six
      Sec 2.3.1: I think "be" is missing from the following: "In displays, a particular I-D or RFC should only *be* included once"
      Sec 2.3.3: r/changes/changed in: "has not changes state"

    Telechat:

  3. Requirements for a Working Group Charter Tool (Informational)
    draft-ietf-genarea-charter-tool-08
    Token: Russ Housley
    Discusses/comments (from ballot 3722):
    1. Jari Arkko: Discuss [2011-04-14]:
      1. I think Section 2.1 should also include working group state (exists, closed). This information already exists in the database, and we do want to be able to track the state and charter changes of closed working groups, as well.
      2. Particularly for rechartering WGs, the WG record should also contain an "explanation" field that is often far more interesting than the technical diff of the charter changes. Such explanations are routinely provided to the IESG/IAB and to the community as a recharter proposal is made. ("The WG has completed its FOO work item, and will no longer pursue BAR given that no implementations exist. However, a work item on SNAAP has been added to address requirements from the FRYYP community.")
      3. Shouldn't the doc say something about the messages that go out; I'd love to see a recharter message with (a) the explanation, (b) the diff, and (c) the proposed new charter.
    2. Adrian Farrel: Comment [2011-04-14]:
      I support Dan's Discuss about Milestone changes. The ability to change milestones should be supported by the tool, and the history of those changes should be maintained.
    3. Dan Romascanu: Discuss [2011-04-12]:
      Are adding of milestones or milestone updates considered changes that should be recorded by the charter tool? The document is mute about these, but they happen often in-between initial chartering and re-chartering.
    4. Dan Romascanu: Comment [2011-04-12]:
      1. Introduction: "Since its publication in 1998, the IETF has started many dozen new WGs, has shut down many dozen, and every WG that has had some (often dozens) changes to its charter."
      The last part of this phrase seems broken. In any case saying that WGs had often (typically) dozens of changes to their charters since 1998 seems to me as an exageration.
      2. Section 2.1: "previous web sites (such as wikis or project sites, if any)"
      I think this should be: "other web sites (such as wikis, trackers or project sites, if any) including web sites previous to the WG formation"
      The rationale is that some WGs may continue to use wikis or issues trackers after chartering
    5. Sean Turner: Comment [2011-04-12]:
      Section 3.1: I seem to remember that dashes also cause problems for some tools. It might be worth adding this to the note.
      Sec 3.1: Has the following: "When moved to this state, a note is sent to the Secretariat to send out the external review announcement to the appropriate lists."
      Are we envisioning a radio dial for "send email to new-work" ad "do not send email to new-work"? Not sure if we want this automated or not.
      Sec 3.2: Do we want to allow the existing WG chairs to submit revised Charters and call it "Recharter Requested"?

    Telechat:

  4. A Survey of Lower-than-Best-Effort Transport Protocols (Informational)
    draft-ietf-ledbat-survey-05
    Token: Wesley Eddy
    Note: Rolf Winter (rolf.winter@neclab.eu) is the Document Shepherd.
    Discusses/comments (from ballot 3747):
    1. Lars Eggert: Comment [2011-03-26]:
      Authors, please see if you want to incorporate the comments from Elwyn Davies' gen-art review into a revision.
    2. Adrian Farrel: Discuss [2011-04-14]:
      I think this is a fine document, but I am a little surprised that Section 9 is empty and that the security aspects of the protocols surveyed are not also discussed. I am holding this Discuss so that I can verify that the Security ADs are comfortable with this point during our conference call. I will then clear my Discuss, and let them carry a Discuss if they think it is necessary.
      No action is required by the authors at this time.
    3. Stephen Farrell: Comment [2011-04-13]:
      Section 6 doesn't seem to really state any conclusion at all. Perhaps change the name of the section?
    4. Russ Housley: Discuss [2011-04-12]:
      The Gen-ART Review by Elwyn Davies on 17-Mar-2011 raises a question that deserves a response.

    Telechat:

3.1.2 Returning Items

  1. (none)

3.2 Individual Submissions Via AD

3.2.1 New Items

  1. A Uniform Resource Name (URN) Namespace for CableLabs (Informational)
    draft-cardona-cablelabs-urn-07
    Token: Peter Saint-Andre
    Discusses/comments (from ballot 3643):
    1. Stephen Farrell: Discuss [2011-04-13]:
      Discuss discuss: Why does the iesg writeup say the URN-NID list has not *yet* reviewed this? Shouldn't they go first?

    Telechat:

  2. Addition of the Camellia Cipher Suites to Transport Layer Security (TLS) (Informational)
    draft-kanno-tls-camellia-01
    Token: Sean Turner
    Note: Satoru Kanno (kanno.satoru@po.ntts.co.jp) is the document shepherd.
    IPR: Certicom's Statement of IPR Related to draft-kanno-tls-camellia-00
    Discusses/comments (from ballot 3734):
    1. Stewart Bryant: Comment [2011-04-11]:
      This document has an IPR disclosure against it, but I do not see this noted in the IETF Last Call notice.
    2. Ralph Droms: Comment [2011-04-14]:
      The IPR disclosure for this document includes: "The seller shall provide the buyer with the following written notice:
      "The use of this product or service is subject to the reasonable, non-discriminatory terms in the Intellectual Property Rights (IPR) Disclosure of Certicom Corp. at the IETF for Addition of Camellia Cipher Suites to Transport Layer Security (TLS) implemented in the product or service."
      I don't recall seeing such a provision in other IPR disclosures. If it is unusual, in my opinion it should be mentioned explicitly in any new IETF last call.
    3. Adrian Farrel: Comment [2011-04-07]:
      I am entering a "no objection" ballot on the basis of a very light review of a document far outside my area of expertise. I am relying on the shepherding Security AD to have ensured that this document is sound.
    4. Stephen Farrell: Comment [2011-04-13]:
      I don't find the idea of adding yet another 42 TLS ciphersuites to be useful and to the extent that it complicates life for developers and consumes their time (mostly) needlessly, it's a bad thing. However, I don't think it would be fair to try to hold this at this stage in the game, given that the authors had agreement from previous IESG members.
      Please also see the secdir review at: http://www.ietf.org/mail-archive/web/secdir/current/msg02584.html that indicates some clarifications may be useful.
    5. Pete Resnick: Comment [2011-04-13]:
      The IANA Considerations section should be marked as "Please remove this section after filling in the values in section 2." Having the values appear in the document twice is a sure-fire way to introduce an error.
    6. Dan Romascanu: Discuss [2011-04-12]:
      I think that the issue raised by Stewart requires a DISCUSS. The IPR disclosure seems to have been submitted after the document was sent to IETF LC - so it was not brought up to the attention of the community.

    Telechat:

  3. Suite B in Secure/Multipurpose Internet Mail Extensions (S/MIME) (Informational)
    draft-housley-rfc5008bis-00
    Token: Sean Turner
    Note: Russ Housley (housley@vigilsec.com) is the document shepherd.
    IPR: Certicom's Statement of IPR Related to draft-housley-rfc5008bis-00
    Discusses/comments (from ballot 3743):
    1. Jari Arkko: Discuss [2011-04-13]:
      This is a fine document otherwise, but I did get a headache from trying to understand what *this* document specifies about behaviour and whether it is exactly the same or different from what existing RFCs have already specified.
      For instance, in Section 3 there is a statement about parameters field not being allowed with SHA256 and SHA384: "When either the ecdsa-with-SHA256 or the ecdsa-with-SHA384 algorithm identifier is used, the AlgorithmIdentifier parameters field MUST be absent."
      However, I'm unable to correlate this with RFC 5480 which just has an ASN.1 comment:
      -- ECDSA with SHA-384
      -- Parameters are ABSENT
      In Section 2 the wording of some of the MUST statements is different than in RFC 5754. I think the semantics are the same. But I did have to stare it for a while to verify, and I'm still not sure.
      There are more examples, e.g., Section 4.3.
      My general point is that we should really avoid repeating normative language from other RFCs, unless we truly intend to make a change and have the new document be the permanent source of that normative language. In general, a suite definition document should not need to define any new behaviour or formats, at most it should just define some new IANA numbers. Why are we doing it here with this document?
    2. Stewart Bryant: Comment [2011-04-11]:
      This document has an IPR disclosure against it, but I did not see that called out in the IETF Last Call notice.
    3. Adrian Farrel: Comment [2011-04-07]:
      I have no objection to the publication of this document.
      I note that idnits says:
      -- The draft header indicates that this document obsoletes RFC5008, but the abstract doesn't seem to mention this, which it should.
    4. Stephen Farrell: Comment [2011-04-13]:
      (1) The document does say "united states" in a few places, but maybe that'd be better included in the title as well.
      (2) The KE in "KE sets" doesn't seem to be expanded anywhere.

    Telechat:

3.2.2 Returning Items

  1. (none)

3.3 IRTF and Independent Submission Stream Documents

3.3.1 New Items

  1. Hierarchical IPv4 Framework (Experimental)
    draft-frejborg-hipv4-13
    Token: Ralph Droms
    Note: IRSG submission. Tony Li (tony.li@tony.li) is the document shepherd.
    Discusses/comments (from ballot 3755):
    1. Jari Arkko: Discuss [2011-04-14]:
      I support the publication of this document as an IRTF RFC. However, it has been our policy before that all submissions around the topic of routing and addressing scalability need to clearly document their downsides, even if they come from the independent or other streams. This is to set a level playing field for all submissions.
      In the case of this document, I wonder if Section 10 should better highlight a couple of additional issues:
      1. That this model require a modification of a large number of end hosts
      2. That as far as I can tell, the document does not describe an incremental deployment model that would explain what happens when one part of the Internet supports the new model but others do not
      There may also be other issues, e.g., I'm not an expert in geographical addressing but my understanding was that it has issues. Maybe those should be highlighted.
      Finally, I think the "carry IP addresses" issue from Section 10.3 is actually a more general referral problem. What about applications that store the client's IP address to contact/compare it later? Its not just an issue of protocols carrying addresses.
    2. Wesley Eddy: Comment [2011-04-12]:
      The Security Considerations section appears to be a bit light, and I would suggest improving this section.
      I have no objections to publishing this, but here are some editorial nits:
      page 5, 3rd to last paragraph: should "three areas: area" be "three types of areas: stub area"?
      should note during first occurrence of "LSR" that this does *not* refer to an MPLS Label Switching Router, since this is overloading an already well-known acronym
      page 10 - "in Internet" -> "in the Internet"
      page 11 - how can the ALOC prefix (which is a prefix, not an address) be assigned as the locator for the LSRs or announced as an anycast *address* as it says on this page? The wording choices might be clarified here.
      page 12 - "since the destination address is the remote ALOC prefix" this text seems to have the same address/prefix confusion as above; should this really say "is within the remote ALOC prefix?" If the bare prefix itself is used as an address, doesn't this severely limit the number of ALOCs available?
    3. Adrian Farrel: Comment [2011-04-14]:
      I have no objection to the publication of this document as Experimental.
      I note that RFC 3032 is given as the eference for [MPLS]. I think that RFC 3031 is a more central anchor for the MPLS architecture.
    4. Stephen Farrell: Comment [2011-04-14]:
      I thought the IRTF process called for something about document status to be in the abstract as well?
    5. Pete Resnick: Comment [2011-04-13]:
      As an IRTF submission, I'm only evaluating on the basis of conflict with IETF stuff. To that end, though it could be argued that using "hIPv4" as an abbreviation of the protocol name "could potentially disrupt the IETF work done in" HIP, I don't feel strongly enough to say that we should file an objection with the RFC Editor just because of that.
      This work is certainly related to work going on in LISP, but I don't think it's conflicting.
    6. Dan Romascanu: Discuss [2011-04-14]:
      This is a DISCUSS-DISCUSS, and I plan to change it into a No-Objection or an Abstain after the telechat. I would like to make sure that we are all OK to approve this document as Experimental and that no IESG note is required. My question marks relate to the nature of the experiment and the transition plans that are discussed in the document in the conditions that IPv4 address depletion is a reality today. Another issue is that some of the text in Appendix C makes the case that a transition to hipv4 is to be preferred to the current IPv4 to IPv6 transition plans - are we OK with the 'green' and economical arguments brought up here?

    Telechat:

3.3.2 Returning Items

  1. (none)

3.3.3 For Action

  1. Bidirectional Forwarding Detection (BFD) with Graceful Restart (Historic)
    draft-palanivelan-bfd-v2-gr-10
    Token: Adrian Farrel
    Note: ISE submission.

    Telechat:

1247 EDT break

1252 EDT back

4 Working Group Actions

4.1 WG Creation

4.1.1 Proposed for IETF Review

  1. Real Time Communication on the World Wide Web (rtcweb)
    Token: Gonzalo

    Telechat:

  2. Protocol to Access WS database (paws)
    Token: Dan

    Telechat:

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. Softwires (softwire)
    Token: Ralph

    Telechat:

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

    Telechat:

5. IAB News We can use

6. Management Issues

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

    Telechat:

  2. Minute Job Assignments (Russ Housley)

    Telechat:

  3. Executive Session for ISOC Board of Trustee Candidate Confirmation (Russ Housley)

    Telechat:

  4. LIAISON STATEMENT FROM ETSI TC ENVIRONMENTAL ENGINEERING (Dan Romascanu)

    Telechat:

  5. ARIN allocation of a /10 for NAT 444 (Ron Bonica)

    Telechat:

7. Agenda Working Group News

1351 EDT Entered Executive Session


Valid HTML 4.01 Strict


Appendix: Snapshot of discusses/comments

(at 2011-04-14 07:30:10 PDT)

draft-ietf-rmt-bb-fec-raptorq

  1. Stewart Bryant: Discuss [2011-04-13]:
        I could not see an IPR disclosure in the Last Call text.
    
    I am by no means an IPR expert, but the IPR claim seems to imply different terms
    depending on whether packets containing this protocol are sent over different
    types of network. That seems contra to the IETF position of wanting to be able
    to send our protocols over any link type. It therefore seems particularly
    important that the community's attention be draft to the IPR statement when
    deciding whether to proceed with the Standard.
    
    Presumably if there is a single a digit error in any one of the number of very
    large tables of numbers there will be at the very least an interoperability
    issue with existing implementations, or even a broken protocol. Is it possible
    to make the generator polynomials for these tables normative, and the tables
    themselves informative? This would substantially reduce the scope for a process
    error somewhere between the original compilation of these tables and the final
    publication of the RFC. 
        
  2. Stephen Farrell: Discuss [2011-04-13]:
        (1) Its not clear to me that an implementer of this would understand whether or
    not they'd be covered by the IPR declaration which only seems to call out
    specific uses. One solution might be to add an applicability statement to the
    draft that matches the conditions under which the IPR situation is well-defined.
    
    (2) Is there a reason to prefer sha-1 in the security considerations section?
    sha-256 may be better as an algorithm that will have a longer shelf-life. If you
    want to stick with sha-1 then you should make it clear what properties of the
    hash algorithm are required (collision resistance, pre-image resistance...) 
        
  3. Peter Saint-Andre: Discuss [2011-04-12]:
        Given that various fields are longer than 8 bits (e.g., the Encoding Symbol ID
    (ESI), Transfer Length (F), and Symbol Size (T) elements), please specify the
    network byte order (probably it is network byte order, but it needs to be
    specified). 
        

draft-ietf-ipfix-structured-data

  1. Stewart Bryant: Comment [2011-04-12]:
    A well written document.
    
    The following are minor nits that I noticed during my review
    
    In Section 2
    "However, the amount of information has become so important..." 
    I think you mean "....so large...."
    
    ====
    2.4. The Proposal
    
    This is a standards track doc - therefore this is no longer a proposal.
    =====
  2. Adrian Farrel: Discuss [2011-04-14]:
        This is a fine document, and I have no objection to it.
    
    However, in reading it I discovered a question about the three-octet
    length encoding. This shows in this documet through text such as:
    
          If the subTemplateMultiList is encoded as a Variable-Length 
          Information Element in 255 or more octets, it is encoded with the 
          Length field per Section 7 of [RFC5101] as follows: 
    
          0                   1                   2                   3 
           0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
          |      255      |      Length (0 to 65535)      |   Semantic    | 
          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    
    On examination of RFC 5101 I find this to be ambiguous. In particular,
    it is not clear what would be meant by the length encoding ff,0,0. Is 
    that invalid, or does it mean a length of zero? I suspect it means a 
    length of zero, and that 255 means "use extended length encoding", and
    does not mean "length is >= 255".
    
    I am querying this with the editor of RFC 5101 and if we can agree a
    clarification, I will raise an Erratum and request that the text in 
    this document is clarified. 
        
  3. Stephen Farrell: Comment [2011-04-13]:
    With the additional rfc editor note added to the security considerations this is
    fine.
  4. Russ Housley: Comment [2011-04-13]:
      The Gen-ART Review by Suresh Krishnan on 12-Apr-2011 shows two places
      where the document is not clear.  Please address these two places.
    
      Section 2 says:
    
        However, the amount of information
        has become so important that, when dealing with highly granular
        information such as Flow information, a push mechanism (as opposed
        to a pull mechanism, such as SNMP) is the only solution for
        routers whose primary function is to route packets.
    
      Did you mean that "the amount of information is so large" or did you
      mean that "collecting this information has become so important" or
      did you mean something else?
    
      Section 2 also says:
    
        Furthermore, in order to reduce the export bandwidth requirements,
        the network elements have to integrate mediation functions to
        aggregate the collected information, both in space and time.
      
      What does aggregation based on space mean?
  5. Peter Saint-Andre: Discuss [2011-04-12]:
        Appendix A appears to redefine or extend the XML (and XML schema) first provided
    in RFC 5102. At a minimum, this document therefore should say that it "Updates
    RFC 5102" (in the first-page header and in the Abstract). Furthermore, it's
    messy to just place some additional XML elements and XML schema definitions in
    Appendix A -- it would be cleaner to provide the complete (updated) XML and XML
    schema to make processing and testing easier. Finally, it is unclear what things
    like elementId="XXX" are supposed to mean -- are the three characters
    placeholders for values to be assigned by the IANA, or are they literal strings? 
        

draft-ietf-avtcore-ports-for-ucast-mcast-rtp

  1. Jari Arkko: Comment [2011-04-14]:
    One comment from Ari Keränen who helped me with some of the reviews:
    
    Section 7.2. says "The use of SDP for the port mapping solution normatively
    requires the support for [...] Multiplexing RTP and RTCP on a single port on
    both endpoints in the unicast session [RFC5761]".
    
    Isn't this a requirement for the whole mechanism (if RTP and RTCP are used on
    the same ports as defined in section 3), not just with SDP? Perhaps the RFC5761
    requirements should already be mentioned in section 3?
  2. Stephen Farrell: Discuss [2011-04-13]:
        
    Overall I like this document and what its trying to do.
    
    The max token size is 1024 bits - right? If so, that would not be enough to
    allow use of many public key encryption schemes and would also prevent inclusion
    of more complex data within a token (e.g. additional client or session
    attributes). I can understand that you might not want that now but it seems a
    bit arbitrary to limit token size like that. Did (or would) the WG consider a
    two byte length field? 
        
  3. Stephen Farrell: Comment [2011-04-13]:
    (1)  s/If there is no NAT devices/If there are no NAT devices/
    
    (2) p20 says:  key-id || hash-alg (client-ip | nonce | abs-expiration) but since
    you're recommending HMAC-SHA1 that should be mac-alg rather than hash-alg.
    
    (3) Since the client controls all the inputs to the recommended HMAC
    calculation, except the expiration time, which may be guessable, it really had
    better not be the case that that same secret key is used for something else that
    could get fooled if presented with a token. This is perhaps an unlikely cross-
    protocol attack (though with manual key management, perhaps not that unlikely)
    but I'd suggest a sentence in the security considerations saying servers MUST
    NOT use the same secret from the recommended scheme for other purposes.
    
    
  4. Pete Resnick: Comment [2011-04-14]:
    I don't object to this document being published, but I must say for someone
    outside of the area, this is rather dense and difficult to comprehend. In
    particular, getting through section 3 is nearly impossible without a lot of
    forward-reference looking. It took me reading through all of sections 4 and 5 to
    finally figure out (a) that the Token is simply a server-generated hash of the
    client's IP address, a time-to-live, and some random data generated by the
    client (section 3 says that "The Token is essentially an opaque encapsulation",
    and I have no idea what that is supposed to mean); and (b) that the client is
    told of the Token's expiration when it requests the Token. I would really like
    that first part of section 3 to lay out the basic principles in easier to
    understand language.
  5. Peter Saint-Andre: Comment [2011-04-12]:
    Please expand "SSM" on first use, and consider adding an informational reference
    to RFC 4607.
  6. Sean Turner: Discuss [2011-04-12]:
        #1) Section 5 contains the following text:
    
       An example way for constructing Tokens is to perform HMAC-SHA1
       [RFC2104] on the concatenated values of the information listed above.
       The HMAC key needs to be at least 160 bits long, and generated using
       a cryptographically secure random source [RFC4086].  While HMAC-SHA1
       is the RECOMMENDED procedure, implementations might adopt different
       approaches.
    
    The paragraph starts off saying HMAC-SHA1 is an example.  It then later says
    it's the recommended way.  It would be much clearer if the paragraph said
    initially that HMAC-SHA1 is the recommended approach. And, then maybe spin
    "needs to be" as "MUST be": if HMAC-SHA1 is used then the HMAC key MUST be 160
    bits long, and generated using ... 
        

draft-ietf-sidr-rpki-algs

  1. Sean Turner: Comment [2011-04-13]:
    
      

draft-ietf-sidr-ta

  1. Gonzalo Camarillo: Comment [2011-04-13]:
    Introductions do not typically contain normative language.
  2. Ralph Droms: Comment [2011-04-12]:
    In section 3, s/as deem appropriate/as deemed appropriate/
  3. Wesley Eddy: Comment [2011-04-12]:
    I think in section 2.1 "A TA in the RPKI TA" is supposed to be just "A TA in the
    RPKI".
  4. Adrian Farrel: Comment [2011-04-14]:
    I have no objection to the publication of this document.
    
    Two piddly nits that are worth addressing only if you have the
    document open for other reasons...
    
    ---
    
    X.509 on the second line of section 2.1 could use a reference.
    
    ---
    
    The definition of a TAL that appears in the first paragraph of 2.1 is
    great and could be greater if it appeared in Section 1. Actually, I am
    not sure that the first 2 to 2.5 paragraphs of section 2.1 don't belong
    in section 1. 
  5. Russ Housley: Comment [2011-04-11]:
      Please consider the editorial comments from the Gen-ART Review by
      Wassim Haddad on 16-Mar-2011.

draft-ietf-sidr-signed-object

  1. Adrian Farrel: Comment [2011-04-14]:
    I have no objection to the publication of this document.
    
    ---
    
    Section 3 nit. 
    
       If the all of the conditions above are
       true, then the signed object may be valid.
    
    s/the all/all/
  2. Stephen Farrell: Discuss [2011-04-13]:
        
    Overall this is a fine document but it seems odd that the signed object types
    that will use this require a standards track RFC, but yet there are no IANA
    considerations? I'd have thought that having an IANA registry for those would be
    useful for implementers. Put another way: should section 4 be turned into an
    IANA considerations section? 
        

draft-ietf-dccp-tfrc-rtt-option

  1. Gonzalo Camarillo: Discuss [2011-04-13]:
        This document updates RFC 5622. However, the reference to RFC 5622 was made
    Informative because RFC 5622 is Experimental. I believe the reference should be
    a Normative one because the document is actually updating RFC 5622. However, if
    the reference is made normative , it would be count as a downref. Let's discuss
    this issue in the telechat. 
        
  2. Gonzalo Camarillo: Comment [2011-04-13]:
    This document, which is in the Standards Track, updates RFC 5622, which is an
    experimental RFC. The authors may want to point out the fact that RFC 5622 is
    Experimental somewhere in the document.
  3. Wesley Eddy: Comment [2011-03-31]:
    The document looks technically solid to me, and to the TSVDIR reviewer (Mark
    Allman).  The authors can consider whether any minor editorial changes could
    help with some of Mark's editorial comments, at their perogative.
  4. Lars Eggert: Comment [2011-03-26]:
    Authors, please see if you want to incorporate the suggestion from Brian
    Carpenter's gen-art review in a revision.
  5. Adrian Farrel: Discuss [2011-04-06]:
        A fine document. I have no issue with its publication, but there is a small
    finge case, that seems to be a little hole.
    
    3.2.1
    
       A value of 0 indicates the absence of a valid RTT sample.  The sender
       MUST set the value to 0 if it does not yet have an RTT estimate.    
    
    How do you indicate a RTT estimate of less than 1 microsecond?
    You should at lea st say that this document assumes that RTTs of less
    than 1 microsecond will not be observed in the type of network in 
    which this option is run. An alternative would be to say that RTT
    estimates of less than 1 microsecond MUST be reported as 1 microsecond.
    You might cover this second case, by saying that estimates MUST be
    rounded up to the nearest microsecond.
     
        

draft-yevstifeyev-tn3270-uri

  1. Jari Arkko: Comment [2011-04-13]:
    I support Ron's discuss.
  2. Ron Bonica: Discuss [2011-04-12]:
        This is probably a DISCUSS-DISCUSS. Considering:
         - the security vulnerabilities associated with TN3270
         - that most applications supporting TN3270 also support HTTP
    
    should we consider capping TN3270 and one day converting all of the 3270 drafts
    to historic. Recall that 3270 terminal production was discontinued many years
    ago. 
        
  3. Peter Saint-Andre: Comment [2011-04-12]:
    Robert Sparks and I had a conversation via IM about the lack of good security in
    the telnet protocol. As a result I have provisionally added the following RFC
    Editor Note to the tracker:
    
    ###
    
       Please add the following paragraph at the end of the
       Security Considerations:
    
          The telnet protocol is inherently insecure.  Those needing
          remote login access and related services are encouraged
          to use a more secure technology, such as Secure Shell
          [RFC4251].
    
    ###
    

draft-ietf-mboned-addrarch

  1. Adrian Farrel: Comment [2011-04-14]:
    Section 6 says...
    
       This memo includes no request to IANA.
    
       IANA considerations in sections 4.1.1 and 4.1.2 of obsoleted and now
       Historic [RFC2908] were never implemented in IANA registry.  No
       update is necessary.
    
       (RFC-editor: This section may be removed prior to publication;
       alternatively, the second paragraph may be left intact.)
    
    Please do keep the second paragraph at least for Historians, but also for
    clarity.
  2. Russ Housley: Comment [2011-04-12]:
      Please consider the improvements suggested in the Gen-ART Review by
      Mary Barnes 7-Apr-2011.  The review can be found at:
    
        http://www.ietf.org/mail-archive/web/gen-art/current/msg06214.html
    
  3. Robert Sparks: Comment [2011-04-12]:
    The abstract doesn't capture the last sentence of the introduction:   
    "This
    memo obsoletes and re-classifies to Historic RFC 2908, and re-classifies to
    Historic RFCs 2776 and 2909."

draft-ietf-genarea-datatracker-community

  1. Adrian Farrel: Comment [2011-04-14]:
    I have no objection to the publication of this document.
    
    There were three requirement-oriented thoughts I had on this most recent
    reading...
    
    ---
    
    As a requirement for an implementor, I found 2.1.1. "Requirement: 
    Lists of I-Ds and RFCs can be large" to be too vague. Is it saying 
    that a hard coded limit is OK provided it supports "hundreds of I-Ds
    and dozens of RFCs"?
    
    Would it not be better to specifically reuqire "no implementation
    limit" to list size?
    
    ---
    
    I don't find 2.1.2 sufficiently clear. It says "Every Datatracker
    user can create a list." It does not say whether the limit is one
    list per user. I have no feeling either way, but I feel the document
    should be clear as it will significantly impact implementation.
    
    ---
    
    Did I miss notification of changes to a list (not of changes to I-Ds 
    in a list)? I can consider:
    - I-D / RFC added to list
    - I-D / RFC removed from list
    - list deleted
    
  2. Dan Romascanu: Comment [2011-04-12]:
    1. Section 1.1: 
    
          This would include not
          only I-Ds that are in the many WGs that directly are changing the
          DNS (DNSEXT, DNSOP, BEHAVE, and so on), but also individual
          submissions, IAB I-Ds, and even IRTF research.
    
    s/IRTF research/IRTF I-Ds/
    
    2. Section 1.2
    
          the ability to get notifications when individual I-Ds from a list
          changes state
    
    s/changes/change/
    
    3. Section 1.3 
    
    What is the difference between "Approved" and "Sent to the RFC Editor"?
    
    4. Section 2.3.2
    
    o  Associated WG or RG
    
    I think this needs to be
    
    o  Associated WG or RG or IAB or IES
  3. Sean Turner: Comment [2011-04-12]:
    Sec 1: r/sixTestVM/six
    
    Sec 2.3.1: I think "be" is missing from the following: 
    
      In displays, a particular I-D or RFC should only *be* included once
    
    Sec 2.3.3: r/changes/changed in:
    
      has not changes state
    
    

draft-ietf-genarea-charter-tool

  1. Jari Arkko: Discuss [2011-04-14]:
        This is a very welcome addition. Thanks for writing the spec. A couple of small
    issues, however:
    
    1. I think Section 2.1 should also include working group state (exists, closed).
    This information already exists in the database, and we do want to be able to
    track the state and charter changes of closed working groups, as well.
    
    2. Particularly for rechartering WGs, the WG record should also contain an
    "explanation" field that is often far more interesting than the technical diff
    of the charter changes. Such explanations are routinely provided to the IESG/IAB
    and to the community as a recharter proposal is made. ("The WG has completed its
    FOO work item, and will no longer pursue BAR given that no implementations
    exist. However, a work item on SNAAP has been added to address requirements from
    the FRYYP community.")
    
    3. Shouldn't the doc say something about the messages that go out; I'd love to
    see a recharter message with (a) the explanation, (b) the diff, and (c) the
    proposed new charter. 
        
  2. Adrian Farrel: Comment [2011-04-14]:
    I support Dan's Discuss about Milestone changes.
    The ability to change
    milestones should be supported by the tool, and the history of those changes
    should be maintained.
  3. Dan Romascanu: Discuss [2011-04-12]:
        Are adding of milestones or milestone updates considered changes that should be
    recorded by the charter tool? The document is mute about these, but they happen
    often in-between initial chartering and re-chartering. 
        
  4. Dan Romascanu: Comment [2011-04-12]:
    1. Introduction 
    
       Since its publication in
       1998, the IETF has started many dozen new WGs, has shut down many
       dozen, and every WG that has had some (often dozens) changes to its
       charter.
    
    The last part of this phrase seems broken. In any case saying that WGs had often
    (typically) dozens of changes to their charters since 1998 seems to me as an
    exageration.
    
    2. Section 2.1
    
    o  previous web sites (such as wikis or project sites, if any)
    
    I think this should be 
    
    o  other web sites (such as wikis, trackers or project sites, if any) including
    web sites previous to the WG formation
    
    The rational is that some WGs may continue to use wikis or issues trackers after
    chartering
  5. Sean Turner: Comment [2011-04-12]:
    Section 3.1: I seem to remember that dashes also cause problems for some tools.
    It might be worth adding this to the note.
    
    Sec 3.1: Has the following:
    
          When moved to this state, a note is sent to the
          Secretariat to send out the external review announcement to the
          appropriate lists.
    
    Are we envisioning a radio dial for "send email to new-work" ad "do not send
    email to new-work"?  Not sure if we want this automated or not.
    
    Sec 3.2: Do we want to allow the existing WG chairs to submit revised Charters
    and  call it "Recharter Requested"?

draft-ietf-ledbat-survey

  1. Lars Eggert: Comment [2011-03-26]:
    Authors, please see if you want to incorporate the comments from Elwyn Davies'
    gen-art review into a revision.
  2. Adrian Farrel: Discuss [2011-04-14]:
        I think this is a fine document, but I am a little surprised that 
    Section 9 is empty and that the security aspects of the protocols 
    surveyed are not also discussed. I am holding this Discuss so that
    I can verify that the Security ADs are comfortable with this point
    during our conference call. I will then clear my Discuss, and let 
    them carry a Discuss if they think it is necessary.
    
    No action is required by the authors at this time. 
        
  3. Stephen Farrell: Comment [2011-04-13]:
    Section 6 doesn't seem to really state any conclusion at all. Perhaps change
    the name of the section?
  4. Russ Housley: Discuss [2011-04-12]:
        
      The Gen-ART Review by Elwyn Davies on 17-Mar-2011 raises a question
      that deserves a response.  The review can be found at:
      
      http://www.ietf.org/mail-archive/web/gen-art/current/msg06196.html 
        

draft-cardona-cablelabs-urn

  1. Stephen Farrell: Discuss [2011-04-13]:
        
    Discuss discuss:
    Why does the iesg writeup say the URN-NID list has not *yet*
    reviewed this? Shouldn't they
    go first? 
        

draft-kanno-tls-camellia

  1. Stewart Bryant: Comment [2011-04-11]:
    This document has an IPR disclosure against it, but I do not see this noted in
    the IETF Last Call notice.
  2. Ralph Droms: Comment [2011-04-14]:
    The IPR disclosure for this document includes:
    
       The seller shall provide the buyer with the following written notice:
    
          The use of this product or service is subject to the reasonable,
          non-discriminatory terms in the Intellectual Property Rights
          (IPR) Disclosure of Certicom Corp. at the IETF for Addition of
          Camellia Cipher Suites to Transport Layer Security (TLS)
          implemented in the product or service.
    
    I don't recall seeing such a provision in other IPR disclosures.  If it
    is unusual, in my opinion it should be mentioned explicitly in any
    new IETF last call.
    
  3. Adrian Farrel: Comment [2011-04-07]:
    I am entering a "no objection" ballot on the basis of a very light review of a
    document far outside my area of expertise. I am relying on the shepherding
    Security AD to have ensured that this document is sound.
  4. Stephen Farrell: Comment [2011-04-13]:
    I don't find the idea of adding yet another 42 TLS ciphersuites to be useful and
    to the extent that it complicates life for developers and consumes their time
    (mostly) needlessly, it's a bad thing. However, I don't think it would be fair
    to try to hold this at this stage in the game, given that the authors had
    agreement from previous IESG members.
    
    Please also see the secdir review at: http://www.ietf.org/mail-
    archive/web/secdir/current/msg02584.html that indicates some clarifications may
    be useful.
  5. Pete Resnick: Comment [2011-04-13]:
    The IANA Considerations section should be marked as "Please remove this section
    after filling in the values in section 2." Having the values appear in the
    document twice is a sure-fire way to introduce an error.
  6. Dan Romascanu: Discuss [2011-04-12]:
        I think that the issue raised by Stewart requires a DISCUSS. The IPR disclosure
    seems to have been submitted after the document was sent to IETF LC - so it was
    not brought up to the attention of the community. 
        

draft-housley-rfc5008bis

  1. Jari Arkko: Discuss [2011-04-13]:
        This is a fine document otherwise, but I did get a headache from trying to
    understand what *this* document specifies about behaviour and whether it is
    exactly the same or different from what existing RFCs have already specified.
    
    For instance, in Section 3 there is a statement about parameters field not being
    allowed with SHA256 and SHA384:
    
       When either the ecdsa-with-SHA256 or the ecdsa-with-SHA384 algorithm
       identifier is used, the AlgorithmIdentifier parameters field MUST be
       absent.
    
    However, I'm unable to correlate this with RFC 5480 which just has an ASN.1
    comment:
    
       -- ECDSA with SHA-384
       -- Parameters are ABSENT
    
    In Section 2 the wording of some of the MUST statements is different than in RFC
    5754. I think the semantics are the same. But I did have to stare it for a while
    to verify, and I'm still not sure.
    
    There are more examples, e.g., Section 4.3.
    
    My general point is that we should really avoid repeating normative language
    from other RFCs, unless we truly intend to make a change and have the new
    document be the permanent source of that normative language. In general, a suite
    definition document should not need to define any new behaviour or formats, at
    most it should just define some new IANA numbers. Why are we doing it here with
    this document? 
        
  2. Stewart Bryant: Comment [2011-04-11]:
    This document has an IPR disclosure against it, but I did not see that called
    out in the IETF Last Call notice.
  3. Adrian Farrel: Comment [2011-04-07]:
    I have no objection to the publication of this document.
    
    I note that idnits says:
      -- The draft header indicates that this document obsoletes RFC5008, but the
         abstract doesn't seem to mention this, which it should.
  4. Stephen Farrell: Comment [2011-04-13]:
    (1) The document does say "united states" in a few places, but maybe that'd be
    better included in the title as well.
    
    (2) The KE in "KE sets" doesn't seem to be expanded anywhere.
    

draft-frejborg-hipv4

  1. Jari Arkko: Discuss [2011-04-14]:
        I support the publication of this document as an IRTF RFC.
    
    However, it has been our policy before that all submissions around the topic of
    routing and addressing scalability need to clearly document their downsides,
    even if they come from the independent or other streams. This is to set a level
    playing field for all submissions.
    
    In the case of this document, I wonder if Section 10 should better highlight a
    couple of additional issues:
    
    1. That this model require a modification of a large number of end hosts
    2. That
    as far as I can tell, the document does not describe an incremental deployment
    model that would explain what happens when one part of the Internet supports the
    new model but others do not
    
    There may also be other issues, e.g., I'm not an expert in geographical
    addressing but my understanding was that it has issues. Maybe those should be
    highlighted.
    
    Finally, I think the "carry IP addresses" issue from Section 10.3 is actually a
    more general referral problem. What about applications that store the client's
    IP address to contact/compare it later? Its not just an issue of protocols
    carrying addresses. 
        
  2. Wesley Eddy: Comment [2011-04-12]:
    The Security Considerations section appears to be a bit light, and I would
    suggest improving this section.
    
    I have no objections to publishing this, but here are some editorial nits:
    
    page 5, 3rd to last paragraph: should "three areas: area" be "three types of
    areas: stub area"?
    
    should note during first occurrence of "LSR" that this does *not* refer to an
    MPLS Label Switching Router, since this is overloading an already well-known
    acronym
    
    page 10 - "in Internet" -> "in the Internet"
    
    page 11 - how can the ALOC prefix (which is a prefix, not an address) be
    assigned as the locator for the LSRs or announced as an anycast *address* as it
    says on this page?  The wording choices might be clarified here.
    
    page 12 - "since the destination address is the remote ALOC prefix" this text
    seems to have the same address/prefix confusion as above; should this really say
    "is within the remote ALOC prefix?"  If the bare prefix itself is used as an
    address, doesn't this severely limit the number of ALOCs available?
  3. Adrian Farrel: Comment [2011-04-14]:
    I have no objection to the publication of this document as Experimental.
    
    I note that RFC 3032 is given as the eference for [MPLS]. I think that RFC 3031
    is a more central anchor for the MPLS architecture.
  4. Stephen Farrell: Comment [2011-04-14]:
    I thought the IRTF process called for something about document status to be in
    the abstract as well?
  5. Pete Resnick: Comment [2011-04-13]:
    As an IRTF submission, I'm only evaluating on the basis of conflict with IETF
    stuff. To that end, though it could be argued that using "hIPv4" as an
    abbreviation of the protocol name "could potentially disrupt the IETF work done
    in" HIP, I don't feel strongly enough to say that we should file an objection
    with the RFC Editor just because of that.
    
    This work is certainly related to work going on in LISP, but I don't think it's
    conflicting.
  6. Dan Romascanu: Discuss [2011-04-14]:
        This is a DISCUSS-DISCUSS, and I plan to change it into a No-Objection or an
    Abstain after the telechat. I would like to make sure that we are all OK to
    approve this document as Experimental and that no IESG note is required. My
    question marks relate to the nature of the experiment and the transition plans
    that are discussed in the document in the conditions that IPv4 address depletion
    is a reality today. Another issue is that some of the text in Appendix C makes
    the case that a transition to hipv4 is to be preferred to the current IPv4 to
    IPv6 transition plans - are we OK with the 'green' and economical arguments
    brought up here?