IESG Narrative Minutes

Narrative Minutes of the IESG Teleconference on 2011-11-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: Pete, John

1 Administrivia

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

2. Protocol Actions

2.1 WG Submissions

2.1.1 New Items

  1. TCP Candidates with Interactive Connectivity Establishment (ICE) (Proposed Standard)
    draft-ietf-mmusic-ice-tcp-15
    Token: Gonzalo Camarillo
    Note: Flemming Andreasen (fandreas@cisco.com) is the document shepherd.
    IPR: Cisco's Statement about IPR claimed in draft-ietf-mmusic-ice-tcp-02
    Discusses/comments (from ballot 2320):
    1. Adrian Farrel: Comment [2011-11-02]:
      Section 1
      "However, ICE only defines procedures for UDP-based transport protocols."
      I think "UDP-based transport protocols" is wrong since UDP *is* a transport protocol. 5245 talks about "UDP-based media streams" and "UDP".
    2. Stephen Farrell: Discuss [2011-10-30]:
      Why is it that "RTP over TLS MUST NOT be used" (end of p10) and why is this specification dictating that to other specifications that might want to make use of ICE? There may be good reasons for that but they're not explained and
      a) I wonder:-) and
      b) dictating what other specs using this one can and cannot do seems like it might be a bit wrong.
      I guess the obvious change could be to explain why this MUST NOT needs to be present, or to remove it, depending.
    3. Stephen Farrell: Comment [2011-10-30]:
      - on page 3, 2nd last para where it talks about "one of the agents" it might be clearer to say "one of the agents (the offerer)"
      - lack of ICE-clue means I didn't get the last para of p5; probably just me but maybe take a look and see if you can make it easier on the ICE-impaired?
      - the last para of section 3 was unexpected - would it be better elsewhere? Such as after initial offers are explained?
      - in 4.1 would s/highly receommended/highly RECOMMENDED/ be better 2119-wise?
      - 4.1 last para, be good to reference the section of whatever RFC defines Ta (5245 section 16 I guess) - when I searched RFC 5389 I didn't find the string " Ta " which confused me.
      - end of 4.3 talks about a "passive" attribute value but the ABNF in 4.5 uses abbreviations "act", "pass" and "so." Why the inconsistency? "Pass" might also be confusing (e.g. vs. "fail"). Maybe saving those few bytes isn't worth it?
      - 5.2: "Server reflexive active candidates can be derived from passive or S-O candidates by using the same IP address as a passive or S-O server reflexive candidate from the same interface has." Seems like a broken sentence.
      - 7.2 Is "on the base of any TCP candidate" going to be clear to readers? Its not that clear to me but then I'm not familiar with ICE really, so it might just be me.
      - I guess I wonder how common STUN shared secrets are in the wild. Is this really a practical mitigation? Would it make sense to note this and to say that appication layer security ought be used since its unlikely one can really ensure that there is no bad actor involved if using ICE? (This isn't a DISCUSS on the basis, that you're probably hosed or don't care without that application layer security but I guess a lot of media applications understand this nowadays.)
      - Section 12 typo: s/Same considerations apply/The same considerations apply/
    4. Russ Housley: Discuss [2011-11-01]:
      Based on the response from the authors to the Gen-ART Review by Vijay Gurbani on 31-Oct-2011, I am expecting to see updates for Section 1 and Section 4.1.
    5. Robert Sparks: Comment [2011-11-01]:
      Are you sure we can't get consent to publish this without the pre5378 boilerplate?
      On page 17, the sentence "STUN is never run within the TLS or DTLS-SRTP session." is too strong. STUN may not occur within those sessions because of ICE, but some application that's using that candidate later may have a reason to run STUN there. I suggest adding "as part of the ICE procedures" to the end of that sentence.
    6. Sean Turner: Comment [2011-11-01]:
      I support Stephen's discuss.

    Telechat:

  2. RTP Payload Format for Raptor FEC (Proposed Standard)
    draft-ietf-fecframe-rtp-raptor-05
    Token: David Harrington
    Note: Greg Shepherd (gjshep@gmail.com) is the document shepherd.
    Discusses/comments (from ballot 3751):
    1. Gonzalo Camarillo: Comment [2011-11-03]:
      I support Robert's discuss and comment.
    2. Stephen Farrell: Discuss [2011-10-30]:
      (1) It isn't clear to me how the source and repair packets are correlated so the recipient can tell what to do and the sender knows what to send. Probably just my ignorance but where is that specified? (I only spent a few minutes looking so expect I'll clear once shown what I didn't find as easily as I thought I would.)
      (2) cleared - we've scheduled a chat about draft-ietf-avt-srtp-not-mandatory for Taipei.
    3. Stephen Farrell: Comment [2011-10-30]:
      - fecframework is now RFC6363 (I actually followed the reference given so the wrong reference might have but didn't mislead)
    4. Russ Housley: Comment [2011-10-30]:
      The Gen-ART Review by Brian Carpenter on 30-Oct-2011 suggests some editorial changes. Please consider them.
      Typo in page header title. It says: RTP Payload Fromat for Raptor
      s/Fromat/Format/
      There are several places where an upper-case MAY is used where a plain English lower case "may" would be fine:
      - all three MAYs in the Introduction;
      - the first sentence of section 3; and
      - all three MAYs in the last paragraph of the Security Conisderations.
    5. Pete Resnick: Discuss [2011-10-29]:
      1. It does not appear that section 5.1 of RFC 4288 was followed:
      "Notice of a potential media type registration in the standards tree MUST be sent to the "ietf-types@iana.org" mailing list for review. This mailing list has been established for the purpose of reviewing proposed media and access types. Registrations in other trees MAY be sent to the list for review as well."
      2. I'm concerned about putting 2119 language (and implementation instructions of any sort) into the registration template itself. For example, each of the templates has a definition of rate which says:
      "o rate: The RTP timestamp (clock) rate. The operator SHALL select a rate larger than 1000 Hz to provide sufficient resolution to RTCP operations and the operator SHOULD select the rate that matches the rate of the protected source RTP stream."
      Selecting an appropriate rate seems like protocol instruction, not a suitable thing to put in a registration. It seems exceedingly odd to put protocol instructions into the definition of the parameter name.
    6. Pete Resnick: Comment [2011-10-29]:
      A bunch of comments on 2119 usage: ...
    7. Robert Sparks: Discuss [2011-11-02]:
      (Based on earlier feedback from Colin Perkins that does not appear to be addressed yet)
      <http://www.ietf.org/mail-archive/web/fecframe/current/msg00756.html> Section 4.1 should explain how the RTP payload type is chosen (dynamic assignment) and signalled using SDP. It should also discuss how the SSRC is assigned, and how the repair RTP session is associated with the source RTP session using RTCP.
      The "Applications that use this media type" sections of the media type registrations need to be populated.
    8. Robert Sparks: Comment [2011-11-02]:
      While it's not a hard requirement at the moment, I think it would help the quality of RTP payload documents to run them through as PAYLOAD working group items. Please consider taking that approach with future payload format specifications.
    9. Sean Turner: Discuss [2011-11-01]:
      This ought to be easy enough to fix up:
      s6.*.1 doesn't specify the format for rate and repair-window. I assume they're both decimal, but I'm only guessing (and that's bad).

    Telechat:

  3. Supporting Authentication Trailer for OSPFv3 (Proposed Standard)
    draft-ietf-ospf-auth-trailer-ospfv3-09
    Token: Stewart Bryant
    Note: Abhay Roy (akr@cisco.com) is the document shepherd.
    Discusses/comments (from ballot 3843):
    1. Ralph Droms: Comment [2011-10-29]:
      Two comments about this text from section 4.1.1:
      4.1.1. Sequence Number Wrap: "When incrementing the sequence number for each transmitted OSPFv3 packet, the sequence number should be treated as an unsigned 64-bit value. If the lower order 32-bit value wraps, the high order 64-bit value should be saved in non-volatile storage. [...] Once the keys have been changes, the higher order sequence number can be reset to 0 and saved to non-volatile storage."
      * I don't understand the second sentence.
      * s/changes/changed/
      I apologize if I'm missing something obvious: where is the format of the SA ID defined?
    2. Adrian Farrel: Comment [2011-11-01]:
      These issues do not rate a Discuss because they are not central to the document, but I wish you would sort them out.
      Abstract:
      This is just about to become an RFC. Please change:
      s/draft/document/
      s/proposes/defines/
      Similar in the Introduction
      I am disappointed by the following paragraph in the Introduction.
      "However, there are some environments, e.g., Mobile Ad-hoc Networks (MANETs), where IPsec is difficult to configure and maintain, and this mechanism cannot be used. There is also an issue with IPsec not being available on some platforms."
      It would make a lot of sense to give a citation for the assertion or take the time to explain the problems with IPsec so that we can evaluate why the solution in this document is better.
      I also think that the lack of availability of IPsec on some platforms is not relevant. After all, *no* platforms support the features described in this document.
      Section 1.1: Please remove
      "When used in lowercase, these words convey their typical use in common language, and are not to be interpreted as described in RFC2119 [RFC2119]."
      Figure 1:
      The text does not describe the figure, and the caption does not correctly indicate the content of the figure.
      Section 2.1:
      "OSPFv3 routers MUST set the AT-bit in
      "OSPFv3 Hello and Database Description packets to indicate that the
      "OSPFv3 router will include the authentication trailer in all OSPFv3 packets on the link."
      I find this ambiguous because I read left to right. Thus I read: "OSPFv3 routers MUST set the AT-bit in OSPFv3 Hello and Database Description packets"
      Could you flip the order of words?
      Section 2.1:
      I see no value and possible minor downside to the inclusion of the figure that shows the list of existing OSPFv3 options. This list is maintained by IANA, and including it here creates potential conflict etc.
      Additionally, you need to consider whether this section is mandating that bit 13 is used as the AF-bit. It is sort of implied, but the IANA section doesn't quite make this clear, and there is no cross-reference between the two sections.
      Section 2.2:
      s/much same as/much the same as/
      Section 3:
      "In the event that the last key associated with an interface expires, it is unacceptable to revert to an unauthenticated condition, and not advisable to disrupt routing. Therefore, the router should send a "last Authentication Key expiration" notification to the network manager and treat the key as having an infinite lifetime until the lifetime is extended, the key is deleted by network management, or a new key is configured"
      I really tnk that both sentences need RFC 2119 language.
      Section 5: "In general, all OSPFv3 routers participating on a link should be migrated to OSPFv3 Authentication at the same time."
      What does this mean?!
    3. Stephen Farrell: Comment [2011-10-24]:
      (Thanks for persevering with the overlong discussion of cross-protocol attacks back in August:-)
      - abstract: maybe s/not depend/not only depend/?
      - section 2, 1st para: maybe s/as, the/as the/ and s/trailer/trailer,/
      - last sentence of section 2.1 - would s/must/MUST/ be better here?
      - Does 2.1 mean that if the AT bit is set in the Hello or Database description packets then it MUST be set in all subsequent packets until lt;sometime>? When is lt;sometime>? This may be my ignorance of OSPF but "is preserved" isn't clear to me - it may be entirely clear to OSPF experts though. Or maybe a forward reference to 4.5 and section 5 would be good. Not sure.
      - end of section 3 is missing a full stop.
      - I wasn't clear on whether or not you're requiring all coders to support the key lifecycle scheme in section 3. The "MUST" in the 2nd last paragraph sort-of seems to make it so, but being explicit would be better I think.
      - section 4.1 s/length in octet/length in octets/
      - Just checking - in 4.2 if a sender ignores the SHOULD and sets the header checksum, and inputs that (non-zero value) to AT calculation, is a receiver supposed to ignore that or barf the packet? (I assume it ignores it if all else is ok?) Might be no harm to be explicit about that.
      - Maybe s/password/authentication key/ in section 6.
      - I'd suggest you encourage deployments to use long random values for the authentication key - while they could use the string "password," that'd seem like a waste;-) Maybe the following text might work:
      "Deployments SHOULD use sufficiently long and random values for the authentication key so that guessing and other cryptographic attacks on the key are infeasible in their environment."
      If you wanted to RECOMMEND those be at least 128 good pseudo-random bits that'd be even better. You might also want to encourage implementers to accept ascii-hex input or something to avoid potential I18N issues with typed values.
    4. Russ Housley: Discuss [2011-11-02]:
      S4.6: when replay is detected, the OSPFv3 packet MUST be dropped.
      When authentication fails, the OSPFv3 packet MUST be discarded and an error event SHOULD be logged.
      Why are these handled differently?
    5. Russ Housley: Comment [2011-11-02]:
      S1, para 1: please add a sentence that explains that AH and ESP are part of IPsec. Otherwise, the claim that IPsec does not work well in certain environments has no linkage to the text about AH and ESP.
      S4.5, step 1: to me, it would be more clear to say: "In this application, Ko is always L octets long, and it is computed as follows:"
      S4.6: please add a paragraph to the end that says the cryptographic sequence number is saved for future replay checks now that all of the checks have been successful.
    6. Dan Romascanu: Discuss [2011-11-01]:
      The DISCUSS is based on comments made by Joel Jaegli in his OPS-DIR review.
      1. In Section 5, the first sentence - "In general, all OSPFv3 routers participating on a link should be migrated to OSPFv3 Authentication at the same time."
      I would rather make this recommendation in a crisper manner by dropping 'In general' and capitalizing SHOULD
      All OSPFv3 routers participating on a link SHOULD be migrated to OSPFv3 Authentication at the same time.
      2. It would be worth mentioning that unlike other potential or implemented extensions to ospfv3 e.g. rfc 5838 downward/backward compatibility isn't feasible to implement, either you support this extension or you do not. The approach described in section 5 while possible in some environments implies the simultanious operation of protected and un-protected ospf on the same devices.
      3. also in section 5: "An implementation MAY have a transition mode where it includes the Authentication Trailer in the packets but does not verify this information. This is provided as a transition aid for networks in the process of migrating to the mechanism described in this draft."
      should be noted that this entails risk that something that is thought to be working is in fact not and that it will fail when enabled
    7. Dan Romascanu: Comment [2011-11-01]:
      1. section 4.1: "OSPFv3 routers implementing this specification SHOULD use available mechanisms to preserve the sequence number's strictly increasing property for the deployed life of the OSPFv3 router (including cold restarts). Techniques such as sequence number space partitioning and non-volatile storage preservation can be used but are beyond the scope of this specification."
      While there are certainly ways to produce such a number that do not incur the saving of state (number of miliseconds since the epoc would be a good initialization value, requires an accurate clock before an adjacency is formed). This is a rather strong requirement. e.g. it implies preserving ephemeral state across hardware replacement. Probably more implementation advice is required.
      2. section 6.
      The assertion that this offers more security than 5340 essentially hinges on the ability to offer replay protection. it does essentially abandon the use of ipsec for ospf protection and in doing so means theirs three ways to deploy ospfv3 (no security, ipsec wrapped, auth trailer) assuming the later ends up being preferred to ipsec there likely will be a protracted period where 2 methods are required on given network, which has potentially interesting routing considerations. The final assessment in the section about 'not causing undue implementation, deployment, or operational complexity' may not always be true.
    8. Sean Turner: Discuss [2011-11-01]:
      #1) s3, s4.1, s4.3: So these might just be typos, but I'm trying to make sure something sinister isn't going on :)
      s3 The "Authentication Algorithm" bullet indicates authentication algorithm id isn't sent on the wire.
      s3 The SA ID bullet indicates that "Each SA ID specifies two independent parts, the authentication protocol and the authentication key, as explained below."
      s4.1 SA ID indicates that it "identifies the algorithm and the secret key".
      s4.3 indicates "As noted earlier, the SA ID implicitly specifies the algorithms used to generate and verify the message digest."
      I assume authentication protocol and authentication algorithm are supposed to be different? So should s4.1 be "identifies the authentication protocol and the secret key"? If they're different the statement in s4.3 doesn't make sense because it would only imply the authentication protocol not the algorithm. Maybe authentication protocol and authentication algorithm are supposed to be the same thing!?
      #2) Implicit algorithm identification:
      NIST has done some funny things in draft FIPS 180-4. They defined SHA-512/224 and SHA-512/256 that are optimized for 64-bit OSes. They output size for SHA-512/224 is the same as SHA-224 and the output size for SHA-512/256 is the same as SHA-256. Who really knows what they're going to do with the SHA-3 options, but what I heard at IETF 81 (from Tim Polk at SAAG) is that the winners are going to also end up using the same output sizes to allow them to be more easily be dropped in existing protocols. This doesn't even take in to account somebody else coming up with the greatest hash algorithm ever that also has the same output lengths as SHA-*. The way you've got it set up another algorithm can't be implicitly identified that that has the same output sizes as what you've defined.
      I think it is really, really short sighted to use implicitly algorithm selection. Was explicit algorithm discussed in the WG?
    9. Sean Turner: Comment [2011-11-01]:
      #1) s1: Mentioned AH in the 1st paragraph but don't say anything about why it's not viable.
      #2) s1: RFC 6234 obsoleted RFC 4634 so please update the reference.
      #3) s4.1/s7: Auth Type 1 - Maybe make it HMAC Cryptographic Authentication. Cryptograph Authentication is pretty darn generic. It would be nice if you maybe indicated the mechanism - i.e., HMAC.
      #4) s4.2: Had the same question Stephen did.
      #5) s4.6: Need to add a pointer back to s4.5 in the last paragraph for the verification algorithm.
      #6) s6: Isn't it more secure than 5430 but only when IPsec isn't used?
      #7) s6: Need some motherhood and apple pie info about issues with manual keying, or you could point to RFC 4552 for manual keying security considerations. Also, is there someplace you could point to a statement like: keep the private key private, when manually exchanging the key do it securely, etc.?

    Telechat:

  4. Dynamic Prefix Allocation for NEMOv4 (Proposed Standard)
    draft-ietf-mip4-nemov4-dynamic-05
    Token: Jari Arkko
    Note: Pete McCann (mccap@petoni.org) is the document shepherd.
    IPR: Motorola's Statement about IPR related to draft-ietf-mip4-nemov4-dynamic-02.txt
    IPR: Cisco's Statement of IPR Related to draft-ietf-mip4-nemov4-dynamic-05
    Discusses/comments (from ballot 3872):
    1. Ralph Droms: Discuss [2011-10-29]:
      I understand the basic idea specified in this document. However, I have some questions about the details that I think need to be discussed before the document can be published.
      1. From section 3.1: "[RFC5177] defines that the prefix field of the mobile network request extension can not be set to zero. This mechanism works only in combination with the explicit mode of operation defined in [RFC5177]."
      However, I can't find the text in RFC 5177 that explicitly requires that the prefix field can not be set to zero. Am I missing something?
      2. The reason I looked in RFC 5177 for the constraint on the prefix field was to see if perhaps this document should be noted as updating RFC 5177. Specifically, if RFC 5177 has text to the effect of "the Prefix field of the Mobile Network Acknowledgement Extension MUST NOT be set to zero," I would ask that the WG consider noting that draft-ietf-mip4-nemov4-dynamic updates RFC 5177.
      Even if there is no such text in RFC 5177, I think the WG should consider whether draft-ietf-mip4-nemov4-dynamic updates RFC 5177, as the former document is assigning new semantics to specific values in the Mobile Network extension.
      3. The behavior of the Mobile Client may be underspecified in section 3.1. Specifically, the behavior of the Mobile Client seems to be unchanged from the behavior specified in RFC 5177. How does the Mobile Client differentiate between Mobile Network Acknowledgment extensions sent in response to an Explicit Mode Mobile Network registration and a Mobile Network dynamic prefix request? Perhaps it's not necessary to differentiate the two cases or a Mobile Client won't perform both operations simultaneously?
      A related question: is it possible for the Mobile Client to send more than one Mobile Network dynamic prefix request; if so, is it possible for the Home Agent to allocate a prefix for some requests while declining others?
    2. Russ Housley: Comment [2011-10-30]:
      The Gen-ART Review by Vijay Gurbani on 28-Oct-2011 includes two suggestions for improved clarity. Please consider them.
      S3.1: "According to this specification ...", I am not sure what "this" refers to. Does it refer to draft-ietf-mip4-nemov4-dynamic or does it, instead, refer to rfc5177 (which is the topic of discussion in the previous paragraph from where the above is quoted)?
      S3.2, third paragraph: s/a prefix it MUST/a prefix, it MUST/
    3. Sean Turner: Comment [2011-10-31]:
      I had the same question as Ralph did about whether this draft updates RFC 5177 (glad he beat me to the discuss).

    Telechat:

  5. Pseudowire Status for Static Pseudowires (Proposed Standard)
    draft-ietf-pwe3-static-pw-status-09
    Token: Stewart Bryant
    Note: Andy Malis (amalis@gmail.com) is the document shepherd.
    Discusses/comments (from ballot 3894):
    1. Jari Arkko: Comment [2011-11-03]:
      Ari Keränen helped me review this specification and he too was concerned about Section 5.3 (PW OAM status message transmit and receive):
      [...] the PW OAM message containing the PW status TLV needs to be transmitted repeatedly to ensure reliable message delivery. [...]
      A PW OAM message containing a PW status TLV with a new status bit set or reset, will be transmitted immediately by the PE. The PW OAM message will then be repeated twice more at an initial interval of one second.
      The message is always sent 3 times during the first 3 seconds? How about ACKs?
    2. Wesley Eddy: Comment [2011-11-02]:
      I support Russ's DISCUSS.
    3. Adrian Farrel: Discuss [2011-11-01]:
      I had real problems with Section 4.
      - The mention of MPLS and MPLS-TP is curious since MPLS-TP is just a subset of MPLS.
      - The text doesn't give a reason for the MUST and MUST NOT
      - There is no reference to RFC 6310 which is really the justification for this work.
      - I really do not think you are updating RFC 5885. If anything, you are updating RFC 6310 that says:
      "Additionally, such a PE MAY use VCCV-BFD CV for both fault detection and status notification (CV types 0x08 and 0x20 [RFC5885])."
      But, frankly, I don't think this is much of an update that is worth mentioning.
      Here is a shot at updating the text. If you like this, you will need to remove the "updates RFC 5885" stuff from the rest of the document.
      OLD: "The procedures described in this draft are intended for the case where PWs are statically configured. These procedures also apply equally to both an Multi Protocol Label Switched Packet Switched Network (MPLS PSN), and an Multi Protocol Label Switched Transport Profile (MPLS-TP) PSN. Where an LDP control plane exists, LDP MUST be used for signaling all PW status messages. However the OPTIONAL 'S-PE' bypass mode described below MAY be used in the presence of an LDP control plane."
      This document updates [RFC5885] as follows: "When BFD is used, and the Pseudowire Status protocol for Static Pseudowires described in this document is used BFD MUST NOT be used to convey PW status signaling information (CV Types 0x08 and 0x20 MUST NOT be used)."
      NEW: "As described in [RFC6310], a PE that establishes an MPLS PW using means other than LDP, e.g., by static configuration or by use of BGP, MUST support some alternative method of status reporting. The procedures described in this document are for use when PWs are statically configured and a LDP control plane is not available.
      "As defined in [RFC6310], a PE that establishes a PW using LDP and that has negotiated use of the LDP status TLV per Section 5.4.3 of [RFC4447], MUST use the PW status TLV mechanism for AC and PW status and defect notification on that PW. In order to avoid duplicate notifications and potentially conflicting notifications, such PEs MUST NOT use the mechanisms described in this document for those PWs, except that the 'S-PE' bypass mode described in Section 5.5 MAY be used in all situations.
      "A PE that establishes a PW using LDP and does not negotiate the use of the LDP status TLV, MAY use the mechanisms described in this document.
      "In order to protect against duplicate notifications and potentially conflicting notifications, when the Pseudowire Status protocol for Static Pseudowires described in this document is used, the BFD-VCCV status signaling mechanisms described in [RFC5885] (CV Types 0x08 and 0x20) MUST NOT be used. VCCV-BFD Connectivity Verification (CV) for fault detection (CV types 0x04 and 0x10) MAY still be used."
      END
      Section 5.1: Don't you need to create an IANA registry for the Flags field in the ACH PW OAM Message Packet Header?
      Section 5.1 needs to state which TLVs can be present. The first paragraph of the section implies that only the PW status TLV is present.
      Section 5.2: "The PW Status TLV format as defined in [RFC4447], and is repeated here for the reader's convenience:"
          0                   1                   2                   3
          0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |Res|     PW Status (0x096A)    |            Length             |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |                          Status Code                          |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                   Figure 2: PW Status Message Format.
      
      So, is this the TLV format or the message format?
      Section 5.2: "To clear a particular status indication, the PE needs to send a new PW OAM message containing a PW Status TLV with the corresponding bit cleared."
      This would be fine if there had been any mention of "corresponding bits" up to this point (or indeed at any other point) in the document. All I can find is an identical statement in Seciton 5.3.
      Please clarify how a status indication is cleared.
      Section 5.2: "PW OAM Status Messages MUST NOT be also used as a connectivity verification method."
      Strike "also" because they must not be used, period. And I support that, but you need to say what you would do if you sent a status message and did not receive a message with the A flag set.
      Section 5.3: There is no discussion of how to handle the refresh timer value when the A flag is set as introduced in Section 5.1.
      Section 5.3.1: "The PE receiving a PW OAM message containing a PW status message can acknowledge the PW status message by simply building an almost identical reply packet with the A bit set, and transmitting it on the PW ACH back to the source of the PW status message."
      "can" is not an RFC 2119 word, so I am unclear what an implementation is supposed to do. There is no perceptable benefit for sending an ack as far as I can see since there is no described behavior if an ack is not received.
      Furthermore, in Section 5.3 we have a statement that under some circumstances an Ack MUST be sent.
      Section 5.5: "Currently the only PW status codes which MAY be sent using the S-PE bypass procedure are:"
      That is not a "MAY"! You are trying to "Other status codes except for those listed MUST NOT be sent using the S-PE bypass procedure"
      Section 5.5: It seems to me that the S-PE bypass mode has a race condition that causes a quirk. The final sentence of 5.5 says...
      However the same PW Status TLVs MUST also be sent in LDP to keep the S-PEs state updated."
      The implication here is that a fault (say x2) is raised and sent by both mechanisms. The fault clears rapidly and the fault clear is sent by both mechanisms. Because of speed of delivery, the egress T-PE will see the fault raised and cleared twice.
      I need to be convinced that this does not matter.
      Section 5.5.1: "When a PW Segment along an MS-PW is using the LDP control protocol, a flag bit MUST be set in the interface parameters sub-TLV to indicate that the T-PE is requesting S-PE bypass status message mode."
      Surely you don't mean this! Do you mean: "When a PW Segment along an MS-PW is using the LDP control protocol wishes to request use of the S-PE bypass status message mode, it sets the B bit in the interface parameters sub-TLV as shown in Figure 3."
      I think you need an IANA registry for the flags in the interface parameters sub-TLV.
      Oh, and please label Figure 3 correctly! The caption is also wrong.
      Seciton 7 is inadequate. The referenced documents do not describe the security of the ACH. While I believe this has been documented elsewhere, you need to give a correct reference.
    4. Adrian Farrel: Comment [2011-11-01]:
      Please consider whether [REDUNDANCY] really needs to be a normative reference. I don't think you use it in that way.
      Section 6 and its sub-section could be more careful about whether PWs or PW segments are switched.
      4385 and 4447 are messed up in the references section.
    5. Stephen Farrell: Comment [2011-10-30]:
      - section 2: s/two Provider Edge (PE)/two Provider Edge (PE) devices/?
      - section 2: s/and [REDUNDANCY].../and elsewhere [REDUNDANCY]/
      - 5.3 1st para: if an unknown or malformed TLV is received but in a message containing >1 TLV, does that imply anything about the other TLVs in that message?
    6. Russ Housley: Discuss [2011-11-02]:
      The Gen-ART Review by Ben Campbell was updated on 31-Oct-2011. Ben previously raised a concern about Section 5.3; he asked: Has the work group considered how the retransmit scheme and 30 second refresh default will scale to very large deployments? Seems like this could result in a lot of retransmissions. Ben received two responses to this comment.
      Stewart Bryant responded: "Are you concerned about the network traffic or the PE load. In the case of the network traffic, this is trivial compared to the data traffic that these systems and their networks are designed to carry.
      "In the case of PE load, the PE is designed to deal with it."
      Luca Martini responded: "Yes. that is correct. This will most likely not scale for large deployments. We have another document that addresses this issue. That extension is not necessary for most common small deployments in the order of 100 PWs per access PE."
      Either of these responses seem fine to me, but one of them should find its way into the document.
    7. Dan Romascanu: Discuss [2011-11-02]:
      In Section 5.2: "The PW Status TLV format as defined in [RFC4447], and is repeated here for the reader's convenience:"
      and then: "The first 2 bits are reserved, and MUST be set to zero on transmit, and ignored on receive."
      However in RFC 4447, in section 5.4.2 the first two bits of the PW Status TLV are represented as 10.
      This seems inconsistent. DO I miss something?
    8. Dan Romascanu: Comment [2011-11-03]:
      1. I support Russ's DISCUSS
      2. [closed]
    9. Sean Turner: Comment [2011-10-31]:
      These would probably all get fixed by the RFC editor, but I noticed them so I included them here.
      1) Header should be: "Updates: 5585 (if approved)"
      2) There's a "MUST not" in s5.3 - is that supposed to be "MUST NOT"?
      3) Expiry date in status of memo section doesn't match the date in the header.

    Telechat:

  6. RTP Payload Format for DV (IEC 61834) Video (Proposed Standard)
    draft-ietf-payload-rfc3189bis-03
    Token: Robert Sparks
    Note: The document shepherd is Roni Even (Even.roni@huawei.com).
    Discusses/comments (from ballot 3928):
    1. Russ Housley: Comment [2011-10-30]:
      The Gen-ART Review by Francis Dupont on 14-Oct-2011 includes a few editorial suggestions. Please consider them.
      - S3.3.1, page 14: I suggest m=* in place of m=??
      - S4, page 15: in general encryption is done after compression for crypto reasons and common sense: quality encryption gives a random result, i.e., something impossible to compress...
    2. Pete Resnick: Comment [2011-10-30]:
      Sent in email to IANA as well: RFC 3189 ought to have registered audio/DV when it was published in 2002, yet there is no registration for audio/DV. IANA should probably register audio/DV now with a pointer to 3189 and simply update to this document once approved.
    3. Dan Romascanu: Comment [2011-10-30]:
      1. In the introduction the following phrase is duplicated in adjoining paragraphs:
      "In the future it can be extended into other video formats managed by 80 byte DV Digital Interface Format (DIF) block."
      2. Please expand at the first occurence IEC, SMPTE, MLDv2, LW-IGMPv3
      3. It is not clear what is the meaning of the statement in the interoperability section 8:
      "In addition, the SDP examples in RFC3189 provides incorrect SDP "a=fmtp" attribute usage."
      Is the example made not relevant or corrected by this document? Why does it show in the interoperability section 8 and not in section 7 (changes from RFC 3189)?

    Telechat:

  7. A Real-Time Transport Protocol (RTP) Header Extension for Client-to- Mixer Audio Level Indication (Proposed Standard)
    draft-ietf-avtext-client-to-mixer-audio-level-05
    Token: Gonzalo Camarillo
    Note: Keith Drage (keith.drage@alcatel-lucent.com) is the document shepherd.
    Discusses/comments (from ballot 3949):
    1. Stewart Bryant: Comment [2011-11-01]:
      "A malicious endpoint could choose to set the values in this header extension falsely, so as to falsely claim that audio or voice is or is not present. It is not clear what could be gained by falsely claiming that audio is not present, but an endpoint falsely claiming that audio is present could perform a denial-of-service attack on an audio conference, so as to send silence to suppress other conference members' audio."
      ... you could also dominate the conversation by always claiming that you have strong audio present.
      This security consideration from the mixer to client looks like it might be applicable
      2. Furthermore, the fact that audio level values would not be protected even in an SRTP session might be of concern in some cases where the activity of a particular participant in a conference is confidential. Also, as discussed in [I-D.perkins-avt-srtp-vbr-audio], an attacker might be able to infer information about the conversation, possibly with phoneme-level resolution.
    2. Adrian Farrel: Comment [2011-11-03]:
      I think Stewart's security point is valid, although I am not quite sure how this differs from simply raising your voice.
    3. Stephen Farrell: Comment [2011-10-30]:
      (1) If vad can expose encrypted vbr, then why don't the security considerations here say "if encrypting vbr and doing vad then you MUST use apply commensurate protection to both"? I don't get the logic in the current section 6 where it says "if encrypting vbr and doing vad then you SHOULD use some additional mechanism" - what's the exceptional case that justifies the SHOULD there and why would you ever do something appreciably weaker or stronger?
      (2) Is the alternative to srtp-encrypted-header-ext to use IPsec or TLS or what? It'd be better to reference those since if you don't then I don't get how srtp-encrypted-header-ext isn't a normative reference? I'd suggest adding a reference to either TLS or IPsec, whichever is more likely to be used.
    4. Robert Sparks: Discuss [2011-11-01]:
      Updating now that I've heard why we don't need the pre5378 boilerplate:
      Several paragraphs in this document are heavily influenced by RFC3389.
      One bit of borrowed text speaks of expressing audio level "relative to the overload point of the system". Even though that text exists in 3349, I'm not sure it's as clear as it needs to be. What is "the system" in this context, and where are its boundaries?
      The first full paragraph on page 5 (beginning "The audio level header extension only carries the level of the audio in...) works well for payload formats that are a sequence of samples, but I'm not sure the description works as well for encodings that are more intricate. Are implementations expected to reconstruct the equivalent of a PCM encoding from whatever encoding is in use to calculate this level value? The section later talks about how redundant data (2198) wouldn't affect the level measure. Shouldn't it also say something about error correcting bits or information used in some encodings for loss concealment also not affecting the measure?
    5. Robert Sparks: Comment [2011-11-01]:
      The Security Considerations section sketches a scenario where an attacker sends high level indications, but encoded audio that is actually silent to suppress other participant's audio. A more likely attack is one that sends high level indications just to seize any speaker-selection algorithm used by a conference system.
    6. Sean Turner: Comment [2011-10-31]:
      I noted the same things Stephen did.

    Telechat:

  8. A Real-Time Transport Protocol (RTP) Header Extension for Mixer-to- Client Audio Level Indication (Proposed Standard)
    draft-ietf-avtext-mixer-to-client-audio-level-05
    Token: Gonzalo Camarillo
    Note: Keith Drage (keith.drage@alcatel-lucent.com) is the document shepherd.
    Discusses/comments (from ballot 3950):
    1. Stephen Farrell: Comment [2011-10-30]:
      Same comments as for client-to-mixer
      (1) If vad can expose encrypted vbr, then why don't the security considerations here say "if encrypting vbr and doing vad then you MUST use apply commemsurate protection to both"? I don't get the logic in the current section 6 where it says "if encrypting vbr and doing vad then you SHOULD use some additional mechanism" - what's the exceptional case that justifies the SHOULD there and why would you ever do something appreciably weaker or stronger?
      (2) Is the alternative to srtp-encrypted-header-ext to use IPsec or TLS or what? It'd be better to reference those since if you don't then I don't get how srtp-encrypted-header-ext isn't a normative reference? I'd suggest adding a reference to either TLS or IPsec, whichever is more likely to be used.
    2. Dan Romascanu: Comment [2011-10-30]:
      1. Lionel Morand made in his OPS-DIR review a number of comments which I suggest to be taken into consideration by the authors or RFC Editor:
      * Overall comment: the document defines a new optional RTP header extension to support a new service capability. However, it should be clarified somewhere (e.g. in the protocol description) the condition of service applicability e.g. all the entities involved need to support this extension.
      * In section 1, figure 1: even if it is just for illustration, please indicate what would be the meaning of (S) and (M)
      * In section 3: I'm not a specialist of RTP and use of mixers. However it might be desirable to extend the section dealing with the possible cascade of mixers. It is not obvious how each mixer will be involved along the path. Especially, it is not clear what is the rational that leads to the conclusion: "it is likely that in such situations average audio levels would be perceptibly different for the participants located behind the different mixers."
      * In section 5, it is said: "Conferencing clients that support audio level indicators and have no mixing capabilities would not be able to provide content for this audio level extension and would hence have to always include the direction parameter in the "extmap" attribute with a value of "recvonly". Conference focus entities with mixing capabilities can omit the direction or set it to "sendrecv" in SDP offers. Such entities would need to set it to "sendonly" in SDP answers to offers with a "recvonly" parameter and to "sendrecv" when answering other "sendrecv" offers."
      Question: Is the setting of the direction parameter purely informative (sorry for my ignorance)? If not i.e. there are associated requirements, the above text is not appropriate (e.g. "would have to always", "would need") and "MUST" should be used instead.
      * Figure 4 and 5: The description of each example should be put above the figures. Even if obvious, please indicate for clarification "SDP Offer:" and "SDP Answer:" on top of the lists of SDP parameter.
      * Figure 4: "A client-initiated example SDP offer/answer exchange negotiating an audio stream with one-way flow of of audio level information."
      s/one-way flow of of audio/one-way flow of audio
      2. Please expand CSRC at first occurence
      3. Please replace the conditional language in the first paragraph of the IANA considerations section.
    3. Robert Sparks: Comment [2011-11-01]:
      The code in the appendix should be explicitly marked as a code component as indicated in Sean's discuss.
    4. Sean Turner: Discuss [2011-10-31]:
      lt;process weeniegt;
      According to the IETF's TLP you need to put:
      <CODE BEGINS>
      /* Copyright (c) 2011 IETF Trust and the persons identified as authors of the code. All rights reserved. Redistribution and use in source and binary forms, with or without modification, is permitted pursuant to, and subject to the license terms contained in, the Simplified BSD License set forth in Section 4.c of the IETF Trust’s Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info). */
      code goes here
      <CODE ENDS>
      in A.1.
      </process weenie>
    5. Sean Turner: Comment [2011-10-31]:
      I noted the same things as Stephen.

    Telechat:

  9. vCard KIND:application (Proposed Standard)
    draft-ietf-vcarddav-kind-app-00
    Token: Pete Resnick
    Note: Simon Perreault (simon.perreault@viagenie.ca) is the document shepherd.
    Discusses/comments (from ballot 3951):
    1. Adrian Farrel: Comment [2011-11-01]:
      Would the DEATHDATE property be applicable if KIND shows an "application" to say when the software crashed or was uninstalled?
    2. Russ Housley: Discuss [2011-10-30]:
      The Gen-ART Review by Roni Even on 29-Oct-2011 raises one concern. Please respond to this concern.
      I noticed that the example in section 3 is presented as XML, but I did not see any text about adding the new kind to the relax NG schema.
      property-kind = element kind { element text { "individual" | "group" | "org" | "location" }* }
    3. Sean Turner: Comment [2011-10-31]:
      From nits checkers:
      == Outdated reference: draft-ietf-vcarddav-vcardrev has been published as RFC 6350
      == Outdated reference: draft-ietf-vcarddav-vcardxml has been published as RFC 6351

    Telechat:

  10. vCard Format Extensions : place of birth, place and date of death (Proposed Standard)
    draft-ietf-vcarddav-birth-death-extensions-01
    Token: Peter Saint-Andre
    Discusses/comments (from ballot 3954):
    1. Stewart Bryant: Comment [2011-11-01]:
      Looking at the other comments, I do wonder whether we need a lighter weight registration scheme for these vcard attributes.
      Wouldn't expert review be adequate?
    2. Wesley Eddy: Comment [2011-10-26]:
      It would be interesting to know why date and place of death are considered useful information in a vcard, since that goes beyond most people's use of an address book or contact list.
    3. Adrian Farrel: Comment [2011-11-01]:
      Well, ain't it weird? RFC 6350 describes the purpose of vCard as... "allows the capture and exchange of information normally stored within an address book or directory application."
      IMHO, the death place and death date are not pertinent for such applications. So, probably, people use vCard for more widespread information storage. That may be OK, but I guess someone should say so, somewhere.
      This seems to follow up the comments from a number of other ADs and I also wonder about inside-leg-measurement.
      Suppose I know someone is dead, but don't know where or when. How do I represent that in your new properties?
      Including a place of death without a date of death, would clearly show the person is dead. Similarly including a date of death without a place would let me know. but obviously if both fields are absent it says nothing one way or the other.
      Maybe you could give as one of the examples...
      DEATHDATE;VALUE=text:unknown
      ...and that states that the person is actually dead,
      But what about if you actually do not know whether the person is dead, and you want to convey this?
      And what do I now assume about a vCard that does not include the death properties? Is that person alive?
      Section 3 says: "This presents no security considerations beyond those in section 9 of the base vcard specification [RFC6350]."
      But surely you have opened up the Internet to attacks from Zombies and Vampires?
    4. Stephen Farrell: Comment [2011-10-30]:
      Is this really needed? There's no real justification and why wouldn't I follow this up with an equivalent for height, shoe size, trouser size, favourite-drink, scratches-nose-occasionally or whatever? Do we really want an RFC for each and every such thing/attribute?
    5. Russ Housley: Comment [2011-10-31]:
      The Gen-ART Review by Martin Thomson on 16-Sep-2011 raised a few questions. Please consider them.
      Did anyone consider that a RESTINGPLACE tag might be added? It seems like in some instances it could be more useful than DEATHPLACE. That might be more relevant for certain "objects". At risk of sounding macabre, for some "objects" this might need to allow multiple values.
      I note that there seems to be some contention about the precise coordinates to use in identifying the wreck, though it appears that Wikipedia (41?43'55"N, 49?56'45"W) was used as a source in this instance.
    6. Dan Romascanu: Comment [2011-11-03]:
      1. As other ADs have noticed place and date of death do not seem to fit comfortably within the scope of the typical information carried by vcards. It would be useful to add some text about applicability, maybe examples.
      2. One of the more current information included in biographies when talking about the pace of birth is the country of birth. Did the authors and WG discuss including this information, maybe the ISO 3166 country codes? This question also applies for the place of death
    7. Sean Turner: Discuss [2011-11-03]:
      1) Does the template allow "description" to be empty? Sometimes folks really don't like normative language in the ABNF - maybe in the description is where you could duplicate the normative requirements from the ABNF.
      2) cleared

    Telechat:

  11. Guidelines for the use of Variable Bit Rate Audio with Secure RTP (BCP)
    draft-ietf-avtcore-srtp-vbr-audio-03
    Token: Robert Sparks
    Note: Magnus Westerlund (magnus.westerlund@ericsson.com) is the document shepherd.
    Discusses/comments (from ballot 3972):
    1. Stewart Bryant: Comment [2011-11-01]:
      I agree with the Discusses raised by Peter and Stephen.
    2. Adrian Farrel: Comment [2011-11-03]:
      Well, I think this is a fine document. An extra editorial pass would help and it would be handy for future generations if the document title mentioned "security".
      Personally, I would have taken out all RFC 2119 language and made this an Informational document that gave advice for people thinking about the problem, deploying, and implementing. But I intend staying out of that debate and watching the rest of the IESG squabble.
    3. Stephen Farrell: Discuss [2011-10-28]:
      I think this is a welcome and useful document, but needs a bit more work so we can be confident in the BCP recommendations.
      (1) There is more recent work [1] on this topic that is not referenced and, I think, needs to be. That's the easy one:-)
      [1] White, A.M.; Matthews, A.R.; Snow, K.Z.; Monrose, F.; , "Phonotactic Reconstruction of Encrypted VoIP Conversations: Hookt on Fon-iks," Security and Privacy (SP), 2011 IEEE Symposium on , vol., no., pp.3-18, 22-25 May 2011 doi: 10.1109/SP.2011.34 URL: http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=5958018&isnumber=5958008
      (2) The harder one: does [1] mean that changes to these recommendations are needed or not? I think this BCP needs to answer that question. In particular, does the claim that "VBR codecs should be considered safe in the context of encrypted unstructured calls" need some additional qualification over and above the "pre-recorded messages" caveats already given?
      (3) Google scholar returns 54 citations to [spot-me] so it looks like there has been more work on this topic in addition to [1] since 2008. Have the authors checked that literature to see if any other recommendations should be included in this BCP?
      (4) The recomendation in section 4, 2nd para on the length of the overhang period seems to just state a requirement without actually saying how to do that. Here I mean that you say that the length of the overhang must be chosen so that something is infeasible but you don't say how to achieve that. It might be that the next paragraph is is trying to say how to do it when describing the exponentially-decreasing PDF - is that the claim? If so, can you make that clear? If not, then can you provide at least one way to meet the requirement?
      (5) It's not clear to me how a program or programmer can decide when a scenario applies where "VBR is unsafe," unless "unsafe" basically means pre-recorded messages only. If unsafe encompasses more scenarios than that, how does one know when to apply the recommendations in section 5? (This discuss point is predicated on there being something new to add as a result of discuss points 2 or 3 above. If points 2 and 3 are sorted without there being anything else to say, then I think this one would also go away.)
      (6) We're hoping to get a saag presentation on this topic in Taipei. If that happens, then there may be additional points arising so this is just a placeholder discuss until after that presentation (if it happens).
    4. Stephen Farrell: Comment [2011-10-28]:
      - maybe s/must be randomly chosen/MUST be randomly chosen/ in 2nd para of section 4 and s/must be packetised/MUST be packetised/
      similarly at the top of p5?
    5. Russ Housley: Comment [2011-10-30]:
      The Gen-ART Review by Ben Campbell on 21-Oct-2011 raises a few comments. Please consider them.
      - Section 1, paragraph 2: "...can be recognised with high accuracy..." That seems like a bit more than a "small amount of information"
      - Section 2, 1st paragraph: "... is already considered a hard problem" Who considers it?
      - Section 4, last paragraph: "It is, however, still expected..." Who expects it?
      - section 6: It might be worth mentioning that this entire draft is about security.
    6. Pete Resnick: Discuss [2011-10-31]:
      I don't see how this is remotely a BCP. This should be on the standards track. It is specifying all sorts of implementation parameters that are clearly testable, may have interoperability implications, and may change over time as we get implementation experience. (E.g., the length of the overhang period may be something that we specify differently, whether VAD is used or not may have interoperability implications, etc.). This discussion would have normally happened in the context of a security considerations section of a base protocol document and would have gone along the standards track with the base protocol. The fact that it is being published separately shouldn't change its treatment.
    7. Peter Saint-Andre: Comment [2011-11-02]:
      I concur with much of the feedback provided by other IESG members.
      Please clean up various infelicities in coordination with the RFC Editor team ("possible sentences are possible", "easily use the rate information to easily recognize", etc.).
    8. Sean Turner: Comment [2011-11-01]:
      I support Stephen's discuss.

    Telechat:

  12. Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) Heartbeat Extension (Proposed Standard)
    draft-ietf-tls-dtls-heartbeat-03
    Token: Sean Turner
    Note: Joe Salowey (jsalowey@cisco.com) is the document shepherd.
    Discusses/comments (from ballot 3974):
    1. Jari Arkko: Discuss [2011-11-03]:
      The document says: "The receiving peer SHOULD discard it silently, if it arrives during or after the handshake."
      I think you need to specify the "or after" part better. Is this a time-based determination, or something based on sequence numbers that show that the packet with the heartbeat arrived later than the packets involved in the handshake?
      Note that one side can initiate a handshake at time t0, another side a heartbeat at t1, and the first handshake packet comes to the side that did the heartbeat at t2, t2>t1>t0.
      Similarly, it is possible that one side has completed a handshake and and sends a heartbeat right after, but the last packet of the handshake and the hearbeat change order in flight, making the other side think that that heartbeat is being run during a handshake.
      You do say that communications should be idle for a period before initiating the heartbeat exchange. I suspect that for PMTU purposes you might want to send some heartbeats immediately in some cases.
    2. Wesley Eddy: Comment [2011-11-02]:
      Stephen's DISCUSS seems very important to consider, though I'm no expert in this area, I support Stephen's DISCUSS.
    3. Adrian Farrel: Discuss [2011-11-02]:
      The document does not describe how often to send a heartbeat. Calling it a heartbeat implies that it is sent (and responded) at regular intervals.
      5.1 is pretty obviously not intended to be more than a probe.
      5.2 gives some guidance by saying... "...allows a check at a much higher rate than the TCP keep-alive" and "HeartbeatRequest messages SHOULD only be sent after an idle period that is at least multiple round trip times long."
      I think you need to give *much* better guidance about the lower bound.
      You might also suggest a default "idle period", and you should define what you mean by "idle period".
      You really should discuss whether the "idle period" needs to be configurable.
    4. Adrian Farrel: Comment [2011-11-02]:
      Section 4: "When a HeartbeatRequest message is received, a corresponding HeartbeatResponse message MUST be sent carrying an exact copy of the payload of the HeartbeatRequest."
      I know what you mean, but several places in the text contradict this by giving cases when a response is not to be sent.
      I wonder why section 5.2 doesn't discuss the question of whether it is necessary to have both ends transmitting heartbeats, or good enough for just one to do it.
    5. Stephen Farrell: Discuss [2011-10-31]:
      This discuss is checking a niggling concern. While I expect the outcome to be "no change," and for that to happen quickly, I still wanna ask just in case...
      (1) This involves sending partly predictable plaintext messages that are then encrypted, with predictable, almost identical cleartext for the responses and so that the keys used on both sides are derived from the same (pre)master secret. Has anyone looked seriously at that specific combination to see if there's any weakness for any known/conceivable ciphersuite?
      (2) I have not done the work asked-for in (1), and know of no specific problem, but would it make sense, just in case, to have some bytes early in the heartbeat_response set randomly by the responder? (Or some such thing to make the plaintexts differ more.)
      (3) If there were to be any weakness then would it be right to say "If a received HeartbeatResponse message does not contain the expected payload the message MUST be discarded silently."
    6. Pete Resnick: Comment [2011-10-31]:
      Section 3 says, "If no corresponding HeartbeatResponse message has been received after some amount of time, the DTLS/TLS connection MAY be terminated by the user." Who is "the user" in this case? The reason I ask is that I'm afraid this sentence is going to cause some not-so-bright implementers to need instructions like we had to provide in draft-ietf-tcpm-persist, taking it to mean that only an end-user can terminate a DTLS/TLS connection. Do you mean "the application that initiated the HeartbeatRequest can terminate the connection"? Or that "the DTLS/TLS layer can terminate the connection"? A little more clarity here would minimize future stupidity.

    Telechat:

  13. IPPM standard advancement testing (Proposed Standard)
    draft-ietf-ippm-metrictest-04
    Token: Wesley Eddy
    Note: Henk Uijterwaal (henk@uijterwaal.nl) is the document shepherd.
    Discusses/comments (from ballot 3976):
    1. Ralph Droms: Comment [2011-10-30]:
      I have just one small editorial comment. I can't parse this test from Section 2; it might need some clarification:
      "o The error induced by the sample size must be small enough to minimize its influence on the test result. This may have to be respected, especially if two implementations measure with different average probing rates."
    2. Adrian Farrel: Comment [2011-11-03]:
      A useful document, thanks.
      Hope you'll be removing the change log before publication.
      I agree with Sean about the Code Copyright boilerplate.
    3. Russ Housley: Discuss [2011-11-02]:
      This seems to be a process document. Shouldn't it be a BCP?
    4. Pete Resnick: Comment [2011-10-31]:
      I agree with the DISCUSS comments of others:
      1) This should be a BCP, not Standards Track.
      2) This should be updated to take into account RFC 6410.
      I also think that the use of 2119 language in here is superfluous, if not just wrong. I don't see what difference it makes to a reader of this document to say, e.g., "The conditions for which the ADK test has been passed with the specified confidence level must be documented" instead of "MUST be documented."
    5. Dan Romascanu: Discuss [2011-10-30]:
      This is a very useful document, but some clarifications are needed before I can approve it
      1. In section 2 the following statement is being made: "Metric specification options chosen by implementors have to be documented. It is REQUIRED to use identical implementation options wherever possible for any test proposed here."
      I am questioning the reason for requiring the use of the same implementation options in testing. In real life different implementations may pick different implenmentation options. It looks to me that a stable and interoperable metrics definition would yield consistent results even if different implementation options are being chosen.
      2. In Section 3.3: "In some cases, a goodness of fit test may not be possible or show disappointing results. To clarify the difficulties arising from different implementation options, the individual options picked for every compared implementation SHOULD be documented in sufficient detail. Based on this documentation, the underlying metric specification should be improved before it is promoted to a standard."
      I believe that test needs to be added here to clarify what 'improve' means. If we deal only with clarification of the differences between implementation options, or even exclusion of one or more of the options from the specifications the advancement on the standards track may still be possible. However if the 'improvement' changes the definition or adds new options recycling at Proposed Standard level is necessary.
      3. Why is this document Standards Track and not BCP?
      4. idnits indicates two downrefs to RFC 2330 and RFC 4459 (both Informational) - where these Last Called?
    6. Dan Romascanu: Comment [2011-10-30]:
      1. The text about changes between different I-D versions needs to be taken out in the final version of the document.
      2. Are [morton-advance-metrics] and [morton-advance-metrics-01] previous versions of the same document? In any case it does not make sense to include two versions of the same document as references.
      3. page 14: "For example, if 802.1Q Ethernet Virtual LANs (VLAN) are applied"
      Drop 'Ethernet' - the Virtual LANs are not Ethernet-specific
      4. runing idnits points to a number of unused references
    7. Robert Sparks: Comment [2011-11-02]:
      I support each of Dan's discuss points, and with Sean's observation about code components.
      There are several places where 2119 keywords are used in non-meaningful ways. It would strengthen the document to review and remove the instances that are not truly needed. (The use of RECOMMENDED at the top of page 10 is a particularly strong example.)
      When you update the document to take RFC 6410 into account, please note that while interop reports are no longer required in general, if you have consensus to do so, you can still require them for advancing these metric definitions. If you chose not to require them, please consider text strongly encouraging them.
      There are several places where you REQUIRE something "whenever possible". That leaves a lot of vagueness in the specification (is "it costs too much" a reasonable excuse for "not possible"?). Please consider removing the exception clause, or at least explicitly discussing what to do or what it means when meeting that requirement is not possible.
      The first paragraph of 3.1 (stating an implementation MUST implement all the MUSTs in a specification) is vacuous - please remove it.
      Or perhaps the intent of the whole section was to clarify what's required to be reported in an implementation report and you were asking for an explicit statement that the implementation implemented all the MUSTs - if so, please clarify. That would be consistent with the second paragraph of 3.1 which appears to be asking that the report document which options were supported in "sufficient detail". But what defines sufficient, and for what purpose? Please consider continuing that sentence ("in sufficient detail to <achieve this documented goal>").
      Please consider addressing the following nits.
      The string "state of the art" isn't adding anything useful to the text - please remove it.
      The third paragraph of section 3.5 does not parse - should "by" be deleted?
      Why is there a link to xml.resource.org in the first paragraph of Appendix A.
    8. Sean Turner: Discuss [2011-10-31]:
      lt;discuss-discuss>
      This is a discuss-discuss that I think we should talk about on the call:
      So isn't this draft updating RFC 2026? It says 2026 defines some rules, but they're kind of hard to apply to our RFCs, so here's our process to determine if they should progress to Internet Standard.
      </discuss-discuss>
      RFC 6410 reduced the number of levels to two: "Proposed Standard" and "Internet Standard". Has this draft been reviewed keeping RFC 6410 in mind? I caught a couple of required changes in s1 and s3.5. Maybe in s1:
      OLD: "beyond the Proposed Standard level,"
      New: "to the Internet Standard level,"
      Maybe in s3.5:
      OLD: "advanced to Draft Standard or Internet Standard"
      NEW: "advanced to Internet Standard"
      <process weenie>
      According to the IETF's TLP you need to put:
      <CODE BEGINS>
      /* Copyright (c) 2011 IETF Trust and the persons identified as authors of the code. All rights reserved. Redistribution and use in source and binary forms, with or without modification, is permitted pursuant to, and subject to the license terms contained in, the Simplified BSD License set forth in Section 4.c of the IETF Trust’s Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info). */
      code goes here
      <CODE ENDS>
      in Annex B. Great choice for the code as there's no copyright issue with NIST.
      </process weenie>
    9. Sean Turner: Comment [2011-10-31]:
      I have the same question Dan has about BCP vs Standards Track.
      There's a couple of extra references that are unused:
      == Unused Reference: 'RFC2680' is defined on line 1070, but no explicit reference was found in the text
      == Unused Reference: 'RFC2681' is defined on line 1073, but no explicit reference was found in the text
      == Unused Reference: 'RFC4719' is defined on line 1094, but no explicit reference was found in the text
      Dan already pointed out the downref issue.

    Telechat:

  14. Defending Against Sequence Number Attacks (Proposed Standard)
    draft-ietf-tcpm-rfc1948bis-01
    Token: Wesley Eddy
    Note: David Borman (david.borman@windriver.com) is the document shepherd.
    Discusses/comments (from ballot 3987):
    1. Adrian Farrel: Comment [2011-11-02]:
      Acronyms should be expanded on first use in the body text.
      In Section 3 you use "F" and "F()" to denote the PRF. You should pick one for consistent use.
    2. Russ Housley: Comment [2011-11-01]:
      The SECDIR Review by Joe Salowey points out a minor typo. In section 3 there is a repeated "the" in the first sentence of the second paragraph.

    Telechat:

2.1.2 Returning Items

  1. (none)

2.2 Individual Submissions

2.2.1 New Items

  1. (none)

2.2.2 Returning Items

  1. (none)

3. Document Actions

3.1 WG Submissions

3.1.1 New Items

  1. Simple Authentication Schemes for the ALC and NORM Protocols (Experimental)
    draft-ietf-rmt-simple-auth-for-alc-norm-05
    Token: David Harrington
    Note: Brian Adamson (adamson@itd.nrl.navy.mil) is the document shepherd.
    Discusses/comments (from ballot 3574):
    1. Ralph Droms: Discuss [2011-11-01]:
      I'm asking for a clarification that should be easy to resolve. Is the mechanism specified in this document intended to be the only format for the use of the EXT_AUTH==1 header extension defined in [RFC5651]?
    2. Ralph Droms: Comment [2011-11-01]:
      I'm looking forward to reading responses to the Discuss positions posted by Pete and Stephen.
    3. Adrian Farrel: Comment [2011-11-03]:
      I support Pete Resnick's Discuss
      Section 1: s/transfer reliably objects/reliably transfer objects/
      "More precisely this document details the EXT_AUTH==1 header extension defined in [RFC5651]."
      Should read
      "More precisely this document details the HET=1 (EXT_AUTH) header extension defined in [RFC5651]."
    4. Stephen Farrell: Discuss [2011-10-31]:
      The parameterisation scheme is hard to follow or broken. It seems to be the case that the asid specifies the selection of scheme and keying on a session by session basis. That seems not to scale, given asid is only 4 bits long - what if a node is part of more than 16 sessions? (Practically, asid values will collide with fewer sessions given the birthday paradox.) What am I getting wrong here? (I must be getting something wrong i think;-)
    5. Stephen Farrell: Comment [2011-10-31]:
      - general: Can all the ECC work here be based on RFC 6090? That should be the case and 6090 should be referenced.
      - the presentation is highly redundant, e.g. figures 1 and 3 seem identical
      - general: you need to acknowledge that RSA puts more load on the signer but much much less on the verifier; whereas ECC puts more similar load on both and hence with many verifiers more CPU is consumed overall.
      - abstract: isn't ecdsa a digital signature scheme? Maybe you really mean, and should say, RSA?
      - abstract: is scheme 3 a group-keyed mac or something else?
      - s1, 1st para, s/transfer reliably/reliably transfer/
      - p6, 3rd bullet: the definition of the key/signature lengths is a bit broken. RSA public keys have a modulus and an exponent but the signature is the same length as the modulus, etc. I wonder if the easiest is not to delete this since its not really a definition in any case.
      - p6 - none of the signature nor group MAC definition bullets actually seem to define terms
    6. Russ Housley: Comment [2011-11-02]:
      Throughout the document, the use of "Signature Cryptographic Function" ought to be replaced by "One-way Hash Function" or "Message Digest Algorithm" (please pick just one).
    7. Pete Resnick: Discuss [2011-10-31]:
      This is much more for the shepherd and AD than it is for the author:
      I do not understand why this document is being put forward as Experimental rather than Standards Track. Unlike most Experimental documents, there is no section in here describing the experiment that is being performed and what the criteria for determining the outcome of said experiment are. When I went to look at the shepherd report and writeup for this document, I must say they were content-free. The only thing the Working Group summary said was that there was consensus for this document. If there was consensus, then why isn't this going forward as Standards Track? There is not enough information in either the document or the writeup to explain why this is Experimental; that information must appear in one of those places.
    8. Sean Turner: Discuss [2011-11-02]:
      #1) s2: Don't you need to specify the requirements for key size? You could steal the text from RFC 5751 s4.2 & s4.3 (i.e., use 1024-2048).
      #2) s3.3.1: I like that you recommended all 3 curves, but do you really need to? Couldn't you just recommend p-256 and be done with it?
    9. Sean Turner: Comment [2011-11-02]:
      #1) a: r/The first scheme is based on digital signatures./The first scheme is based on RSA digital signatures.
      #2) s1: Parameters are discussed in 2.2, 3.2, 4.2, and 5.2 so maybe: "This is detailed in Sections 2.2, 3.2, 4.2, and 5.2."
      #3) s2.1, s3.1, s4.1, s5.1: reserved - should also specify that the bits are ignored on receipt.
      #4) s2.2: When discussing Signature Cryptographic Function aren't you just talking about Message Digest Algorithms? Like in s3.2?
      OLD: "o MUST communicate the Signature Cryptographic Function, ..."
      NEW: "o MUST communicate the Message Digest Algorithm, ... ;"
      #5) s2.2: Could add a reference to RFC 6194 in the following: "Because of security threats on SHA-1, the use of SHA-256 is RECOMMENDED;"
      because it discusses those concerns.
      #6) s4.2: Contains the following: "As a side effect, the receivers also know the key length and the non truncated MAC output length;"
      This is true of the HMAC-SHA-1/224/256/384/512 but what about the HMAC-SHA512/224 and HMAC-512/256 algs in FIPS 180-4 (assuming they get defined)? I guess I'm curious if this is always going to be true.
      #7) s4.4: If you're recommending HMAC-SHA256, it's probably best to show an HMAC-SHA256 example. People do silly things like only implement the examples.

    Telechat:

  2. Home Agent assisted Route Optimization between Mobile IPv4 Networks (Experimental)
    draft-ietf-mip4-nemo-haaro-06
    Token: Jari Arkko
    Note: Pete McCann (mccap@petoni.org) is the document shepherd.
    Discusses/comments (from ballot 3723):
    1. Ralph Droms: Discuss [2011-11-01]:
      This seems to be the telechat for asking "why has this document been submitted for publication as Experimental?"
      draft-ietf-mip4-nemo-haaro-06 includes the following text, which appears to be the only text referring to publication of the specification as Experimental, at the end of section 1:
      "The specification in this document is meant to be experimental, with the primary design goal is to limit the load on the backend to minimum."
      This text, in addition to containing a non sequitor, says nothing about why the document is submitted for publication as Experimental, what the experiment might be, how the experiment might be evaluated and when the specification might be considered for publication as Standards Track or moved to Historic status.
      I have to say that I very much like the text at the end of the Introduction of draft-ietf-pim-port, which explains why that specification is Experimental - in this case, because it's doing some new stuff that hasn't been tried before - how the results of implementing the Experimental specification can be interpreted and under what circumstances the specification should be considered for Standards Track status.
      So, to make this Discuss actionable, I'd like to hear from the mip4 WG what aspects of this specification cause the request for Experimental status, how the results of the experiment with implementation and deployment should be reviewed and under what circumstance should this specification be considered for publication on the Standards Track.
    2. Adrian Farrel: Comment [2011-11-01]:
      I support Ralph's Discuss although I see that the reasoning is clear from the charter. It should be simple to construct equivalent text to go in the document.
      I searched for a definition of "optimum" or "route optimizaton". I found
      "This document proposes a method to optimize routes between networks behind Mobile Routers, as defined by NEMO [RFC5177]."
      But RFC 5177 says;
      "This document does not touch on aspects related to route optimization of this traffic."
      Section 1 does include a number of statements that "route optimization addresses this issue" for several issues. That is great, but I still missed a succinct definition of "route optimization" and some understanding of how I would recognize "optimum" if I saw it.
      Section 3.2.2seems to have "should" and "may" that might benefit from moving to RFC 2119 usage.
    3. Stephen Farrell: Comment [2011-11-02]:
      I'm assuming that these questions just reflect my ignorance of nemo, and since this is (currently) aimed at experimental, I'll not make them a discuss. (If it were going for PS, I think these would be discuss-worthy.)
      (1) I don't get how Kcr is setup as required in 3.2? Is Kcr supposed to be manually installed? Do all MR's need to have a different Kcr for all other MRs or is Kcr shared between the MR and HA?
      (2) 3.2.1 says an MR MAY generate a new key at any time. How is that distributed (securely)?
    4. Russ Housley: Discuss [2011-11-01]:
      The Gen-ART Review by Roni Even on 29-Oct-2011 raises two concerns that deserve a response.
      1. The IANA Considerations section is not clear. It talks about three new tables but it was not clear to me which one they were and what is the extension policy for the tables.
      2. Section 4.2 talks about realm compression. Is it always used when using prefix compression or can you just do prefix compression if there is no benefit from using the realm compression?
    5. Russ Housley: Comment [2011-11-01]:
      The Gen-ART Review by Roni Even on 29-Oct-2011 raises two editorial comments. Please consider them.
      1. Typo in Section 3.1, first paragraph: “alredy”
      2. In Section 3.3.1: “only be when” change to “only when”; and “and and whose” delete one of the “and”.
    6. Pete Resnick: Comment [2011-11-02]:
      I agree with Ralph that more should be said in the document about the nature of the experiment.
    7. Robert Sparks: Comment [2011-11-02]:
      Related to Russ' discuss (which I support):
      IANA has unanswered questions (Authors - you received them directly and can also see them at the line starting:
      2011-10-31...06.Amanda Baber...IANA has several questions about draft-ietf-mip4-nemo-haaro-06.txt.
      at <https://datatracker.ietf.org/doc/draft-ietf-mip4-nemo-haaro/history/>

    Telechat:

  3. Methods to convey FEC Framework Configuration Information (Experimental)
    draft-ietf-fecframe-config-signaling-06
    Token: David Harrington
    Note: Greg Shepherd (gjshep@gmail.com) is the document shepherd.
    Discusses/comments (from ballot 3749):
    1. Jari Arkko: Comment [2011-11-03]:
      Ari Keränen helped me review this, and he had a couple of comments:
      Many of the internal references ("see section x") are referring to apparently wrong sections.
      1. Introduction: "This document describes how to use various signaling protocols to communicate the Configuration information between sender and receiver(s). The configuration information may be encoded in any compatible format such as SDP [RFC4566], XML etc."
      I found this statement confusing considering that only SDP encoding is defined (right?). The same statement is found also later in the draft.
    2. Ron Bonica: Discuss [2011-11-02]:
      This document includes a informative reference to draft-ietf-mboned-session-announcement-req. draft-ietf-mboned-session-announcement-req has expired and doesn't seem to have gained traction in MBONED.
    3. Gonzalo Camarillo: Comment [2011-11-03]:
      I agree with other discusses in that the purpose of the draft should be clarified.
      Also, introductions should not contain normative language. Normative terminology is not even introduced before Section 2.
    4. Wesley Eddy: Discuss [2011-10-26]:
      It's not clear in what sense this is Experimental. It seems to be more of an Informational document, as it is not particularly prescriptive as a protocol or mechanism. For instance, I don't think it would be possible to create compatible implementations based solely on this document; many decisions are punted on.
    5. Adrian Farrel: Comment [2011-11-03]:
      I really don't see the point of raising a further Discuss on this document since my concerns overlap extensively with those already raised.
      However, one point really bothered me...
      The Abstract says: "This document describes how to use existing signaling protocols to determine and dynamically communicate the Configuration information between sender(s) and receiver(s)."
      I would expect the Abstract to state clearly which protocols. But I read on and found in the Introduction:
      This document describes how to use various signaling protocols to communicate the Configuration information between sender and receiver(s). The configuration information may be encoded in any compatible format such as SDP [RFC4566], XML etc. A signaling protocol could be utilised by any FEC scheme and/or any Content Delivery Protocol (CDP)."
      So I realised that the document is attempting to give an abstract description of how one might use *a* signaling protocol for the tasks identified, but without actually doing the protocol specification. Fair enough - although that clearly makes it an Informational framework.
      This view was confirmed by Section 5 that is clearly abstract, and by Section 5.2 that says:
      "This document describes leveraging any signaling protocol that is already used by the unicast application, for exchanging the FEC Framework Configuration Information between two nodes."
      But in Section 5.1:
      "This specification describes using Session Announcement Protocol (SAP) version 2 [RFC2974] as the signaling protocol to multicast the configuration information from one sender to many receivers."
      Which is not abritrary at all.
      To make this actionable I suggest you work out very clearly what the purpose of the document is and capture that both in the Abstract and the Introduction. It would also help if you clearly defined what *you* mean by a signaling protocol because people at different layers of the stack have very different understandings of the term.
    6. Stephen Farrell: Comment [2011-11-01]:
      - What does "MAY employ cryptography" mean? You already said SHOULD to the authentication header so what kind of non cryptographic authentication header do you have in mind? RFC 2974 defines PGP and CMS options so presumably the SHOULD means that you've gotta do one of those unless you have a good reason.
      - Is it clear how one would use GDOI to manage keys for a SAP authentication header?
      - I agree with Wes' discuss.
    7. Pete Resnick: Discuss [2011-11-02]:
      Even if this document was written properly as a protocol document (see Wes's Discuss comment), there is no explanation of what about this document is experimental in the first place. There is no description about what is being experimented on, why it is an experiment, and what the results of the experiment might be. Such an explanation should appear in the Introduction.
    8. Pete Resnick: Comment [2011-11-02]:
      I agree with Wes's Discuss comment.
    9. Robert Sparks: Discuss [2011-11-02]:
      (It would help to read the comments below before reading these DISCUSS points)
      1) In several sections (5.1 in particular) it's very hard to tell which requirements are new requirements on an implementation defined in this draft and which are restatements of requirements from other RFCs. Some of these restatements leave out important context (an example is the deletion requirement in 5.1.2 of this document vs the description of explicit deletion in section 4 of RFC2974). Please explicitly call out each instance where you are just restating a requirement, and consider just pointing to the actual definition of behavior instead of restating it.
      2) Is the list of unicast mechanisms intended to be complete? Is it intended to constrain CDPs to choose only between them instead of inventing something new?
    10. Robert Sparks: Comment [2011-11-02]:
      It's not clear what this document is trying to acheive. Parts of it seem to be considerations that a CDP specification should take into account when defining how FCCI is disributed. Section 5.2, which calls out a few unicast mechanisms, has this flavor in particular. It's almost a survey, and while the descriptions call out important aspects a CDP should consider, they are not sufficiently detailed for a CDP to point to this document to define how these mechanisms would be used. Section 5.1, on the other hand, tries to define how an (abstract?) CDP would utilize multicast SAP, adding a few requirements beyond the base SAP specification.
      Please consider restructuring (perhaps even renaming) the document to make its goals clearer.
    11. Sean Turner: Discuss [2011-11-02]:
      I see that authentication is a SHOULD. I went and looked at RFC 2974 and it says either PGP or CMC can be used. Don't you have to pick a MUST implement?
    12. Sean Turner: Comment [2011-11-02]:
      s5 contains the following: "The SAP message(s) SHOULD contain an authentication header and MAY employ cryptography."
      I think you mean "MAY employ encryption."
      I too am scratching my head about the GDOI reference. Further, RFC 3547 was recently obsoleted by RFC 6407. There were a fair number of changes. I'm unclear whether you should update the reference or keep the reference to the obsoleted RFC. Are there any implementations of the newer or older GDOI mechanism?

    Telechat:

  4. A Reliable Transport Mechanism for PIM (Experimental)
    draft-ietf-pim-port-09
    Token: Adrian Farrel
    Note: Mike McBride (mmcbride@cisco.com) is the document shepherd.
    Discusses/comments (from ballot 3882):
    1. Stephen Farrell: Comment [2011-11-01]:
      - Presumably if this experiment is a success then some method of doing automated key management would be required for a successor standards track document. I think just noting that in the security considerations section would be good.
      - I wondered why TLS wasn't considered as an additional option. Be good to explain why, esp if there's a reason it wouldn't work well enough.
    2. Russ Housley: Discuss [2011-11-02]:
      The Gen-ART Review by Suresh Krishnan in 1-Nov-2011 raises two points that deserve a response.
      Section 3.1: From my reading of the document, it is not clear whether we can have a node advertise multiple capability options of the same transport protocol (say PIM-over-TCP-Capable) in the same message. e.g. A dual stack node might want to advertise its capability to do both IPv4 and IPv6. Is this possible? If so, how?
      Section 4.7: Section 4 talks about the router with the lower connection ID initiating the transport layer connection but this does not really map into the rules mentioned in Section 4.7. Specifically, I am not sure Rule 3 for Node A in Section 4.7 conveys the same intent as the rest of Section 4.
    3. Sean Turner: Comment [2011-11-02]:
      s3.1 and s3.2: Not being a PIM expert, I tripped up over how IPv6 addresses could fit in to TCP Connection ID and SCTP Connection ID. I kind of had to guess where I'd find more information about this, so a pointer to the xoring mechanism in RFC 4061 would have helped a lot.

    Telechat:

  5. Data for Reachability of Inter/tra-NetworK SIP (DRINKS) Use cases and Protocol Requirements (Informational)
    draft-ietf-drinks-usecases-requirements-06
    Token: Gonzalo Camarillo
    Note: Alexander Mayrhofer (alexander.mayrhofer@nic.at) is the document shepherd.
    Discusses/comments (from ballot 3916):
    1. Wesley Eddy: Comment [2011-11-02]:
      I would think that it would be much better if the requirements were complete sentences, but won't hold the document up over it ...
    2. Adrian Farrel: Comment [2011-11-03]:
      Section 3 typo
      s/(see Section Section 5)/(see Section 5)/
    3. Stephen Farrell: Comment [2011-11-01]:
      - I was confused by this: "Any request to provision, modify or delete data is subject to several security considerations (see Section Section 5). This document does not address these considerations."
      Section 5 does seem to address the security considerations so I don't get it?
      - Section 5 says that authorization is REQUIRED, which is fine, but you're not clear on the intended granularity which will make a huge difference. If you could state e.g. whether or not UC PI#6 (modification of authority) has to be authorized at the level of a specific phone number that'd make it clear. As is, you've punted on this, so may have more trouble getting closure on the protocol.

    Telechat:

  6. Problem Statement and Requirements for Transporting User to User Call Control Information in SIP (Informational)
    draft-ietf-cuss-sip-uui-reqs-07
    Token: Gonzalo Camarillo
    Note: Vijay K. Gurbani (vkg@bell-labs.com) is the document shepherd.
    Discusses/comments (from ballot 3948):
    1. Stephen Farrell: Comment [2011-11-01]:
      - REQ-11 is very prescriptive about the "one octet discriminator." Its not clear from the phrasing that the "at least" also applies to that. I guess it does though.
      - I think it'd be good to note that there will be UA security considerations to be considered - if any old set of bytes can be attached to an INVITE and then a UA will try to render those, then that's probably gonna generate new vulnerabilities.
      - Its a pity that the SIP community seem to have given up on e2e security, which is how I read this. I wonder if there's any way to make that better... (maybe rtcweb will do better in this respect)
    2. Russ Housley: Discuss [2011-11-02]:
      The Gen-ART Review by Ben Campbell was updated on 1-Nov-2011. Points raised in his previous review were responded to with reasonable explanations. In both cases, the requirements would be more clear if the clarifications were included in the document:
      REQ-12: What degree of certainty is required here? (i.e. strong identity?) If implied by the SIP dialog, does that impact expectations on what sort of authorization must happen at the SIP layer?
      The reasonable response was: "This is not meant to imply strong identity. And since UUI data can appear in a response, there aren't really any strong methods available with SIP. The UUI mechanism does not introduce stronger authorization requirements for SIP, but instead the mechanism needs to be able to utilize existing SIP approaches."
      REQ 13: I'm not sure I understand how this interacts with the ability for intermediaries to remove UUI. Should this be detectable by the endpoints? Or is that ability limited to the hop-by-hop case, or require no integrity protection?
      The reasonable response was: "Yes, there are tradeoffs between this requirement and requirement REQ-9. Hop-by-hop protection is one way to resolve this interaction."
    3. Robert Sparks: Discuss [2011-11-02]:
      The discussion below REQ-1 implies that 3xx responses are end-to-end. They are hop-by-hop, and a proxy might chose to recurse on them.
      Is there a requirement that a recursing proxy preserve the UUI into any INVITEs created towards the Contacts in a 3xx?
      Suppose a simple forking scenario where an INVITE forks to two elements, each of which return 3xx responses with UUI information. Is there a requirement for the information from both branches to be included in any 3xx response the proxy returns to the original UAC (assuming it doesn't recurse)?
      Related to REQ-9: Is there a requirement for the applications at each end to be able to tell that a particular application usage of UUI data has been removed? Or is there a requirement that the application NOT be able to tell? Either way, please be explicit.

    Telechat:

3.1.2 Returning Items

  1. Source Address Validation Improvement Framework (Informational)
    draft-ietf-savi-framework-05
    Token: Jari Arkko
    Note: Jean-Michel Combes (jeanmichel.combes@gmail.com) is the document shepherd.
    Discusses/comments (from ballot 3767):
    1. Stephen Farrell: Discuss [2011-11-01]:
      This makes no mention at all of privacy which I think needs to be there somewhere. Given that Joel is planning to add text on that to savi-threats I'd be fine if that is just referenced from here, or even if that text is moved from savi-threats to this document, and savi-threats could refer to it here. But the privacy implications of SAVI do need to be covered here too. (That assumes that Joel's text is as fine as I'm sure it will turn out to be:-)
    2. Stephen Farrell: Comment [2011-11-01]:
      - Ted Hardie also reviewed this from the privacy perspective and had what I think is more or less the same concern as in my discuss.
      http://www.ietf.org/mail-archive/web/privacydir/current/msg00059.html
      - general: The term "legitimate IP address" is used a good few times, and is sort-of defined in the 1st bullet of section 3, but a clearer definition would be good - I think you mean that "legitimate" == "not considered a spoofed source by SAVI" and no more, (which is fine), but it could be read to mean "authorised by the authorities" which would give the wrong impression (I hope:-). You might even consider inventing your own term for this, e.g. "SAVI-legitimate" or whatever (but I'm only weakly suggesting that, I can understand that inventing such a term might just cause more confusion now).
      - p4, maybe s/network operators/network administrators/? The term "operator" tends to be taken to mean a specific type of admin.
      - p4, Is "on the path" right really? SAVI devices need to be close to the host as is correctly stated elsewhere.
      - p5, Is "must be verifiable" correct in point#2? I think it would be better to say "needs to be verifiable....if SAVI is to work"
      - p6, What foes "full protection for the hosts" mean? SAVI is not protecting the host with the source address, but rather the network or the receiving hosts and doesn't provide "full" protection in any sense I can understand? Maybe just end that sentence at "lower" is the easiest change.
      - p6, Is it correct to say that it is through "assignment" that a host becomes the "legitimate" user of a source address for all cases? (Just checking.)
      - p7, Are all of the examples of binding anchors listed in 3.2 in scope of the SAVI WG? I think it'd be good to say which are or are not, if not all are or maybe to only list those that are in scope.
      - p11, What is a "premier check"?

    Telechat:

3.2 Individual Submissions Via AD

3.2.1 New Items

  1. Suite B Profile for Transport Layer Security (TLS) (Informational)
    draft-salter-rfc5430bis-01
    Token: Sean Turner
    Note: Russ Housley is the Document Shepherd.
    IPR: Certicom Corp's Statement of IPR Related to draft-salter-rfc5430bis-00
    Discusses/comments (from ballot 3973):
    1. Adrian Farrel: Comment [2011-11-01]:
      Shame about not cleaning up the idnits before presenting for review. Please save the RFC Editor the time by fixing them before advancing.
    2. Pete Resnick: Comment [2011-11-02]:
      Gads, I hate the use of RFC 2119 language when what you're saying is, "In order to conform to NSA Suite B, you MUST do this." That sort of fails the 2119 requirement that "they MUST only be used where it is actually required for interoperation or to limit behavior which has potential for causing harm (e.g., limiting retransmisssions) For example, they must not be used to try to impose a particular method on implementors where the method is not required for interoperability." It's not a DISCUSSion worth having for this document individually, and the document that this one obsoletes does exactly the same thing, but it's a discussion we should have at some point.
    3. Peter Saint-Andre: Comment [2011-11-02]:
      It seems that this document is missing the section on "differences from RFC 5430".

    Telechat:

3.2.2 Returning Items

  1. (none)

3.3 IRTF and Independent Submission Stream Documents

3.3.1 New Items

  1. HIP Experiment Report (Informational)
    draft-irtf-hip-experiment-14
    Token: Ralph Droms
    Note: The document shepherd is Tom Henderson (thomas.r.henderson@boeing.com)
    Discusses/comments (from ballot 3958):
    1. Ralph Droms: Comment [2011-10-18]:
      It would be helpful to include a terminology section, for those not so familiar with HIP.
      section 1.2: "HIT-based lookups"
      expand HIT on first usage
      section 2.3.5: Are there any specific references to the "initial specification attempts?"
      To solve this problem, the HIP layer could inform the transport layer of mobility events. This method, known as transport triggers, is still under research although initial specification attempts have been made in the IET
      section 2.5: I can't quite parse this sentence:
      "Although counter-examples exist, e.g. SCTP is a large unit in the kernel, the Linux community resisted incorporating the HIP code."
      It's not clear to me what SCTP is a counter-example for?
      section 3.2: are there an acronym expansions for "HI" and "I2"?
      "when the HI is encrypted, middleboxes in the network cannot verify the signature of the I2"
    2. Stephen Farrell: Comment [2011-11-02]:
      - A lot of this document would apply to any overlay or alternative n/w approach and not just HIP. Might be worth a mention in the abstract?
      - not all acronyms are expanded on 1st use, e.g. sigma, beet, tap
      - I wondered what were the "controversial experiences" on p10. Seems a shame to tease the reader like that.
      - What is an "I1" on p13? And "I2" on p17. Maybe expand those to the full message names or something?
      - Isn't TKK now Aalto? (p15 & p23)
      - A reference for the "double jump mobility" problem on p19 would be good.
    3. Dan Romascanu: Comment [2011-11-03]:
      A very good document. I would like to see more of this type describing experience in implementation and deployment of protocols developped in the IETF.

    Telechat:

  2. Host Identity Protocol Distributed Hash Table Interface (Experimental)
    draft-irtf-hiprg-dht-04
    Token: Ralph Droms
    Note: The document shepherd is Tom Henderson (thomas.r.henderson@boeing.com).
    Discusses/comments (from ballot 3959):
    1. Jari Arkko: Discuss [2011-11-03]:
      Ari Keränen helped me look at this draft and he pointed out the following:
      The packet defines a new HIP packet type [1] but these values can only be allocated through "IETF Consensus" which implies that the draft couldn't really come from outside the IETF [3]
      [1] http://tools.ietf.org/html/draft-irtf-hiprg-dht-04#section-8
      [2] http://tools.ietf.org/html/rfc5201#section-9
      [3] http://tools.ietf.org/html/rfc5226#section-4.1
      IESG Approval for this registry would have been the right thing. Food for thought for RFC 5201bis?
    2. Gonzalo Camarillo: Comment [2011-11-03]:
      I am clearing my discuss because Ralph had already run an IETF LC on this. Anyway, since some people in the HIP WG seem to have missed it, I have sent a note to the HIP WG's list so that everybody is aware of this draft. Additionally, I have also ask the WG to consider this issue when working on the bis specs.
    3. Ralph Droms: Comment [2011-10-18]:
      Expand acronyms on first use and/or give pointer to terminology and/or add terrninology section.
    4. Adrian Farrel: Discuss [2011-11-01]:
      A quick process question before I move to a No Objection ballot.
      Was this document explicitly brought to the attention of the HIP working group (as well as the IETF last call)?
    5. Russ Housley: Discuss [2011-11-01]:
      The Gen-ART Review by Kathleen Moriarty on 20-Oct-2011 raised a concern about the use of SHA-1. The authors said a change would be made, but it has not been posted yet.

    Telechat:

  3. IBAKE: Identity-Based Authenticated Key Exchange (Informational)
    draft-cakulev-ibake-05
    Token: Sean Turner
    IPR: Alcatel Lucent's Statement about IPR related to draft-cakulev-ibake-01
    Discusses/comments (from ballot 3990):
    1. Stewart Bryant: Comment [2011-10-31]:
      I am voting No Objection on the basis of the IESG note and a quick check that this draft has no routing implications.
    2. Adrian Farrel: Discuss [2011-11-01]:
      Before moving to No Objeciton, I would like to spend time on the call Discussing the proposed IESG note on the basis that this is not an IETF document (coming through the ISE) and so it would not be expected that it received any IETF review compared to other Informational RFCs. Furthermore, ISE documents normally carry a standard disclaimer that "this is not the work of the IETF"
      I suppose my point is: what message is the IESG note trying to send?
    3. Stephen Farrell: Comment [2011-11-02]:
      - I agree with the proposed IESG note, but I guess we need to figure out (with the ISE?) how to properly state that.
      - another case where the IPR declaration refers to a "standard" but this isn't going to be one.
      - section 1, Public key protocols do not require "large scale" PKI, as clearly demonstrated by the success of ssh. The statement is incorrect.
      - section 1, No evidence is give for the assertion that a PKG is "simple." Personally, I doubt that and the word's not needed in any case. Suggest s/simple//
      - section 1, Many IBE schemes have claimed that including dates in names avoids revocation issues. However, afaik, no one has actually done this in the wild so this claim is also just a bare assertion since the usability issues related to this idea are essentially untested.
      - section 2.1, IBE does not allow a public key to be calculated from an identity. IBE requires an identity *and* a set of PKG parameters in order to generate a public key. Truth-in-advertising would be better here.
      - Its not clear to me that two implementations of this would interoperate. That may or may not be the case, but I guess additional specification would be required. It would be good to say more about what'd be needed for that.
      - Its not really possible to evaluate the security claims of this protocol as part of a 5742 review. It'd be good if a statement to that effect were included. I'm not doubting the security claims, but they have not been exposed to wide spread review which would be needed were something like this to come out of the IETF track.
      - Its hard to see how 2119 is the only normative reference here.
      - typo: s/Privet/Private/
    4. Pete Resnick: Discuss [2011-11-02]:
      I agree with Adrian and Robert that the current IESG Note is confusing and I'm not sure what we're trying to say in it. That said, I'm also a bit concerned that this document *is* trying to extend IETF protocol (EAP?) and therefore should go through IETF process. It sounds like we suspect that IETF Review would fail to garner consensus, but that's not a reason to give the ISE a go-ahead. I may be confused on the meaning of 5742 in this regard, so I'd like to discuss.
    5. Robert Sparks: Discuss [2011-11-02]:
      The additional note in the proposed response doesn't make sense for an ISE document.
      Based on conversations with Sean, it was based on a similar note placed in an IETF stream document.
      The boilerplate for the ISE stream documents will already say:
      Independent Stream: "This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor has chosen to publish this document at its discretion and makes no statement about its value for implementation or deployment."
      The current proposed additional note ("Due to its specialized nature, this document experienced limited review within the IETF.") implies that there was some IETF review beyond the 5742 review for conflict, and could imply that _other_ documents get more IETF review. These documents get no such IETF review beyond the conflict review called out in RFC 5742.

    Telechat:

3.3.2 Returning Items

  1. (none)

1245 EDT break

1250 EDT back

4 Working Group Actions

4.1 WG Creation

4.1.1 Proposed for IETF Review

  1. (none)

4.1.2 Proposed for Approval

  1. (none)

4.2 WG Rechartering

4.2.1 Under evaluation for IETF Review

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

    Telechat:

4.2.2 Proposed for Approval

  1. (none)

5. IAB News We can use

6. Management Issues

  1. RFC 6410 Clarification (Russ Housley)

    Telechat:

  2. Designated Expert for Timezone Database (Peter Saint-Andre)

    Telechat:

  3. LISP Name (Jari Arkko)

    Telechat:

  4. Designated Expert for RFC3798 (MDN - Message Disposition Notification) [IANA #499647] (Michelle Cotton)

    Telechat:

  5. Designated Expert for RFC5797 (FTP Commands and Extensions) [IANA #499641] (Michelle Cotton)

    Telechat:

  6. Replacement expert for RFC2506 (Media Feature Tags) [IANA #496739] (Michelle Cotton)

    Telechat:

  7. Designated Expert for WebSocket (Peter Saint-Andre)

    Telechat:

7. Agenda Working Group News

Russ: thanks to shepherds and secretariat for excellent preparation which allowed us to finish early

Amy: secretariat on travel Tuesday to Thursday

1328 EDT Adjourned


Valid HTML 4.01 Strict


Appendix: Snapshot of discusses/comments

(at 2011-11-03 07:30:05 PDT)

draft-ietf-mmusic-ice-tcp

  1. Adrian Farrel: Comment [2011-11-02]:
    Section 1
    
       However, ICE only defines procedures for UDP-based
       transport protocols.
    
    I think "UDP-based transport protocols" is wrong snce UDP *is* a 
    transport protocol. 5245 talks about "UDP-based media streams" and 
    "UDP".
  2. Stephen Farrell: Discuss [2011-10-30]:
        Why is it that "RTP over TLS MUST NOT be used" (end of p10)
    and why is this specification dictating that to other
    specifications that might want to make use of ICE? There may be
    good reasons for that but they're not explained and a) I wonder:-)
    and b) dictating what other specs using this one can and cannot do
    seems like it might be a bit wrong. 
    
    I guess the obvious change could be to explain why this MUST
    NOT needs to be present, or to remove it, depending.  
        
  3. Stephen Farrell: Comment [2011-10-30]:
    - on page 3, 2nd last para where it talks about "one of the
    agents" it might be clearer to say "one of the agents (the
    offerer)"
    
    - lack of ICE-clue means I didn't get the last para of
    p5; probably just me but maybe take a look and see if you
    can make it easier on the ICE-impaired?
    
    - the last para of section 3 was unexpected - would it be better
    elsewhere? Such as after initial offers are explained?
    
    - in 4.1 would s/highly receommended/highly RECOMMENDED/ be better
    2119-wise?
    
    - 4.1 last para, be good to reference the section of whatever RFC
    defines Ta (5245 section 16 I guess)  - when I searched RFC 5389 I
    didn't find the string " Ta " which confused me. 
    
    - end of 4.3 talks about a "passive" attribute value but the 
    ABNF in 4.5 uses abbreviations "act", "pass" and "so." Why
    the inconsistency? "Pass" might also be confusing (e.g. vs.
    "fail"). Maybe saving those few bytes isn't worth it?
    
    - 5.2: "Server reflexive active candidates can be derived from
    passive or S-O candidates by using the same IP address as a
    passive or S-O server reflexive candidate from the same interface
    has." Seems like a broken sentence.
    
    - 7.2 Is "on the base of any TCP candidate" going to be clear
    to readers? Its not that clear to me but then I'm not familiar
    with ICE really, so it might just be me.
    
    - I guess I wonder how common STUN shared secrets are in the
    wild. Is this really a practical mitigation? Would it make
    sense to note this and to say that appication layer security
    ought be used since its unlikely one can really ensure that
    there is no bad actor involved if using ICE? (This isn't a
    DISCUSS on the basis, that you're probably hosed or don't
    care without that application layer security but I guess a
    lot of media applications understand this nowadays.)
    
    - Section 12 typo: s/Same considerations apply/The same
    considerations apply/
    
  4. Russ Housley: Discuss [2011-11-01]:
        
      Based on the response from the authors to the Gen-ART Review by
      Vijay Gurbani on 31-Oct-2011, I am expecting to see updates for
      Section 1 and Section 4.1. 
        
  5. Robert Sparks: Comment [2011-11-01]:
    Are you sure we can't get consent to publish this without the pre5378
    boilerplate?
    
    On page 17, the sentence "STUN is never run within the TLS or DTLS-SRTP
    session." is too strong. STUN may not occur within those sessions because of
    ICE, but some application that's using that candidate later may have a reason to
    run STUN there. I suggest adding "as part of the ICE procedures" to the end of
    that sentence.
  6. Sean Turner: Comment [2011-11-01]:
    I support Stephen's discuss.

draft-ietf-fecframe-rtp-raptor

  1. Gonzalo Camarillo: Comment [2011-11-03]:
    I support Robert's discuss and comment.
  2. Stephen Farrell: Discuss [2011-10-30]:
        (1) It isn't clear to me how the source and repair packets are
    correlated so the recipient can tell what to do and the sender
    knows what to send. Probably just my ignorance but where is that
    specified? (I only spent a few minutes looking so expect I'll clear
    once shown what I didn't find as  easily as I thought I would.)
    
    (2) cleared -  we've scheduled a chat about 
    draft-ietf-avt-srtp-not-mandatory for Taipei. 
        
  3. Stephen Farrell: Comment [2011-10-30]:
    - fecframework is now RFC6363 (I actually followed the reference
    given so the wrong reference might have but didn't mislead)
  4. Russ Housley: Comment [2011-10-30]:
      The Gen-ART Review by Brian Carpenter on 30-Oct-2011 suggests some
      editorial changes.  Please consider them.
    
      Typo in page header title.  It says: RTP Payload Fromat for Raptor
      s/Fromat/Format/
    
      There are several places where an upper-case MAY is used where a
      plain English lower case "may" would be fine:
      - all three MAYs in the Introduction;
      - the first sentence of section 3; and
      - all three MAYs in the last paragraph of the Security Conisderations.
  5. Pete Resnick: Discuss [2011-10-29]:
        1. It does not appear that section 5.1 of RFC 4288 was followed:
    
       Notice of a potential media type registration in the standards tree
       MUST be sent to the "ietf-types@iana.org" mailing list for review.
       This mailing list has been established for the purpose of reviewing
       proposed media and access types.  Registrations in other trees MAY be
       sent to the list for review as well.
    
    2. I'm concerned about putting 2119 language (and implementation instructions of
    any sort) into the registration template itself. For example, each of the
    templates has a definition of rate which says:
    
       o  rate: The RTP timestamp (clock) rate.  The operator SHALL select a
          rate larger than 1000 Hz to provide sufficient resolution to RTCP
          operations and the operator SHOULD select the rate that matches
          the rate of the protected source RTP stream.
    
    Selecting an appropriate rate seems like protocol instruction, not a suitable
    thing to put in a registration. It seems exceedingly odd to put protocol
    instructions into the definition of the parameter name. 
        
  6. Pete Resnick: Comment [2011-10-29]:
    A bunch of comments on 2119 usage:
    
    Overall: I'm not a big fan of SHALL instead of MUST; it seems to me that MUST
    works better throughout all of your uses.
    
    Specific problems:
    
    Section 3: "MAY" is not appropriate here. You're not defining a protocol option;
    you're saying that repair packets can be generated.
    
    4.1: "The following rules SHALL be followed". That's redundant, and not how 2119
    is used. The rules below each of SHALLs in them; this only needs to say, "The
    requirements for the use of the RTP header with FEC repair packets are as
    follows:"
    
    That said, I'm not clear on why the marker bit is labeled with a SHALL. The
    marker bit is set to 1 for the last packet and is otherwise 0. I suppose it is a
    requirement, but I can't imagine how an implementation could decide to set the
    marker bit to 0 for a non-final packet. Seems like a silly use of SHALL. Same
    with the definition of timestamp. You don't need a 2119 keyword to make a
    definition unless you think an implementation might incorrectly choose
    otherwise.
    
    Again, "MAY" here does not appear to be a protocol option. The timestamp can be
    used for timing and jitter calculations.
    
    4.3: Again, the two SHALLs seem inappropriate.
    
    Section 6: 
    
       o  P: The value of this parameter is the FEC Framework Configuration
          Information element "Payload ID Format" as defined in
          [I-D.ietf-fecframe-raptor].  If this parameter is missing the
          value "A" SHALL be assumed.
    
    I don't think this is an appropriate 2119 use of SHALL. It should simply say,
    "If the 'P' parameter is missing, the default value is 'A'."
    
    Section 7: The "SHALL" in the last paragraph is unnecessary. s/SHALL be/are
    
    Section 8: The 2119 language in the first bullet is fine. In the last bullet,
    the first MUST is again unnecessary. Instead of "MUST be assumed", "is the
    default" makes sense. The rest of the bullet looks fine.
    
    Section 11: "Such a cryptographic system MAY also allow..." is not a correct use
    of "MAY". That's a can. Same for "other alternatives MAY exist."
  7. Robert Sparks: Discuss [2011-11-02]:
        (Based on earlier feedback from Colin Perkins that does not appear to be
    addressed yet)
    <http://www.ietf.org/mail-
    archive/web/fecframe/current/msg00756.html>
    Section 4.1 should explain how the
    RTP payload type is chosen (dynamic 
    assignment) and signalled using SDP.  It
    should also discuss how the SSRC 
    is assigned, and how the repair RTP session is
    associated with the source 
    RTP session using RTCP.
    
    The "Applications that use this media type" sections of the media type 
    registrations need to be populated.
    
        
  8. Robert Sparks: Comment [2011-11-02]:
    While it's not a hard requirement at the moment, I think it would help
    the quality of RTP payload documents to run them through as PAYLOAD
    working group items. Please consider taking that approach with future
    payload format specifications.
  9. Sean Turner: Discuss [2011-11-01]:
        This ought to be easy enough to fix up:
    
      s6.*.1 doesn't specify the format for rate and repair-window.
      I assume they're both decimal, but I'm only guessing (and
      that's bad). 
        

draft-ietf-ospf-auth-trailer-ospfv3

  1. Ralph Droms: Comment [2011-10-29]:
    Two comments about this text from section 4.1.1:
    
    4.1.1.  Sequence Number Wrap
    
       When incrementing the sequence number for each transmitted OSPFv3
       packet, the sequence number should be treated as an unsigned 64-bit
       value.  If the lower order 32-bit value wraps, the high order 64-bit
       value should be saved in non-volatile storage.  [...]
       Once the keys have been changes, the higher order
       sequence number can be reset to 0 and saved to non-volatile
       storage.
    
    * I don't understand the second sentence.
    * s/changes/changed/
    
    I apologize if I'm missing something obvious: where is the format of
    the SA ID defined?
  2. Adrian Farrel: Comment [2011-11-01]:
    These issues do not rate a Discuss because they are not central to the
    document, but I wish you would sort them out.
    
    ---
    
    Abstract
             
    This is just about to become an RFC. Please change:
    s/draft/document/
    s/proposes/defines/
    
    Similar in the Introduction
    
    ---
    
    I am disappointed by the following paragraph in the Introduction.
    
       However, there are some environments, e.g., Mobile Ad-hoc Networks
       (MANETs), where IPsec is difficult to configure and maintain, and
       this mechanism cannot be used.  There is also an issue with IPsec not
       being available on some platforms.
    
    It would make a lot of sense to give a citation for the assertion or
    take the time to explain the problems with IPsec so that we can 
    evaluate why the solution in this document is better.
    
    I also think that the lack of availability of IPsec on some platforms
    is not relevant. After all, *no* platforms support the features
    described in this document.
    
    ---
    
    Section 1.1
    
    Please remove
    
       When used in lowercase, these words convey their typical use in
       common language, and are not to be interpreted as described in
       RFC2119 [RFC2119].
    
    ---
    
    Figure 1
    
    The text does not describe the figure, and the caption does not
    correctly indicate the content of the figure.
    
    ---
    
    Section 2.1
    
       OSPFv3 routers MUST set the AT-bit in
       OSPFv3 Hello and Database Description packets to indicate that the
       OSPFv3 router will include the authentication trailer in all OSPFv3
       packets on the link.
    
    I find this ambiguous because I read left to right. Thus I read: 
       OSPFv3 routers MUST set the AT-bit in OSPFv3 Hello and Database
       Description packets
    
    Could you flip the order of words?
    
    ---
    
    Section 2.1
    
    I see no value and possible minor downside to the inclusion of the
    figure that shows the list of existing OSPFv3 options. This list is
    maintained by IANA, and including it here creates potential conflict
    etc.
    
    Additionally, you need to consider whether this section is mandating
    that bit 13 is used as the AF-bit. It is sort of implied, but the
    IANA section doesn't quite make this clear, and there is no cross-
    reference between the two sections.
    
    ---
    
    Section 2.2
    
    s/much same as/much the same as/
    
    ---
    
    Section 3
    
       In the event that the last key associated
       with an interface expires, it is unacceptable to revert to an
       unauthenticated condition, and not advisable to disrupt routing.
       Therefore, the router should send a "last Authentication Key
       expiration" notification to the network manager and treat the key as
       having an infinite lifetime until the lifetime is extended, the key
       is deleted by network management, or a new key is configured
    
    I really tnk tat both sentences need RFC 2119 language.
    
    ---
    
    Section 5
    
       In general, all OSPFv3 routers participating on a link should be
       migrated to OSPFv3 Authentication at the same time.
    
    What does this mean?!
  3. Stephen Farrell: Comment [2011-10-24]:
    (Thanks for persevering with the overlong discussion of 
    cross-protocol attacks back in August:-)
    
    - abstract: maybe s/not depend/not only depend/?
    
    - section 2, 1st para: maybe s/as, the/as the/ and s/trailer/trailer,/ 
    
    - last sentence of section 2.1 - would s/must/MUST/ be better here?
    
    - Does 2.1 mean that if the AT bit is set in the Hello or Database
    description packets then it MUST be set in all subsequent packets
    until <sometime>? When is <sometime>?  This may be my ignorance of
    OSPF but "is preserved" isn't clear to me - it may be entirely clear
    to OSPF experts though. Or maybe a forward reference to 4.5
    and section 5 would be good. Not sure.
    
    - end of section 3 is missing a full stop.
    
    - I wasn't clear on whether or not you're requiring all coders
    to support the key lifecycle scheme in section 3. The "MUST" 
    in the 2nd last paragraph sort-of seems to make it so, but
    being explicit would be better I think.
    
    - section 4.1 s/length in octet/length in octets/
    
    - Just checking - in 4.2 if a sender ignores the SHOULD and sets the
    header checksum, and inputs that (non-zero value) to AT calculation,
    is a receiver supposed to ignore that or barf the packet? (I assume
    it ignores it if all else is ok?) Might be no harm to be explicit about
    that.
    
    - Maybe s/password/authentication key/ in section 6.
    
    - I'd suggest you encourage deployments to use long random values
    for the authentication key - while they could use the string
    "password," that'd seem like a waste;-) Maybe the following text
    might work: "Deployments SHOULD use sufficiently long and random
    values for the authentication key so that guessing and other
    cryptographic attacks on the key are infeasible in their
    environment." If you wanted to RECOMMEND those be at least 128 good
    pseudo-random bits that'd be even better. You might also want to
    encourage implementers to accept ascii-hex input or something to
    avoid potential I18N issues with typed values. 
    
  4. Russ Housley: Discuss [2011-11-02]:
        
      S4.6: when replay is detected, the OSPFv3 packet MUST be dropped.
      When authentication fails, the OSPFv3 packet MUST be discarded and
      an error event SHOULD be logged.  Why are these handled differently? 
        
  5. Russ Housley: Comment [2011-11-02]:
      S1, para 1: please add a sentence that explains that AH and ESP are
      part of IPsec.  Otherwise, the claim that IPsec does not work well in
      certain environments has no linkage to the text about AH and ESP.
    
      S4.5, step 1: to me, it would be more clear to say: "In this
      application, Ko is always L octets long, and it is computed as
      follows:"
    
      S4.6: please add a paragraph to the end that says the cryptographic
      sequence number is saved for future replay checks now that all of the
      checks have been successful.
  6. Dan Romascanu: Discuss [2011-11-01]:
        The DISCUSS is based on comments made by Joel Jaegli in his OPS-DIR review. 
    
    1. In Section 5, the first sentence - 
    
    In general, all OSPFv3 routers participating on a link should be
       migrated to OSPFv3 Authentication at the same time. 
    
    I would rather make this recommendation in a crisper manner by dropping 'In
    general' and capitalizing SHOULD
    
    All OSPFv3 routers participating on a link SHOULD be
       migrated to OSPFv3 Authentication at the same time.  
    
    2. It would be worth mentioning that unlike other potential or implemented
    extensions to ospfv3 e.g. rfc 5838 downward/backward compatibility isn't
    feasible to implement, either you support this extension or you do not. The
    approach described in section 5 while possible in some environments implies the
    simultanious operation of protected and un-protected ospf on the same devices.
    
    3. also in section 5:
    
       An implementation MAY have a transition mode where it includes the
       Authentication Trailer in the packets but does not verify this
       information.  This is provided as a transition aid for networks in
       the process of migrating to the mechanism described in this draft.
    
    should be noted that this entails risk that something that is thought to be
    working is in fact not and that it will fail when enabled 
        
  7. Dan Romascanu: Comment [2011-11-01]:
    1. section 4.1
    
          OSPFv3 routers implementing this specification SHOULD use
          available mechanisms to preserve the sequence number's strictly
          increasing property for the deployed life of the OSPFv3 router
          (including cold restarts).  Techniques such as sequence number
          space partitioning and non-volatile storage preservation can be
          used but are beyond the scope of this specification.
    
    While there are certainly ways to produce such a number that do not incur the
    saving of state (number of miliseconds since the epoc would be a good
    initialization value, requires an accurate clock before an adjacency is formed).
    This is a rather strong requirement. e.g. it implies preserving ephemeral state
    across hardware replacement. Probably more implementation advice is required.
    
    2. section 6.
    
    The assertion that this offers more security  than 5340 essentially hinges on
    the ability to offer replay protection. it does essentially abandon the use of
    ipsec for ospf protection and in doing so means theirs three ways to deploy
    ospfv3 (no security, ipsec wrapped, auth trailer) assuming the later ends up
    being preferred to ipsec there likely will be a protracted period where 2
    methods are required on given network, which has potentially interesting routing
    considerations. The final assessment in the section about 'not causing undue
    implementation, deployment, or operational complexity' may not always be true.
  8. Sean Turner: Discuss [2011-11-01]:
        #1) s3, s4.1, s4.3: So these might just be typos, but I'm trying to make sure
    something sinister isn't going on :)
    
    s3 The "Authentication Algorithm" bullet indicates authentication algorithm id
    isn't sent on the wire.
    s3 The SA ID bullet indicates that "Each SA ID specifies
    two independent parts, the authentication protocol and the authentication key,
    as explained below."
    s4.1 SA ID indicates that it "identifies the algorithm and
    the secret key".
    s4.3 indicates "As noted earlier, the SA ID implicitly
    specifies the algorithms used to generate and verify the message digest."
    
    I assume authentication protocol and authentication algorithm are supposed to be
    different? So should s4.1 be "identifies the authentication protocol and the
    secret key"?  If they're different the statement in s4.3 doesn't make sense
    because it would only imply the authentication protocol not the algorithm.
    Maybe authentication protocol and authentication algorithm are supposed to be
    the same thing!?
    
    #2) Implicit algorithm identification:
    
    NIST has done some funny things in draft FIPS 180-4.  They defined SHA-512/224
    and SHA-512/256 that are optimized for 64-bit OSes.  They output size for
    SHA-512/224 is the same as SHA-224 and the output size for SHA-512/256 is the
    same as SHA-256.  Who really knows what they're going to do with the SHA-3
    options, but what I heard at IETF 81 (from Tim Polk at SAAG) is that the winners
    are going to also end up using the same output sizes to allow them to be more
    easily be dropped in existing protocols.  This doesn't even take in to account
    somebody else coming up with the greatest hash algorithm ever that also has the
    same output lengths as SHA-*.  The way you've got it set up another algorithm
    can't be implicitly identified that that has the same output sizes as what
    you've defined.
    
    I think it is really, really short sighted to use implicitly algorithm
    selection.  Was explicit algorithm discussed in the WG? 
        
  9. Sean Turner: Comment [2011-11-01]:
    #1) s1: Mentioned AH in the 1st paragraph but don't say anything about why it's
    not viable.
    
    #2) s1: RFC 6234 obsoleted RFC 4634 so please update the reference.
    
    #3) s4.1/s7: Auth Type 1 - Maybe make it HMAC Cryptographic Authentication.
    Cryptograph Authentication is pretty darn generic.  It would be nice if you
    maybe indicated the mechanism - i.e., HMAC.
    
    #4) s4.2: Had the same question Stephen did.
    
    #5) s4.6: Need to add a pointer back to s4.5 in the last paragraph for the
    verification algorithm.
    
    #6) s6: Isn't it more secure than 5430 but only when IPsec isn't used?
    
    #7) s6: Need some motherhood and apple pie info about issues with manual keying,
    or you could point to RFC 4552 for manual keying security considerations.  Also,
    is there someplace you could point to a statement like: keep the private key
    private, when manually exchanging the key do it securely, etc.?

draft-ietf-mip4-nemov4-dynamic

  1. Ralph Droms: Discuss [2011-10-29]:
        I understand the basic idea specified in this document.  However, I
    have some questions about the details that I think need to be
    discussed before the document can be published.
    
    1. From section 3.1:
    
       [RFC5177] defines that the prefix field of the mobile network request
       extension can not be set to zero.  This mechanism works only in
       combination with the explicit mode of operation defined in [RFC5177].
    
    However, I can't find the text in RFC 5177 that explicitly requires
    that the prefix field can not be set to zero.  Am I missing something?
    
    2. The reason I looked in RFC 5177 for the constraint on the prefix
    field was to see if perhaps this document should be noted as updating
    RFC 5177.  Specifically, if RFC 5177 has text to the effect of "the
    Prefix field of the Mobile Network Acknowledgement Extension MUST NOT
    be set to zero," I would ask that the WG consider noting that
    draft-ietf-mip4-nemov4-dynamic updates RFC 5177.
    
    Even if there is no such text in RFC 5177, I think the WG should
    consider whether draft-ietf-mip4-nemov4-dynamic updates RFC 5177, as
    the former document is assigning new semantics to specific values in
    the Mobile Network extension.
    
    3. The behavior of the Mobile Client may be underspecified in section
    3.1.  Specifically, the behavior of the Mobile Client seems to be
    unchanged from the behavior specified in RFC 5177. How does the Mobile
    Client differentiate between Mobile Network Acknowledgment extensions
    sent in response to an Explicit Mode Mobile Network registration and
    a Mobile Network dynamic prefix request?  Perhaps it's not necessary
    to differentiate the two cases or a Mobile Client won't perform both
    operations simultaneously?
    
    A related question: is it possible for the Mobile Client to send more
    than one Mobile Network dynamic prefix request; if so, is it possible
    for the Home Agent to allocate a prefix for some requests while
    declining others? 
        
  2. Russ Housley: Comment [2011-10-30]:
      The Gen-ART Review by Vijay Gurbani on 28-Oct-2011 includes two
      suggestions for improved clarity.  Please consider them.
    
      S3.1: "According to this specification ...", I am not sure what "this"
      refers to.  Does it refer to draft-ietf-mip4-nemov4-dynamic or does
      it, instead, refer to rfc5177 (which is the topic of discussion in the
      previous paragraph from where the above is quoted)?
    
      S3.2, third paragraph: s/a prefix it MUST/a prefix, it MUST/
  3. Sean Turner: Comment [2011-10-31]:
    I had the same question as Ralph did about whether this draft updates RFC 5177
    (glad he beat me to the discuss).

draft-ietf-pwe3-static-pw-status

  1. Jari Arkko: Comment [2011-11-03]:
    Ari Keränen helped me review this specification and he too was concerned about
    Section 5.3 (PW OAM status message transmit and receive):
    
    [...] the PW OAM
    message containing the PW status TLV needs to be transmitted
    repeatedly to ensure reliable message delivery. [...]
    A PW OAM message containing a PW status TLV with a new status bit set
    or reset, will be transmitted immediately by the PE. The PW OAM
    message will then be repeated twice more at an initial interval of
    one second.
    
    The message is always sent 3 times during the first 3 seconds? How about
    ACKs?
  2. Wesley Eddy: Comment [2011-11-02]:
    I support Russ's DISCUSS.
  3. Adrian Farrel: Discuss [2011-11-01]:
        I had real problems with Section 4.
    
    - The mention of MPLS and MPLS-TP is curious since MPLS-TP is just a
      subset of MPLS.
    
    - The text doesn't give a reason for the MUST and MUST NOT
    
    - There is no reference to RFC 6310 which is really the justification
      for this work.
    
    - I really do not think you are updating RFC 5885. If anything, you are
      updating RFC 6310 that says:
    
        Additionally, such a PE MAY use VCCV-BFD CV for both fault detection
        and status notification (CV types 0x08 and 0x20 [RFC5885]).
    
      But, frankly, I don't think this is much of an update that is worth
      mentioning.
    
    Here is a shot at updating the text. If you like this, you will need
    to remove the "updates RFC 5885" stuff from the rest of the document.
    
    OLD
       The procedures described in this draft are intended for the case
       where PWs are statically configured. These procedures also apply
       equally to both an Multi Protocol Label Switched Packet Switched
       Network (MPLS PSN) , and an Multi Protocol Label Switched Transport
       Profile (MPLS-TP) PSN. Where an LDP control plane exists, LDP MUST be
       used for signaling all PW status messages.  However the OPTIONAL 'S-
       PE' bypass mode described below MAY be used in the presence of an LDP
       control plane.
    
       This document updates [RFC5885] as follows:
    
       When BFD is used, and the Pseudowire Status protocol for Static
       Pseudowires described in this document is used BFD MUST NOT be used
       to convey PW status signaling information (CV Types 0x08 and 0x20
       MUST NOT be used).
    NEW
       As described in [RFC6310], a PE that establishes an MPLS PW using 
       means other than LDP, e.g., by static configuration or by use of BGP,
       MUST support some alternative method of status reporting. The
       procedures described in this document are for use when PWs are 
       statically configured and a LDP control plane is not available.
    
       As defined in [RFC6310], a PE that establishes a PW using LDP and 
       that has negotiated use of the LDP status TLV per Section 5.4.3 of 
       [RFC4447], MUST use the PW status TLV mechanism for AC and PW status
       and defect notification on that PW. In order to avoid duplicate
       notifications and potentially conflicting notifications, such PEs
       MUST NOT use the mechanisms described in this document for those PWs,
       except that the 'S-PE' bypass mode described in Section 5.5 MAY be
       used in all situations.
    
       A PE that establishes a PW using LDP and does not negotiate the use
       of the LDP status TLV, MAY use the mechanisms described in this 
       document.
    
       In order to protect against duplicate notifications and potentially
       conflicting notifications, when the Pseudowire Status protocol for 
       Static Pseudowires described in this document is used, the BFD-VCCV
       status signaling mechanisms described in [RFC5885] (CV Types 0x08 and
       0x20) MUST NOT be used. VCCV-BFD Connectivity Verification (CV) for
       fault detection (CV types 0x04 and 0x10) MAY still be used.
    END
    
    ---
    
    Section 5.1
    
    Don't you need to create an IANA registry for the Flags field in the 
    ACH PW OAM Message Packet Header?
    
    ---
    
    Section 5.1 needs to state which TLVs can be present. The first
    paragraph of the section implies that only the PW status TLV is present.
    
    ---
    
    Section 5.2
    
       The PW Status TLV format as defined in [RFC4447], and is
       repeated here for the reader's convenience:
    
        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |Res|     PW Status (0x096A)    |            Length             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                          Status Code                          |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                 Figure 2: PW Status Message Format.
    
    So, is this the TLV format or the message format?
    
    ---
    
    Section 5.2
    
       To clear a particular status indication, the PE needs to send a new
       PW OAM message containing a PW Status TLV with the corresponding bit
       cleared.
    
    This would be fine if there had been any mention of "corresponding bits"
    up to this point (or indeed at any other point) in the document. All I
    can find is an identical statement in Seciton 5.3.
    
    Please clarify how a status indication is cleared.
    
    ---
    
    Section 5.2
    
       PW OAM Status Messages MUST NOT be also used as
       a connectivity verification method.
    
    Strike "also" because they must not be used, period.
    And I support that, but you need to say what you would do if you sent a
    status message and did not receive a message with the A flag set.
    
    ---
    
    Section 5.3
    
    There is no discussion of how to handle the refresh timer value when the
    A flag is set as introduced in Section 5.1.
    
    ---
    
    Section 5.3.1
    
       The PE receiving a PW OAM message containing a PW status message can
       acknowledge the PW status message by simply building an almost
       identical reply packet with the A bit set, and transmitting it on the
       PW ACH back to the source of the PW status message.
    
    "can" is not an RFC 2119 word, so I am unclear what an implementation is
    supposed to do. There is no perceptable benefit for sending an ack as 
    far as I can see since there is no described behavior if an ack is not
    received.
    
    Furthermore, in Section 5.3 we have a statement that under some 
    circumstances an Ack MUST be sent.
    
    ---
    
    Section 5.5
    
       Currently the only PW status codes which MAY be sent using the S-PE
       bypass procedure are:
    
    That is not a "MAY"! You are trying to "Other status codes except for 
    those listed MUST NOT be sent using the S-PE bypass procedure"
    
    ---
    
    Section 5.5
    
    It seems to me that the S-PE bypass mode has a race condition that 
    causes a quirk. The final sentence of 5.5 says...
    
       However the same PW Status TLVs MUST
       also be sent in LDP to keep the S-PEs state updated.
    
    The implication here is that a fault (say x2) is raised and sent by both
    mechanisms. The fault clears rapidly and the fault clear is sent by both
    mechanisms. Because of speed of delivery, the egress T-PE will see the
    fault raised and cleared twice.
    
    I need to be convinced that this does not matter.
    
    ---
    
    Section 5.5.1
    
       When a PW Segment along an MS-PW is using the LDP control protocol, a
       flag bit MUST be set in the interface parameters sub-TLV to indicate
       that the T-PE is requesting S-PE bypass status message mode.
    
    Surely you don't mean this! Do you mean:
    
       When a PW Segment along an MS-PW is using the LDP control protocol
       wishes to request use of the S-PE bypass status message mode, it sets
       the B bit in the interface parameters sub-TLV as shown in Figure 3.
    
    I think you need an IANA registry for the flags in the interface
    parameters sub-TLV.
    
    Oh, and please label Figure 3 correctly! The caption is also wrong.
    
    ---
    
    Seciton 7 is inadequate. The referenced documents do not describe the
    security of the ACH. While I believe this has been documented elsewhere,
    you need to give a correct reference. 
        
  4. Adrian Farrel: Comment [2011-11-01]:
    Please consider whether [REDUNDANCY] really needs to be a normative 
    reference. I don't think you use it in that way.
    
    ---
    
    Section 6 and its sub-section could be more careful about whether PWs or
    PW segments are switched.
    
    ---
    
    4385 and 4447 are messed up in the references section.
  5. Stephen Farrell: Comment [2011-10-30]:
    - section 2: s/two Provider Edge (PE)/two Provider Edge (PE)
    devices/?
    
    - section 2: s/and [REDUNDANCY].../and elsewhere [REDUNDANCY]/
    
    - 5.3 1st para: if an unknown or malformed TLV is received but
    in a message containing >1 TLV, does that imply anything about
    the other TLVs in that message?
  6. Russ Housley: Discuss [2011-11-02]:
        
      The Gen-ART Review by Ben Campbell was updated on 31-Oct-2011.
      Ben previously raised a concern about Section 5.3; he asked:  Has the
      work group considered how the retransmit scheme and 30 second refresh
      default will scale to very large deployments?  Seems like this could
      result in a lot of retransmissions.  Ben received two responses to
      this comment.
    
      Stewart Bryant responded:
      >
      > Are you concerned about the network traffic or the PE load.
      > In the case of the network traffic, this is trivial compared to the
      > data traffic that these systems and their networks are designed to
      > carry.
      >
      > In the case of PE load, the PE is designed to deal with it.
    
      Luca Martini responded:
      >
      > Yes. that is correct. This will most likely not scale for large
      > deployments. We have another document that addresses this issue.
      > That extension is not necessary for most common small deployments
      > in the order of 100 PWs per access PE.
    
      Either of these responses seem fine to me, but one of them should
      find its way into the document. 
        
  7. Dan Romascanu: Discuss [2011-11-02]:
        In Section 5.2: 
    
       The PW Status TLV format as defined in [RFC4447], and is
       repeated here for the reader's convenience:
    
    and then: 
    
      The first 2 bits are reserved, and MUST be set to zero on transmit,
       and ignored on receive.
    
    However in RFC 4447, in section 5.4.2 the first two bits of the PW Status TLV
    are represented as 10.
    
    This seems inconsistent. DO I miss something? 
     
        
  8. Dan Romascanu: Comment [2011-11-03]:
    1. I support Russ's DISCUSS
    
    2. [closed]
  9. Sean Turner: Comment [2011-10-31]:
    These would probably all get fixed by the RFC editor, but I noticed them so I
    included them here.
    
    1) Header should be:
    
      Updates: 5585 (if approved)
    
    2) There's a "MUST not" in s5.3 - is that supposed to be "MUST NOT"?
    
    3) Expiry date in status of memo section doesn't match the date in the header.

draft-ietf-payload-rfc3189bis

  1. Russ Housley: Comment [2011-10-30]:
      The Gen-ART Review by Francis Dupont on 14-Oct-2011 includes a few
      editorial suggestions.  Please consider them.
    
      - S3.3.1, page 14: I suggest m=* in place of m=??
    
      - S4, page 15: in general encryption is done after compression for
      crypto reasons and common sense: quality encryption gives a random
      result, i.e., something impossible to compress...
  2. Pete Resnick: Comment [2011-10-30]:
    Sent in email to IANA as well: RFC 3189 ought to have registered audio/DV when
    it was published in 2002, yet there is no registration for audio/DV. IANA should
    probably register audio/DV now with a pointer to 3189 and simply update to this
    document once approved.
  3. Dan Romascanu: Comment [2011-10-30]:
    1. In the intorduction the following phrase is duplicated in adjoining
    paragraphs:
    
    > In the future it can be extended into other video formats managed by
       80 byte DV Digital Interface Format (DIF) block.
    
    2. Please expand at the first occurence IEC, SMPTE, MLDv2, LW-IGMPv3
    
    3. It is not clear what is the meaning of the statement in the interoperability
    section 8:
    
    > In addition, the SDP examples in RFC3189 provides incorrect SDP
       "a=fmtp" attribute usage.
    
    Is the example made not relevant or corrected by this document? Why does it show
    in the interoperability section 8 and not in section 7 (changes from RFC 3189)?

draft-ietf-avtext-client-to-mixer-audio-level

  1. Stewart Bryant: Comment [2011-11-01]:
       "A malicious endpoint could choose to set the values in this header
       extension falsely, so as to falsely claim that audio or voice is or
       is not present.  It is not clear what could be gained by falsely
       claiming that audio is not present, but an endpoint falsely claiming
       that audio is present could perform a denial-of-service attack on an
       audio conference, so as to send silence to suppress other conference
       members' audio.  "
    
    ... you could also dominate the conversation by always claiming that you have
    strong audio present.
    
    =======
    
    This security  consideration from the mixer to client looks like it might be
    applicable
    
    2.  Furthermore, the fact that audio level values would not be
           protected even in an SRTP session might be of concern in some
           cases where the activity of a particular participant in a
           conference is confidential.  Also, as discussed in
           [I-D.perkins-avt-srtp-vbr-audio], an attacker might be able to
           infer information about the conversation, possibly with phoneme-
           level resolution.
  2. Adrian Farrel: Comment [2011-11-03]:
    I think Stewart's security point is valid, although I am not quite sure how this
    differs from simply raising your voice.
  3. Stephen Farrell: Comment [2011-10-30]:
    (1) If vad can expose encrypted vbr, then why don't the security
    considerations here say "if encrypting vbr and doing vad then you
    MUST use apply commensurate protection to both"? I don't get the
    logic in the current section 6 where it says "if encrypting vbr
    and doing vad then you SHOULD use some additional mechanism" -
    what's the exceptional case that justifies the SHOULD there and
    why would you ever do something appreciably weaker or stronger?
    
    (2) Is the alternative to srtp-encrypted-header-ext to use IPsec or
    TLS or what? It'd be better to reference those since if you don't
    then I don't get how srtp-encrypted-header-ext isn't a normative
    reference? I'd suggest adding a reference to either TLS or IPsec,
    whichever is more likely to be used.
  4. Robert Sparks: Discuss [2011-11-01]:
        Updating now that I've heard why we don't need the pre5378 boilerplate:
    
    Several paragraphs in this document are heavily influenced by RFC3389.
    
    One bit of borrowed text speaks of expressing audio level "relative to the
    overload point of the system". Even though that text exists in 3349, I'm not
    sure it's as clear as it needs to be. What is "the system" in this context, and
    where are its boundaries?
    
    The first full paragraph on page 5 (beginning "The audio level header extension
    only carries the level of the audio in...) works well for payload formats that
    are a sequence of samples, but I'm not sure the description works as well for
    encodings that are more intricate. Are implementations expected to reconstruct
    the equivalent of a PCM encoding from whatever encoding is in use to calculate
    this level value? The section later talks about how redundant data (2198)
    wouldn't affect the level measure. Shouldn't it also say something about error
    correcting bits or information used in some encodings for loss concealment also
    not affecting the measure? 
        
  5. Robert Sparks: Comment [2011-11-01]:
    The Security Considerations section sketches a scenario where an attacker sends
    high level indications, but encoded audio that is actually silent to suppress
    other participant's audio. A more likely attack is one that sends high level
    indications just to seize any speaker-selection algorithm used by a conference
    system.
  6. Sean Turner: Comment [2011-10-31]:
    I noted the same things Stephen did.

draft-ietf-avtext-mixer-to-client-audio-level

  1. Stephen Farrell: Comment [2011-10-30]:
    Same comments as for client-to-mixer
    
    (1) If vad can expose encrypted vbr, then why don't the security
    considerations here say "if encrypting vbr and doing vad then you
    MUST use apply commemsurate protection to both"? I don't get the
    logic in the current section 6 where it says "if encrypting vbr
    and doing vad then you SHOULD use some additional mechanism" -
    what's the exceptional case that justifies the SHOULD there and
    why would you ever do something appreciably weaker or stronger?
    
    (2) Is the alternative to srtp-encrypted-header-ext to use IPsec
    or TLS or what? It'd be better to reference those since if you
    don't then I don't get how srtp-encrypted-header-ext isn't a
    normative reference? I'd suggest adding a reference to either TLS
    or IPsec, whichever is more likely to be used.
    
  2. Dan Romascanu: Comment [2011-10-30]:
    1. Lionel Morand made in his OPS-DIR review a number of comments which I suggest
    to be taken into consideration by the authors or RFC Editor:
    
    * Overall comment: the document defines a new optional RTP header extension to
    support a new service capability. However, it should be clarified somewhere
    (e.g. in the protocol description) the condition of service applicability e.g.
    all the entities involved need to support this extension.
    
    * In section 1, figure 1: even if it is just for illustration, please indicate
    what would be the meaning of (S) and (M)
    
    * In section 3: I'm not a specialist of RTP and use of mixers. However it might
    be desirable to extend the section dealing with the possible cascade of mixers.
    It is not obvious how each mixer will be involved along the path. Especially, it
    is not clear what is the rational that leads to the conclusion:
    "it is likely
    that in such situations average audio levels would be perceptibly different for
    the participants located behind the different mixers."
     
    * In section 5, it is
    said:
       "Conferencing clients that support audio level indicators and have no
    mixing capabilities would not be able to provide content for this
       audio level
    extension and would hence have to always include the
       direction parameter in
    the "extmap" attribute with a value of
       "recvonly".  Conference focus entities
    with mixing capabilities can
       omit the direction or set it to "sendrecv" in
    SDP offers.  Such
       entities would need to set it to "sendonly" in SDP answers
    to offers
       with a "recvonly" parameter and to "sendrecv" when answering other
    "sendrecv" offers."
    
    Question: Is the setting of the direction parameter purely informative (sorry
    for my ignorance)? If not i.e. there are associated requirements, the above text
    is not appropriate (e.g. "would have to always", "would need") and "MUST" should
    be used instead.
    
    * Figure 4 and 5: The description of each example should be put above the
    figures. Even if obvious, please indicate for clarification "SDP Offer:" and
    "SDP Answer:" on top of the lists of SDP parameter.
    
    * Figure 4:
       "A client-initiated example SDP offer/answer exchange negotiating an
       audio stream with one-way flow of of audio level information."
    
    s/one-way flow of of audio/one-way flow of audio
    
    2. Please expand CSRC at first occurence
    
    3. Please replace the conditional language in the first paragraph of the IANA
    considerations section.
  3. Robert Sparks: Comment [2011-11-01]:
    The code in the appendix should be explicitly marked as a code component as
    indicated in Sean's discuss.
  4. Sean Turner: Discuss [2011-10-31]:
        <process weenie> 
    
    According to the IETF's TLP you need to put: 
    
    <CODE BEGINS>
    
    /*
    
       Copyright (c) 2011 IETF Trust and the persons identified
       as authors of the code. All rights reserved.
    
       Redistribution and use in source and binary forms, with
       or without modification, is permitted pursuant to, and subject
       to the license terms contained in, the Simplified BSD License
       set forth in Section 4.c of the IETF Trust’s Legal Provisions
       Relating to IETF Documents (http://trustee.ietf.org/license-info).
    
    */ 
    
    code goes here
    
    <CODE ENDS>
    
    in A.1.
    
    </process weenie> 
        
  5. Sean Turner: Comment [2011-10-31]:
    I noted the same things as Stephen.

draft-ietf-vcarddav-kind-app

  1. Adrian Farrel: Comment [2011-11-01]:
    Would the DEATHDATE property be applicable if KIND shows an
    "application" to say when the software crashed or was uninstalled?
    
  2. Russ Housley: Discuss [2011-10-30]:
        
      The Gen-ART Review by Roni Even on 29-Oct-2011 raises one concern.
      Please respond to this concern.
      
      I noticed that the example in section 3 is presented as XML, but I
      did not see any text about adding the new kind to the relax NG schema.
    
       property-kind = element kind { element text { "individual" | "group" | "org"
    | "location" }* } 
        
  3. Sean Turner: Comment [2011-10-31]:
    From nits checkers:
    
     == Outdated reference: draft-ietf-vcarddav-vcardrev has been published as
         RFC 6350
    
      == Outdated reference: draft-ietf-vcarddav-vcardxml has been published as
         RFC 6351

draft-ietf-vcarddav-birth-death-extensions

  1. Stewart Bryant: Comment [2011-11-01]:
    Looking at the other comments, I do wonder whether we need a lighter weight
    registration scheme for these vcard attributes.
    
    Wouldn't expert review be adequate?
  2. Wesley Eddy: Comment [2011-10-26]:
    It would be interesting to know why date and place of death are considered
    useful information in a vcard, since that goes beyond most people's use of an
    address book or contact list.
  3. Adrian Farrel: Comment [2011-11-01]:
    Well, ain't it weird? RFC 6350 describes the purpose of vCard as...
    
       allows the capture and exchange of
       information normally stored within an address book or directory
       application.
    
    IMHO, the death place and death date are not pertinent for such
    applications. So, probably, people use vCard for more widespread
    information storage. That may be OK, but I guess someone should say
    so, somewhere.
    
    This seems to follow up the comments from a number of other ADs
    and I also wonder about inside-leg-measurement.
    
    ---
    
    Suppose I know someone is dead, but don't know where or when. How do I
    represent that in your new properties?
    
    Including a place of death without a date of death, would clearly show
    the person is dead. Similarly including a date of death without a place
    would let me know. but obviously if both fields are absent it says 
    nothing one way or the other.
    
    Maybe you could give as one of the examples...
    
           DEATHDATE;VALUE=text:unknown
    
    ...and that states that the person is actually dead,
    
    But what about if you actually do not know whether the person is dead,
    and you want to convey this?
    
    And what do I now assume about a vCard that does not include the death
    properties? Is that person alive?
    
    ---
    
    Section 3 says:
    
       This presents no security considerations beyond those in section 9 of
       the base vcard specification [RFC6350].
    
    But surely you have opened up the Internet to attacks from Zombies and
    Vampires?
  4. Stephen Farrell: Comment [2011-10-30]:
    Is this really needed? There's no real justification
    and why wouldn't I follow this up with an equivalent
    for height, shoe size, trouser size, favourite-drink, 
    scratches-nose-occasionally or whatever? Do we 
    really want an RFC for each and every such 
    thing/attribute?
    
    
  5. Russ Housley: Comment [2011-10-31]:
      The Gen-ART Review by Martin Thomson on 16-Sep-2011 raised a few
      questions.  Please consider them.
    
      Did anyone consider that a RESTINGPLACE tag might be added?  It seems
      like in some instances it could be more useful than DEATHPLACE.  That
      might be more relevant for certain "objects".  At risk of sounding
      macabre, for some "objects" this might need to allow multiple values.
    
      I note that there seems to be some contention about the precise
      coordinates to use in identifying the wreck, though it appears that
      Wikipedia (41?43'55"N, 49?56'45"W) was used as a source in this
      instance.
  6. Dan Romascanu: Comment [2011-11-03]:
    1. As other ADs have noticed place and date of death do not seem to fit
    comfortably within the scope of the typical information carried by vcards. It
    would be useful to add some text about applicability, maybe examples.
    
    2. One of the more current information included in biographies when talking
    about the pace of birth is the country of birth. Did the authors and WG discuss
    including this information, maybe the ISO 3166 country codes? This question
    also applies for the place of death
  7. Sean Turner: Discuss [2011-11-03]:
        1) Does the template allow "description" to be empty?  Sometimes folks really
    don't like normative language in the ABNF - maybe in the description is where
    you could duplicate the normative requirements from the ABNF.
    
    2) cleared 
        

draft-ietf-avtcore-srtp-vbr-audio

  1. Stewart Bryant: Comment [2011-11-01]:
    I agree with the Discusses raised by Peter and Stephen.
    
  2. Adrian Farrel: Comment [2011-11-03]:
    Well, I think this is a fine document. An extra editorial pass would help and
    it would be handy for future generations if the document title mentioned
    "security".
    
    Personally, I would have taken out all RFC 2119 language and made this an
    Informational document that gave advice for people thinking about the problem,
    deploying, and implementing. But I intend staying out of that debate and
    watching the rest of the IESG squabble.
  3. Stephen Farrell: Discuss [2011-10-28]:
        I think this is a welcome and useful document, but needs a bit more
    work so we can be confident in the BCP recommendations.
    
    (1) There is more recent work [1] on this topic that is not
    referenced and, I think, needs to be. That's the easy one:-)
    
       [1] White, A.M.; Matthews, A.R.; Snow, K.Z.; Monrose, F.; ,
       "Phonotactic
    Reconstruction of Encrypted VoIP Conversations:
       Hookt on Fon-iks," Security
    and Privacy (SP), 2011 IEEE Symposium
       on , vol., no., pp.3-18, 22-25 May 2011
    doi: 10.1109/SP.2011.34
       URL:
    http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=5958018&isnumber=5958008
    
    (2) The harder one: does [1] mean that changes to these
    recommendations are needed or not? I think this BCP needs to answer
    that question.  In particular, does the claim that "VBR codecs
    should be considered safe in the context of encrypted unstructured
    calls" need some additional qualification over and above the
    "pre-recorded messages" caveats already given?
    
    (3) Google scholar returns 54 citations to [spot-me] so it looks
    like there has been more work on this topic in addition to [1] since
    2008. Have the authors checked that literature to see if any other
    recommendations should be included in this BCP? 
    
    (4) The recomendation in section 4, 2nd para on the length of the
    overhang period seems to just state a requirement without actually
    saying how to do that. Here I mean that you say that the length of
    the overhang must be chosen so that something is infeasible but you
    don't say how to achieve that. It might be that the next paragraph
    is is trying to say how to do it when describing the
    exponentially-decreasing PDF - is that the claim? If so, can you
    make that clear?  If not, then can you provide at least one way to
    meet the requirement?
    
    (5) Its not clear to me how a program or programmer can decide when
    a scenario applies where "VBR is unsafe," unless "unsafe" basically
    means pre-recorded messages only. If unsafe encompasses more
    scenarios than that, how does one know when to apply the
    recommendations in section 5? (This discuss point is predicated on
    there being something new to add as a result of discuss points 2 or
    3 above. If points 2 and 3 are sorted without there being anything
    else to say, then I think this one would also go away.)
    
    (6) We're hoping to get a saag presentation on this topic in Taipei.
    If that happens, then there may be additional points arising so this
    is just a placeholder discuss until after that presentation (if it
    happens). 
     
        
  4. Stephen Farrell: Comment [2011-10-28]:
    - maybe s/must be randomly chosen/MUST be randomly chosen/ in 2nd
    para of section 4 and s/must be packetised/MUST be packetised/
    similarly at the top of p5?
    
  5. Russ Housley: Comment [2011-10-30]:
      The Gen-ART Review by Ben Campbell on 21-Oct-2011 raises a few
      comments.  Please consider them.
      
      - Section 1, paragraph 2: "...can be recognised with high accuracy..."
        That seems like a bit more than a "small amount of information"
    
      - Section 2, 1st paragraph: "... is already considered a hard problem"
        Who considers it?
    
      - Section 4, last paragraph: "It is, however, still expected..."
        Who expects it?
    
      - section 6: It might be worth mentioning that this entire draft is
        about security.
  6. Pete Resnick: Discuss [2011-10-31]:
        I don't see how this is remotely a BCP. This should be on the standards track.
    It is specifying all sorts of implementation parameters that are clearly
    testable, may have interoperability implications, and may change over time as we
    get implementation experience. (E.g., the length of the overhang period may be
    something that we specify differently, whether VAD is used or not may have
    interoperability implications, etc.). This discussion would have normally
    happened in the context of a security considerations section of a base protocol
    document and would have gone along the standards track with the base protocol.
    The fact that it is being published separately shouldn't change its treatment. 
        
  7. Peter Saint-Andre: Comment [2011-11-02]:
    I concur with much of the feedback provided by other IESG members.
    
    Please clean up various infelicities in coordination with the RFC Editor team
    ("possible sentences are possible", "easily use the rate information to easily
    recognize", etc.).
  8. Sean Turner: Comment [2011-11-01]:
    I support Stephen's discuss.

draft-ietf-tls-dtls-heartbeat

  1. Jari Arkko: Discuss [2011-11-03]:
        The document says:
    
      The receiving peer SHOULD discard it silently, if it
       arrives during or after the handshake.
    
    I think you need to specify the "or after" part better. Is this a time-based
    determination, or something based on sequence numbers that show that the packet
    with the heartbeat arrived later than the packets involved in the handshake?
    
    Note that one side can initiate a handshake at time t0, another side a heartbeat
    at t1, and the first handshake packet comes to the side that did the heartbeat
    at t2, t2>t1>t0.
    
    Similarly, it is possible that one side has completed a handshake and and sends
    a heartbeat right after, but the last packet of the handshake and the hearbeat
    change order in flight, making the other side think that that heartbeat is being
    run during a handshake.
    
    You do say that communications should be idle for a period before initiating the
    heartbeat exchange. I suspect that for PMTU purposes you might want to send some
    heartbeats immediately in some cases. 
        
  2. Wesley Eddy: Comment [2011-11-02]:
    Stephen's DISCUSS seems very important to consider, though I'm no expert in this
    area, I support Stephen's DISCUSS.
  3. Adrian Farrel: Discuss [2011-11-02]:
        The document does not describe how often to send a heartbeat. Calling it
    a heartbeat implies that it is sent (and responded) at regular 
    intervals.
    
    5.1 is pretty obviously not intended to be more than a probe.
    
    5.2 gives some guidance by saying...
    
       ...allows a check at a much higher rate than the TCP keep-alive
    
    and
    
       HeartbeatRequest messages SHOULD only be sent after an idle period
       that is at least multiple round trip times long.
    
    I think you need to give *much* better guidance about the lower bound.
    
    You might also suggest a default "idle period", and you should define
    what you mean by "idle period".
    
    You really should discuss whether the "idle period" needs to be 
    configurable. 
        
  4. Adrian Farrel: Comment [2011-11-02]:
    Section 4
    
       When a HeartbeatRequest message is received, a corresponding
       HeartbeatResponse message MUST be sent carrying an exact copy of the
       payload of the HeartbeatRequest.
    
    I know what you mean, but several places in the text contradict this by
    giving cases when a response is not to be sent.
    
    ---
    
    I wonder why section 5.2 doesn't discuss the question of whether it is
    necessary to have both ends transmitting heartbeats, or good enough for
    just one to do it.
  5. Stephen Farrell: Discuss [2011-10-31]:
        This discuss is checking a niggling concern. While I expect the
    outcome to be "no change," and for that to happen quickly, I still
    wanna ask just in case...
    
    (1) This involves sending partly predictable plaintext messages
    that are then encrypted, with predictable, almost identical
    cleartext for the responses and so that the keys used on both
    sides are derived from the same (pre)master secret.  Has anyone
    looked seriously at that specific combination to see if there's
    any weakness for any known/conceivable ciphersuite?
    
    (2) I have not done the work asked-for in (1), and know of no
    specific problem, but would it make sense, just in case, to have
    some bytes early in the heartbeat_response set randomly by the
    responder? (Or some such thing to make the plaintexts differ
    more.)
    
    (3) If there were to be any weakness then would it be right to say
    "If a received HeartbeatResponse message does not contain the
    expected payload the message MUST be discarded silently."
     
        
  6. Pete Resnick: Comment [2011-10-31]:
    Section 3 says, "If no corresponding HeartbeatResponse message has been received
    after some amount of time, the DTLS/TLS connection MAY be terminated by the
    user." Who is "the user" in this case? The reason I ask is that I'm afraid this
    sentence is going to cause some not-so-bright implementers to need instructions
    like we had to provide in draft-ietf-tcpm-persist, taking it to mean that only
    an end-user can terminate a DTLS/TLS connection. Do you mean "the application
    that initiated the HeartbeatRequest can terminate the connection"? Or that "the
    DTLS/TLS layer can terminate the connection"? A little more clarity here would
    minimize future stupidity.

draft-ietf-ippm-metrictest

  1. Ralph Droms: Comment [2011-10-30]:
    I have just one small editorial comment.  I can't parse this test from
    Section 2; it might need some clarification:
    
       o  The error induced by the sample size must be small enough to
          minimize its influence on the test result.  This may have to be
          respected, especially if two implementations measure with
          different average probing rates.
    
  2. Adrian Farrel: Comment [2011-11-03]:
    A useful document, thanks.
    
    Hope you'll be removing the change log before publication.
    
    I agree with Sean about the Code Copyright boilerplate.
  3. Russ Housley: Discuss [2011-11-02]:
        
      This seems to be a process document.  Shouldn't it be a BCP? 
        
  4. Pete Resnick: Comment [2011-10-31]:
    I agree with the DISCUSS comments of others:
    
    1) This should be a BCP, not Standards Track.
    2) This should be updated to take into account RFC 6410.
    
    I also think that the use of 2119 language in here is superfluous, if not just
    wrong. I don't see what difference it makes to a reader of this document to say,
    e.g., "The conditions for which the ADK test has been passed with the specified
    confidence level must be documented" instead of "MUST be documented."
  5. Dan Romascanu: Discuss [2011-10-30]:
        This is a very useful document, but some clarifications are needed before I can
    approve it
    
    1. In section 2 the following statement is being made: 
    
    > Metric
       specification options chosen by implementors have to be documented.
       It is REQUIRED to use identical implementation options wherever
       possible for any test proposed here.  
    
    I am questioning the reason for requiring the use of the same implementation
    options in testing. In real life different implementations may pick different
    implenmentation options. It looks to me that a stable and interoperable metrics
    definition would yield consistent results even if different implementation
    options are being chosen.
    
    2. In Section 3.3
    
    > In some cases, a goodness of fit test may not be possible or show
       disappointing results.  To clarify the difficulties arising from
       different implementation options, the individual options picked for
       every compared implementation SHOULD be documented in sufficient
       detail.  Based on this documentation, the underlying metric
       specification should be improved before it is promoted to a standard.
    
    I believe that test needs to be added here to clarify what 'improve' means. If
    we deal only with clarification of the differences between implementation
    options, or even exclusion of one or more of the options from the specifications
    the advancement on the standards track may still be possible. However if the
    'improvement' changes the definition or adds new options recycling at Proposed
    Standard level is necessary.
    
    3. Why is this document Standards Track and not BCP? 
    
    4. idnits indicates two downrefs to RFC 2330 and RFC 4459 (both Informational) -
    where these Last Called? 
        
  6. Dan Romascanu: Comment [2011-10-30]:
    1. The text about changes between different I-D versions needs to be taken out
    in the final version of the document.
    
    2. Are [morton-advance-metrics] and [morton-advance-metrics-01] previous
    versions of the same document? In any case it does not make sense to include two
    versions of the same document as references.
    
    3. page 14: 
    
    > For example, if 802.1Q
       Ethernet Virtual LANs (VLAN) are applied 
    
    Drop 'Ethernet' - the Virtual LANs are not Ethernet-specific
    
    4. runing idnits points to a number of unused references
  7. Robert Sparks: Comment [2011-11-02]:
    I support each of Dan's discuss points, and with Sean's observation about code
    components.
    
    There are several places where 2119 keywords are used in non-meaningful ways. It
    would strengthen
    the document to review and remove the instances that are not
    truly needed. (The use of RECOMMENDED
    at the top of page 10 is a particularly
    strong example.)
    
    When you update the document to take RFC 6410 into account, please note
    that
    while interop reports are no longer required in general, if you have consensus
    to do so, you can still require them for advancing these metric definitions. If
    you
    chose not to require them, please consider text strongly encouraging them.
    
    There are several places where you REQUIRE something "whenever possible". That
    leaves a lot of vagueness in the specification (is "it costs too much" a
    reasonable excuse for
    "not possible"?). Please consider removing the exception
    clause, or at least explicitly discussing 
    what to do or what it means when
    meeting that requirement is not possible.
    
    The first paragraph of 3.1 (stating an implementation MUST implement all the
    MUSTs in a specification)
    is vacuous - please remove it.
    
    Or perhaps the intent of the whole section was to clarify what's required to be
    reported in an
    implementation report and you were asking for an explicit
    statement that the implementation
    implemented all the MUSTs - if so, please
    clarify. That would be consistent with the second paragraph
    of 3.1 which appears
    to be asking that the report document which options were supported in
    "sufficient
    detail". But what defines sufficient, and for what purpose? Please
    consider continuing that sentence 
    ("in sufficient detail to <achieve this
    documented goal>").
    
    Please consider addressing the following nits.
    
    The string "state of the art" isn't adding anything useful to the text - please
    remove it.
    
    The third paragraph of section 3.5 does not parse - should "by" be deleted?
    
    Why is there a link to xml.resource.org in the first paragraph of Appendix A.
  8. Sean Turner: Discuss [2011-10-31]:
        <discuss-discuss>
    
    This is a discuss-discuss that I think we should talk about on the call:
    
    So isn't this draft updating RFC 2026?  It says 2026 defines some rules, but
    they're kind of hard to apply to our RFCs, so here's our process to determine if
    they should progress to Internet Standard.
    
    </discuss-discuss>
    
    RFC 6410 reduced the number of levels to two: "Proposed Standard" and "Internet
    Standard".  Has this draft been reviewed keeping RFC 6410 in mind?  I caught a
    couple of required changes in s1 and s3.5.  Maybe in s1:
    
    OLD:
    
    beyond the Proposed Standard level,
    
    New:
    
    to the Internet Standard level,
    
    Maybe in s3.5:
    
    OLD:
    
    advanced to Draft Standard or Internet Standard
    
    NEW:
    
    advanced to Internet Standard
    
    <process weenie> 
    
    According to the IETF's TLP you need to put: 
    
    <CODE BEGINS>
    
    /*
    
       Copyright (c) 2011 IETF Trust and the persons identified
       as authors of the code. All rights reserved.
    
       Redistribution and use in source and binary forms, with
       or without modification, is permitted pursuant to, and subject
       to the license terms contained in, the Simplified BSD License
       set forth in Section 4.c of the IETF Trust’s Legal Provisions
       Relating to IETF Documents (http://trustee.ietf.org/license-info).
    
    */ 
    
    code goes here
    
    <CODE ENDS>
    
    in Annex B.  Great choice for the code as there's no copyright issue with NIST.
    
    </process weenie> 
        
  9. Sean Turner: Comment [2011-10-31]:
    I have the same question Dan has about BCP vs Standards Track.
    
    There's a couple of extra references that are unused:
    
     == Unused Reference: 'RFC2680' is defined on line 1070, but no explicit
          reference was found in the text
    
     == Unused Reference: 'RFC2681' is defined on line 1073, but no explicit
          reference was found in the text
    
     == Unused Reference: 'RFC4719' is defined on line 1094, but no explicit
          reference was found in the text
    
    Dan already pointed out the downref issue.

draft-ietf-tcpm-rfc1948bis

  1. Adrian Farrel: Comment [2011-11-02]:
    Acronyms should be expanded on first use in the body text.
    
    ---
    
    In Section 3 you use "F" and "F()" to denote the PRF. You should pick
    one for consistent use.
  2. Russ Housley: Comment [2011-11-01]:
      The SECDIR Review by Joe Salowey  points out a minor typo.
      In section 3 there is a repeated "the" in the first sentence of
      the second paragraph.

draft-ietf-rmt-simple-auth-for-alc-norm

  1. Ralph Droms: Discuss [2011-11-01]:
        I'm asking for a clarification that should be easy to resolve.  Is the
    mechanism specified in this document intended to be the only format
    for the use of the EXT_AUTH==1 header extension defined in [RFC5651]?
     
        
  2. Ralph Droms: Comment [2011-11-01]:
    I'm looking forward to reading responses to the Discuss positions
    posted by Pete and Stephen.
  3. Adrian Farrel: Comment [2011-11-03]:
    I support Pete Resnick's Discuss
    
    ---
    
    Section 1
    
    s/transfer reliably objects/reliably transfer objects/
    
    --
    
       More precisely this document details the EXT_AUTH==1 header extension
       defined in [RFC5651].
    
    Should read
    
       More precisely this document details the HET=1 (EXT_AUTH) header 
       extension defined in [RFC5651].
  4. Stephen Farrell: Discuss [2011-10-31]:
        The parameterisation scheme is hard to follow or broken. It
    seems to be the case that the asid specifies the selection of
    scheme and keying on a session by session basis. That seems not to
    scale, given asid is only 4 bits long - what if a node is part of
    more than 16 sessions? (Practically, asid values will collide with
    fewer sessions given the birthday paradox.) What am I getting
    wrong here? (I must be getting something wrong i think;-) 
        
  5. Stephen Farrell: Comment [2011-10-31]:
    - general: Can all the ECC work here be based on RFC 6090? That
    should be the case and 6090 should be referenced.
    
    - the presentation is highly redundant, e.g. figures 1 and 3 seem
    identical
    
    - general: you need to acknowledge that RSA puts more load on the
    signer but much much less on the verifier; whereas ECC puts more
    similar load on both and hence with many verifiers more CPU is
    consumed overall.
    
    - abstract: isn't ecdsa a digital signature scheme? Maybe you
    really mean, and should say, RSA?
    
    - abstract: is scheme 3 a group-keyed mac or something else? 
    
    - s1, 1st para, s/transfer reliably/reliably transfer/
    
    - p6, 3rd bullet: the definition of the key/signature lengths is a
    bit broken. RSA public keys have a modulus and an exponent but the
    signature is the same length as the modulus, etc. I wonder if the
    easiest is not to delete this since its not really a definition in
    any case.
    
    - p6 - none of the signature nor group MAC definition bullets
    actually seem to define terms
    
  6. Russ Housley: Comment [2011-11-02]:
      Throughout the document, the use of "Signature Cryptographic Function"
      ought to be replaced by "One-way Hash Function" or "Message Digest
      Algorithm" (please pick just one).
  7. Pete Resnick: Discuss [2011-10-31]:
        This is much more for the shepherd and AD than it is for the author:
    
    I do not understand why this document is being put forward as Experimental
    rather than Standards Track. Unlike most Experimental documents, there is no
    section in here describing the experiment that is being performed and what the
    criteria for determining the outcome of said experiment are. When I went to look
    at the shepherd report and writeup for this document, I must say they were
    content-free. The only thing the Working Group summary said was that there was
    consensus for this document. If there was consensus, then why isn't this going
    forward as Standards Track? There is not enough information in either the
    document or the writeup to explain why this is Experimental; that information
    must appear in one of those places. 
        
  8. Sean Turner: Discuss [2011-11-02]:
        #1) s2: Don't you need to specify the requirements for key size?  You could
    steal the text from RFC 5751 s4.2 & s4.3 (i.e., use 1024-2048).
    
    #2) s3.3.1: I like that you recommended all 3 curves, but do you really need to?
    Couldn't you just recommend p-256 and be done with it? 
        
  9. Sean Turner: Comment [2011-11-02]:
    #1) a: r/The first scheme is based on digital signatures.
               /The first scheme is based on RSA digital signatures.
    
    #2) s1: Parameters are discussed in 2.2, 3.2, 4.2, and 5.2 so maybe:
    
      This is detailed in Sections 2.2, 3.2, 4.2, and 5.2.
    
    #3) s2.1, s3.1, s4.1, s5.1: reserved - should also specify that the bits are
    ignored on receipt.
    
    #4) s2.2: When discussing Signature Cryptographic Function aren't you just
    talking about Message Digest Algorithms?  Like in s3.2?
    
    OLD:
    
     o MUST communicate the Signature Cryptographic Function, ...
    
    NEW:
    
     o MUST communicate the Message Digest Algorithm, ... ;
    
    #5) s2.2: Could add a reference to RFC 6194 in the following:
    
      Because of security threats on SHA-1, the use of
      SHA-256 is RECOMMENDED;
    
    because it discusses those concerns.
    
    #6) s4.2: Contains the following:
    
      As a side effect, the receivers also know the
      key length and the non truncated MAC output length;
    
    This is true of the HMAC-SHA-1/224/256/384/512 but what about the HMAC-
    SHA512/224 and HMAC-512/256 algs in FIPS 180-4 (assuming they get defined)?  I
    guess I'm curious if this is always going to be true.
    
    #7) s4.4: If you're recommending HMAC-SHA256, it's probably best to show an
    HMAC-SHA256 example.  People do silly things like only implement the examples.

draft-ietf-mip4-nemo-haaro

  1. Ralph Droms: Discuss [2011-11-01]:
        This seems to be the telechat for asking "why has this document been
    submitted for publication as Experimental?"
    
    draft-ietf-mip4-nemo-haaro-06 includes the following text, which
    appears to be the only text referring to publication of the
    specification as Experimental, at the end
    of section 1: 
    
       The specification in this document is meant to be experimental, with
       the primary design goal is to limit the load on the backend to
       minimum.
    
    This text, in addition to containing a non sequitor, says nothing
    about why the document is submitted for publication as Experimental,
    what the experiment might be, how the experiment might be evaluated
    and when the specification might be considered for publication as
    Standards Track or moved to Historic status.
    
    I have to say that I very much like the text at the end of the
    Introduction of draft-ietf-pim-port, which explains why that
    specification is Experimental - in this case, because it's doing some
    new stuff that hasn't been tried before - how the results of
    implementing the Experimental specification can be interpreted and
    under what circumstances the specification should be considered for
    Standards Track status.
    
    So, to make this Discuss actionable, I'd like to hear from the mip4 WG
    what aspects of this specification cause the request for Experimental
    status, how the results of the experiment with implementation and
    deployment should be reviewed and under what circumstance should this
    specification be considered for publication on the Standards Track.
     
        
  2. Adrian Farrel: Comment [2011-11-01]:
    I support Ralph's Discuss although I see that the reasoning is clear
    from the charter. It should be simple to construct equivalent text to
    go in the document.
    
    ---
    
    I searched for a definition of "optimum" or "route optimizaton". I 
    found
    
       This document proposes a method to
       optimize routes between networks behind Mobile Routers, as defined by
       NEMO [RFC5177].
    
    But RFC 5177 says;
    
       This document
       does not touch on aspects related to route optimization of this
       traffic.
    
    Section 1 does include a number of statements that "route optimization
    addresses this issue" for several issues. That is great, but I still 
    missed a succinct definition of "route optimization" and some 
    understanding of how I would recognize "optimum" if I saw it.
    
    ---
    
    Section 3.2.2seems to have "should" and "may" that might benefit from
    moving to RFC 2119 usage.
  3. Stephen Farrell: Comment [2011-11-02]:
    I'm assuming that these questions just reflect my ignorance of nemo, 
    and since this is (currently) aimed at experimental, I'll not make them
    a discuss. (If it were going for PS, I think these would be discuss-worthy.)
    
    (1) I don't get how Kcr is setup as required in 3.2?  Is Kcr
    supposed to be manually installed? Do all MR's need to have a
    different Kcr for all other MRs or is Kcr shared between the MR and
    HA?
    
    (2) 3.2.1 says an MR MAY generate a new key at any time. How is that
    distributed (securely)?
    
  4. Russ Housley: Discuss [2011-11-01]:
        
      The Gen-ART Review by Roni Even on 29-Oct-2011 raises two concerns
      that deserve a response.
    
      1. The IANA Considerations section is not clear. It talks about three
         new tables but it was not clear to me which one they were and what
         is the extension policy for the tables.
    
      2. Section 4.2 talks about realm compression. Is it always used when
         using prefix compression or can you just do prefix compression if
         there is no benefit from using the realm compression? 
        
  5. Russ Housley: Comment [2011-11-01]:
      The Gen-ART Review by Roni Even on 29-Oct-2011 raises two editorial
      comments.  Please consider them.
    
      1. Typo in Section 3.1, first paragraph: “alredy”
    
      2. In Section 3.3.1: “only be when” change to “only when”; and
         “and and whose” delete one of the “and”.
  6. Pete Resnick: Comment [2011-11-02]:
    I agree with Ralph that more should be said in the document about the nature of
    the experiment.
  7. Robert Sparks: Comment [2011-11-02]:
    Related to Russ' discuss (which I support):
    
    IANA has unanswered questions (Authors - you received them directly and can also
    see them at the
    line starting:
    2011-10-31      06      Amanda Baber    
    IANA has
    several questions about draft-ietf-mip4-nemo-haaro-06.txt.
    
    at
    
    <https://datatracker.ietf.org/doc/draft-ietf-mip4-nemo-haaro/history/>
    
    

draft-ietf-fecframe-config-signaling

  1. Jari Arkko: Comment [2011-11-03]:
    Ari Keränen helped me review this, and he had a couple of comments:
    
    Many of the internal references ("see section x") are referring to 
    apparently wrong sections.
    
    1. Introduction
    
        This document describes how to use various signaling protocols to
        communicate the Configuration information between sender and
        receiver(s). The configuration information may be encoded in any
        compatible format such as SDP [RFC4566], XML etc.
    
    I found this statement confusing considering that only SDP encoding is 
    defined (right?). The same statement is found also later in the draft.
    
  2. Ron Bonica: Discuss [2011-11-02]:
        This document includes a informative reference to draft-ietf-mboned-session-
    announcement-req. draft-ietf-mboned-session-announcement-req has expired and
    doesn't seem to have gained traction in MBONED. 
        
  3. Gonzalo Camarillo: Comment [2011-11-03]:
    I agree with other discusses in that the purpose of the draft should be
    clarified.
    
    Also, introductions should not contain normative language. Normative terminology
    is not even introduced before Section 2.
  4. Wesley Eddy: Discuss [2011-10-26]:
        It's not clear in what sense this is Experimental.  It seems to be more of an
    Informational document, as it is not particularly prescriptive as a protocol or
    mechanism.  For instance, I don't think it would be possible to create
    compatible implementations based solely on this document; many decisions are
    punted on.
    
        
  5. Adrian Farrel: Comment [2011-11-03]:
    I really don't see the point of raising a further Discuss on this document since
    my concerns overlap extensively with those already raised.
    
    However, one point really bothered me...
    
    The Abstract says:
    
       This document describes how to use existing signaling protocols to
       determine and dynamically communicate the Configuration information
       between sender(s) and receiver(s).
    
    I would expect the Absatrct to state clearly which protocols. But I read on and
    found in the Introduction:
    
       This document describes how to use various signaling protocols to
       communicate the Configuration information between sender and 
       receiver(s). The configuration information may be encoded in any
       compatible format such as SDP [RFC4566], XML etc. A signaling
       protocol could be utilised by any FEC scheme and/or any Content
       Delivery Protocol (CDP).
    
    So I realised that the document is attempting to give an abstract description of
    how one might use *a* signaling protocol for the tasks identified, but without
    actually doing the protocol specification. Fair enough - although that clearly
    makes it an Informational framework.
    
    This view was confirmed by Section 5 that is clearly abstract, and by Section
    5.2 that says:
    
       This document describes leveraging any signaling protocol that is
       already used by the unicast application, for exchanging the FEC
       Framework Configuration Information between two nodes.
    
    But in Section 5.1:
    
       This specification describes using Session Announcement Protocol
       (SAP) version 2 [RFC2974] as the signaling protocol to multicast the
       configuration information from one sender to many receivers.
    
    Which is not abritrary at all.
    
    To make this actionable I suggest you work out very clearly what the purpose of
    the document is and capture that both in the Abstract and the Introduction. It
    would also help if you clearly defined what *you* mean by a signaling protocol
    because people at different layers of the stack have very different
    understandings of the term.
  6. Stephen Farrell: Comment [2011-11-01]:
    - What does "MAY employ cryptography" mean? You
    already said SHOULD to the authentication header
    so what kind of non cryptographic authentication
    header do you have in mind? RFC 2974 defines PGP
    and CMS options so presumably the SHOULD means
    that you've gotta do one of those unless you have
    a good reason.
    
    - Is it clear how one would use GDOI to manage
    keys for a SAP authentication header?
    
    - I agree with Wes' discuss.
    
  7. Pete Resnick: Discuss [2011-11-02]:
        Even if this document was written properly as a protocol document (see Wes's
    Discuss comment), there is no explanation of what about this document is
    experimental in the first place. There is no description about what is being
    experimented on, why it is an experiment, and what the results of the experiment
    might be. Such an explanation should appear in the Introduction. 
        
  8. Pete Resnick: Comment [2011-11-02]:
    I agree with Wes's Discuss comment.
  9. Robert Sparks: Discuss [2011-11-02]:
        (It would help to read the comments below before reading these DISCUSS points)
    
    1) In several sections (5.1 in particular) it's very hard to tell which
       requirements are new requirements on an implementation defined in this
       draft and which are restatements of requirements from other RFCs. Some
       of these restatements leave out important context (an example is the
       deletion requirement in 5.1.2 of this document vs the description of
       explicit deletion in section 4 of RFC2974). Please explicitly call out
       each instance where you are just restating a requirement, and consider
       just pointing to the actual definition of behavior instead of restating 
       it.
    
    2) Is the list of unicast mechanisms intended to be complete? Is it intended
       to constrain CDPs to choose only between them instead of inventing something
       new?
     
        
  10. Robert Sparks: Comment [2011-11-02]:
    It's not clear what this document is trying to acheive. Parts of it seem to
    be considerations that a CDP specification should take into account when
    defining how FCCI is disributed. Section 5.2, which calls out a few
    unicast mechanisms, has this flavor in particular. It's almost a survey, 
    and while the descriptions call out important aspects a CDP should consider, 
    they are not sufficiently detailed for a CDP to point to this document to 
    define how these mechanisms would be used. Section 5.1, on 
    the other hand, tries to define how an (abstract?) CDP would utilize 
    multicast SAP, adding a few requirements beyond the base SAP specification.
    
    Please consider restructuring (perhaps even renaming) the document to make 
    its goals clearer.
  11. Sean Turner: Discuss [2011-11-02]:
        I see that authentication is a SHOULD.  I went and looked at RFC 2974 and it
    says either PGP or CMC can be used.  Don't you have to pick a MUST implement? 
        
  12. Sean Turner: Comment [2011-11-02]:
    s5 contains the following:
    
      The SAP message(s) SHOULD contain an
      authentication header and MAY employ cryptography.
    
    I think you mean "MAY employ encryption."
    
    I too am scratching my head about the GDOI reference.  Further, RFC 3547 was
    recently obsoleted by RFC 6407.  There were a fair number of changes.  I'm
    unclear whether you should update the reference or keep the reference to the
    obsoleted RFC.  Are there any implementations of the newer or older GDOI
    mechanism?

draft-ietf-pim-port

  1. Stephen Farrell: Comment [2011-11-01]:
    - Presumably if this experiment is a success then some method of
    doing automated key management would be required for a successor
    standards track document. I think just noting that in the
    security considerations section would be good.
    
    - I wondered why TLS wasn't considered as an additional option.
    Be good to explain why, esp if there's a reason it wouldn't work
    well enough.
    
  2. Russ Housley: Discuss [2011-11-02]:
        
      The Gen-ART Review by Suresh Krishnan in 1-Nov-2011 raises two points
      that deserve a response.
    
      Section 3.1: From my reading of the document, it is not clear whether
      we can have a node advertise multiple capability options of the same
      transport protocol (say PIM-over-TCP-Capable) in the same message.
      e.g. A dual stack node might want to advertise its capability to do
      both IPv4 and IPv6. Is this possible? If so, how?
    
      Section 4.7: Section 4 talks about the router with the lower
      connection ID initiating the transport layer connection but this does
      not really map into the rules mentioned in Section 4.7. Specifically,
      I am not sure Rule 3 for Node A in Section 4.7 conveys the same intent
      as the rest of Section 4. 
        
  3. Sean Turner: Comment [2011-11-02]:
    s3.1 and s3.2: Not being a PIM expert, I tripped up over how IPv6 addresses
    could fit in to TCP Connection ID and SCTP Connection ID.  I kind of had to
    guess where I'd find more information about this, so a pointer to the xoring
    mechanism in RFC 4061 would have helped a lot.

draft-ietf-drinks-usecases-requirements

  1. Wesley Eddy: Comment [2011-11-02]:
    I would think that it would be much better if the requirements were complete
    sentences, but won't hold the document up over it ...
  2. Adrian Farrel: Comment [2011-11-03]:
    Section 3 typo
    
    s/(see Section Section 5)/(see Section 5)/
  3. Stephen Farrell: Comment [2011-11-01]:
    - I was confused by this: "Any request to provision, modify or
    delete data is subject to several security considerations (see
    Section Section 5).  This document does not address these
    considerations. " Section 5 does seem to address the security
    considerations so I don't get it?
    
    - Section 5 says that authorization is REQUIRED, which is fine,
    but you're not clear on the intended granularity which will make
    a huge difference. If you could state e.g. whether or not UC PI#6
    (modification of authority) has to be authorized at the level of a
    specific phone number that'd make it clear.  As is, you've punted
    on this, so may have more trouble getting closure on the
    protocol. 
    

draft-ietf-cuss-sip-uui-reqs

  1. Stephen Farrell: Comment [2011-11-01]:
    - REQ-11 is very prescriptive about the "one octet
    discriminator." Its not clear from the phrasing that the "at
    least" also applies to that. I guess it does though.
    
    - I think it'd be good to note that there will be UA security
    considerations to be considered - if any old set of bytes can be
    attached to an INVITE and then a UA will try to render those,
    then that's probably gonna generate new vulnerabilities. 
    
    - Its a pity that the SIP community seem to have given up on e2e
    security, which is how I read this. I wonder if there's any way
    to make that better...  (maybe rtcweb will do better in this
    respect)
    
  2. Russ Housley: Discuss [2011-11-02]:
        
      The Gen-ART Review by Ben Campbell was updated on 1-Nov-2011.  Points
      raised in his previous review were responded to with reasonable
      explanations.  In both cases, the requirements would be more clear if
      the clarifications were included in the document:
    
      REQ-12: What degree of certainty is required here? (i.e. strong
      identity?)  If implied by the SIP dialog, does that impact
      expectations on what sort of authorization must happen at the
      SIP layer?
    
      The reasonable response was:
      >
      > This is not meant to imply strong identity.  And since UUI data
      > can appear in a response, there aren't really any strong methods
      > available with SIP.  The UUI mechanism does not introduce stronger
      > authorization requirements for SIP, but instead the mechanism needs
      > to be able to utilize existing SIP approaches.
    
      REQ 13: I'm not sure I understand how this interacts with the ability
      for intermediaries to remove UUI.  Should this be detectable by the
      endpoints?  Or is that ability limited to the hop-by-hop case, or
      require no integrity protection?
    
      The reasonable response was:
      >
      > Yes, there are tradeoffs between this requirement and requirement
      REQ-9.  Hop-by-hop protection is one way to resolve this interaction. 
        
  3. Robert Sparks: Discuss [2011-11-02]:
        The discussion below REQ-1 implies that 3xx responses are end-to-end. They are
    hop-by-hop,
    and a proxy might chose to recurse on them.
    
    Is there a requirement that a recursing proxy preserve the UUI into any INVITEs
    created
    towards the Contacts in a 3xx?
    
    Suppose a simple forking scenario where an INVITE forks to two elements, each of
    which
    return 3xx responses with UUI information. Is there a requirement for the
    information
    from both branches to be included in any 3xx response the proxy
    returns to the original
    UAC (assuming it doesn't recurse)?
    
    Related to REQ-9: Is there a requirement for the applications at each end to be
    able
    to tell that a particular application usage of UUI data has been removed?
    Or is there
    a requirement that the application NOT be able to tell? Either way,
    please be explicit. 
        

draft-ietf-savi-framework

  1. Stephen Farrell: Discuss [2011-11-01]:
        This makes no mention at all of privacy which I think needs to
    be there somewhere. Given that Joel is planning to add text on
    that to savi-threats I'd be fine if that is just referenced from
    here, or even if that text is moved from savi-threats to this
    document, and savi-threats could refer to it here. But the
    privacy implications of SAVI do need to be covered here too.
    (That assumes that Joel's text is as fine as I'm sure it
    will turn out to be:-)
     
        
  2. Stephen Farrell: Comment [2011-11-01]:
    - Ted Hardie also reviewed this from the privacy perspective 
    and had what I think is more or less the same concern as
    in my discuss.
    
       http://www.ietf.org/mail-archive/web/privacydir/current/msg00059.html
    
    - general: The term "legitimate IP address" is used a good few
    times, and is sort-of defined in the 1st bullet of section 3,
    but a clearer definition would be good - I think you mean that
    "legitimate" == "not considered a spoofed source by SAVI" and no
    more, (which is fine), but it could be read to mean "authorised
    by the authorities" which would give the wrong impression (I
    hope:-). You might even consider inventing your own term for
    this, e.g. "SAVI-legitimate" or whatever (but I'm only weakly
    suggesting that, I can understand that inventing such a term
    might just cause more confusion now).
    
    - p4, maybe s/network operators/network administrators/? The
    term "operator" tends to be taken to mean a specific type
    of admin.
    
    - p4, Is "on the path" right really? SAVI devices need to
    be close to the host as is correctly stated elsewhere.
    
    - p5, Is "must be verifiable" correct in point#2? I think it
    would be better to say "needs to be verifiable....if SAVI is to
    work"
    
    - p6, What foes "full protection for the hosts" mean? SAVI is
    not protecting the host with the source address, but rather
    the network or the receiving hosts and doesn't provide "full"
    protection in any sense I can understand? Maybe just end 
    that sentence at "lower" is the easiest change.
    
    - p6, Is it correct to say that it is through "assignment"
    that a host becomes the "legitimate" user of a source
    address for all cases? (Just checking.)
    
    - p7, Are all of the examples of binding anchors listed in
    3.2 in scope of the SAVI WG? I think it'd be good to say
    which are or are not, if not all are or maybe to only list
    those that are in scope.
    
    - p11, What is a "premier check"?
    

draft-salter-rfc5430bis

  1. Adrian Farrel: Comment [2011-11-01]:
    Shame about not cleaning up the idnits before presenting for review. Please save
    the RFC Editor the time by fixing them before advancing.
  2. Pete Resnick: Comment [2011-11-02]:
    Gads, I hate the use of RFC 2119 language when what you're saying is, "In order
    to conform to NSA Suite B, you MUST do this." That sort of fails the 2119
    requirement that "they MUST only be used where it is actually required for
    interoperation or to limit behavior which has potential for causing harm (e.g.,
    limiting retransmisssions)  For example, they must not be used to try to impose
    a particular method on implementors where the method is not required for
    interoperability." It's not a DISCUSSion worth having for this document
    individually, and the document that this one obsoletes does exactly the same
    thing, but it's a discussion we should have at some point.
  3. Peter Saint-Andre: Comment [2011-11-02]:
    It seems that this document is missing the section on "differences from RFC
    5430".

draft-irtf-hip-experiment

  1. Ralph Droms: Comment [2011-10-18]:
    It would be helpful to include a terminology section, for those not so
    familiar with HIP.
    
    section 1.2: "HIT-based lookups"
    
      expand HIT on first usage
    
    section 2.3.5: Are there any specific references to the "initial
    specification attempts?"
    
       To solve this problem, the HIP layer could
       inform the transport layer of mobility events.  This method, known as
       transport triggers, is still under research although initial
       specification attempts have been made in the IET
    
    section 2.5: I can't quite parse this sentence:
    
       Although counter-examples exist, e.g.  SCTP is a large
       unit in the kernel, the Linux community resisted incorporating the
       HIP code.
    
    It's not clear to me what SCTP is a counter-example for?
    
    section 3.2: are there an acronym expansions for "HI" and "I2"?
    
       when the HI is
       encrypted, middleboxes in the network cannot verify the signature of
       the I2
  2. Stephen Farrell: Comment [2011-11-02]:
    - A lot of this document would apply to any overlay or
    alternative n/w approach and not just HIP. Might be
    worth a mention in the abstract?
    
    - not all acronyms are expanded on 1st use, e.g. sigma, beet, tap
    
    - I wondered what were the "controversial experiences" on p10. Seems
    a shame to tease the reader like that.
    
    - What is an "I1" on p13? And "I2" on p17. Maybe expand those to
    the full message names or something?
    
    - Isn't TKK now Aalto? (p15 & p23)
    
    - A reference for the "double jump mobility" problem on p19
    would be good.
    
  3. Dan Romascanu: Comment [2011-11-03]:
    A very good document. I would like to see more of this type describing
    experience in implementation and deployment of protocols developped in the IETF.

draft-irtf-hiprg-dht

  1. Jari Arkko: Discuss [2011-11-03]:
        Ari Keränen helped me look at this draft and he pointed out the following:
    
    The packet defines a new HIP packet type [1] but these values can only be
    allocated through "IETF 
    Consensus" which implies that the draft couldn't really
    come from outside the IETF [3]
    
    [1] http://tools.ietf.org/html/draft-irtf-hiprg-dht-04#section-8
    [2] http://tools.ietf.org/html/rfc5201#section-9
    [3] http://tools.ietf.org/html/rfc5226#section-4.1
    
    IESG Approval for this registry would have been the right thing. Food for
    thought for RFC 5201bis? 
        
  2. Gonzalo Camarillo: Comment [2011-11-03]:
    I am clearing my discuss because Ralph had already run an IETF LC on this.
    Anyway, since some people in the HIP WG seem to have missed it, I have sent a
    note to the HIP WG's list so that everybody is aware of this draft.
    Additionally, I have also ask the WG to consider this issue when working on the
    bis specs.
    
    
  3. Ralph Droms: Comment [2011-10-18]:
    Expand acronyms on first use and/or give pointer to terminology and/or
    add terrninology section.
  4. Adrian Farrel: Discuss [2011-11-01]:
        A quick process question before I move to a No Objection ballot.
    
    Was this document explicitly brought to the attention of the HIP working group
    (as well as the IETF last call)? 
        
  5. Russ Housley: Discuss [2011-11-01]:
        
      The Gen-ART Review by Kathleen Moriarty on 20-Oct-2011 raised a
      concern about the use of SHA-1.  The authors said a change would be
      made, but it has not been posted yet. 
        

draft-cakulev-ibake

  1. Stewart Bryant: Comment [2011-10-31]:
    I am voting No Objection on the basis of the IESG note and a quick check that
    this draft has no routing implications.
  2. Adrian Farrel: Discuss [2011-11-01]:
        Before moving to No Objeciton, I would like to spend time on the call Discussing
    the proposed IESG note on the basis that this is not an IETF document (coming
    through the ISE) and so it would not be expected that it received any IETF
    review compared to other Informational RFCs. Furthermore, ISE documents normally
    carry a standard disclaimer that "this is not the work of the IETF"
    
    I suppose my point is: what message is the IESG note trying to send? 
        
  3. Stephen Farrell: Comment [2011-11-02]:
    - I agree with the proposed IESG note, but I guess we need to
    figure out (with the ISE?) how to properly state that.
    
    - another case where the IPR declaration refers to a "standard"
    but this isn't going to be one.
    
    - section 1, Public key protocols do not require "large scale" PKI,
    as clearly demonstrated by the success of ssh. The statement is
    incorrect.
    
    - section 1, No evidence is give for the assertion that a PKG is
    "simple." Personally, I doubt that and the word's not needed in
    any case. Suggest s/simple// 
    
    - section 1, Many IBE schemes have claimed that including dates
    in names avoids revocation issues. However, afaik, no one has 
    actually done this in the wild so this claim is also just a
    bare assertion since the usability issues related to this idea
    are essentially untested.
    
    - section 2.1, IBE does not allow a public key to be calculated from
    an identity. IBE requires an identity *and* a set of PKG parameters
    in order to generate a public key. Truth-in-advertising would be
    better here.
    
    - Its not clear to me that two implementations of this would
    interoperate. That may or may not be the case, but I guess
    additional specification would be required. It would be good
    to say more about what'd be needed for that.
    
    - Its not really possible to evaluate the security claims of
    this protocol as part of a 5742 review. It'd be good if a
    statement to that effect were included. I'm not doubting the
    security claims, but they have not been exposed to wide
    spread review which would be needed were something like this
    to come out of the IETF track. 
    
    - Its hard to see how 2119 is the only normative reference
    here.
    
    - typo: s/Privet/Private/
    
  4. Pete Resnick: Discuss [2011-11-02]:
        I agree with Adrian and Robert that the current IESG Note is confusing and I'm
    not sure what we're trying to say in it. That said, I'm also a bit concerned
    that this document *is* trying to extend IETF protocol (EAP?) and therefore
    should go through IETF process. It sounds like we suspect that IETF Review would
    fail to garner consensus, but that's not a reason to give the ISE a go-ahead. I
    may be confused on the meaning of 5742 in this regard, so I'd like to discuss. 
        
  5. Robert Sparks: Discuss [2011-11-02]:
        The additional note in the proposed response doesn't make sense for an ISE
    document.
    
    Based on conversations with Sean, it was based on a similar note placed in an
    IETF stream document.
    
    The boilerplate for the ISE stream documents will already say:
    
       Independent Stream:
          "This is a contribution to the RFC Series, independently of any
          other RFC stream.  The RFC Editor has chosen to publish this
          document at its discretion and makes no statement about its value
          for implementation or deployment."
    
    The current proposed additional note ("Due to its specialized nature, this
    document
    experienced limited review within the IETF.") implies that there was
    some IETF review 
    beyond the 5742 review for conflict, and could imply that
    _other_ documents get more 
    IETF review. These documents get no such IETF review
    beyond the conflict review called
    out in RFC 5742.