IESG Narrative Minutes

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

Narrative scribe: John Leslie and Susan Hares (The scribe was sometimes uncertain who was speaking.)

Corrections from: Robert, Dan

1 Administrivia

  1. Roll Call 1133 EST 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. Extensible Markup Language Evidence Record Syntax (Proposed Standard)
    draft-ietf-ltans-xmlers-11
    Token: Tim Polk
    Note: Carl Wallace is the document sheperd
    Discusses/comments (from ballot 3592):
    1. Lars Eggert: Comment [2011-01-17]:
      I agree with Sean's discuss on RFC2119 usage.
    2. Alexey Melnikov: Discuss [2011-01-30]:
      3.1.2. Time-Stamp: "Since at the time being there is no standard for an XML Time-Stamp, the following structure example is provided (referring to the Entrust XML Schema for Time-Stamp http://www.entrust.com/schemas/timestamp19protocol-20020207), which is a digital signature compliant to [XMLDSig] specification containing Time-Stamp specific data, such as time-stamped value and time within <Object> element of a signature."
      Is this enough for interoperability? The text almost looks informative in places.
      <element name="TimeStampInfo">
      ...
    3. Alexey Melnikov: Comment [2011-01-30]:
      (blank)
    4. Peter Saint-Andre: Discuss [2011-01-24]:
      (Updated per version -11 of the spec.)
      5. Section 2.1 states: "<TimeStamp> tag holds a <TimeStampToken> element with a Time-Stamp Token provided by the Time-Stamping Authority and optional element <CryptographicInformationList>."
      This makes it sound as if the structure of the <TimeStamp/> element (not "tag"!) is a sequence formed of a required <TimeStampToken/> element and an optional <CryptographicInformationList/> element. However, the schema in Section 7 defines the <TimeStamp/> element as having a mixed content model. This is confusing. Furthermore, mixed content models can make parsing more complex. Is there a good reason why this document defines a mixed content model for the <TimeStamp/> element?
      As a further clarification, in Section 3.1.2 there can be found the following examples...
      <TimeStamp Type="RFC3161">MIAGCSqGSIb3DQEH...</TimeStamp>
      or
      <TimeStamp Type="XMLENTRUST"><dsig:Signature>...</dsig:Signature> </TimeStamp>.
      To prevent the mixed content model, why not do something like the following?
      (snip)
      6. Section 2.1 states: "<Attributes> tag contains additional information that may be provided by an LTA used to support processing of Evidence Records. An example of this supporting information may be a processing policy, like a renewal, a cryptographic (e.g. [RFC5698]) or an archiving policy. Such policies can provide inputs, which are relevant for data object(s) preservation and evidence validation at a later stage. Each data object is put into a separate child element <Attribute>, with a mandatory Order attribute to indicate the order within the parent element and an optional Type attribute to indicate processing directions."
      This makes it sound as if the structure of the <Attributes/> element (not "tag"!) is a sequence formed of one or more required <Attribute/> elements. However, the schema in Section 7 defines the <Attributes/> element as having a mixed content model. This is confusing. Furthermore, mixed content models can make parsing more complex. Is there a good reason why this document defines a mixed content model for the <Attributes/> element?
      7. Section 2.1 does not define the syntax and semantics for the 'Type' attribute of the <Attribute/> element or the <SupportingInformationList/> element. The text says only that this attribute is used "to indicate processing directions". What does that mean? What values are allowed? How is the application supposed to determine the processing directions based on the value of the 'Type' attribute? The lack of specification here will likely cause interoperability problems.
      9. In Section 3.1.2, the "ts:" prefix is undefined. Is it hardcoded to "ts:" or is that just an example? Is the "ts:" prefix associated with the (unspecified) namespace from <http://www.entrust.com/schemas/timestamp19protocol-20020207>? Are you aware that the referenced URL currently yields an HTTP 404 error at www.entrust.com? Can you please provide a stable reference to the "Entrust XML Schema for Time-Stamp"? The lack of a clear definition or a stable reference is problematic. Finally, if the text beginning with <element name="TimeStampInfo"> is intended to be a schema snippet that defines the <TimeStampInfo/> element, then this should be included in the schema within Section 7 or in a separate schema, and we should make sure that this contribution was made in conformance with the IETF's "Note Well" policy.
      11. In Section 7, I suggest that you redefine the schema so that it no longer uses mixed content models.
    5. Peter Saint-Andre: Comment [2011-01-24]:
      1. In Section 1.3, some of these terms are repeated from RFC 3275 and RFC 4051. Sometimes the definitions are the same (e.g., "Archive data object") and sometimes they are slightly different (e.g., "Evidence"). Why does this document not simply reference RFC 3275 and RFC 4051 for the repeated terms?
    6. Sean Turner: Comment [2011-01-24]:
      #5) Sec 2.1: Should probably also indicate how many of the fields can be included (i.e, match the +, ?, * in the schema to the text).
      #6) I didn't see the changes for this one:
      Sec 3.1.1: I put that hex string in to a couple of Base64 encoders and got:
      QTk5OTNFMzYgNDcwNjgxNkEgQkEzRTI1NzEgNzg1MEMyNkMgOUNEMEQ4OUQ==

    Telechat:

  2. Guidelines for Considering New Performance Metric Development (BCP)
    draft-ietf-pmol-metrics-framework-08
    Token: Dan Romascanu
    Note: Al Morton (acmorton@att.com) is the document shepherd.
    Discusses/comments (from ballot 3661):
    1. Jari Arkko: Comment [2011-02-02]:
      It is a very good idea to publish an RFC for defining the task of a directorate. However, I do want to make a few suggestions:
      1. The name "Entity" is a bit odd. The established IETF terminology is "directorate"
      2. I would not make the directorate a formal requirement or mandatory part of the process. I think it is better cast as a review organization that can help the working group, the IETF, and the IESG in making the right decisions.
    2. Ron Bonica: Discuss [2011-02-02]:
      Point 1: This document appears to have two purposes:
      "The purpose of this document is to define a framework and a process for developing Performance Metrics for protocols above and below the IP-layer (such as IP-based applications that operate over reliable or datagram transport protocols), that can be used to characterize traffic on live networks and services. As such, this document does not define any Performance Metrics."
      -and-
      "This document refers to the implementation of a Performance Metrics Entity, whose goal is to advice and support the Performance Metric development at the IETF. A recommendation about the Performance Metrics Entity is made in Section 6.6."
      You don't need an RFC to form a directorate. Just do it.
      Point 2: Does this document need to be a BCP? Or, asked another way, do you need a club to prevent someone outside of BMWG/PMOL/IPPM from developing a benchmarking metric using some other method? (And who would those people be?)
    3. Gonzalo Camarillo: Discuss [2011-02-03]:
      Section 6 describes a policy to accept new metrics and establishes a directorate. As you know, RFC 5226 defines a set of policies to be applied when something needs to be registered with the IANA. However, in this case new metrics do not seem to be registered with the IANA. So, what is the process trying to prevent? Someone writing a new metrics proposal and referencing this document? (this relates to Ron's discuss). I think the information about what to look for when reviewing proposals for new metrics is useful. Couldn't the document just provide it as information for those who will be reviewing proposals submitted to the IETF and not as a process definition?
    4. Gonzalo Camarillo: Comment [2011-02-03]:
      The reference to RFC 2119 appears right after the Abstract. I would place it inside the Terminology section (Section 2 instead).
      Section 1.1 uses the present tense to describe events that happened in the past (e.g., "the IETF has two active WGs" or "there is a gap"). This also related to Adrian's comment on the same section. This section could be more explicit about what is describing, which seems to be the creation of the PMOL WG.
      When talking about SBCs in Section 5.5.4, you may want to reference RFC 5853
    5. Lars Eggert: Comment [2011-02-03]:
      Agree with everyone else that the process stuff needs to be changed.
      Intended status: BCP: Agree with Ron - this should not be a BCP.
      Section 2.1., paragraph 1: "The Performance Metrics Entity is a directorate that coordinates the Performance Metric development in the IETF."
      "Entity" is a weird name for a directorate. Why don't you just call it a directorate?
      (four Nits)
    6. Adrian Farrel: Discuss [2011-02-02]:
      I agree with Ron that if what is wanted is a Directorate, it should simply be created by the AD. Furthermore, I am worried that codifying the directorate in this document is implying changes to the IETF process that are not acceptable.
      I strongly support the guidelines part of this document (which feels Informational), but recommend that all reference to the directorate be removed.
    7. Adrian Farrel: Comment [2011-02-02]:
      Section 1.1: "Although the IETF has two active Working Groups (WGs) dedicated to the development of Performance Metrics, they each have strict limitations in their charters:"
      You seem to fail to list the PMOL WG. Is Section 1.1 simply trying to justify the creation of PMOL? If so it can be removed from the document because the WG seems to exist :-)
    8. Alexey Melnikov: Discuss [2011-02-03]:
      In general I think this document is adding some rather weak requirements on process (lots of "SHOULD"s).
      I also have the following question which is another way of formulating one of Robert's DISCUSS points:
      5.4.2. Normative parts of Performance Metric definition: "The normative part of a Performance Metric definition MUST define at least the following: (i) Metric Name: Performance Metric names MUST be unique within the set of metrics being defined and MAY be descriptive."
      Is there a formal syntax for performance metric names? How are these names to be used (e.g. are they going to be used by IANA to guaranty uniqueness)?
    9. Alexey Melnikov: Comment [2011-02-03]:
      6.4. Performance Metrics Entity Interaction with other WGs: "The Performance Metrics Entity SHALL work in partnership with the related protocol development WG when considering an Internet Draft that specifies Performance Metrics for a protocol. A sufficient number of individuals with expertise must be willing to consult on the draft. If the related WG has concluded, comments on the proposal should still be sought from key RFC authors and former chairs, or"
      I think "or" --> "and/or". I.e., there is not reason to choose the former over the latter if both are available.
    10. Tim Polk: Discuss [2011-02-02]:
      In my opinion, the sections that establish a new directorate and make it part of the official process require an "Updates 2026". In particular, section 6.3 integrates the directorate into the approval process for new work items. I would also note that this is a much stronger role than any other directorate has been given. Secdir, mib doctors, etc. have a review role but they are not asked to approve new work items.
      It would be more appropriate to excise all text about the directorate; forming the directorate and reviewing metrics related efforts does not require an RFC. I also suggest that the directorate make itself available for early review upon request, but strongly oppose any attempt to establish a gating function.
      If the authors do not wish to remove this text or modify these functions, I believe another Last Call is in order after adding "updates 2026" to the header, since I do not believe these changes have community consensus.
    11. Tim Polk: Comment [2011-02-02]:
      To be clear, I am not opposed to creating the directorate.
    12. Robert Sparks: Discuss [2011-02-02]:
      1) Section 6.3 is not adding any new process (it is recommending using the directorate framework we already have, asking an AD to set up and use a new team). It could stop with it's first sentence, and that sentence does not need to be restated in this document. I think you have the same document if you delete this section. If you agree, please delete it. If you don't agree, the document needs to be more explicit on what the section is trying to achieve.
      2) I'm not sure Section 5.4.2 (i) is clear about the domain over which it is requiring names to be unique. It could be read to mean "unique within a given document defining metrics". Did you intend it to mean "Unique within the set of standardized metrics for a given protocol"? What mechanisms are you advising be used to ensure this uniqueness? Should this document advise metric designers to help establish and manage registries per thing being measured, or are you anticipating something more lightweight?
      3) Why did you make a new metric for the example in 5.4.5 instead of exemplifying one that is already well specified? (Or have I missed the specification? It's related to discussion in 3550 and 3661, but I don't see this defined as a metric there). If it's new, could this section be misconstrued as actually defining the metric? I'd hate to see some future document trying to normatively refer an implementer to this section...
      5) Section 6.2 is the section of the document that is going to guide reviewers. It's not as clear as it needs to be. For instance, reviewers are being asked to assess a metric according the the qualification "use cases" and that is the only place the string appears in the document. What are you requiring with respect to use cases?
      6) Why didn't Section 6.6 recommend a particular Area?
    13. Robert Sparks: Comment [2011-02-02]:
      1) "defined in a similar way" is very vague.
      2) The language in 5.3.1 stating that measurements need to be non-overlapping and contiguous to be meaningfully composed caused me to pause. It's certainly easier to build meaningful compositions from measurements with those properties, but it's possible to build meaningful compositions when the properties, particularly contiguity, aren't met.
      3) Consider adding a discussion to section 5.4.2 (v) noting that the metric definition should discuss how the metric might vary depending which measurement point is chosen. The time between a SIP request and final response can be significantly different at the UAC and the UAS for example. Also consider noting that these kinds of differences should be taken into account when composing metrics.
      4) In 5.4.3 it would help readers to note that 3550 calls this interarrival jitter.
      5) It's not really clear what you want readers to do with the information in section 5.5. Please consider a short introduction to the section discussing whether these are observations that a metric designer needs to keep in mind, or if you are asking reviewers to ensure a specification says something about these things, or if you had a completely different audience in mind.
    14. Sean Turner: Comment [2011-02-03]:
      I support everybody else's discuss wrt to the process section.

    Telechat:

2.1.2 Returning Items

  1. SONET/SDH Circuit Emulation Service Over Packet (CEP) Management Information Base (MIB) Using SMIv2 (Proposed Standard)
    draft-ietf-pwe3-cep-mib-14
    Token: Stewart Bryant
    Note: Still waiting on text from authors
    Discusses/comments (from ballot 2726):
    1. Lars Eggert: Comment [2011-02-03]:
      Section 7., paragraph 54: "An agent with CEP capability MUST be capable of supporting at least n intervals. The minimum value of n is 4, the default of n is 32 and the maximum value of n is 96."
      I don't get this. How can you state a MUST requirement for a specific value, and then give a range for that value?
    2. Adrian Farrel: Comment [2011-02-02]:
      I'm entering a 'Yes' ballot because this work is technically sound and useful. However, I found a slew of nits that really should be worked on to make the RFC more valuable...
    3. Russ Housley: Comment [2011-02-01]:
      Please remove this paragraph prior to publication: "Comments should be made directly to the PWE3 mailing list at pwe3@ietf.org."
    4. Dan Romascanu: Comment [2011-01-23]:
      (blank)

    Telechat:

  2. Reducing the TIME-WAIT state using TCP timestamps (BCP)
    draft-ietf-tcpm-tcp-timestamps-03
    Token: Lars Eggert
    Note: Wesley Eddy (Wesley.M.Eddy@nasa.gov) is the document shepherd.
    Discusses/comments (from ballot 3647):
    1. Stewart Bryant: Comment [2010-12-13]:
      "2*MSL" Term not defined in the document.
    2. Ralph Droms: Comment [2010-12-15]:
      Stylistic suggestion: in the bullets in section 2, either include the parenthetical "(creating a connection in the SYN-RECEIVED state)" in every sub-bullet or only the first.
      Where ISN comparisons are performed in the rules in section 2, is the comparison strictly "less than", or is the (rather unlikely event of) wraparound considered?
    3. Adrian Farrel: Comment [2010-12-13]:
      "The Timestamps option, specified in RFC 1323 [RFC1323], allows a TCP to include a timestamp value in its segments, that can be used to"
      s/TCP/TCP implementation/?
    4. David Harrington: Comment [2010-12-14]:
      section 3: s/are important for TCPs that/are important for TCP connections that/
      s/break prevent/prevent/
      appendix A: "the workaround in RFC 1337" - can you be more specific?
    5. Russ Housley: Comment [2010-12-15]:
      I expected a few (minor) changes following the Gen-ART Review by Francis Dupont on 2010-12-10. The changes have not appeared yet.
    6. Tim Polk: Discuss [2011-02-02]:
      I have one relatively minor issue with the Security Considerations section: the first sentence doesn't have any connection with security considerations. I suggest dropping the text entirely, retaining the pointer in the second sentence.
    7. Tim Polk: Comment [2011-02-02]:
      I think it would be better to point to draft-ietf-tcpm-tcp-security, rather than [CPNI-TCP], since it will represent community consensus with respect to security issues for tcp.
    8. Sean Turner: Comment [2010-12-15]:
      I support Tim's discuss.

    Telechat:

2.2 Individual Submissions

2.2.1 New Items

  1. Additional New ASN.1 Modules (Proposed Standard)
    draft-turner-additional-new-asn-06
    Token: Tim Polk
    Discusses/comments (from ballot 3628):
    1. Stewart Bryant: Discuss [2011-01-31]:
      This is a discuss discuss which I hope to clear on the call.
      This document provided updated ASN.1 syntax for a number of standards track documents. I would like to discuss:
      1) Should itself be a standards track document.
      2) Whether this document should formally indicate that it updates those documents.
    2. Lars Eggert: Comment [2011-02-03]:
      IMO, this should be PS *and* formally "Update" these other RFCs. See Stuart's discuss.
      (two Nits)
    3. Adrian Farrel: Comment [2011-02-02]:
      I support Stewart's Discuss.
      Although the resultant long list of "updates" may be a nuisance to some, it is important for the person who plans to update one of the other RFCs to know that this update exists.
      I am a bit confused why the document talks about RFCs using the old (1988) syntax, but only describes the updates from 2002 to 2008.
    4. Russ Housley: Comment [2011-02-02]:
      Please consider the comments from the Gen-ART Review by Kathleen Moriarty on 5-JAN-2011.
    5. Alexey Melnikov: Comment [2011-02-01]:
      I support Stewart's DISCUSS in regards to updating other RFCs, in particular RFC 5911, which defined earlier versions of new style ASN.1 modules.
      I don't have much opinion regarding Informational versa PS, but I think PS would have been just fine.
      Which tool was used to verify the new ASN.1?
    6. Dan Romascanu: Discuss [2011-02-03]:
      This is a DISCUSS-DISCUSS. Should we not make a recommendation about using the 2008 version for documents including CMS format expressions in the future?
    7. Dan Romascanu: Comment [2011-02-03]:
      1. I support Stewart's DISCUSS
      2. I think that the title of the document is too general and should be more specific - e.g. 'Additional New ASN.1 Modules Using the Cryptographic Message Syntax (CMS) format.
    8. Robert Sparks: Comment [2011-01-31]:
      For Stuart and Alexey: I raised very similar questions during the processing of <https://datatracker.ietf.org/doc/draft-ietf-smime-new-asn1/history/>. This document is following the same pattern that document did.

    Telechat:

  2. Algorithms for Cryptographic Message Syntax (CMS) Protection of Symmetric Key Package Content Types (Proposed Standard)
    draft-turner-cms-symmetrickeypackage-algs-00
    Token: Tim Polk
    Note: Sean Turner (turners@ieca.com) is the document Shepherd.
    Discusses/comments (from ballot 3677):
    1. Adrian Farrel: Comment [2011-02-02]:
      Section 3: "Regardless of the key management technique choice, implementations MUST support AES-128 Key Wrap with Padding [RFC5649] as the content encryption algorithm. Implementations SHOULD support AES-256 Key Wrap with Padding [RFC5649] as the content encryption algorithm."
      Is it sufficiently clear from context that this "MUST" applies only to the case on an implementation that supports EnvelopedData?
    2. Russ Housley: Comment [2011-02-02]:
      In section 3 please replace: "When key agreement is used, a key wrap algorithm is also specified to wrap the content encryption key."
      with:
      "When key agreement is used, the same key wrap algorithm MUST be used for both key and content encryption."
      Global changes:
      s/key encryption key/key-encryption key/
      s/key encryption algorithm/key-encryption algorithm/
      s/content encryption key/content-encryption key/
      s/content encryption algorithm/content-encryption algorithm/

    Telechat:

2.2.2 Returning Items

  1. (none)

3. Document Actions

3.1 WG Submissions

3.1.1 New Items

  1. Session PEERing for Multimedia INTerconnect Architecture (Informational)
    draft-ietf-speermint-architecture-17
    Token: Gonzalo Camarillo
    Note: Document Shepherd: Jason Livingood (Jason_Livingood@cable.comcast.com)
    Discusses/comments (from ballot 3626):
    1. Adrian Farrel: Comment [2011-02-02]:
      You will need to remove the citation from the Abstract.
      You will find it worth your while to shake up your ADs to find out why [I-D.ietf-speermint-requirements] is stuck.
      There is a minor alignment problem with the lines indicating the edges of the networks in Figure 1.
      Section 3: "The originating or indirect SSP would likely perform steps 1-4, the target SSP would likely perform steps 4, and either one is likely to perform step 5."
      I found this a little vague. Who else could perform these steps?
      4. Relationships Between Functions/Elements
      I didn't like this section :-(
      You have functions and functional elements with the same name. And you appear to also have implementation components with overlapping names. All in all, you appear to be observing that functions are performed by functional elements, and that functional elements can be implemented in different places according to implementation choices.
      5.1.2.2. Routing Table
      There is nothing wrong with the text in this section, but it does not mention the "routing table" at all, and that seems odd.
    2. Dan Romascanu: Discuss [2011-02-03]:
      The OPS-DIR review by Bert Wijnen raised the following issue:
      'There might be some operational aspects in the sense that sometimes secure/encrypted connections are needed and other times it may be OK to use unencrypted connections if they are inside the same secure building. So is there not something for an operator to configure in such cases?'
      I would like to know what is the answer before I approved this document.
    3. Robert Sparks: Comment [2011-01-31]:
      Deep in section 2 (on page 5) the document notes "An SSP may also be referred to as an Internet Telephony Service Provider (ITSP). While the terms ITSP and SSP are frequently used interchangeably, this document and other subsequent SIP peering-related documents should use the term SSP".
      Please consider moving, or copying that to the first paragraph of the introduction.

    Telechat:

  2. RFC 4148 and the IPPM Metrics Registry are Obsolete (Informational)
    draft-morton-ippm-rfc4148-obsolete-03
    Token: Lars Eggert
    Note: Document shepherd is Henk Uijterwaal (henk@ripe.net).
    Discusses/comments (from ballot 3681):
    1. Stewart Bryant: Comment [2011-02-01]:
      Please add a reference to Zombie_apocalypse, for example http://en.wikipedia.org/wiki/Zombie_apocalypse
    2. Tim Polk: Comment [2011-01-30]:
      I would like to see the security considerations expanded to explain the environments where the risk of a zombie apocalypse is considered most likely, and any suggested mitigations.
    3. Dan Romascanu: Comment [2011-02-03]:
      1. It would be useful to introduce a terminology section that would explain terms like 'zombie' and 'apocalypse' used in the Security Considerations section.
      2. In the IANA Considerations section: "The registry will no longer be updated, and the current contents will be maintained as-is on the day that RFC XXXX was published."
      As this is text to be appended to the Description of the registry on the IANA Web site, it would be useful I think to specify explicitly the date of publication of the RFC - which is also the date of definitive freeze of the registry.
    4. Robert Sparks: Comment [2011-01-31]:
      This Informational document is Obsoleting a BCP (4148 is also BCP 108). Given 4148's content, I agree with the choice of this document's intended status.
    5. Sean Turner: Comment [2011-01-30]:
      While the security considerations made me laugh out loud (thanks for that), I think it should probably be amended to strike the parenthetical.

    Telechat:

  3. MPLS-TP Control Plane Framework (Informational)
    draft-ietf-ccamp-mpls-tp-cp-framework-05
    Token: Adrian Farrel
    Note: Deborah Brungard (db3546@att.com) is the Document Shepherd.
    Discusses/comments (from ballot 3691):
    1. Adrian Farrel: Comment [2011-02-01]:
      Ben Campbell raised some minor points in his review to be cleaned up in the next revision.
      Similarly, Julien Meuric raised some small issues...
    2. Russ Housley: Comment [2011-02-01]:
      Please consider the comments from the Gen-ART Review by Ben Campbell on 31-JAN-2011.

    Telechat:

3.1.2 Returning Items

  1. NSIS Operation Over IP Tunnels (Experimental)
    draft-ietf-nsis-tunnel-13
    Token: Lars Eggert
    Note: The document shepherd is Jukka Manner (jukka.manner@tkk.fi).
    IPR: The Trustees of Columbia University in the City of New York's Statement about IPR related to draft-ietf-nsis-tunnel-13
    IPR: The Trustees of Columbia University in the City of New York's Statement about IPR related to draft-ietf-nsis-tunnel-13
    Discusses/comments (from ballot 3471):
    1. Adrian Farrel: Comment [2010-07-15]:
      Section 3.1: "The following definition of IP tunneling is derived from [RFC2473] and adapted for both IPv4 and IPv6."
      This is a bit odd given the existence of RFC 1853.
    2. Russ Housley: Comment [2010-06-28]:
      Pleae consider the editorial comments from the Gen-ART Review by Francis Dupont on 2010-06-15.
    3. Peter Saint-Andre: Comment [2010-06-28]:
      It appears that the following references might be normative, not informative: [RFC4080], [RFC2473], [RFC2113], [RFC2711], [RFC2746], [RFC3697], [RFC4081].
      Please consult http://www.ietf.org/iesg/statement/normative-informative.html for guidelines regarding the difference between normative and informative references, and consider whether some of the foregoing references would best be changed to normative.

    Telechat:

3.2 Individual Submissions Via AD

3.2.1 New Items

  1. Elliptic Curve-based Certificate-less Signatures for Identifier Based Encryption (ECCSI) (Informational)
    draft-groves-eccsi-00
    Token: Tim Polk
    Discusses/comments (from ballot 3551):
    1. Ralph Droms: Comment [2011-02-02]:
      A minor suggestion - it would help avoid confusion through interpretation of different textual descriptions in section 3 to take out the informal description of integer representation as an octet string and use just the pointer to [P1363]. The informal use of octet string might also be cleaned up a little to clarify that they are all indicating the use of the representation in [P1363].
    2. Lars Eggert: Discuss [2011-02-03]:
      DISCUSS: This is from the sec-dir review:
      "This document is unusual for the IETF, in that it defines a new cryptographic algorithm, which we normally don't do. While there is no particular reason not to publish it here, I would be wary of using this algorithm in any IETF protocol until it has seen extensive review by the cryptographic community. It looks to me like it should work, but I am not a cryptographer and may well have missed an obvious flaw."
      Do we need an IESG note on this document? It seems like an IETF last call doesn't really help much if we don't have the expertise in the community. Why is this being published via the IETF stream?
    3. Lars Eggert: Comment [2011-02-03]:
      It is the job of the *AD* to check conformance to idnits for AD-sponsored documents...
      INTRODUCTION, paragraph 10: "Copyright Notice"
      Boilerplate is outdated for a -00 doc that was submitted Jun 2010.
      INTRODUCTION, paragraph 15: "Table of Contents"
      The document seems to lack an IANA Considerations section.
    4. Russ Housley: Comment [2011-02-01]:
      Please consider the comments from the Gen-ART Review by Francis Dupont on 13-JAN-2011.
    5. Alexey Melnikov: Comment [2011-02-03]:
      The "||" convention needs to be explained early in the document.
      SHA-256 needs a reference.
    6. Sean Turner: Discuss [2011-01-30]:
      #1) Section 3.2: Has the following text:
        Points on E  Elliptic Curve Points MUST be represented in
                     Uncompressed representation ("affine coordinates")
                     as defined in Section 5.5.6 of [P1363a].  For an
                     elliptic curve point (x,y) with x and y in F_p,
                     this representation is given by 0x00 || x' || y' ,
                     where x' is the N-octet string representing x and
                     y' is the N-octet string representing y.
      

      Please double check that it is in fact 0X00 || x' || y'. RFC 5480, SECG SEC1, and ANSI use 0x04 not 0x00 to indicate that the key is uncompressed. Also the P1363 draft I found on the web (I'm unsure whether it's final) says the following about uncompressed keys:
      "In this representation, the octet PC shall have binary value 0000 0100 and the octet strings X and Y shall represent x' and y' respectively."
      #2) Section 3.2, 3.3, and 6, when writing RFC 5915 (Elliptic Curve Private Key Structure) somebody corrected my notation, they suggested it needed to be "ceiling (log2(n)/8) where n is the order of the curve". Do you need to specify in this draft whether "ceil(lg(p)/8)" it's log base 2 or 10 or something else (I assume it's base 2, but it's best to be explicit)?
      #3) Section 4.1 defines N as N = ceil(n/8) and section 3.2 defines it as N = ceil(lg(p)/8). Would it be better to define one as something else? Or does ceil(n/8) = ceil(lg(p)/8)?
      #3) I understand that this draft is intended to be used with the other two draft-groves-* documents on this weeks IESG telechat, but for interoperability sake (no pun intended) can you state at the end of Section 2 where in the other two drafts we can find the points that this draft "does not specify (but comments on)" to ensure implementors can get interoperability? I'm thinking something like:
      "When used with draft-groves-sakke and draft-grove-mikey-sakke, this information can be found ..."
      And, then add an informative reference to draft-grove-mikey-sakke.
      #4) The introductory text in Appendix A needs to say that it uses SHA-256 and I think you need to add a reference to FIPS 186-3. I noted in the other drafts you referred to FIPS 180-2 any reason this can't point to -3?
      #5) (not a cryptographer ;) Section 3.1, based on: "All elliptic curve points will be defined over F_p."
      That means this won't work over F_2^M (characteristic 2 finite fields)? Is it worth noting that p = q in Section 4.1 or is that assumed because it's only over finite fields?
      #6) Section 3.1, is the equation for the curve: y^2= x^3-3x+B(modulo p) (see Section D.1 of FIPS 186-3)?
      #7) Needs an IANA considerations section.
    7. Sean Turner: Comment [2011-01-30]:
      #1) Is it Identifier-Based Encryption or Identity-Based Encryption? RFC 5091 indicates it's the latter.
      #2) In section 3.2, there are two references to P1363. Is there any chance we could change the reference for the integer-to-octet-string conversion in http://datatracker.ietf.org/doc/draft-mcgrew-fundamental-ecc/ (this one is about to be published shortly as an RFC) and RFC 5480 for the uncompressed key info?
      #3) In the penultimate paragraph in Section 7, please add an informative reference to RFC 4086 for random requirements when generating random values (we make everybody point to this RFC when it generates random #s).

    Telechat:

  2. MIKEY-SAKKE: Sakai-Kasahara Key Exchange in Multimedia Internet KEYing (MIKEY) (Informational)
    draft-groves-mikey-sakke-00
    Token: Tim Polk
    Discusses/comments (from ballot 3552):
    1. Gonzalo Camarillo: Comment [2011-02-03]:
      Abstract: this document mentions this key exchange method is used in the IMS. It may be good to repeat the statement in the Introduction adding a reference to an IMS-reated 3GPP spec.
      TGK is not expanded in the text.
    2. Lars Eggert: Comment [2011-02-03]:
      It is the job of the *AD* to check conformance to idnits for AD-sponsored documents...
      INTRODUCTION, paragraph 10: "Copyright Notice"
      Boilerplate is outdated for a -00 doc that was submitted Jun 2010.
      INTRODUCTION, paragraph 15: "Table of Contents"
      The document seems to lack an IANA Considerations section.
    3. Adrian Farrel: Discuss [2011-02-03]:
      No issue with this document, but a couple of matters of process to be sorted out, I think.
      Figure 1 uses some form of syntax that isn't defined in this document. Please insert a reference to the document that defines the syntax.
      Section 3.2: There is an example phone number +441234567890
      This doesn't look like a "standard" example phone number to me.
    4. Adrian Farrel: Comment [2011-02-03]:
    5. Russ Housley: Comment [2011-02-01]:
      Please consider the editorial comments from the Gen-ART Review by Avshalom Houri on 19-JAN-2011.
    6. Robert Sparks: Discuss [2011-02-02]:
      1) (This is mostly a question for the sponsoring AD for telechat discussion, but anyone is welcome to reply). Is this intended to be an IETF consensus document? What boilerplate are you targeting?
      2) This document is registering a mikey mode. Does it need to mention Lawful Intercept (see RFC2804)? Is it necessary for it to discuss forking, retargeting, and deferred delivery as part of registering the mode? These things need to be discussed somewhere, but is this the right document?
    7. Sean Turner: Discuss [2011-01-31]:
      #1) Needs an IANA section. Basically, it needs to point to Section 4 to say you're registering X # of new items for MIKEY.
      #2) Section 3.2 indicates that: "Further Identifier schemes MAY be defined for communities that require different key longevity."
      Is there some type of registry needed for the different identifiers? I.e., would somebody that wanted to do bi-weekly updates need new registry entries in Section 4? For example should it be SAKKE - Monthly so when people decide to do it biweekly it'd be SAKKE- Bi Weekly?
    8. Sean Turner: Comment [2011-01-30]:
      #1) Abstract: "The acronym IDPKC doesn't match the capitalized letters in its expansion. Suggestion: s/Identifier-based Public Key Cryptography/Identifier-Based Public Key Cryptography/
      Please expand IMS.
      #2) Is it Identifier-Based Encryption or Identity-Based Encryption? RFC 5091 indicates it's the latter.
      #3) Any reason this can't reference FIPS 180-3?
      #4) In section 1, paragraph 2, s/legislation/legislations/.
      #5) In the title of section 2, s/Mode;/Mode:/.
      #6) In section 2.1, paragraph 1, the acronym "TGK" is not expanded on first use.

    Telechat:

  3. Sakai-Kasahara Key Establishment (SAKKE) (Informational)
    draft-groves-sakke-00
    Token: Tim Polk
    Discusses/comments (from ballot 3553):
    1. Lars Eggert: Discuss [2011-02-03]:
      Section 3.2., paragraph 3: "We provide pseudocode for computing <R,Q>"
      DISCUSS: Pseudocode does not contain the needed license statement for the IETF Trust.
      Section 7., paragraph 4: "Table 1: Comparable strengths, taken from Table 2 of [SP800-57]"
      DISCUSS: Missing reference to [SP800-57], and it appears to be normative.
    2. Lars Eggert: Comment [2011-02-03]:
      It is the job of the *AD* to check conformance to idnits for AD-sponsored documents...
      INTRODUCTION, paragraph 10: "Copyright Notice"
      Boilerplate is outdated for a -00 doc that was submitted Jun 2010.
      INTRODUCTION, paragraph 15: "Table of Contents"
      The document seems to lack an IANA Considerations section.
    3. Russ Housley: Discuss [2011-02-01]:
      The Gen-ART Review by Richard Barnes on 4-Jan-2010 raises some issues regarding integration of this algorithm into a protocol. Please tell the reader:
      - Which parameters are constant for the whole algorithm
      - Which parameters are expected to be set out of band for a given implementation
      - Which parameters need be negotiated in the protocol
      For example, the algorithm uses a hash function and an elliptic curve, but it is not clear how the communicating parties agree on them.
      If this document is extending RFC 5091, then it should formally update it (as in, with a line at the top), and explain in more detail its relation to RFC 5091.
    4. Russ Housley: Comment [2011-02-01]:
      Please consider the comments from the Gen-ART Review by Richard Barnes on 4-Jan-2010.
    5. Dan Romascanu: Comment [2011-02-03]:
      The following non-blocking comment made by Mike Sneed in his OPS-DIR review is worth being considered:
      The draft is intended for Informational status. The scope is limited to description of the encryption algorithm and the key establishment algorithm. As the document is intended for Informational status, and is limited to describing an algorithm, there are no operational issues to be addressed. However, there are significant operational issues involved in the deployment of Identifier-Based encryption, eg. KMS key management, which would certainly need to be addressed if this algorithm were to be incorporated into a working system.
    6. Sean Turner: Discuss [2011-01-31]:
      #1) Section 4: Has the following text:
        Points on E  Elliptic Curve Points MUST be represented in
                         Uncompressed representation as defined in Section
                         5.5.6 of [P1363a].  For an elliptic curve point (
                         x , y ) with x and y in F_p, this representation
                         is given by 0x00 || x' || y' , where x' is the
                         octet string representing x, y' is the octet
                         string representing y and 0x00 is a NULL octet. 
                         The representation is 2*L+1 octets in length.
      

      Please double check that it is in fact 0X00 || x' || y'. RFC 5480, SECG SEC1, and ANSI use 0x04 not 0x00 to indicate that the key is uncompressed. Also the P1363 draft I found on the web (I'm unsure whether it's final) says the following about uncompressed keys:
      "In this representation, the octet PC shall have binary value 0000 0100 and the octet strings X and Y shall represent x' and y' respectively."
      #2) When specifying lg, specify the base log2, log10 etc.
      #3) Section 4, when defining integer the text is missing the text from groves-eccsi: "There will be no need to represent negative integers. When transmitted or hashed, such octet strings MUST have length N = ceil(lg(p)/8)."
      should it be added?
      #4) The introductory text in Appendix A needs to say that it uses SHA-256 and I think you need to add a reference to FIPS 180-3.
      #5) Needs an IANA section. Even if there's no actions, it needs one.
    7. Sean Turner: Comment [2011-01-30]:
      #1) RFC 5091 indicates it's identity based encryption not identifier based encryption.
      #2) Section 2.1: E: equation is groves-eccsi is y^2 = x^3 - 3 * B vice y^2 = x^3 - 3 * x. Can't we use the same notation? Also isn't (modulo p) missing?
      #3) Notation for ceiling is different than in groves-essci. There it is ceil() here it is Ceiling().
      #4) In section 4, there are two references to P1363. Is there any chance we could change the reference for the integer-to-octet-string conversion in http://datatracker.ietf.org/doc/draft-mcgrew-fundamental-ecc/ (this one is about to be published shortly as an RFC) and RFC 5480 for the uncompressed key info?
      #5) In the last paragraph in Section 7, please add an informative reference to RFC 4086 for random requirements when generating random values (we make everybody point to this RFC when it generates random #s).

    Telechat:

  4. Security Considerations for the SHA-0 and SHA-1 Message-Digest Algorithms (Informational)
    draft-turner-sha0-sha1-seccon-03
    Token: Peter Saint-Andre
    Note: Sean Turner (turners@ieca.com) is the document Shepherd.
    Discusses/comments (from ballot 3663):
    1. Adrian Farrel: Discuss [2011-02-02]:
      Section 4, "Guidance" seems stronger than I expect in an Informational I-D. Not only does it tell protocol designers what they "must" and "should" do, but it also refers to this document as a "specification".
      I know you would like to set some hard rules, and they are possibly necessary, but this is not the way to do it. Either tone down the language, or bring this guidance back as standards track.
    2. Adrian Farrel: Comment [2011-02-02]:
      The first paragraph of Section 1 mentions the SHA-1 and SHA-2 family. It then goes on to say that SHA-0 and SHA-1 are message digest algorithms, but there is no further mention of SHA-2. I find that to be a bit of a tease.
      "HMAC" is used unexpanded.
    3. Dan Romascanu: Comment [2011-02-03]:
      I support Adrian's DISCUSS. Reading the recommendations section and the supporting justification I rather have the feeling that the recommendations need to be 2119 capitalized and the document should be either standards track or BCP.

    Telechat:

3.2.2 Returning Items

  1. (none)

3.3 IRTF and Independent Submission Stream Documents

3.3.1 New Items

  1. (none)

3.3.2 Returning Items

  1. (none)

3.3.3 For Action

  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.

    Telechat:

  2. Using Self-Delimiting Numeric Values in Protocols (Informational)
    draft-irtf-dtnrg-sdnv-08
    Token: Russ Housley
    Note: IRTF Submission. Elwyn Davies (elwynd@dial.pipex.com) is the document shepherd.

    Telechat:

  3. Compressed Bundle Header Encoding (CBHE) (Experimental)
    draft-irtf-dtnrg-cbhe-08
    Token: Russ Housley
    Note: IRTF submission. Elwyn Davies (elwynd@dial.pipex.com) is the document shepherd.

    Telechat:

  4. Delay-Tolerant Networking Metadata Extension Block (Experimental)
    draft-irtf-dtnrg-bundle-metadata-block-09
    Token: Russ Housley
    Note: IRTF submission. Elwyn Davies (elwynd@dial.pipex.com) is the document shepherd.

    Telechat:

  5. Delay-Tolerant Networking Previous Hop Insertion Block (Experimental)
    draft-irtf-dtnrg-bundle-previous-hop-block-12
    Token: Russ Housley
    Note: IRTF submission. Elwyn Davies (elwynd@dial.pipex.com) is the document shepherd.

    Telechat:

  6. Delay-Tolerant Networks (DTN) Bundle Protocol IANA Registries (Informational)
    draft-irtf-dtnrg-iana-bp-registries-01
    Token: Russ Housley
    Note: IRTF submission. Elwyn Davies (elwynd@dial.pipex.com) is the document shepherd.

    Telechat:

1307 EST break

1312 EST back

4 Working Group Actions

4.1 WG Creation

4.1.1 Proposed for IETF Review

  1. (none)

4.1.2 Proposed for Approval

  1. Light-Weight Implementation Guidance (lwig)
    Token: Jari

    Telechat:

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. Expert for Kerberos Pre-authentication and Typed Data Registry [IANA #424161] (Michelle Cotton)

    Telechat:

  2. New Arc for ABFAB WG [IANA #423474] (Michelle Cotton)

    Telechat:

  3. Request for variance in 4 references in RFC-to-be-6071 (Sean Turner)

    Telechat:

7. Agenda Working Group News

1409 EST Adjourned


Valid HTML 4.01 Strict


Appendix: Snapshot of discusses/comments

(at 2011-02-03 07:26:39 PST)

draft-ietf-ltans-xmlers

  1. Lars Eggert: Comment [2011-01-17]:
    I agree with Sean's discuss on RFC2119 usage.
  2. Alexey Melnikov: Discuss [2011-01-30]:
        [Updated. All my other issues were resolved. Please let me know if I missed a
    resolution or reply to the only remaining issue.]
    
    3.1.2. Time-Stamp 
    
       Since at the time being there is no standard 
       for an XML Time-Stamp, the following structure example is provided 
       (referring to the Entrust XML Schema for Time-Stamp 
       http://www.entrust.com/schemas/timestamp19protocol-20020207), which 
       is a digital signature compliant to [XMLDSig] specification 
       containing Time-Stamp specific data, such as time-stamped value and 
       time within <Object> element of a signature. 
    
    Is this enough for interoperability? The text almost looks informative in
    places.
    
       <element name="TimeStampInfo"> 
          <complexType> 
             <sequence> 
                <element ref="Policy" />  
                <element ref="Digest" />  
                <element ref="SerialNumber" minOccurs="0" />  
                <element ref="CreationTime" />  
                <element ref="Accuracy" minOccurs="0" />  
                <element ref="Ordering" minOccurs="0" />  
                <element ref="Nonce" minOccurs="0" />  
                <element ref="Extensions" minOccurs="0" />  
             </sequence> 
          </complexType> 
       </element> 
     
        
  3. Alexey Melnikov: Comment [2011-01-30]:
    
        
  4. Peter Saint-Andre: Discuss [2011-01-24]:
        This a reconstructed review, since the first one was lost in a datatracker
    accident. My apologies if I have missed anything that was in the initial review.
    
    (Updated per version -11 of the spec.)
    
    DISCUSSES
    
    1. [addressed in -11]
    
    2. [addressed in -11]
    
    3. [addressed in -11]
    
    4. [addressed in -11]
    
    5. Section 2.1 states:
    
       <TimeStamp> tag holds a <TimeStampToken> element with a Time-Stamp
       Token provided by the Time-Stamping Authority and optional element
       <CryptographicInformationList>.
    
    This makes it sound as if the structure of the <TimeStamp/> element (not "tag"!)
    is a sequence formed of a required <TimeStampToken/> element and an optional
    <CryptographicInformationList/> element. However, the schema in Section 7
    defines the <TimeStamp/> element as having a mixed content model. This is
    confusing. Furthermore, mixed content models can make parsing more complex. Is
    there a good reason why this document defines a mixed content model for the
    <TimeStamp/> element?
    
    As a further clarification, in Section 3.1.2 there can be found the following
    examples...
    
       For example:
    
       <TimeStamp Type="RFC3161">MIAGCSqGSIb3DQEH...</TimeStamp>
    
       or
    
       <TimeStamp Type="XMLENTRUST"><dsig:Signature>...</dsig:Signature>
       </TimeStamp>.
    
    To prevent the mixed content model, why not do something like the following?
    
       <TimeStamp
    Type="RFC3161"><ASN1Data>MIAGCSqGSIb3DQEH...</ASN1Data></TimeStamp>
    
    That would enable you to define the schema as something like this:
    
       <xs:complexType name='TimeStampTokenType'
                       xmlns:dsig='http://www.w3.org/2000/09/xmldsig#'>
          <xs:choice>
            <xs:element name='ASN1Data' type='xs:base64Binary'/>
            <xs:element ref='dsig:Signature'/>
          </xs:choice>
       </xs:complexType>
    
    Much simpler...
    
    6. Section 2.1 states:
    
         <Attributes> tag contains additional information that may be
         provided by an LTA used to support processing of Evidence Records.
         An example of this supporting information may be a processing
         policy, like a renewal, a cryptographic (e.g. [RFC5698]) or an
         archiving policy. Such policies can provide inputs, which are
         relevant for data object(s) preservation and evidence validation at
         a later stage. Each data object is put into a separate child
         element <Attribute>, with a mandatory Order attribute to indicate
         the order within the parent element and an optional Type attribute
         to indicate processing directions.
    
    This makes it sound as if the structure of the <Attributes/> element (not
    "tag"!) is a sequence formed of one or more required <Attribute/> elements.
    However, the schema in Section 7 defines the <Attributes/> element as having a
    mixed content model. This is confusing. Furthermore, mixed content models can
    make parsing more complex. Is there a good reason why this document defines a
    mixed content model for the <Attributes/> element?
    
    7. Section 2.1 does not define the syntax and semantics for the 'Type' attribute
    of the <Attribute/> element or the <SupportingInformationList/> element. The
    text says only that this attribute is used "to indicate processing directions".
    What does that mean? What values are allowed? How is the application supposed to
    determine the processing directions based on the value of the 'Type' attribute?
    The lack of specification here will likely cause interoperability problems.
    
    8. [addressed in -11]
    
    9. In Section 3.1.2, the "ts:" prefix is undefined. Is it hardcoded to "ts:" or
    is that just an example? Is the "ts:" prefix associated with the (unspecified)
    namespace from <http://www.entrust.com/schemas/timestamp19protocol-20020207>?
    Are you aware that the referenced URL currently yields an HTTP 404 error at
    www.entrust.com? Can you please provide a stable reference to the "Entrust XML
    Schema for Time-Stamp"? The lack of a clear definition or a stable reference is
    problematic. Finally, if the text beginning with <element name="TimeStampInfo">
    is intended to be a schema snippet that defines the <TimeStampInfo/> element,
    then this should be included in the schema within Section 7 or in a separate
    schema, and we should make sure that this contribution was made in conformance
    with the IETF's "Note Well" policy.
    
    10. [addressed in -11]
    
    11. In Section 7, I suggest that you redefine the schema so that it no longer
    uses mixed content models.
    
    12. [addressed in -11]
    
    13. [addressed in -11]
    
    14. [addressed in -11]
    
    15. [addressed in -11] 
        
  5. Peter Saint-Andre: Comment [2011-01-24]:
    COMMENTS
    
    1. In Section 1.3, some of these terms are repeated from RFC 3275 and RFC 4051.
    Sometimes the definitions are the same (e.g., "Archive data object") and
    sometimes they are slightly different (e.g., "Evidence"). Why does this document
    not simply reference RFC 3275 and RFC 4051 for the repeated terms?
    
    2. [addressed in -11]
    
    3. [addressed in -11]
    
    4. [addressed in -11]
    
    5. [addressed in -11]
    
    6. [addressed in -11]
    
    7. [addressed in -11]
    
    8. [addressed in -11]
    
    9. [addressed in -11]
    
  6. Sean Turner: Comment [2011-01-24]:
    #1) addressed
    
    #2) addressed
    
    #3) addressed
    
    #4) addressed
    
    #5) Sec 2.1: Should probably also indicate how many of the fields can be
    included (i.e, match the +, ?, * in the schema to the text).
    
    #6) I didn't see the changes for this one:
    
    Sec 3.1.1: I put that hex string in to a couple of Base64 encoders and got:
    
    QTk5OTNFMzYgNDcwNjgxNkEgQkEzRTI1NzEgNzg1MEMyNkMgOUNEMEQ4OUQ==
    
    #7) addressed

draft-ietf-pmol-metrics-framework

  1. Jari Arkko: Comment [2011-02-02]:
    It is a very good idea to publish an RFC for defining the task of a directorate.
    However, I do want to make a few suggestions:
    
    1. The name "Entity" is a bit odd. The established IETF terminology is
    "directorate"
    
    2. I would not make the directorate a formal requirement or mandatory part of
    the process. I think it is better cast as a review organization that can help
    the working group, the IETF, and the IESG in making the right decisions.
  2. Ron Bonica: Discuss [2011-02-02]:
        Point 1: 
    
    This document appears to have two purposes:
    
    "The purpose of this document is to define a framework and a process for
    developing Performance Metrics for protocols above and below the IP-layer (such
    as IP-based applications that operate over reliable or datagram transport
    protocols), that can be used to characterize traffic on live networks and
    services.  As such, this document does not define any Performance Metrics."
    
    -and-
    
    "This document refers to the implementation of a Performance Metrics Entity,
    whose goal is to advice and support the Performance Metric development at the
    IETF.  A recommendation about the Performance Metrics Entity is made in Section
    6.6."
    
    You don't need an RFC to form a directorate. Just do it.
    
    Point 2:
    
    Does this document need to be a BCP? Or, asked another way, do you need a club
    to prevent someone outside of BMWG/PMOL/IPPM from developing a benchmarking
    metric using some other method? (And who would those people be?) 
        
  3. Gonzalo Camarillo: Discuss [2011-02-03]:
        Section 6 describes a policy to accept new metrics and establishes a
    directorate. As you know, RFC 5226 defines a set of policies to be applied when
    something needs to be registered with the IANA. However, in this case new
    metrics do not seem to be registered with the IANA. So, what is the process
    trying to prevent? Someone writing a new metrics proposal and referencing this
    document? (this relates to Ron's discuss). I think the information about what to
    look for when reviewing proposals for new metrics is useful. Couldn't the
    document just provide it as information for those who will be reviewing
    proposals submitted to the IETF and not as a process definition? 
        
  4. Gonzalo Camarillo: Comment [2011-02-03]:
    draft-ietf-pmol-metrics-framework-08
    
    The reference to RFC 2119 appears right after the Abstract. I would place it
    inside the Terminology section (Section 2 instead).
    
    Section 1.1 uses the present tense to describe events that happened in the past
    (e.g., "the IETF has two active WGs" or "there is a gap"). This also related to
    Adrian's comment on the same section. This section could be more explicit about
    what is describing, which seems to be the creation of the PMOL WG.
    
    When talking about SBCs in Section 5.5.4, you may want to reference RFC 5853
  5. Lars Eggert: Comment [2011-02-03]:
    Agree with everyone else that the process stuff needs to be changed.
    
     > Intended status: BCP
    
      Agree with Ron - this should not be a BCP.
    
    Section 2.1., paragraph 1:
    >    The Performance Metrics Entity is a directorate that coordinates the
    >    Performance Metric development in the IETF.
    
      "Entity" is a weird name for a directorate. Why don't you just call it
      a directorate?
    
    Section 3., paragraph 2:
    >    intended to supercede existing working methods within WGs that have
    
      Nit: s/supercede/supersede/
    
    Section 5.3.1., paragraph 6:
    >    In the context of flow records in IP Flow Informatin eXport (IPFIX),
    
      Nit: s/Informatin/Information/
    
    Section 5.4.3., paragraph 3:
    >    definition is to assist implementers to achieve consistents results.
    
      Nit: s/consistents/consistent/
    
  6. Adrian Farrel: Discuss [2011-02-02]:
        I agree with Ron that if what is wanted is a Directorate, it should
    simply be created by the AD. Furthermore, I am worried that codifying
    the directorate in this document is implying changes to the IETF
    process that are not acceptable.
    
    I strongly support the guidelines part of this document (which feels
    Informational), but recommend that all reference to the directorate
    be removed. 
        
  7. Adrian Farrel: Comment [2011-02-02]:
    Section 1.1
    
       Although the IETF has two active Working Groups (WGs) dedicated to
       the development of Performance Metrics, they each have strict
       limitations in their charters:
    
    You seem to fail to list the PMOL WG. Is Section 1.1 simply trying to
    justify the creation of PMOL? If so it can be removed from the 
    document because the WG seems to exist :-)
  8. Alexey Melnikov: Discuss [2011-02-03]:
        In general I think this document is adding some rather weak requirements on
    process (lots of "SHOULD"s).
    
    I also have the following question which is another way of formulating one of
    Robert's DISCUSS points:
    
    5.4.2.  Normative parts of Performance Metric definition
    
       The normative part of a Performance Metric definition MUST define at
       least the following:
    
       (i) Metric Name
    
       Performance Metric names MUST be unique within the set of metrics
       being defined and MAY be descriptive.
    
    Is there a formal syntax for performance metric names? How are these names to be
    used (e.g. are they going to be used by IANA to guaranty uniqueness)? 
        
  9. Alexey Melnikov: Comment [2011-02-03]:
    6.4.  Performance Metrics Entity Interaction with other WGs
    
       The Performance Metrics Entity SHALL work in partnership with the
       related protocol development WG when considering an Internet Draft
       that specifies Performance Metrics for a protocol.  A sufficient
       number of individuals with expertise must be willing to consult on
       the draft.  If the related WG has concluded, comments on the proposal
       should still be sought from key RFC authors and former chairs, or
    
    I think "or" --> "and/or". I.e., there is not reason to choose the former over
    the latter if both are available.
    
       from the WG mailing list if it was not closed.
    
  10. Tim Polk: Discuss [2011-02-02]:
        In my opinion, the sections that establish a new directorate and make it part of
    the official process require an
    "Updates 2026".  In particular, section 6.3
    integrates the directorate into the approval process for new work items.
    I would
    also note that this is a much stronger role than any other directorate has been
    given.  Secdir, mib doctors, etc.
    have a review role but they are not asked to
    approve new work items.
    
    It would be more appropriate to excise all text about the directorate; forming
    the directorate and reviewing metrics
    related efforts does not require an RFC.
    I also suggest that the directorate make itself available for early review
    upon
    request, but strongly oppose any attempt to establish a gating function.
    
    If the authors do not wish to remove this text or modify these functions, I
    believe another Last Call is in order after
    adding "updates 2026" to the header,
    since I do not believe these changes have community consensus. 
        
  11. Tim Polk: Comment [2011-02-02]:
    To be clear, I am not opposed to creating the directorate.  
  12. Robert Sparks: Discuss [2011-02-02]:
        1) Section 6.3 is not adding any new process (it is recommending using the
    directorate framework we already have, asking an AD to set up and use a new
    team). It could stop with it's first sentence, and that sentence does not need
    to be restated in this document.  I think you have the same document if you
    delete this section.  If you agree, please delete it. If you don't agree, the
    document needs to be more explicit on what the section is trying to achieve.
    
    2) I'm not sure Section 5.4.2 (i) is clear about the domain over which it is
    requiring names to be unique. It could be read to mean "unique within a given
    document defining metrics". Did you intend it to mean "Unique within the set of
    standardized metrics for a given protocol"? What mechanisms are you advising be
    used to ensure this uniqueness?  Should this document advise metric designers to
    help establish and manage registries per thing being measured, or are you
    anticipating something more lightweight?
    
    3) Why did you make a new metric for the example in 5.4.5 instead of
    exemplifying one that is already well specified?  (Or have I missed the
    specification? It's related to discussion in 3550 and 3661, but I don't see this
    defined as a metric there). If it's new, could this section be misconstrued as
    actually defining the metric? I'd hate to see some future document trying to
    normatively refer an implementer to this section...
    
    5) Section 6.2 is the section of the document that is going to guide reviewers.
    It's not as clear as it needs to be. For instance, reviewers are being asked to
    assess a metric according the the qualification "use cases" and that is the only
    place the string appears in the document. What are you requiring with respect to
    use cases?
    
    6) Why didn't Section 6.6 recommend a particular Area? 
        
  13. Robert Sparks: Comment [2011-02-02]:
    1) "defined in a similar way" is very vague.
    
    2) The language in 5.3.1 stating that measurements need to be non-overlapping
    and contiguous to be meaningfully composed caused me to pause. It's certainly
    easier to build meaningful compositions from measurements with those properties,
    but it's possible to build meaningful compositions when the properties,
    particularly contiguity, aren't met.
    
    3) Consider adding a discussion to section 5.4.2 (v) noting that the metric
    definition should discuss how the metric might vary depending which measurement
    point is chosen. The time between a SIP request and final response can be
    significantly different at the UAC and the UAS for example. Also consider noting
    that these kinds of differences should be taken into account when composing
    metrics.
    
    4) In 5.4.3 it would help readers to note that 3550 calls this interarrival
    jitter.
    
    5) It's not really clear what you want readers to do with the information in
    section 5.5. Please consider a short introduction to the section discussing
    whether these are observations that a metric designer needs to keep in mind, or
    if you are asking reviewers to ensure a specification says something about these
    things, or if you had a completely different audience in mind.
  14. Sean Turner: Comment [2011-02-03]:
    I support everybody else's discuss wrt to the process section. 

draft-ietf-pwe3-cep-mib

  1. Lars Eggert: Comment [2011-02-03]:
    Section 7., paragraph 54:
    >          An agent with CEP capability MUST be capable of supporting
    >          at least n intervals. The minimum value of n is 4, the
    >          default of n is 32 and the maximum value of n is 96.
    
      I don't get this. How can you state a MUST requirement for a specific
      value, and then give a range for that value?
    
  2. Adrian Farrel: Comment [2011-02-02]:
    I'm entering a 'Yes' ballot because this work is technically sound and useful.
    However, I found a slew of nits that really should be worked on to make the RFC
    more valuable.
    
    ---
    
    The various write-ups and announcements should be updated to reflect the new
    responsible AD
    
    ---
    
    The double page-throws are a nuisance
    
    ---
    
    Section 1
    
    Need to expand CEP on first use
    
    ---
    
    Section 2
    
       The mechanism for structured
       emulation (as outlined in the CEP draft)
    
    Hmmm? do you mean RFC 4842?
    
    ---
    
    Section 2
    
    s/Since A SONET/Since a SONET/
    
    ---
    
    6.3.  PW-STD-MIB Modules Usage
    
    s/Modules/Module/
    
    ---
    
    Section 7
    
    The comments on the IMPORT clauses are welcome, but should not show
    in square brackets as they are not references (because the MIB module 
    is standalone with section 10.
    
    ---
    
    Section 7
    
    You can remove the two notes to the RFC Editor in the IMPORTS
    clause as you have already fixed up the RFC numbers yourselves.
    
    ---
    
    MODULE-IDENTITY DESCRIPTION CLAUSE
    
     -- RFC Editor: Please replace yyyy with actual RFC number and
     -- remove this note
    
    I think this is xxxx
    
    ---
    
    TEXTUAL CONVENTIONS
    
    I'm a bit disappointed that the TCs defined here don't come with
    REFERENCE clauses.
    
    ---
    
    PwCepFracAsyncMap, pwCepType, pwCepFracMode, pwCepFracSdhVc4Mode, and
    pwCepPerfIntervalReset
    
    Although not a requirement, it is usual for INTEGER enumerations to
    start at zero. Sometimes other schemes are used to stay in synch with
    protocols - if so, it is nice to say so and give a reference.
    
    ---
    
    pwCepEntry
    
             however change of some objects (for example
             pwCepCfgIndex) during PW forwarding state MAY cause traffic
             disruption.
    
    s/MAY/may/
    
    ---
    
    pwCepValidIntervals
    
    Telling us the default value for a read-only object is a little
    distracting.
    
    ---
    
    pwCepPeerCepOption
    
    How is this object set when the PW is statically provisioned?
    
    ---
    
    pwCepCfgIndex
    
    Should indicate what meaning is assigned to the value zero since
    zero is not a valid index to pwCepCfgTable
    
    ---
    
    pwCepCfgJtrBfrDepth
    
             The actual jitter buffer MUST be at least twice this
             value for proper operation.
                                           
    I think this warrants a REFERENCE
    
    ---
    
    pwCepFracSdhVc4Tu3Map1 and similar objects
    
             "If the first TUG-3 within the VC-4 contains a TU-3, this
              variable must be set to the required mode. "
    
        DEFVAL { other }
    
    So, I was going to say s/must/MUST/ but since you have a DEFVAL
    defined for each case, I don't understand the meaning of the text.
    
    ---
    
    pwCepPerfCurrentAbsPtrAdjust. pwCepPerfIntervalAbsPtrAdjust, and
    pwCepPerf1DayIntervalAbsPtrAdjust
    
    Are the Description clauses in English?
    
    ---
    
     pwCepPerfIntervalNumber OBJECT-TYPE
        SYNTAX        Integer32 (1..96)
        MAX-ACCESS    not-accessible
        STATUS        current
        DESCRIPTION
            "A number (normally between 1 and 96 to cover a 24 hour
             period) which identifies the interval for which the set
             of statistics is available. The interval identified by 1
             is the most recently completed 15-minute interval and
             the interval identified by N is the interval immediately
             preceding the one identified by N-1. The minimum range of
             N is 1 through 4. The default range is 1 through 32. The
             maximum value of N is 1 through 96."
    
    I'd be interested in the non-normal case given the SYNTAX !
    
    I find the text about ranges clumsy. Anyway, since the object is
    not-accessible, it is moot.
    
    ---
                                                       
    UNITS clauses would be nice in objects like pwCepPerfIntervalTimeElapsed
    and pwCepPerfIntervalInPtrAdjustSecs
    
    ---
    
     pwCepPerf1DayIntervalNumber OBJECT-TYPE
        SYNTAX      Unsigned32(1..31)
        MAX-ACCESS  not-accessible
        STATUS      current
        DESCRIPTION
          "History Data Interval number. Interval 1 is the current day
           measurement period, interval 2 is the most recent previous
           day; interval 30 is 31 days ago. Intervals 3..31 are
           optional."
        ::= { pwCepPerf1DayIntervalEntry 1 }
    
    What does "optional" mean in a not-accessible object?
    
    ---
    
    pwCepPerf1DayIntervalUASs looks like it needs a Reference clause
    
    ---
    
    Section 10.1
    As indicated by idnits...
    
    The RFC number is missing from the BCP14 reference.
    
    ---
  3. Russ Housley: Comment [2011-02-01]:
      Please remove this paragraph prior to publication:
    
       Comments should be made directly to the PWE3 mailing list at
       pwe3@ietf.org.
  4. Dan Romascanu: Comment [2011-01-23]:
    
      

draft-ietf-tcpm-tcp-timestamps

  1. Stewart Bryant: Comment [2010-12-13]:
    2*MSL
    
    Term not defined in the document.
  2. Ralph Droms: Comment [2010-12-15]:
       Stylistic suggestion: in the bullets in section 2, either include
       the parenthetical "(creating a connection in the SYN-RECEIVED
       state)" in every sub-bullet or only the first.
    
       Where ISN comparisons are performed in the rules in section 2, is
       the comparison strictly "less than", or is the (rather unlikely
       event of) wraparound considered?
    
  3. Adrian Farrel: Comment [2010-12-13]:
       The Timestamps option, specified in RFC 1323 [RFC1323], allows a TCP
       to include a timestamp value in its segments, that can be used to
    
    s/TCP/TCP implementation/?
    
  4. David Harrington: Comment [2010-12-14]:
    section 3:
    s/are important for TCPs that/are important for TCP connections that/
    
    s/break prevent/prevent/
    
    appendix A: "the workaround in RFC 1337" - can you be more specific?
    
    
  5. Russ Housley: Comment [2010-12-15]:
      I expected a few (minor) changes following the Gen-ART Review by
      Francis Dupont on 2010-12-10.  The changes have not appeared yet.
  6. Tim Polk: Discuss [2011-02-02]:
        [Revised 2 February]
    
    Nice document, very clear presentation.
    
    I have one relatively minor issue with the Security Considerations section: the
    first sentence doesn't have any connection with security considerations.
    I
    suggest dropping the text entirely, retaining the pointer in the second
    sentence. 
        
  7. Tim Polk: Comment [2011-02-02]:
    I think it would be better to point to draft-ietf-tcpm-tcp-security, rather than
    [CPNI-TCP],
    since it will represent community consensus with respect to security
    issues for tcp.
  8. Sean Turner: Comment [2010-12-15]:
    I support Tim's discuss.

draft-turner-additional-new-asn

  1. Stewart Bryant: Discuss [2011-01-31]:
        This is a discuss discuss which I hope to clear on the call.
    
    This document provided updated ASN.1 syntax for a number of standards track
    documents. I would like to discuss:
    
    1) Should itself be a standards track document.
    2) Whether this document should
    formally indicate that it updates those documents. 
        
  2. Lars Eggert: Comment [2011-02-03]:
    IMO, this should be PS *and* formally "Update" these other RFCs. See Stuart's
    discuss.
    
    Section 6., paragraph 13:
    >     --  Define each of the MAC-ALGOIRTHM objects to describe the
    
      Nit: s/MAC-ALGOIRTHM/MAC-ALGORITHM/
    
    Section 2., paragraph 1:
    >    Protocol designers can make use of the '08 ASN.1 contraints to define
    
      Nit: s/contraints/constraints/
    
  3. Adrian Farrel: Comment [2011-02-02]:
    I support Stewart's Discuss.
    Although the resultant long list of "updates" may
    be a nuisance to some, it is important for the person who plans to update one of
    the other RFCs to know that this update exists.
    
    ---
    
    I am a bit confused why the document talks about RFCs using the old (1988)
    syntax, but only describes the updates from 2002 to 2008.
  4. Russ Housley: Comment [2011-02-02]:
      Please consider the comments from the Gen-ART Review by Kathleen
      Moriarty on 5-JAN-2011.  You can found the review at:
      
        http://www.softarmor.com/rai/temp-gen-art/
        draft-turner-additional-new-asn-06-moriarty.txt
  5. Alexey Melnikov: Comment [2011-02-01]:
    I support Stewart's DISCUSS in regards to updating other RFCs, in particular RFC
    5911, which defined earlier versions of new style ASN.1 modules.
    
    I don't have much opinion regarding Informational versa PS, but I think PS would
    have been just fine.
    
    Which tool was used to verify the new ASN.1?
    
  6. Dan Romascanu: Discuss [2011-02-03]:
        This is a DISCUSS-DISCUSS. Should we not make a recommendation about using the
    2008 version for documents including CMS format expressions in the future? 
        
  7. Dan Romascanu: Comment [2011-02-03]:
    1. I support Stewart's DISCUSS
    
    2. I think that the title of the document is too general and should be more
    specific - e.g. 'Additional New ASN.1 Modules Using the Cryptographic Message
    Syntax (CMS) format.
  8. Robert Sparks: Comment [2011-01-31]:
    For Stuart and Alexey: I raised very similar questions during the processing of
    <https://datatracker.ietf.org/doc/draft-ietf-smime-new-asn1/history/>. This
    document is
    following the same pattern that document did.

draft-turner-cms-symmetrickeypackage-algs

  1. Adrian Farrel: Comment [2011-02-02]:
    Section 3
    
       Regardless of the key management technique choice, implementations 
       MUST support AES-128 Key Wrap with Padding [RFC5649] as the content 
       encryption algorithm.  Implementations SHOULD support AES-256 Key 
       Wrap with Padding [RFC5649] as the content encryption algorithm. 
    
    Is it sufficiently clear from context that this "MUST" applies only
    to the case on an implementation that supports EnvelopedData? 
    
  2. Russ Housley: Comment [2011-02-02]:
    In section 3 please replace:
    
      When key agreement is used, a key wrap algorithm is also specified to wrap the
    content encryption key.
    
    with:
    
      When key agreement is used, the same key wrap algorithm MUST be used for both
    key and content encryption.
      
    Global changes:
      s/key encryption key/key-
    encryption key/
      s/key encryption algorithm/key-encryption algorithm/
    s/content encryption key/content-encryption key/
      s/content encryption
    algorithm/content-encryption algorithm/

draft-ietf-speermint-architecture

  1. Adrian Farrel: Comment [2011-02-02]:
    You will need to remove the citation from the Abstract.
    
    ---
    
    You will find it worth your while to shake up your ADs to find out
    why [I-D.ietf-speermint-requirements] is stuck.
    
    ---
    
    There is a minor alignment problem with the lines indicating the edges
    of the networks in Figure 1.
    
    ---
    
    Section 3
    
       The originating or indirect SSP would likely perform steps 1-4, the
       target SSP would likely perform steps 4, and either one is likely to
       perform step 5.
    
    I found this a little vague. Who else could perform these steps?
    
    ---                                            
    
    4.  Relationships Between Functions/Elements
    
    I didn't like this section :-(
    
    You have functions and functional elements with the same name. And you
    appear to also have implementation components with overlapping names.
    All in all, you appear to be observing that functions are performed
    by functional elements, and that functional elements can be implemented
    in different places according to implementation choices.
    
    ---
    
    5.1.2.2.  Routing Table
    
    There is nothing wrong with the text in this section, but it does not
    mention the "routing table" at all, and that seems odd.
  2. Dan Romascanu: Discuss [2011-02-03]:
        The OPS-DIR review by Bert Wijnen raised the following issue: 
    
    'There might be some operational aspects in the sense that sometimes
    secure/encrypted connections are needed and other times it may be OK to use
    unencrypted connections if they are inside the same secure building. So is there
    not something for an operator to configure in such cases?'
    
    I would like to know what is the answer before I approved this document. 
     
        
  3. Robert Sparks: Comment [2011-01-31]:
    Deep in section 2 (on page 5) the document notes "An SSP may also be referred to
    as an Internet Telephony Service Provider (ITSP).  While the terms ITSP and SSP
    are frequently used interchangeably, this document and other subsequent SIP
    peering-related documents should use the term SSP".
    
    Please consider moving, or copying that to the first paragraph of the
    introduction.

draft-morton-ippm-rfc4148-obsolete

  1. Stewart Bryant: Comment [2011-02-01]:
    Please add a reference to Zombie_apocalypse, for example
    http://en.wikipedia.org/wiki/Zombie_apocalypse
  2. Tim Polk: Comment [2011-01-30]:
    I would like to see the security considerations expanded to explain the
    environments where the risk of a zombie
    apocalypse is considered most likely,
    and any suggested mitigations.
  3. Dan Romascanu: Comment [2011-02-03]:
    1. It would be useful to introduce a terminology section that would explain
    terms like 'zombie' and 'apocalypse' used in the Security Considerations
    section.
    
    2. In the IANA Considerations section: 
    
    >  The registry will no longer be updated, and the current contents will
       be maintained as-is on the day that RFC XXXX was published.
    
    As this is text to be appended to the Description of the registry on the IANA
    Web site, it would be useful I think to specify explicitly the date of
    publication of the RFC - which is also the date of definitive freeze of the
    registry.
  4. Robert Sparks: Comment [2011-01-31]:
    This Informational document is Obsoleting a BCP (4148 is also BCP 108). Given
    4148's content, I agree with the choice of this document's intended status.
  5. Sean Turner: Comment [2011-01-30]:
    While the security considerations made me laugh out loud (thanks for that), I
    think it should probably be amended to strike the parenthetical.

draft-ietf-ccamp-mpls-tp-cp-framework

  1. Adrian Farrel: Comment [2011-02-01]:
    Ben Campbell raised some minor points in his review to be cleaned up in the next
    revision.
    Similarly, Julien Meuric raised some small issues.
    
    === Ben ===
    
    Minor issues:
    
    -- Section 2 (and subsections)
    
    This section appears to be made up almost entirely of restatements of
    requirements that are normatively stated elsewhere. That takes up about 16
    pages. Is that really necessary, other than to say which requirements apply to
    the control plane? You could do that by merely calling out the numbers of the
    requirements that apply from each document, and making notes when more
    explanation is needed. Since you explicitly state that the source documents are
    authoritative, then a careful reader will need to read those documents anyway.
    OTOH, a not-so-careful reader may not read the source documents, and therefore
    be misinformed if this document introduces any discrepancies.
    
    -- Security Considerations:
    
    Are you willing to assert that no new security considerations are introduced by
    the existing mechanism being used in this new context?
    
    Nits/editorial comments:
    
    -- IDNits returns errors and warnings. Please check.
    
    -- The document lists 5 editors on the front page, and 8 authors in the author
    section. That's a bit on the high side. I have no opinion whether that is
    reasonable for this draft--I just call it out so others can decide.
    
    -- Please number the tables.
    
    -- The document makes inconsistent use of references. For example, you jump
    between the forms of "... as defined in document[xxx]", "... as defined in
    document, see [xxx]", and "as defined in [xxx]". More consistency would make for
    easier reading. I personally prefer the first form, and find the second form
    disruptive to the flow of reading.
    
    -- Section 1, paragraph 1: "(MPLS-TP) is being defined"
    
    Be careful with time-sensitive statements such as this. An RFC lives forever,
    and this statement may be nonsensical to readers in e future. At least qualify
    it with something like "at the time of this writing..."
    
    -- Section 1, paragraph 2: "as defined by the ITU-T"
    
    Reference?
    
    -- Section 1.2, numbered list:
    
    This is really just normal information, not a sequence. I suggest paragraph
    form, or a bullet list if you really need a list format.
    
    Please put space between the list entries. A long list like this is difficult to
    read without some white space.
    
    Please expand acronyms on first use. There are a number of unexpanded acronyms
    in this section.
    
    -- section 2, first paragraph: "The requirements are summarized in this section,
    but do not replace those documents. If there are differences between this
    section and those documents, those documents shall be considered authoritative."
    
    I assume that makes this entire section non-normative, even though it uses terms
    like "must" (albeit non-capitalized). It might be good to say that explicitly,
    as readers may not notice the lack of capitals.
    
    -- section 2.1, req 38:
    
    Do you expect to keep "requirement removed" in the final RFC?
    
    -- ..., req 39:
    
    Which documents are you treating as authoritative for the purpose of this
    document, the ITU or IETF documents?
    
    -- req 52:
    
    The referenced requirement says it MUST be possible to require 100% of traffic
    on the protected path. "Up to 100%" is not the same thing
    
    -- req 95:
    
    Is that a requirement, or an observation?
    
    -- req 100:
    
    Is that a requirement, or an observation?
    
    -- req 101:
    
    Is that a requirement, or an observation?
    
    -- section 4.1.1: "Out-of-band, in-fiber"
    
    You are talking about any scenario using the same physical network, right? Is
    the concept limited to fiber in any way?
    
    -- section 4.1.1, last paragraph: "Some expect the G-ACh to be used
    extensively..."
    
    Who expects it? Can you say something more concrete?
    
    -- 4.1.5, 1st paragraph: "... it is deprecated, and must not be used for MPLS-
    TP."
    
    Do you mean that to be normative?
    
    -- 4.1.9, last paragraph: "Recovery for MPLS-TP LSPs as discussed in [TP-
    SURVIVE], is signaled..."
    
    Missing comma before "as"
    
    -- 4.2.1.1, list:
    
    Please use vertical white space between list entries
    
    -- 4.2.1.2
    
    There are lots of statements of the form "must be possible". Do you mean
    anything in this section to be normative?
    
    -- 4.4.1, last paragraph: "This work will serve as the foundation..."
    
    The referenced work, or this draft? (Similar question for 4.4.5)
    
    Also, there's an odd mid-sentence paragraph break here in the PDF version.
    
    -- 4.4.5
    
    This whole paragraph is very time sensitive, and asserts a number of things that
    may no longer be true at some point in the future.
    
    -- 5.3, 2nd paragraph: "See the table in the section above"
    
    Please give a section or table number cross reference.
    
    -- 5.3.2, third paragraph: "it may be required that bidirectional traffic
    follows congruent paths."
    
    "May be required" is pretty vague. Are you talking about requirements on the
    protocol as listed in this document, or something else? (who may require it?)
    
    === Julien ===
    
    *Minor Issues:* (leaving out acronym expansion or references to add 
    already highlighted by the AD)
    ----------
    Section 1.3
    Quoting Adrian (by the way: congratulations!): "A reference to 
    draft-ietf-mpls-tp-uni-nni might be appropriate to aid the discussion of 
    UNIs and NNIs." Indeed, but it requires more than a reference: since the 
    aforementioned I-D only defines "service interfaces", a little 
    elaboration on the use of "NNI" in draft-ietf-ccamp-mpls-tp-cp-framework 
    is needed.
    ----------
    Section 2.1
    Requirement 17 looks like a tautology. Requirement 19 in RFC 5654 
    clarifies the intend, but I am not sure it is needed here more than "A 
    control plane must not be required to support coffee making".
    
    Requirements 21 and 22 refers to "homogeneous" and "non homogeneous" 
    domains, but I do not think it is defined. Would my domain with all my 
    640 Mb/s switching capacity nodes be homogeneous?
    
    I believe requirement 24 also covers 27.C from RFC 5654.
    
    Requirement 39 mentions ASON: I thought the scope of ASON was 
    circuit-switched technologies, has it been extended for packet-switched?
    
    Requirement 62 states "this should be the default": I guess "this" 
    refers to bidirectional, but I believe the wording should be improved.
    
    Requirement 65 says "the control plane may support extra-traffic": not 
    sure what is means (extra traffic over the control network?).
    ----------
    Section 4.2.1
    It is consistent to section 2 of RFC 5951: an explicit reference could 
    be added, especially when considering the title of that RFC...
    ----------
    Section 4.3 and 5.2
    Not sure about the dashes following the numbers: should not they be in 
    the right column instead of the left one?
    
    It is a bit surprising to see explicitly "proper vendor implementation" 
    while it is should be implicit for any standard specification...
    ----------
    Section 5.3.2: "If the control plane is physically separated... 
    information".
    I do not believe this paragraph is needed here: no other section 
    mentions that sub-case (which might be in the scope of the ForCES WG).
    ----------
    Section 4.2.1 focuses on "Management Plane Support" within the "4. TE 
    LSPs" section. The same kind of paragraph is expected in the "5. 
    Pseudowires" section but is currently missing.
    ----------
    
    *Nits:*
    ----------
    Section 1.2
    s/over LSP based/over LSP-based/
    ----------
    Section 2.3
    s/customer/client/
    ----------
      Section 4.1.1
    s/control (and management) planes/control (and management) plane(s)/
    ----------
    Section 4.1.2
    s/and consequently, MPLS-TP uses/and consequently MPLS-TP, uses/
    s/control (and management) planes/control (and management) plane(s)/
    ----------
    Section 4.1.4.1 (interesting concepts)
    s/(PCE) Based approaches/(PCE)-based approaches/
    s/PCE requests and responses/requests to and responses from PCE/
    ----------
    Section 4.1.9
    s/LSPs as discussed in [TP-SURVIVE], is/LSPs, as discussed in 
    [TP-SURVIVE], is/
    ----------
    Section 4.2.1.2
    s/the life, (traffic hit/the life (traffic hit/
    ----------
    Section 4.4.4
    s/but nonetheless, must/but nonetheless must/
    ----------
    Section 4.4.5
    s/OAM related/OAM-related/ (twice)
    ----------
    Section 4.4.6
    s/Diffserv enable/Diffserv-enabled/transport
    s/Diffserv related/Diffserv-related/
    ----------
    Section 4.4.8
    s/entity related/entity-related/
    ----------
    Section 5.3.1
    s/to be, theoretically, a straightforward exercise/to be a 
    straightforward exercise/ (unless there is a strong reason to keep it 
    theoretical)
    ----------
    Section 5.3.5
    s/transport service require OAM/transport service requires OAM/
    s/performance related monitor/performance-related monitor/
    ----------
    Section 6
    s/MPLS and GMPLS related/MPLS- and GMPLS-related/
    ----------
    
  2. Russ Housley: Comment [2011-02-01]:
      Please consider the comments from the Gen-ART Review by Ben Campbell
      on 31-JAN-2011.  You can found the review at:
    
        http://www.softarmor.com/rai/temp-gen-art/
        draft-ietf-ccamp-mpls-tp-cp-framework-05-campbell.txt

draft-ietf-nsis-tunnel

  1. Adrian Farrel: Comment [2010-07-15]:
    Section 3.1
    
       The following definition of IP tunneling is derived from [RFC2473]
       and adapted for both IPv4 and IPv6.
    
    This is a bit odd given the existence of RFC 1853.
  2. Russ Housley: Comment [2010-06-28]:
      Pleae consider the editorial comments from the Gen-ART Review by
      Francis Dupont on 2010-06-15.  The review can be found at:
    
        http://www.softarmor.com/rai/temp-gen-art/
        draft-ietf-nsis-tunnel-11-dupont.txt
  3. Peter Saint-Andre: Comment [2010-06-28]:
    It appears that the following references might be normative, not informative:
    [RFC4080], [RFC2473], [RFC2113], [RFC2711], [RFC2746], [RFC3697], [RFC4081].
    Please consult http://www.ietf.org/iesg/statement/normative-informative.html for
    guidelines regarding the difference between normative and informative
    references, and consider whether some of the foregoing references would best be
    changed to normative.

draft-groves-eccsi

  1. Ralph Droms: Comment [2011-02-02]:
    A minor suggestion - it would help avoid confusion through
    interpretation of different textual descriptions in section 3 to
    take out the informal description of integer representation
    as an octet string and use just the pointer to [P1363].  The
    informal use of octet string might also be cleaned up a little
    to clarify that they are all indicating the use of the
    representation in [P1363].
  2. Lars Eggert: Discuss [2011-02-03]:
         DISCUSS: This is from the sec-dir review:
    
    > This document is unusual
    > for the IETF, in that it defines a new cryptographic algorithm, which
    > we normally don't do.  While there is no particular reason not to
    > publish it here, I would be wary of using this algorithm in any IETF
    > protocol until it has seen extensive review by the cryptographic
    > community.  It looks to me like it should work, but I am not a
    > cryptographer and may well have missed an obvious flaw.
    
     Do we need an IESG note on this document? It seems like an IETF
     last call doesn't really help much if we don't have the expertise in the
     community. Why is this being published via the IETF stream?
    
        
  3. Lars Eggert: Comment [2011-02-03]:
    It is the job of the *AD* to check conformance to idnits for AD-sponsored
    documents...
    
    INTRODUCTION, paragraph 10:
    > Copyright Notice
    
      Boilerplate is outdated for a -00 doc that was submitted Jun 2010.
    
    INTRODUCTION, paragraph 15:
    > Table of Contents
    
      The document seems to lack an IANA Considerations section.
    
  4. Russ Housley: Comment [2011-02-01]:
      Please consider the comments from the Gen-ART Review by Francis Dupont
      on 13-JAN-2011.  You can found the review at:
    
        http://www.softarmor.com/rai/temp-gen-art/
        draft-groves-eccsi-00-dupont.txt
  5. Alexey Melnikov: Comment [2011-02-03]:
    The "||" convention needs to be explained early in the document.
    
    SHA-256 needs a reference.
    
  6. Sean Turner: Discuss [2011-01-30]:
        This is an updated discuss position.  new #7 and tweaked #4.
    
    #1) Section 3.2: Has the following text:
    
      Points on E  Elliptic Curve Points MUST be represented in
                   Uncompressed representation ("affine coordinates")
                   as defined in Section 5.5.6 of [P1363a].  For an
                   elliptic curve point (x,y) with x and y in F_p,
                   this representation is given by 0x00 || x' || y' ,
                   where x' is the N-octet string representing x and
                   y' is the N-octet string representing y. 
    
    Please double check that it is in fact 0X00 || x' || y'.  RFC 5480, SECG SEC1,
    and ANSI use 0x04 not 0x00 to indicate that the key is uncompressed.  Also the
    P1363 draft I found on the web (I'm unsure whether it's final) says the
    following about uncompressed keys:
    
           In this representation, the octet PC shall have binary value 0000 0100
           and the octet strings X and Y shall represent x' and y' respectively. 
    
    #2) Section 3.2, 3.3, and 6, when writing RFC 5915 (Elliptic Curve Private Key
    Structure) somebody corrected my notation,  they suggested it needed to be
    "ceiling (log2(n)/8) where n is the order of the curve".  Do you need to specify
    in this draft whether "ceil(lg(p)/8)" it's log base 2 or 10 or something else (I
    assume it's base 2, but it's best to be explicit)?
    
    #3) Section 4.1 defines N as N = ceil(n/8) and section 3.2 defines it as N =
    ceil(lg(p)/8).  Would it be better to define one as something else?  Or does
    ceil(n/8) = ceil(lg(p)/8)?
    
    #3) I understand that this draft is intended to be used with the other two
    draft-groves-* documents on this weeks IESG telechat, but for interoperability
    sake (no pun intended) can you state at the end of Section 2 where in the other
    two drafts we can find the points that this draft "does not specify (but
    comments on)" to ensure implementors can get interoperability?  I'm thinking
    something like:
    
    When used with draft-groves-sakke and draft-grove-mikey-sakke, this information
    can be found ...
    
    And, then add an informative reference to draft-grove-mikey-sakke.
    
    #4) The introductory text in Appendix A needs to say that it uses SHA-256 and I
    think you need to add a reference to FIPS 186-3.  I noted in the other drafts
    you referred to FIPS 180-2 any reason this can't point to -3?
    
    #5) (not a cryptographer ;) Section 3.1, based on:
    
       All elliptic curve points will be defined over F_p. 
    
    That means this won't work over F_2^M (characteristic 2 finite fields)?  Is it
    worth noting that p = q in Section 4.1 or is that assumed because it's only over
    finite fields?
    
    #6) Section 3.1, is the equation for the curve: y^2= x^3-3x+B(modulo p) (see
    Section D.1 of FIPS 186-3)?
    
    #7) Needs an IANA considerations section. 
        
  7. Sean Turner: Comment [2011-01-30]:
    #1) Is it Identifier-Based Encryption or Identity-Based Encryption?  RFC 5091
    indicates it's the latter.
    
    #2) In section 3.2, there are two references to P1363.  Is there any chance we
    could change the reference for the integer-to-octet-string conversion in
    http://datatracker.ietf.org/doc/draft-mcgrew-fundamental-ecc/ (this one is about
    to be published shortly as an RFC) and RFC 5480 for the uncompressed key info?
    
    #3) In the penultimate paragraph in Section 7, please add an informative
    reference to RFC 4086 for random requirements when generating random values (we
    make everybody point to this RFC when it generates random #s).
    
    

draft-groves-mikey-sakke

  1. Gonzalo Camarillo: Comment [2011-02-03]:
    Abstract: this document mentions this key exchange method is used in the IMS. It
    may be good to repeat the statement in the Introduction adding a reference to an
    IMS-reated 3GPP spec.
    
    TGK is not expanded in the text.
  2. Lars Eggert: Comment [2011-02-03]:
    It is the job of the *AD* to check conformance to idnits for AD-sponsored
    documents...
    
    INTRODUCTION, paragraph 10:
    > Copyright Notice
    
     Boilerplate is outdated for a -00 doc that was submitted Jun 2010.
    
    INTRODUCTION, paragraph 15:
    > Table of Contents
    
     The document seems to lack an IANA Considerations section.
    
  3. Adrian Farrel: Discuss [2011-02-03]:
        No issue with this document, but a couple of matters of process to be sorted
    out, I think.
    
    ---
    
    Figure 1 uses some form of syntax that isn't defined in this document.
    Please insert a reference to the document that defines the syntax.
    
    ---
    
    Section 3.2
    
    There is an example phone number +441234567890
    This doesn't look like a "standard" example phone number to me. 
        
  4. Adrian Farrel: Comment [2011-02-03]:
    I am not sure that I would necessarily describe "support for lawful 
    interception" as a "desirable feature".
    
    ---
    
    Would be nice to run idnits and tidy the document up.
    
  5. Russ Housley: Comment [2011-02-01]:
      Please consider the editorial comments  from the Gen-ART Review by
      Avshalom Houri on 19-JAN-2011.  You can found the review at:
    
        http://www.softarmor.com/rai/temp-gen-art/
        draft-groves-mikey-sakke-00-houri.txt
  6. Robert Sparks: Discuss [2011-02-02]:
        1) (This is mostly a question for the sponsoring AD for telechat discussion, but
    anyone is welcome to reply). Is this intended to be an IETF consensus document?
    What boilerplate are you targeting?
    
    2) This document is registering a mikey mode. Does it need to mention Lawful
    Intercept (see RFC2804)? Is it necessary for it to discuss forking, retargeting,
    and deferred delivery as part of registering the mode? These things need to be
    discussed somewhere, but is this the right document? 
        
  7. Sean Turner: Discuss [2011-01-31]:
        #1) Needs an IANA section.  Basically, it needs to point to Section 4 to say
    you're registering X # of new items for MIKEY.
    
    #2) Section 3.2 indicates that:
    
       Further Identifier
       schemes MAY be defined for communities that require different key
       longevity. 
    
    Is there some type of registry needed for the different identifiers? I.e., would
    somebody that wanted to do bi-weekly updates need new registry entries in
    Section 4?  For example should it be SAKKE - Monthly so when people decide to do
    it biweekly it'd be SAKKE- Bi Weekly? 
        
  8. Sean Turner: Comment [2011-01-30]:
    #1) Abstract:
    
    The acronym IDPKC doesn't match the capitalized letters in
    its expansion.  Suggestion: s/Identifier-based Public Key
    Cryptography/Identifier-Based Public Key Cryptography/
    
    Please expand IMS.
    
    #2) Is it Identifier-Based Encryption or Identity-Based Encryption?  RFC 5091
    indicates it's the latter.
    
    #3) Any reason this can't reference FIPS 180-3?
    
    #4) In section 1, paragraph 2, s/legislation/legislations/.
    
    #5) In the title of section 2, s/Mode;/Mode:/.
    
    #6) In section 2.1, paragraph 1, the acronym "TGK" is not expanded on first use.

draft-groves-sakke

  1. Lars Eggert: Discuss [2011-02-03]:
        Section 3.2., paragraph 3:
    >    We provide pseudocode for computing <R,Q>
    
      DISCUSS: Pseudocode does not contain the needed license statement for
      the IETF Trust.
    
    Section 7., paragraph 4:
    >          Table 1: Comparable strengths, taken from Table 2 of [SP800-57]
    
      DISCUSS: Missing reference to [SP800-57], and it appears to be
      normative.
     
        
  2. Lars Eggert: Comment [2011-02-03]:
    It is the job of the *AD* to check conformance to idnits for AD-sponsored
    documents...
    
    INTRODUCTION, paragraph 10:
    > Copyright Notice
    
      Boilerplate is outdated for a -00 doc that was submitted Jun 2010.
    
    INTRODUCTION, paragraph 15:
    > Table of Contents
    
      The document seems to lack an IANA Considerations section.
    
  3. Russ Housley: Discuss [2011-02-01]:
        
      The Gen-ART Review by Richard Barnes on 4-Jan-2010 raises some issues
      regarding integration of this algorithm into a protocol.  Please tell
      the reader:
    
        -  Which parameters are constant for the whole algorithm
        -  Which parameters are expected to be set out of band for a given
           implementation
        -  Which parameters need be negotiated in the protocol
    
      For example, the algorithm uses a hash function and an elliptic curve,
      but it is not clear how the communicating parties agree on them.
    
      If this document is extending RFC 5091, then it should formally update
      it (as in, with a line at the top), and explain in more detail its
      relation to RFC 5091. 
        
  4. Russ Housley: Comment [2011-02-01]:
      Please consider the comments from the Gen-ART Review by
      Richard Barnes on 4-Jan-2010.  You can found the review at:
    
        http://www.softarmor.com/rai/temp-gen-art/
        draft-groves-sakke-00-barnes.txt
  5. Dan Romascanu: Comment [2011-02-03]:
    The following non-blocking comment made by Mike Sneed in his OPS-DIR review is
    worth being considered:
    
    > The draft is intended for Informational status. The scope is limited to
    description of the encryption algorithm and the key establishment algorithm.  As
    the document is intended for Informational status, and is limited to describing
    an algorithm,  there are no operational issues to be addressed.  However, there
    are significant operational issues involved in the deployment of Identifier-
    Based encryption, eg.  KMS key  management,  which would certainly need to be
    addressed if this algorithm were to be incorporated into a working system.
  6. Sean Turner: Discuss [2011-01-31]:
        
    #1) Section 4: Has the following text:
    
      Points on E  Elliptic Curve Points MUST be represented in
                       Uncompressed representation as defined in Section
                       5.5.6 of [P1363a].  For an elliptic curve point (
                       x , y ) with x and y in F_p, this representation
                       is given by 0x00 || x' || y' , where x' is the
                       octet string representing x, y' is the octet
                       string representing y and 0x00 is a NULL octet. 
                       The representation is 2*L+1 octets in length.
    
    Please double check that it is in fact 0X00 || x' || y'.  RFC 5480, SECG SEC1,
    and ANSI use 0x04 not 0x00 to indicate that the key is uncompressed.  Also the
    P1363 draft I found on the web (I'm unsure whether it's final) says the
    following about uncompressed keys:
    
           In this representation, the octet PC shall have binary value 0000 0100
           and the octet strings X and Y shall represent x' and y' respectively. 
    
    #2) When specifying lg, specify the base log2, log10 etc.
    
    #3) Section 4, when defining integer the text is missing the text from groves-
    eccsi:
    
      There will
      be no need to represent negative integers.  When
      transmitted or hashed, such octet strings MUST
      have length N = ceil(lg(p)/8). 
    
    should it be added?
    
    #4) The introductory text in Appendix A needs to say that it uses SHA-256 and I
    think you need to add a reference to FIPS 180-3.
    
    #5) Needs an IANA section.  Even if there's no actions, it needs one. 
        
  7. Sean Turner: Comment [2011-01-30]:
    #1) RFC 5091 indicates it's identity based encryption not identifier based
    encryption.
    
    #2) Section 2.1: E: equation is groves-eccsi is y^2 = x^3 - 3 * B vice y^2 = x^3
    - 3 * x.  Can't we use the same notation?  Also isn't (modulo p) missing?
    
    #3) Notation for ceiling is different than in groves-essci.  There it is ceil()
    here it is Ceiling().
    
    #4) In section 4, there are two references to P1363.  Is there any chance we
    could change the reference for the integer-to-octet-string conversion in
    http://datatracker.ietf.org/doc/draft-mcgrew-fundamental-ecc/ (this one is about
    to be published shortly as an RFC) and RFC 5480 for the uncompressed key info?
    
    #5) In the last paragraph in Section 7, please add an informative reference to
    RFC 4086 for random requirements when generating random values (we make
    everybody point to this RFC when it generates random #s).

draft-turner-sha0-sha1-seccon

  1. Adrian Farrel: Discuss [2011-02-02]:
        Section 4, "Guidance" seems stronger than I expect in an Informational
    I-D. Not only does it tell protocol designers what they "must" and
    "should" do, but it also refers to this document as a "specification".
    
    I know you would like to set some hard rules, and they are possibly
    necessary, but this is not the way to do it. Either tone down the
    language, or bring this guidance back as standards track.
     
        
  2. Adrian Farrel: Comment [2011-02-02]:
    The first paragraph of Section 1 mentions the SHA-1 and SHA-2 family.
    It then
    goes on to say that SHA-0 and SHA-1 are message digest
    algorithms, but there is
    no further mention of SHA-2. I find that to be 
    a bit of a tease.
    ---
    
    "HMAC" is used unexpanded.
  3. Dan Romascanu: Comment [2011-02-03]:
    I support Adrian's DISCUSS. Reading the recommendations section and the
    supporting justification I rather have the feeling that the recommendations need
    to be 2119 capitalized and the document should be either standards track or BCP.

draft-irtf-rrg-design-goals

draft-irtf-dtnrg-sdnv

draft-irtf-dtnrg-cbhe

draft-irtf-dtnrg-bundle-metadata-block

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

draft-irtf-dtnrg-iana-bp-registries