IESG Narrative Minutes

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

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

Corrections from: Dan

1 Administrivia

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

2. Protocol Actions

2.1 WG Submissions

2.1.1 New Items

  1. Negotiation of Generic Image Attributes in SDP (Proposed Standard)
    draft-ietf-mmusic-image-attributes-10
    Token: Robert Sparks
    Note: Tom Taylor (tom111.taylor@bell.net) is the Document Shepherd.
    Discusses/comments (from ballot 3533):
    1. Adrian Farrel: Comment [2011-01-20]:
      I have only partially reviewed this document, but I have no objection to the technical content in this document. I found a lot of the text somewhat ambiguous or hard to parse, and the number of such issues was (IMHO) close to making the document quality suspect and warranting a Discuss. Although the RFC Editor will work on these issues, it is my opinion that such a level of changes will result in a proportion of cases will result in:
      - bad fixes made by the RFC Editor
      - issues being missed.
      I urge the authors to at least make fixes to the issues I have identified, and preferably find a technology-aware native speaker to review and update the text.
      The Abstract really needs to mention SDP. I would prefer if the Introduction was also clearer sooner that this document applies to SDP
      SDP is not a well-known acronym according to the RFC Editor so should be expanded...
      You should expunge all references to "draft" and replace with "document"
      In the Abstract...: "The draft also helps to maintain an optimal bitrate for video as only the image size that is desired by the receiver is transmitted."
      A nice trick if you can do it, but actually, I think that someone needs to implement something! How about...
      "The mechanisms defined in this document can also be used to help maintain an optimal bitrate for video, as only the image size that is desired by the receiver is transmitted."
      Section 1: "This document proposes a new attribute to make it possible to negotiate different image attributes such as image size. The term image size is defined here as it may differ from the physical screen size of for instance a hand-held terminal."
      I do not find the term "image size" defined. You may want s/defined/used/ or you may want to add the definition.
      Section 1: "There are a number of benefits with a possibility to negotiate the image size:"
      /with a/to the/
      Section 1: "Optimal quality for the given bitrate: The sender does not need to encode an entire CIF (352x288) image if only an image size of 288x256 is displayed on the receiver screen. This alternatively gives a saving in bitrate."
      s/alternatively/alternative/ ?
      REQ-1: s/wish/wishes/
      3.1.1: "The attribute typically contains a "send" and a "recv" keyword. These specify the preferences for the media once the session is set up, in the send and receive direction respectively from the point of view of the sender of the session description. One of the keywords ("send" or "recv") MAY be omitted, see Section 3.2.4 and Section 3.2.2 for a description of cases when this may be appropriate."
      I see this saying: "The attribute MUST contain at least one of the keywords "send" and "recv"."
      3.1.1: "For sendrecv streams both of the send and recv directions SHOULD BE present in the SDP.
      s/BE/be/
      3.1.1: "For inactive streams it is RECOMMENDED that both of the send and recv directions are present in the SDP."
      s/SDP/SDP message/ ?
      3.1.1.1: "Payload type number (PT): The image attribute is bound to a specific codec by means of the payload type number."
      It may be obvious, but there is no statement of where the possible values of PT can be found. I think you should add this.
    2. David Harrington: Comment [2011-01-18]:
      This document is well-written. These comments require no action by the authors, but if these fixes were applied, it might make for a cleaner document...
    3. Russ Housley: Comment [2011-01-20]:
      As noted in the Gen-ART Review by Avshalom Houri on 19-Jan-2011, the following lines in Section 4.2.4 need to be reworded:
      Neither part is required to rescale like this (sar may be ignored), the consequence will of course be a distorted image."
      Also, please consider the editorial changes proposed in the Gen-ART Review by Avshalom Houri.
    4. Alexey Melnikov: Comment [2011-01-14]:
      I've done a detailed review of the document and overall I think it is fine. Some comments below...
    5. Tim Polk: Discuss [2011-01-17]:
      This is mostly a discuss-discuss, but also is a reminder that the authors have agreed to add security considerations about DoS attacks after a discussion with the security directorate reviewer (Stephen Farrell). Since no text has been proposed as yet, and I agree with his premise, I will hold the discuss as a placeholder even after the discussion takes place...
      Actionable part:
      When an offeror "sees no reason to use the image attribute", section 3.2.1 recommends including the attribute with the wildcard. The security directorate review notes that an answerer could select attributes that would demand significant resources, resulting in a DOS attack. To resolve this, I believe some text needs to be added noting that memory and other resource considerations need to be considered before accepting the response, even if the specified attributes can be supported/accepted.
      Here's the discuss-discuss part: the ABNF permits the attribute list to be a wild card for both send and recv. Is there any good reason for the offeror to specify the wildcard (as opposed to an explicit list) for the send attribute list? Are there really any systems that would not restrict the formats it was willing to send to a list? Offering to send media without restricting the format seems to invite the kind of DoS attack that Stephen was thinking about. (Flexibility regarding reception of media seems more logical to me, although there is still a clear attack vector.)
    6. Peter Saint-Andre: Comment [2011-01-18]:
      The document is difficult to read in numerous places because of run-on sentences and non-standard English.
      I suggest that the authors review the conformance terms in accordance with RFC 2119, because sometimes lowercase keywords (lacking any conformance meaning) are used when uppercase keywords seem more appropriate...
      There are also several instances of uppercase keywords when no conformance meaning is in force...
    7. Sean Turner: Comment [2011-01-19]:
      I support Tim's discuss.

    Telechat:

  2. Datagram Transport Layer Security version 1.2 (Proposed Standard)
    draft-ietf-tls-rfc4347-bis-04
    Token: Sean Turner
    Note: Joe Salowey (jsalowey@cisco.com) is the document Shepherd.
    IPR: Certicom's Statement about IPR related to RFC 4346, RFC 5246, RFC 5289, RFC 4492, RFC 2409, RFC 4306, RFC 4754, RFC 4753, RFC 4869, RFC 4253, RFC 2633, RFC 3278, RFC 4347, RFC 4366, RFC 4109, RFC 4252, RFC 3850, RFC 3851, RFC 5008, draft-ietf-tls-rfc43...
    IPR: Certicom's Statement about IPR related to RFC 4346, RFC 5246, RFC 5289, RFC 4492, RFC 2409, RFC 4306, RFC 4754, RFC 4753, RFC 4869, RFC 4253, RFC 2633, RFC 3278, RFC 4347, RFC 4366, RFC 4109, RFC 4252, RFC 3850, RFC 3851, RFC 5008, draft-ietf-tls-rfc43...
    IPR: Certicom's Statement about IPR related to RFC 4346, RFC 5246, RFC 5289, RFC 4492, RFC 2409, RFC 4306, RFC 4754, RFC 4753, RFC 4869, RFC 4253, RFC 2633, RFC 3278, RFC 4347, RFC 4366, RFC 4109, RFC 4252, RFC 3850, RFC 3851, RFC 5008, draft-ietf-tls-rfc43...
    Discusses/comments (from ballot 3537):
    1. Ron Bonica: Comment [2011-01-17]:
      Support OPS-DIR DISCUSS
    2. Stewart Bryant: Comment [2011-01-19]:
      (blank)
    3. Adrian Farrel: Discuss [2011-01-20]:
      Section 4.3 needs to inanding the factwithstclude a reference to RFC 5246 for the defnition of the syntax used. This is important (not that the changes are relative to 5246) because although the format looks like 'C' it is not 'C'
    4. Adrian Farrel: Comment [2011-01-20]:
      I support Alexey's Discuss about description of the changes since/to 4347
      Should the version numbering be recorded by IANA?
      How is wrapping of epoch and sequence number handled? Or is it considered that they will never need to wrap?
      It might be valuable to repeat the UDP warning from 4.1.2.7 in section 5
      Section 4.3: "This section includes specifications for the data structures that have changed between TLS 1.2 and DTLS."
      I think s/DTLS/DTLS 1.2/
    5. Russ Housley: Discuss [2011-01-18]:
      The Gen-ART Review by Miguel Garcia on 12-Dec-2010 raised a question about Section 4.1 that deserves a response. The reivew says:
      Section 4.1, previous last paragraph on page 8: The sentence requires implementations to compute the TCP maximum segment lifetime. If an implementation runs DTLS over UDP, how can it compute the TCP maximum segment lifetime, which is a parameter for a different protocol? I suspect DTLS implementations running over UDP (or even SCTP) will not have a clue of what is the TCP maximum segment lifetime.
    6. Alexey Melnikov: Discuss [2011-01-02]:
      1). 7. IANA Considerations: "This document uses the same identifier space as TLS [TLS12], so no new IANA registries are required. When new identifiers are assigned for TLS, authors MUST specify whether they are suitable for DTLS."
      Does this mean that this document Updates [TLS12]? Section 4.1.2.5 also confirms that.
      2). I don't see a section "changes since DTLS 1.0" required by ID-nits. Can you convince me that it is not needed?
    7. Alexey Melnikov: Comment [2011-01-02]:
      SCTP, RC4, SCTP-AUTH should have Informative references.
    8. Tim Polk: Comment [2011-01-20]:
      placeholder for Charlie Kaufman's secdir review - this deserves a response. I made this a comment since I know that the sponsoring AD intends to seem them addressed.
    9. Dan Romascanu: Discuss [2011-01-17]:
      The DISCUSS and COMMENT is largely based on the OPS-DIR review by Pekka Savola. I did not see the issues raised by Pekka answered and I believe that part of them (listed below) need to be addressed.
      1. The document does not describe how DTLS 1.2 will interwork with DTLS 1.0 (if it will). The TLS 1.2 spec (RFC5246, Appendix E.1) does have some that will apply, but there are likely some DTLS specifics as well.
      2. 3.2.3. Message Size: "TLS and DTLS handshake messages can be quite large (in theory up to 2^24-1 bytes, in practice many kilobytes). By contrast, UDP datagrams are often limited to <1500 bytes if fragmentation is not desired. In order to compensate for this limitation, each DTLS handshake message may be fragmented over several DTLS records. Each DTLS handshake message contains both a fragment offset and a fragment length."
      4.1.1. Transport Layer Mapping: "Each DTLS record MUST fit within a single datagram. In order to avoid fragmentation, clients of the DTLS record layer SHOULD attempt to size records so that they fit within any PMTU estimates obtained from the record layer."
      ... these seem somewhat contradictory. Maybe I'm missing something. The latter seems to be saying that DTLS implementations should try to avoid IP fragmentation, but the former seems to imply that it's de-facto mode of operation.
      3. "If there is a transport protocol indication (either via ICMP or via a refusal to send the datagram as in DCCP Section 14), then DTLS record layer should inform the upper layer protocol of the error."
      Why a 'should'? I've have thought that it would be natural that if DTSLS record layer gets this notification (which, in the case of ICMP and omitting information, is not necessarily given), it MUST pass this information up. Note that the refusal to send could also apply to UDP if packet is bigger than PMTU and DF bit is set or IPv6 is used. What is the alternative if it doesn't? It would be fine if the alternative is that the DTLS record layer react to that information itself, but completely ignoring e.g. ICMP packet too big would lead to communication failure
      4. 7. IANA Considerations: "This document uses the same identifier space as TLS [TLS12], so no new IANA registries are required. When new identifiers are assigned for TLS, authors MUST specify whether they are suitable for DTLS."
      ... this may be inadequate. I was unable to find from the registry (tls-parameters) which of these parameters this applies to. All of them?
      If I understand what you mean, 1) you should actually be asking IANA to reformat the registry so that there is an additional column in all the tables "DTLS-OK?" or some such, and possibly 2) modifying TLS 1.2 spec IANA registration guidelines (i.e. what should the IANA requesters know about when they're making their request), and also possibly 3) asking IANA to ask future registrants about DTLS-OK feature if the requestor fails to do so on their own.
    10. Dan Romascanu: Comment [2011-01-17]:
      1. The document does not have a "Changes from DTLS 1.0 (RFC4347)" section which is customary in 'bis' documents. Why?
      2. For the completeness, when referring to PMTU discovery, in addition to RFC1191 one should probably also refer to RFC1981 (the IPv6 version).
      [WHYIPSEC] Bellovin, S., "Guidelines for Mandating the Use of IPsec", Work in Progress, October 2003. ... this should probably be rfc5406?
    11. Peter Saint-Andre: Comment [2011-01-18]:
      I support Alexey's DISCUSS regarding the need for a section describing the changes from DTLS 1.0 (RFC 4347).

    Telechat:

  3. Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence (Proposed Standard)
    draft-ietf-xmpp-3921bis-19
    Token: Gonzalo Camarillo
    Note: Joe Hildebrand (jhildebr@cisco.com) is the document shepherd.
    Discusses/comments (from ballot 3579):
    1. Lars Eggert: Comment [2011-01-17]:
      (two Nits)
    2. Adrian Farrel: Comment [2011-01-17]:
      I'm ballotting "no objection" based on selective reading of a few sections of this I-D and "trust" of the WG, the author, and the ADs who have ballotted "yes".
    3. Alexey Melnikov: Comment [2011-01-19]:
      I like Robert's comments, modulo the 4th point in his DISCUSS, which I think is already covered by rfc3920bis.
      In 4.3.2: "Implementation Note: The handling of the 'id' attribute in relation to presence probes was unspecified in RFC 3921..."
      Use of "however" can be read as if the 'id' attribute is not to be returned in the case specified below, however it is still returned. I suggest dropping "however" here.
      In 4.5.2: "The user's server MUST also send the unavailable notification to all of the user's available resources (including the resource that generated the presence notification in the first place)."
      Comment: The text in (): but the resource is unavailable :-).
      "The <subject/> element MUST NOT contain mixed content (as defined in Section 3.2.2 of [XML])."
      Should the same be said about presence' <status> element?
      11. Security Considerations: "A user's server MUST NOT leak the user's network availability to entities who are not authorized to know the user's presence, either via an explicit subscription as described herein or via an existing trust relationship (such as presence-enabled user directories within organizations)."
      I don't understand this paragraph. If a user is subscribed to presence, then she is authorized to know user's presence?
    4. Robert Sparks: Discuss [2011-01-19]:
      In section 3.1.3 item 4, a server is required to keep a complete presence stanza for an unbounded amount of time (potentially forever). This looks like a vector for a state-exhaustion attack. The restriction for keeping only one such stanza per sender helps, but a malicious attacking server could send stanzas from an arbitrary number of identites. I suggest providing implementation guidance on when it's ok to drop information that's truly stale, and call out the potential for this attack in the security considerations.
      Section 5.2.4 calls out "for the purpose of providing alternate versions of the same subject" when allowing multiple subjects to appear with different xml:lang attributes. Section 5.2.3 does not have analogous text constraining multiple bodies. Should it?
      Section 5.3 - Was the intent to constrain the contents of a message stanza to things intended to be rendered to a user? As written, this section would allow <message/> to be used as part of the framing of an arbitrary transport protocol.
      Section 5.3 - The document should say what an implementation receiving a child element in a namespace it doesn't understand should do with that child.
    5. Robert Sparks: Comment [2011-01-19]:
      In section 2.3.3, is the intent that error conditions listed earlier in the section take precedence over error conditions listed later in the section? What's the appropriate response if a message qualifies for both a <forbidden/> and a <bad-request/> as described in this section?
      When would an element choose not to follow the SHOULD in 3.1.2 item 1, and what are the consequences?
      The end of section 4.3 has an implementation note containing normative requirements. Can these be moved into the main prose? This same implementation note may be easy to misinterpret. I don't believe it is meant to prevent an implementation from returning an error to a malformed presence probe, but it could be read that way.
      Section 5.2.5 does not prevent a thread from claiming it is its own parent (should that be allowed?), or warn implementations about the possibility of thread A indicating a parent of B, and thread B indicating a parent of A (generalize this to any kind of cycle). I don't think XEP-0201 calls this out either. Should it be mentioned as an implementation consideration? (A naive implementation would very likely crash or do something surprising with its UI.)
      In section 8.5.2.1, I encourage adding text explaining why delivering to all non-negative resources is SHOULD and not MUST. I understand from out-of-band communication that local policy may determine that some particular resource not receive the message, but the document does not say this. As written, I can see implementations that adopt a policy of delivering to the first non-negative resource and claim they've met the requirement.

    Telechat:

  4. Pseudowire (PW) OAM Message Mapping (Proposed Standard)
    draft-ietf-pwe3-oam-msg-map-14
    Token: Stewart Bryant
    Note: Andrew Malis, andrew.g.malis@verizon.com is the document shepherd.
    IPR: Cisco's Statement about IPR Claimed in draft-ietf-pwe3-oam-msg-map-05.txt
    Discusses/comments (from ballot 3588):
    1. Adrian Farrel: Discuss [2011-01-03]:
      There are a couple of nits reported by idnits (an out of date reference, an old license statement). I think the license statement should be fixed and posted (to reflect the authors' intent) before the document is approved.
      I see IPR disclosed at http://datatracker.ietf.org/ipr/863/ I don't see this declared in the proto write-up. More important, it is not present in the IETF last call announcement in datatracker.
      What is the situation wrt multi-segment PWs? I can understand that this document was developed before the WG turned to MS-PWs, but we now have RFC 5254 and RFC 5659.
      I would prefer that this document fully addressed MS-PWs. That would not be hard because each PW segment at an S-PE regards the adjacent segments as ACs, so it could probably be addressed in just one or two paragraphs in a new section.
      However, an option is to declare MS-PW out of scope, and provide a forward reference to work being done on OAM message mapping for MS-PWs in the PWE3 WG.
      Section 4.2: "If LSP-Ping [RFC4379] is run over a PW as described in [RFC4377], it will be referred to as "VCCV-Ping". "
      I believe s/RFC4377/RFC5085/
      Section 5: You should add a note to explain why the CE ends of the ACs are not considered as possible defect locations. They are part of the emulated service, so a naif reader might expect to see them listed. Possibly you will want to explicitly include it in case (a).
      Additionally, your text does not match the figure: "c. Defect on a PE1 PSN interface." But (c) also appears on the PE2-PSN interface in the figure.
      Furthermore, (e) and (f) appear tbe reversed in the figure compared to the text.
      Section 13: RFC 5085 and RFC 4447 should be presented as references.
      I will let Security experts comment further, but:
      It seems to me that facilitating end-to-end coordination of PW status and fualt reporting provides an extra tool for attackers. I would expect this to be pointed out and held up as a reason for ensuring the use of the security mechanisms.
      I think that there are security coordination issues. Perhaps these are already mentioned in the references. Consider carrying NS OAM from CE to CE across the PSN in Single Emulated OAM Loop mode or Coupled OAM Loops mode. The security relationship perceived by the CEs would presumably be between each other, but doesn't the PE need to participate?
    2. Adrian Farrel: Comment [2011-01-03]:
      Section 3: s/whereby/where/
      The Introduction uses a number of acronyms without prior expansion...
      Section 4.1: Several acronyms are not used in the rest of the document...
      Section 4.2: "The words "defect" and "fault" are used interchangeably..." I'm fine with this, but I think "obstructs" is ambiguous. Do you mean "impose a complete blockage", or do you mean to include degradation in some form? Perhaps you could add a clarification.
      Section 4.2: "If BFD is run over a PW as described in [RFC5885], it will be referred to as "VCCV-BFD"." Add a reference to [RFC5880]
      Section 4.2: "A "transmit defect" is any defect that impacts traffic that is meant to be sent or relayed by the observing PE. A "receive defect" is any defect that impacts traffic that is meant to be received by the observing PE."
      While "meant to be" is appropriate for the reception of data, I don't think it necessarily applies to transmission. Consider that the defect may be somewhat downstream of (and not yet notfied to) the upstream PE such that the traffic that is impaced is that which *has* been sent or relayed by the observing PE.
      Additionally, the term "observing PE" has not been defined and may clarify or complicate the meaning of the text.
      I had a few problems with Section 8.1. I think my issue is with the use of the control plane as an OAM exchange mechanism (this also shows up in Appendix B). I believe the section could benefit from some polishing.
      "For MPLS and MPLS/IP PSNs, a PE that establishes a PW using Label Distribution Protocol [RFC3036] MUST use the LDP status TLV as the mechanism for AC and PW status and defect notification, as explained in [RFC4447]."
      I don't think that this "MUST" is good or consitent with:
      - the text in Section 7 that is relaxed in saying "LDP or in the ACH"
      - the work in MPLS-TP
      It sounds like 3036 (or rather 5036) is a normative reference.
      While conveying PW status in LDP per 4447 is fine, it is not OAM with the utility of rapid propagation of fault notifications. LDP, reliant as it is on TCP, is not suitable to that purpose.
      Wouldn't it be better to require the use of the ACH for OAM fault notification messages, and (if you must :-) mandate the use of LDP for status information propagation when LDP is present (but not as a replacement for real OAM).
      Additionally... "Additionally, a PE MAY use VCCV-BFD Connectivity Verification (CV) for fault detection only (CV types 0x04 and 0x10 [RFC5885]) but SHOULD notify the remote PE using the LDP Status TLV." The "SHOULD" here seems to be in conflict with te previous "MUST"
      And it goes on... "A PE that establishes a PW using means other than LDP, e.g., by static configuration or by use of BGP, MAY use VCCV-BFD CV (CV types 0x08 and 0x20 [RFC5885]) for AC and PW status and defect notification. Note that these CV types SHOULD NOT be used when the PW is established with the LDP control plane."
      If you supply only a "MAY" you should probably describe how else the fault notification might work.
      As to the "SHOULD NOT" in the last sentence. Well, see my previous comments. And what possible harm could it do?
      Section 6: "Generally, a PE cannot detect transmit defects directly and will therefore need to be notified of AC transmit or PW transmit defects by other devices."
      I think you mean s/directly/direct/
      Section 8.1.1: "[RFC4447] specifies that the "Pseudowire forwarding" code point is used to clear all faults. It also specifies that the "Pseudowire Not Forwarding" code is used to convey any defect that cannot be represented by the other code points."
      The language seems rather week. The use of the code point does not clear the faults. It is used to report (notify) that the faults have been cleared. Likewise, defects are not conveyed by the use of a control points, but existence of the defect can be reported (or conveyed, if you like).
    3. Russ Housley: Comment [2011-01-05]:
      Appendix B.3: s/Los/Loss/

    Telechat:

  5. Indication of support for keep-alive (Proposed Standard)
    draft-ietf-sipcore-keep-11
    Token: Robert Sparks
    Note: Adam Roach (adam@nostrum.com) is the document shepherd.
    Discusses/comments (from ballot 3595):
    1. Adrian Farrel: Comment [2011-01-17]:
      Section 1.2: "In some cases all SIP entities that need to be able to negotiate the usage of keep-alives might not support SIP Outbound. However, they might still support the keep-alive mechanisms defined in SIP Outbound, and need to be able to negotiate usage of them."
      Do you actually mean... "In some cases not all SIP entities that need to be able to negotiate the use of keep-alives might support SIP Outbound. However, they might still support the keep-alive mechanisms defined in SIP Outbound, and need to be able to negotiate usage of them."
      Or maybe more elegant as... "In some cases some SIP entities that need to be able to negotiate the use of keep-alives might not support SIP Outbound. However, they might still support the keep-alive mechanisms defined in SIP Outbound, and need to be able to negotiate usage of them."
    2. Alexey Melnikov: Comment [2011-01-12]:
      8. Grammar: "This specification defines a new Via header field parameter, "keep". The ABNF [RFC5234] is:
      via-params =/ keep
      keep = "keep" [ EQUAL 1*(DIGIT) ]
      "
      This doesn't tell me where <via-params>, <EQUAL> or <DIGIT> is defined. Please add the references as either ABNF comments or in the text before the grammar.
    3. Peter Saint-Andre: Comment [2011-01-10]:
      1. In second paragraph of the Security Considerations, please spell out "TLS" and "DTLS" on first use and add informative references for the relevant specifications.
      2. In the fourth paragraph of the Security Considerations, the specification says that a SIP entity MUST stop sending keep-alive requests if it does not receive responses to the STUN keep-alives that it sends to an adjacent downstream SIP entity. However, this does not take into account the fact that STUN requests and responses could be dropped, so it would be good to provide some more specific guidance here, e.g., stop sending STUN keep-alive requests if no STUN responses are received after sending two or more STUN requests (it seems suboptimal to stop sending STUN keep-alive requests if no response is received to only the very first STUN keep-alive request). Furthermore, no guidance is provided about the number of seconds the sender should wait before concluding that the adjacent downstream SIP entity has not responded. If these matters are covered in RFC 5389 then it would be helpful to cite the specific sections where they are discussed (e.g., Section 7.2.1 regarding retransmission timeouts).
    4. Sean Turner: Comment [2011-01-20]:
      Juergen Schoenwaelder spotted two editorial nits in the security considerations during his SECDIR review:
      a) [...] This specification does not specify a connection reuse mechanism, and it does it address security issues related to connection reuse. [...]
      s/it does it/it does not/
      b) [...] They do not instruct the enity to place a value in a "keep" parameter of any request it forwards. [...]
      s/enity/entity/

    Telechat:

  6. Registration for Multiple Phone Numbers in the Session Initiation Protocol (SIP) (Proposed Standard)
    draft-ietf-martini-gin-12
    Token: Gonzalo Camarillo
    Note: Bernard Aboba (Bernard_Aboba@hotmail.com) is the document shepherd.
    Discusses/comments (from ballot 3597):
    1. Adrian Farrel: Comment [2011-01-20]:
      AOR is used without expansion in the abstract.
    2. Alexey Melnikov: Comment [2011-01-19]:
      In Section 7.1.2: "All base64 encoding discussed in the following sections MUST use the character set and encoding defined in RFC 2045 [1],"
      RFC 4648 is a better reference here.
      In Section 7.1.2.1: SHA256-80 needs a reference and an explanation (i.e. that the output of the hash function is truncated to 80 bits).
      The first reference to TLS needs an Informative reference.
    3. Dan Romascanu: Comment [2011-01-18]:
      The OPS-DIR review by Warren Kumari signalled a number of nits which would be useful to fix...
    4. Robert Sparks: Comment [2011-01-19]:
      The examples in section 8 have bugs that are important to fix before publication. The Call-ID changes unintentionally in each example. The messages that have two Via header field values have the values in the wrong order.
    5. Sean Turner: Discuss [2011-01-20]:
      #1) Section 7.1.2.2: The following threw me for a loop: "A SIP-PBX that issues temporary GRUUs to its UAs MUST maintain an HMAC key, PK_a. This value is used to validate that incoming GRUUs were generated by the SIP-PBX."
      I'm probably reading more in to "PK_a" than I ought to but it isn't a Public Key (PK) - right!? It would be bad to use a public key as the HMAC secret. SK_a is terminology used in Section 7.1.2.1 - can we use the same term or SK_SSP and SK_SIP-PBX?
      #2) The scenarios in Section 8.1 and 8.2 do not show the authentication step called. I think it should or the text should say we left them out but you still need to do them.
      #3) Alexey caught the bit about HMAC-256-80 needing a reference. I think it's a bigger deal because I don't which which parts of the output get used: 1st 80bits, last 80bits, etc.? It's hard to interoperate without knowing this. But, if a reference exists it'll be easy to clear.
    6. Sean Turner: Comment [2011-01-20]:
      Section 7.1.2.2: Seems like there should be a pointer to RFC 4086 for the "D" method.

    Telechat:

  7. Base Deployment for Multicast Listener Support in PMIPv6 Domains (BCP)
    draft-ietf-multimob-pmipv6-base-solution-07
    Token: Jari Arkko
    Note: Behcet Sarikaya (sarikaya@ieee.org) is the document shepherd.
    Discusses/comments (from ballot 3609):
    1. Stewart Bryant: Comment [2011-01-19]:
      I agree with Lars.
    2. Ralph Droms: Discuss [2011-01-18]:
      If I'm reading the document correctly, the LMAs arrange to receive multicast streams and forward the streams to the MAGs, which then forward the streams to subscribed MNs.
      In figure 1, suppose MN1, associated with LMA1, and MN2, associated with LMA2, are both associated with multicast stream MC. Will MAG1 receive copies of MC from both LMA1 and LMA2?
      Was a design considered in which the MAG arrange directly for the delivery of multicast streams as required by attached MNs?
    3. Lars Eggert: Discuss [2011-01-17]:
      DISCUSS: I'm not getting why this document is going for BCP. Informational seems fully adequate to me.
    4. Adrian Farrel: Discuss [2011-01-20]:
      The use of RFC 2119 language puzzles me. Are statement like:
      "As links connecting MNs and MAGs change under mobility, MLD proxies at MAGs MUST be able to dynamically add and remove downstream interfaces in its configuration."
      Making new definitions of behavior, or are they refering to existing norms specified elsewhere (that is, restating requirements)? In the former case, it looks like the document is actually Standards Track. In the latter case, I suggest inserting a reference and dropping to lower case.
      And other statements like: "In summary, the following steps are executed on handover:" [SNIP] "4. The MAG SHOULD determine whether the MN is admissible to multicast services, and stop here otherwise."
      In this case "SHOULD" is not indicative of a step that is executed.
    5. Adrian Farrel: Comment [2011-01-20]:
      MN-HNP is used without expansion
    6. Alexey Melnikov: Comment [2011-01-19]:
      I agree with Lars, although I don't have a strong opinion on the matter.
    7. Peter Saint-Andre: Comment [2011-01-18]:
      I concur with Lars's DISCUSS regarding the intended status of this document. Other than that, the document seems fine.

    Telechat:

  8. Routing Metrics used for Path Calculation in Low Power and Lossy Networks (Proposed Standard)
    draft-ietf-roll-routing-metrics-16
    Token: Adrian Farrel
    Note: David Culler (culler@eecs.berkeley.edu) is the document shepherd.
    Discusses/comments (from ballot 3622):
    1. Jari Arkko: Discuss [2011-01-18]:
      I am concerned about the complexity of the RPL system. The set of attributes is relatively complex, 8 different attributes (The BGP parameters registry has 26, but RPL is expected to be run in environments where there is no experts to monitor its operation or fine-tune the parameters.) The large set of attributes, dynamically changing parameters, complex topologies, and unattended operation seems like a recipe for operational and interoperability problems. I do recognize the need to have dynamic metrics, power-aware routing, and many of the other things in this specification, however. My question is whether this is the absolute minimum set that we should define. Do we need Section 2.1 A field? Section 3.1 A or O flags? The mid-complexity solution from Section 3.2? Section 4.3.1 *and* Section 4.3.2 reliability metrics?
      A few more specific concerns:
      Section 3.1: "A Flag: data Aggregation Attribute. Data fusion involves more complicated processing to improve the accuracy of the output data, while data aggregation mostly aims at reducing the amount of data."
      This is underspecified. And why do you talk about data fusion, if the attribute signals data aggregation. Please define what the semantics of the bit and the participant's behaviour is with respect to data aggregation, or point to a reference.
    2. Jari Arkko: Comment [2011-01-18]:
      I agree with Lars Eggert's Discuss.
      Section 4.3: "In LLNs, link reliability is degraded by external interference and multi-path interference (wireless links). Multipath typically affects both directions on the link equally, whereas external interference is sometimes unidirectional."
      I'm not sure I understand the term "multi-path interference" in this context. Perhaps you should use some other term. Multi-path usually refers to the use of multiple paths simultaneously. Radio interference from multiple links can certainly occur in ROLL networks. But I'm not sure why you call it "multi-path interference". I would probably just say "... degraded by attenuation (due to distance and objects) and interference (from external objects or within the RPL network)".
    3. Ron Bonica: Discuss [2011-01-19]:
      This may be a DISCUSS-DISCUSS.
      I believe that in order to achieve loop-free routing, the following conditions must be true:
      - all nodes must construct identical link state data bases (LSDB)
      - all nodes must run identical (or at least equivalent) SPF algorithms over that LSDB
      While I understand how ROLL devices might construct identical LSDBs, I don't understand how all nodes will run and identical (or even equivalent) SPF algorithms. The first problem is that all nodes don't neccessarily understand all metrics advertised with C-bit == 0. So, if all SPFs don't understand all of the same inputs, how can they be expected to produce the same outputs? THe second problem is an SPF with multiple inputs is pretty complex. Is it documented well enough that multiple vendors may produce interworking implementations? Finally, a node might advertise a metric with C-bit = 0 and then override that same metric with C-bit =1. When that happens, does the old advertisement disappear from the LSDB.
    4. Lars Eggert: Discuss [2011-01-17]:
      DISCUSS: My high-level concern with this document is that it focuses on how metrics are encoded in RPL TLVs, rather than giving formal and therefore unambiguous definitions of the metrics. Not in all cases, but in several. For example, the misnamed "throughput" metric doesn't make it clear whether it describes nominal link capacity or residual capacity, or whether it is an instantaneous metric or averaged over some period, etc. The "delay" metric leaves it open whether buffering delays are supposed to be included or not. The link reliability metric is much too open; when does e.g. a ZigBee link have a reliability of 5? When of 6? Hat about a BT-LE link? And so on.
      The reason I'm bringing this up is that in oder to have route selection pick paths for end systems based on these metrics, it needs to be understood what these metrics concretely *mean*. I don't think that's currently possible, and I believe that makes them rather less useful that advertised. If IPPM has taught us anything it's that metrics really do need to be unambiguously defined for them to be useful.
      I realize this discuss isn't really actionable. I plan to clear it after discussing my concern with the IESG call.
    5. Lars Eggert: Comment [2011-01-17]:
      (mostly Nits)
    6. Alexey Melnikov: Comment [2011-01-15]:
      In 2.1: "The A field has no meaning when the C Flag is set (i.e. when the Routing Metric/Constraint object refers to a routing constraint) and he only valid when the R bit is cleared. Otherwise, the A field MUST"
      Is "he" should be here at all?
      4.1. Throughput: "Throughput: 32 bits. The Throughput is encoded in 32 bits in unsigned integer format,"
      In network byte order? (Also in 4.2)
    7. Dan Romascanu: Discuss [2011-01-18]:
      1. Section 2.1 - Value: variable for Routing Metric/Constraint TLVs. What is the length range. 255 is maximum I assume, but is zero an acceptable length value?
      2. Section 3.1 - "An implementation MAY decide to add optional TLVs (not currently defined) to further describe the node traffic aggregator functionality."
      It is not clear to me how an implementation can make such a decision. Two different implementations would not be interoperable if this is not defined some place. Is this about extensibility?
      3. Section 3.2 - it is not clear from the text that estimating the 'energetic happiness' - actually the remaining power battery for battery operated devices is always possible, and if not how this metrics is being filled in. Will just the E bit be cleared and no estimation provided?
      4. Section 4.2 - the latency metric is unsufficiently defined. What is the measurement observation point? is buffering taken into consideration?
      5. Section 4.3.1: "The Link Quality Level (LQL) object is used to quantify the link reliability using a discrete value, from 0 to 7 where 0 indicates that the link quality level is unknown and 1 reports the highest link quality level. The mechanisms and algorithms used to compute the LQL are implementation specific and outside of the scope of this document."
      This seems broken. How can interoperability be ensured between two independent implementations if the metric is a discrete value whose algorithm of determination is implementation specific?
    8. Dan Romascanu: Comment [2011-01-18]:
      1. The way the Flag field is defined in Figure 1 is confusing. The field is defined as length 16 bits, but then there are 5 bits labelled Flags on the diagram which are actually the currently reserved or un-allocated Flags. The A field and PRec filed are part of the Flag field, but there is no indication or indent to make this clear.
      2. Expand DIO at first occurence
      3. Section 4.1 - the Throughput object seems to be mis-named. Looks more like Link Capacity.
    9. Peter Saint-Andre: Comment [2011-01-19]:
      Based on the reviews provided by IESG members more expert than I in the technology under consideration, I am ballotting "No Objection". That said, based on my own review I concur with the DISCUSS raised by Jari Arkko regarding the complexity of the system.

    Telechat:

  9. Compression Format for IPv6 Datagrams in 6LoWPAN Networks (Proposed Standard)
    draft-ietf-6lowpan-hc-13
    Token: Ralph Droms
    Note: The Document Shepherd is 6LoWPAN WG co-chair Carsten Bormann
    (cabo@tzi.org).
    Discusses/comments (from ballot 3627):
    1. Jari Arkko: Comment [2011-01-19]:
      Ari Keränen reviewed this draft. His comments: ...
    2. Ron Bonica: Comment [2011-01-19]:
      I also support the GENART DISCUSS on the checksum
    3. Stewart Bryant: Comment [2011-01-19]:
      I support Russ' Discuss on the checksum.
      The mandatory use of checksum in IPv6 is controversial amongst some IETF communities (particularly the community using UDP as a tunnel type). Either this controversy needs to be resolved, or draft-ietf-6lowpan-hc needs to deal correctly with the c/s /no c/s case. It could of course do this by always carrying the c/s, but it seems perverse to have to carry 16 bits of c/s to say that there is no c/s.
    4. Lars Eggert: Discuss [2011-01-17]:
      [Edited to include David Black's gen-art review, since I'm already holding a discuss on part of the issues he has raised.]
      Section 4.3.2., paragraph 1: "The UDP checksum operation is mandatory with IPv6 [RFC2460] for all packets. For that reason [RFC4944] disallows the compression of the UDP checksum. With this specification, a compressor in the source transport endpoint MAY elide the UDP checksum if it is authorized by the Upper Layer. The compressor SHOULD NOT set the C bit unless it has received such authorization. The Upper Layer SHOULD only provide the authorization in the following cases"
      DISCUSS: First, I think you want to use "MUST NOT" and "MAY only" here. Second, there are additional issues here (see draft-ietf-6man-udpzero). For example, even if there is an upper layer integrity check present for a given app, if the port number field gets corrupted and a message gets mis-delivered to an incorrect application (port), *that* application may not have an upper layer integrity check implemented to protect it. And so on. Have you run this part of the spec by 6MAN?
      Also, from David Black: "A forwarding node MAY imply authorization from an incoming packet if the C bit is set. A forwarding node that cannot unambiguously derive such authorization SHOULD NOT elide the UDP checksum when performing 6LoWPAN compression."
      This needs to be a MUST NOT.
    5. Adrian Farrel: Discuss [2011-01-16]:
      Section 4.3.1: "This specification introduces a range of well-known ports (0xF0Bx) that can be compressed to 4 bits."
      I don't believe that these are "Well Known Ports". They would be in the range 0-1023.
      They appear to be "Dynamic and/or Private Ports"
      I guess you are trying to say that these ports are known by 6lowpan hc implementers. Maybe a complete rewriting of this sentence?
      "This specification defines the use of range of ports from the Dynamic and/or Private Ports range. Using only ports of the type 0xF0Bx means that the port number can be compressed to 4 bits."
      But I am unclear that you are really using this range of port numbers! Are you not actually using 4 bits to encode up to 16 port number aliases and, as your text says, you require some mapping to be installed to expand those aliases back to real port numbers.
      If I am wrong (and you are really using ports in the range you state) you need to add text to indicate how this is safe and will not clash with other usage of these port numbers that might happen randomly as an application picks (dynamically or privately) some port number to use.
    6. Adrian Farrel: Comment [2011-01-16]:
      I found a few small points of house-keeping: ...
    7. Russ Housley: Discuss [2011-01-18]:
      The Gen-ART Review by David Black on 17-Jan-2011 lead to a discussion about the use of checksums with UDP. This discussion does not seem to be over. The last thing that I saw was:
      "I'm still unhappy since the text allows a middle point to recomputed the checksum which then might be delivered erroneously to the wrong IP or port. This was done to ensure that a packet that flows on the Internet would 'look right' to middle boxes and end points. It is probably OK for most 802.15.4 cases since L2 security is almost always on and protects the frames a lot better than 2 octets of checksum. But if there's no security at work, it would probably be better to let the packet go with a zero checksum and add some text on authorizing that an arbitrary end point."
      This discussion needs to reach a resolution before this document is approved.
    8. Peter Saint-Andre: Comment [2011-01-10]:
      1. According to Section 2, this document appears to update RFC 4944. However, the document header does not include "Updates: RFC 4944".
      2. In Section 6, please add an informative reference for Transport Layer Security (TLS).
    9. Sean Turner: Comment [2011-01-20]:
      I support Russ's discuss.

    Telechat:

  10. Extensions to IS-IS for Layer-2 Systems (Proposed Standard)
    draft-ietf-isis-layer2-09
    Token: Stewart Bryant
    Note: David Ward (dward@juniper.net) is the document shepherd.
    Discusses/comments (from ballot 3645):
    1. Ron Bonica: Comment [2011-01-17]:
      Please run the nit-checker. There are a few missing and unused references.
    2. Ralph Droms: Discuss [2011-01-18]:
      IESG Writeup appears to be missing; will clear when I can review the background on WG review and consensus.
    3. Ralph Droms: Comment [2011-01-18]:
      Extraordinarily pedantic nit: MAC address in section 2.1 is not to scale...
    4. Lars Eggert: Comment [2011-01-17]:
      Section 2.2., paragraph 2: "Type: TLV Type, set to MT-PORT-CAP TLV 143 [TBD]."
      What's TBD here?
    5. Russ Housley: Comment [2011-01-19]:
      Please consider the editorial comments in the Gen-ART Review by Kathleen Moriarty on 19- Jan-2011.
    6. Alexey Melnikov: Comment [2011-01-14]:
      2.2. Multi Topology aware Port Capability TLV: "Topology Identifier: MT ID is a 12-bit field containing the MT ID of the topology being announced. This field when set to zero implies that it is being used to carry base topology information."
      Excuse my ignorance, but is this description actually sufficient for interoperability? Which values are valid here and where are they coming from?
      Also I don't think specifying exact values before they are assigned by IANA is a good idea.
    7. Dan Romascanu: Discuss [2011-01-18]:
      The OPS-DIR review by Menachem Dodge (posted in the tracker) raised a number of issues which I believe require clarification and edits. As the authors of the document answered that they will deal with the comments in a revised version of the document I am holding a DISCUSS until the comments are resolved by edits or detailed clarification answers.

    Telechat:

  11. TRILL Use of IS-IS (Proposed Standard)
    draft-ietf-isis-trill-04
    Token: Stewart Bryant
    Note: David Ward (dward@juniper.net) is the document shepherd.
    Discusses/comments (from ballot 3646):
    1. Ralph Droms: Discuss [2011-01-20]:
      This DISCUSS is a placeholder to ensure an issue with draft-ietf-trill-rbridge-protocol-16 is addressed before publication. I"ll clear as soon as updates to draft-ietf-trill-rbridge-protocol-16 are agreed to and the RFC Editor is informed of the changes.
      draft-ietf-trill-rbridge-protocol-16 was written before draft-ietf-isis-layer2 was split into 3 documents. A reference to draft-ietf-isis-trill needs to be added to draft-ietf-trill-rbridge-protocol-16, and citations to draft-ietf-isis-layer2 need to be checked against the split between draft-ietf-isis-layer2 and draft-ietf-isis-trill.
      This DISCUSS also applies to draft-ietf-isis-layer2, but there is no need to delay publication of draft-ietf-isis-layer2 while draft-ietf-trill-rbridge-protocol-16 is updated.
    2. Lars Eggert: Comment [2011-01-17]:
      (Nit)
    3. Alexey Melnikov: Comment [2011-01-16]:
      It might be worth mention the byte order used for fields longer than 1 byte.
    4. Dan Romascanu: Discuss [2011-01-17]:
      Before approving this document I believe that the following statement made in the Introduction section needs clarification:
      "Intermediate Systems (ISs) implementing TRILL are compatible with IEEE 802.1 customer bridges and can incrementally replace such bridges."
      What does 'compatible' mean in this context? What are the IEEE 802.1 customer bridges that can incrementally be replaced by ISs implementing TRILL. Either a reference to the exact IEEE 802.1 standards or a reference to the IETF documents that specify these would be useful.

    Telechat:

  12. Generalized Labels for Lambda-Switching Capable Label Switching Routers (Proposed Standard)
    draft-ietf-ccamp-gmpls-g-694-lambda-labels-11
    Token: Adrian Farrel
    Note: Lou Berger (lberger@labn.net) is the document shepherd.
    Discusses/comments (from ballot 3670):
    1. Stewart Bryant: Comment [2011-01-19]:
      "In the scenario of Figure 1, consider the setting up of a bidirectional LSP from ingress switch 1 to egress switch 9 using GMPLS RSVP-TE."
      Figure 1 shows them as nodes
      "To deal with the widening scope of MPLS into the optical and time domains"
      I think that you mean ... optical switching and time division multiplexing domains.
      "In a case, the label indicates the wavelength to be used for the LSP."
      Do you mean "In this case.." ?
    2. Alexey Melnikov: Comment [2011-01-20]:
      I am missing some text about byte order for 16bit fields.
      4. Security Considerations: "This document introduces no new security considerations to [RFC3471] and [RFC3473]. For a general discussion on MPLS and GMPLS related security issues, see the MPLS/GMPLS security framework [RFC5920]."
      Surely lasers are dangerous weapons and kids shouldn't be allowed to play with them.

    Telechat:

  13. IPv4 and IPv6 Infrastructure Addresses in Multicast-VPN Routes (Proposed Standard)
    draft-ietf-l3vpn-mvpn-infra-addrs-02
    Token: Stewart Bryant
    Note: Ben Niven-Jenkins (ben@niven-jenkins.co.uk) is the document shepherd.
    Discusses/comments (from ballot 3671):
    1. Stewart Bryant: Comment [2011-01-18]:
      - In a couple of places, the word "route" occurs where it would be clearer to say "NLRI"
      - The paragraph on "VRF Route Import Extended Community" is misplaced, as it is an attribute of IP-VPN routes rather than of MCAST-VPN routes; this paragraph should probably be a top-level section of its own.
      - That paragraph contains the term "IPv6 Address Specific Route Target" when it should say "IPv6 Extended Community".
    2. Lars Eggert: Comment [2011-01-17]:
      I agree with Alexey's discuss that this document is probably missing a bunch of "updates" relationships.
      Additionally, with regards to [MVPN-BGP], could some or maybe all of the content of this ID rolled into [MVPN-BGP]? (Since that isn't actually published yet?)
    3. Adrian Farrel: Comment [2011-01-16]:
      I have reviewed this I-D and support its publication as an RFC with the change proposed to resolve Alexey's Discuss.
    4. Russ Housley: Discuss [2011-01-18]:
      The Gen-ART Review by Suresh Krishnan on 17-Jan-2011 asks a question that deserves a response: will this document update draft-ietf-l3vpn-2547bis-mcast-bgp-08, once it is published as an RFC?
    5. Alexey Melnikov: Discuss [2011-01-16]:
      The document begs for "Updates: RFC XYZW", I am just not sure what this RFC XYZW needs to be. Maybe it would need to update multiple RFCs.
      For example, when I read this text:
      1.3. IPv4 and IPv6 Addresses in MCAST-VPN Routes: "[MVPN-BGP] defines a new set of BGP route types that are used by SPs to provide Multicast Virtual Private Network service to their customers. These routes have a newly defined BGP NLRI, the "MCAST-VPN" NLRI... ..."
      It looks to me that this document is fixing a deficiency in [MVPN-BGP] and/or [BGP-MP]. Thus it looks like it should be Updating at least one of them.
      As per reply from Eric Rosen: the document should use "Updates: [MVPN-BGP]"

    Telechat:

2.1.2 Returning Items

  1. (none)

2.2 Individual Submissions

2.2.1 New Items

  1. Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS) (BCP)
    draft-saintandre-tls-server-id-check-14
    Token: Alexey Melnikov
    Note: There is an open question on whether this document should be a BCP or PS. As the shepherding AD I don't have a strong opinion either way.

    Discusses/comments (from ballot 3205):
    1. Lars Eggert: Comment [2011-01-17]:
      Section 1.5., paragraph 8: "These suggestions are not entirely consistent with all practices that are currently followed by certification authorities, client developers, and service providers. However, they reflect the best aspects of current practices and are expected to become more widely adopted in the coming years."
      This seems to argue that the doc should be a BCP and not a PS?
      (three Nits)
    2. Tim Polk: Discuss [2011-01-20]:
      This is a discuss-discuss. I support publication as a BCP, but thought some of the guidance should be much stronger.
    3. Robert Sparks: Discuss [2011-01-19]:
      I agree with the review comments supporting publishing this as PS and not as BCP.
      The majority of this document is specifying behavior that is appropriate to progress through the standards ladder. There is a small section providing guidance to certificate authorities that could be written as a BCP, encouraging "full and immediate instantiation" (see section 5.1 of RFC2026). If it's important to give that section BCP designation, I suggest placing it in a separate document. However, I think it will have the same effect in this document, published as PS.
      Assuming the consensus is to move forward as proposed standard, I expect to move to a "Yes" position.

    Telechat:

  2. Signer Info Algorithm Protection Attribute (Proposed Standard)
    draft-schaad-smime-algorithm-attribute-04
    Token: Sean Turner
    Note: Jim Schaad (ietf@augustcellars.com) is the Document Shepherd.
    Discusses/comments (from ballot 3664):
    1. Lars Eggert: Comment [2011-01-17]:
      INTRODUCTION, paragraph 4: Signer Info Algorithm Protection Attribute: "A new attribute is defined that allows for protection of the digest and signature algorithm structures in an authenticated data or a signer info structure. Using the attribute includes the algorithm definition information in the integrity protection process."
      It's be good if the title and abstract had some context that this stuff is about CMS...
    2. Adrian Farrel: Comment [2011-01-18]:
      The use of the passive voice in the first sentence of the Abstract is disconcerting!
      There is also some missing context!
      The second sentence is pretty hard to parse. Why not write:
      "This document defines a new attribute that allows for protection of the digest and signature algorithm structures in an authenticated data or a signer info structure used in the Cryptographic Message Syntax (CMS). When the new attribute is used, the algorithm definition information is included in the integrity protection process."
      The introduction would benefit from a similar (but more verbose) fix.
      I think it is conventional to include a reference to the ASN.1 spec that defines the language you are using. Presumably X.208 (1988) and X.209 (1988) could be added as references.
    3. Russ Housley: Discuss [2011-01-19]:
      Some signature algorithms, such as RSA PKCS#1 v1.5, sign both the digest algorithm identifier and the message digest. So, if the attacker changes the identifier, the signature will not validate. While this is not true of all signature algorithms, it does significantly diminish the scope of the concern being addressed by this document. Please add this to the discussion.
    4. Robert Sparks: Comment [2011-01-19]:
      Can the section on comparing fields in the verification process (2nd paragraph of section 3) be made more precise? Currently, it says "It is not required that a field which is absent in one case and present in another case be compared as equivalent". Does that mean it's allowed to compare those as equivalent? Or was the intent that they MUST NOT be equivalent?

    Telechat:

2.2.2 Returning Items

  1. (none)

3. Document Actions

3.1 WG Submissions

3.1.1 New Items

  1. Example call flows using Session Initiation Protocol (SIP) security mechanisms (Informational)
    draft-ietf-sipcore-sec-flows-08
    Token: Gonzalo Camarillo
    Note: Adam Roach (adam@nostrum.com) is the document shepherd.
    Discusses/comments (from ballot 3629):
    1. Alexey Melnikov: Comment [2011-01-19]:
      6. Additional Test Scenarios: "assure that the most specific CommonName in the Subject field matches if there are no dNSName entries in the subjectAltName at all (which is not the same as there being no matching dNSName entries). This match can be either exact, or against an entry that uses the wildcard matching character '*' "
      Anywhere in the domain pattern or only in the leftmost position?
      Nits: The usual (many acronyms are not spelled out on first use, etc.)
    2. Dan Romascanu: Comment [2011-01-18]:
      The 'Observed Interoperability Issues' section includes a number of example of implementation problems detected during the SIPit events. I can guess that this information canges in time, as interoperability problems due to implementation bugs or lack of clarity in documents are in the majority of the cases being fixed in the coming releases of the implementations. For this purpose it would be useful I think to mention what is the time reference (may be the indication of the SIPit event) when the problems were detected.
    3. Peter Saint-Andre: Comment [2011-01-18]:
      This is a fine document. My only nits ...
    4. Sean Turner: Discuss [2011-01-20]:
      #1) The AKIs seems to include all three possibilities. RFC 5280 says: "The identification MAY be based on either the key identifier (the subject key identifier in the issuer's certificate) or the issuer name and serial number."
      It also goes on to recommend using the keyIdentifier choice. I'd remove the other two (authorityCertIssuer and authorityCertSerialNumber) they're just making the certificates bigger than they need to be.
      #2) User certificate subject names: look a lot like email addresses. RFC 5280 requires that new implementations put the email address in the SAN extension with the rfc822Name choice. Shouldn't the last component of the user's common name be Cullen Jennings, Kumiko, etc and then put the email addresss in SAN:rfc822Name?
    5. Sean Turner: Comment [2011-01-20]:
      Appendix A: Add an informative reference to PKCS#8 [RFC5958].
      ASN.1 dumps: The "hority" wraps around the line oddly.
      Section 5: Is it worth noting that the SHA2 algs also say don't include the parameters according to [RFC5754].

    Telechat:

  2. A Security Framework for Routing over Low Power and Lossy Networks (Informational)
    draft-ietf-roll-security-framework-04
    Token: Adrian Farrel
    Note: JP Vasseur (jpv@cisco.com) is the document shepherd.
    Discusses/comments (from ballot 3630):
    1. Russ Housley: Discuss [2011-01-19]:
      The Gen-ART Review by David Black raised a significant concern. The confidentiality and privacy requirements are SHOULD. It seems to me that they ought to be "MUST implement" so that every implementation can be configured to make use of confidentiality and privacy. An alternative would be "MUST implement" coupled with "SHOULD use when" statements, or "SHOULD" coupled with "geographic information MUST NOT be handled when confidentiality protection is not enabled."
    2. Tim Polk: Discuss [2011-01-20]:
      I think this is a really good document, and support its publication. However, I think some of the issues I was persuaded to remove from my discuss on roll-rpl because they would be more appropriate in this document were omitted. I am specifically concerned about punting the details on public key distribution, then finding they are not covered here either.
      Did I get the wrong document? Where are those issues going to be addressed?
      I will hold this discuss while we sort out the best place to address these issues...
    3. Peter Saint-Andre: Comment [2011-01-19]:
      1. In Section 3.2, "the service of non-repudiation implies after-the-fact" sounds like it should be "the service of non-repudiation applies after-the-fact" but instead the authors seem to mean that "the service of non-repudiation implies that the attack occurs after the fact" or somesuch.
      2. In Section 3.3, "can all contribute to key management issues" could be construed as contributing to important or critical ("key") issues related to network management, not as "complicating the operations of key management" as in the previous paragraph; I suggest repeating the previously-used phrasing.
      There are also several unfortunate typographical errors (e.g., "fundament" instead of "fundamental" in Section 3.4, "undue utilization of exhaustion" instead of "undue utilization or exhaustion" in Section 4.3.4, "any device local or remote" instead of "any local or remote device" in Section 5.1.5, "compliment" instead of "complement" in Section 6.1, "aimed the manipulation" instead of "aimed at the manipulation" in Section 6.5).
      With regard to Denial of Service (DoS) in Section 4.3.3, please add a reference to RFC 4732.
      Please provide informative references for OSPF and ISIS in Section 5.2.5.
      In Section 6.1, is uppercase "MAY" meant in the text "new ciphering key may therefore be concurrently generated or updated"?
      In Section 6.4, is uppercase "MUST" meant in the text "a LLN must include a process for key and credential distribution"?
      In Section 6.4, is uppercase "SHOULD" meant in the text Correspondingly, the routing protocol(s) specified by the ROLL Working Group should assume that the system affords key management mechanisms consistent with the guidelines given in [RFC4107]"?
      In Section 6.5, is uppercase "SHOULD" meant in the text " As routing is one component of a LLN system, the actual strength of the security services afforded to it should be made to conform to each system's security policy"?
      (And so on; in general, I suggest that the authors check all lowercase keywords throughout Section 6.)

    Telechat:

  3. MPLS Transport Profile User-to-Network and Network-to-Network Interfaces (Informational)
    draft-ietf-mpls-tp-uni-nni-03
    Token: Adrian Farrel
    Note: Loa Andersson (loa@pi.nu) is the Document Shepherd.
    Discusses/comments (from ballot 3656):
    1. Russ Housley: Discuss [2011-01-19]:
      The Gen-ART Review by Ben Campbell on 21-Dec-2010 lead to a discussion. The discussion of Figure 1 and Figure 2 does not seem to be finished. The discussion needs to reach closure before this document is approved.

    Telechat:

  4. Threat Analysis for TCP Extensions for Multi-path Operation with Multiple Addresses (Informational)
    draft-ietf-mptcp-threat-07
    Token: Lars Eggert
    Note: Yoshifumi Nishida (nishida@sfc.wide.ad.jp) is the document shepherd.
    Discusses/comments (from ballot 3669):
    1. Jari Arkko: Comment [2011-01-19]:
      In Section 3, where the document discusses differences between MIPv6 RO and MPTCP situation I had a couple of comments. First, I'm not sure I understand what you mean with the bullet about MIPv6 relying on the original path always being available. MIPv6 certainly assumes that the path that we are using at that moment is working, and if it is not, the system will attempt to move to some other address or network attachment point. Secondly, I think you are missing one additional difference: in MIPv6 we assume that there's always a trusted third party (the home agent) that can help us with some of the security problems. In MPTCP there is no such entity. You might also be missing the difference that MPTCP intends to be able to use multiple paths simultaneously, which was not an original design goal of the MIPv6 work.
      In Section 6.3, the text discusses the effects of NAT on securing the implicitly reported new address. The text fails to explain that while explicit mode would allow better protection of the reported new address, such protection would be pointless because it would protect an address that is no longer relevant on the outside of the NAT. You actually *need* to report the address as changed by the NAT. And by the way, I see nothing wrong with that... that's is how current TCP works, too.
      I like the basic recommendations in Section 7. But I am unsure if the analysis in the document actually supports the advanced recommendation to have optional support for HMAC. Why would that needed? Also, should the conclusions say something about how MPTCP design should deal with sequence number spaces -- it seems that different choices here would result in different impacts.
    2. David Harrington: Comment [2011-01-19]:
      While fully understandable, I found the text a bit wordy, with extra phrases and clauses thrown in where they really weren't needed. This document could be much more concise, and if you are doing a new revision, you might want to consider tightening up the text. But this is purely a style issue, and the authors are free to ignore this comment if they so choose. ...
    3. Alexey Melnikov: Comment [2011-01-15]:
      In Section 1: "This note includes a threat analysis for MPTCP. It should be noted that there are there may other ways to provide multiple paths for a TCP"
      This doesn't read well
      In Section 3: "Similarly to the MPTCP case,"
      Did you mean "MIPv6 RO" here?
    4. Dan Romascanu: Comment [2011-01-20]:
      In the OPS-DIR review Lionel Morand raised the issue that it is recommended to allow the support of multiple security mechanisms but there is nothing about potential related mechanism negotiation issues. I suggest that this be addressed before the publication of the document, even if it is not a blocking issue.

    Telechat:

  5. Architectural Guidelines for Multipath TCP Development (Informational)
    draft-ietf-mptcp-architecture-04
    Token: Lars Eggert
    Note: Philip Eardley (philip.eardley@bt.com) is the Document Shepherd.
    Discusses/comments (from ballot 3672):
    1. Jari Arkko: Comment [2011-01-19]:
      An excellent document. Thanks for writing it. I would change the urgent data support to a MAY, however.
    2. David Harrington: Comment [2011-01-19]:
      1) The architecture document has no discussion of how MPTCP should be managed, or what types of information should be made accessible for management purposes. I believe it should - at an architectural level.
      However, since this is the architecture document for a protocol being put forth as Experimental, it would be beneficial to take the results of the experiment into consideration when designing an appropriate management solution. Therefore, I have reduced this to a comment.
      TCP is intrumented with a MIB that is widely implemented on devices and used by network management applications. MPTCP should share that MIB for aspects that are designed to be transparent to the application. However, there should be extensions specific to MPTCP so an operator can monitor the operational state and impact of MPTCP. For example,
      a) MPTCP should be able to be enabled/disabled, the enabled/disabled state should be able to be queried, and the fallback mentioned in section 2.1 should be indicated in operational state.
      b) if there are errors or congestion on a path and MPTCP can detect those errors or congestion, it should make that information available to an operator via the MIB.
      c) if MPTCP can determine the performance of each path, that information should be made available via the MIB for use by performance monitoring applications.
      d) if MPTCP can determine the different security state of different paths, that information should be made available via the MIB. It would probbaly be good if an operator can choose to provide a weight for different paths based on the security properties of the path.
    3. Russ Housley: Discuss [2011-01-19]:
      The Gen-ART Review by Joel Halpern on 14-Jan-2011 raises one concern that needs to be addressed. That is, "break-before-make" is added in the security design decisions in section 5.8. Even if this is merely a desirable behavior, it should be described in the behaviors before being referenced in the design decisions.
    4. Alexey Melnikov: Comment [2011-01-16]:
      5.6. Connection Identification: "Legacy applications will not, however, have access to this identifier and in such cases a MPTCP connection will be identified by the 5-tuple of the first TCP subflow. It is out of the scope of this document, however, to define the behaviour of the MPTCP implementation if the first TCP subflow later fails... In the case of applications that have used an existing API call to bind to a specific address or interface, the MPTCP extension MUST NOT be used, since the applications are indicating a clear choice of path to use and thus will have expectations of behaviour that must be maintained, in order to adhere to the application compatibility goals."
      I am not convinced your use of MUST NOT is correct here. In fact, it seems that it is in direct conflict with the following paragraph:
      "Since the requirements of applications are not clear at this stage, however, it is as yet unconfirmed what the best behaviour is. It will be an implementation-specific solution, however, and as such the behaviour is expected to be chosen by implementors once more research has been undertaken to determine its impact."
      I.e., it is actually possible to know from the current socket API what is the application intent in this case?
    5. Dan Romascanu: Comment [2011-01-20]:
      I support David's COMMENT

    Telechat:

3.1.2 Returning Items

  1. (none)

3.2 Individual Submissions Via AD

3.2.1 New Items

  1. URI Scheme for Java(tm) Message Service 1.0 (Informational)
    draft-merrick-jms-uri-11
    Token: Alexey Melnikov
    Discusses/comments (from ballot 3514):
    1. Lars Eggert: Comment [2011-01-17]:
      INTRODUCTION, paragraph 4: "The syntax of this 'jms' URI is not compatible with any known current vendor implementation, but the expressivity of the format should permit all vendors to use it."
      So are there vendor implementations of 'jms' already? If yes, what it the value in publishing a specification that is not compatible with any of them? Or do we have an indication that the vendors will adopt this spec?
    2. Alexey Melnikov: Comment [2011-01-14]:
      It looks like IANA issue was actually addressed in the last revision.

    Telechat:

  2. Addition of the ARIA Cipher Suites to Transport Layer Security (TLS) (Informational)
    draft-nsri-tls-aria-01
    Token: Sean Turner
    Note: Woo-Hwan Kim (whkim5@ensec.re.kr) is the document shepherd
    Discusses/comments (from ballot 3662):
    1. Adrian Farrel: Comment [2011-01-20]:
      "This document proposes the addition of new cipher suites to the Transport Layer Security (TLS)"
      Please don't be so timid. "This document defines/specifies ..."
    2. Dan Romascanu: Comment [2011-01-18]:
      Please expand PRF at first occurence.

    Telechat:

  3. Experiment: Hash functions with parameters in CMS and S/MIME (Experimental)
    draft-schaad-smime-hash-experiment-04
    Token: Sean Turner
    Note: Jim Schaad (ietf@augustcellars.com) is the document shepherd.
    Discusses/comments (from ballot 3665):
    1. Lars Eggert: Discuss [2011-01-17]:
      DISCUSS: ID is missing the RFC2119 boilerplate and reference.
    2. Lars Eggert: Comment [2011-01-17]:
      (Nits)
    3. Russ Housley: Discuss [2011-01-19]:
      There are many algorithm identifiers that specify a hash algorithm and a signature algorithm used in combination. It is highly desirable that the same hash algorithm be used for computing the digest of the attributes and the content. How would xor-md5WithRSAEncryption be handled?
    4. Alexey Melnikov: Discuss [2011-01-19]:
      I generally support this experiment. However the MIME section contains several errors that need to be fixed before this document can be approved: ...
    5. Alexey Melnikov: Comment [2011-01-19]:
      RFC 1847 needs to be an Informative Reference. I think MIME as well.

    Telechat:

3.2.2 Returning Items

  1. (none)

3.3 IRTF and Independent Submission Stream Documents

3.3.1 New Items

  1. Cisco Vendor Specific RADIUS Attributes for the Delivery of Keying Material (Informational)
    draft-zorn-radius-keywrap-18
    Token: Dan Romascanu
    Discusses/comments (from ballot 2377):
    1. Lars Eggert: Comment [2007-01-25]:
      Agree with Russ and Dan.
    2. Dan Romascanu: Comment [2011-01-13]:
      In the Abstract Section s/This attributes/These attributes/

    Telechat:

3.3.2 Returning Items

  1. (none)

3.3.3 For Action

  1. The Internet Routing Overlay Network (IRON) (Experimental)
    draft-templin-iron-17
    Token: Jari Arkko
    Note: Tony Li (tony.li@tony.li) is the document shepherd.
    Discusses/comments (from ballot 3638):
    1. Jari Arkko: Comment [2010-12-16]:
      (blank)
    2. Stewart Bryant: Comment [2010-12-15]:
      I am surprise that the document contains no reference to LISP which is operating broadly in this space.
      SRA is not a defined abbreviation.
      This needs a few words of clarification - presumably the "locator addresses" are the addresses learned from the relay: "After the Client receives an SRA message from the nearby Relay listing the locator addresses of nearby Servers, it sends SRS test messages to one or more of the locator addresses to elicit SRA messages."
      "If this Server fails, the Client will quickly select a new one which will automatically update the VPC overlay network mapping system with a new EP-to-Server mapping."
      "quickly" is a non-specific metric
      [I-D.templin-intarea-seal] looks like it should be normative
      [I-D.templin-intarea-vet] looks like it should be normative
      Although the RFCeditor may wish to overlook this if there is a concern that these drafts will not be taken to completion.
    3. Ralph Droms: Comment [2010-12-16]:
      I have one suggestion about the content of the document. I'd like to see an analysis of how IRON actually "provide[s] scalable PI addressing without changing the current BGP [RFC4271] routing system" along with costs incurred by IRON. How does hiding the EPA addresses inside the IRON locator prefixes reduce the routes in the real Internet core? What is the cost in the routing tables maintained by the relays? How expensive is the anycast routing? How does inter-VPC routing work and how expensive is it?
      The remainder of my COMMENTs are editorial. ...
    4. Adrian Farrel: Comment [2010-12-16]:
      Thank you for bringing this work forward as Experimental and so increasing the documentation and discussion of potential solutions.
      I feel that it would be helpful if the document contained a pointer to draft-irtf-rrg-recommendation so that the other ideas in the field can be easily found and compared.

    Telechat:

1257 EST break

1302 EST back

4 Working Group Actions

4.1 WG Creation

4.1.1 Proposed for IETF Review

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

    Telechat:

4.1.2 Proposed for Approval

  1. Audio/Video Transport Payloads (payload)
    Token: Robert

    Telechat:

  2. Metric Blocks for use with RTCP's Extended Report Framework (xrblock)
    Token: Robert

    Telechat:

  3. Audio/Video Transport Core Maintenence (avtcore)
    Token: Robert

    Telechat:

  4. Audio/Video Transport Extensions (avtext)
    Token: Robert

    Telechat:

4.2 WG Rechartering

4.2.1 Under evaluation for IETF Review

  1. Mobility EXTensions for IPv6 (mext)
    Token: Jari

    Telechat:

4.2.2 Proposed for Approval

  1. (none)

5. IAB News We can use

6. Management Issues

  1. IPR disclosure mailing list selections (Jari Arkko)

    Telechat:

  2. Archiving Media Type registrations from other SDOs on www.iana.org (Alexey Melnikov)

    Telechat:

  3. Request for early allocation [IANA #419797] (Michelle Cotton)

    Telechat:

  4. Posting rights to the iesg-only@ietf.org mailing list (Alexey Melnikov)

    Telechat:

  5. Executive Session (Russ)

    Telechat:

7. Agenda Working Group News

1458 EST End of open session


Valid HTML 4.01 Strict


Appendix: Snapshot of discusses/comments

(at 2011-01-20 07:27:33 PST)

draft-ietf-mmusic-image-attributes

  1. Adrian Farrel: Comment [2011-01-20]:
    I have only partially reviewed this document, but I have no objection to
    the technical content in this document. I found a lot of the text 
    somewhat ambiguous or hard to parse, and the number of such issues was 
    (IMHO) close to making the document quality suspect and warranting a 
    Discuss. Although the RFC Editor will work on these issues, it is my 
    opinion that such a level of changes will result in a proportion of
    cases will result in:
    - bad fixes made by the RFC Editor
    - issues being missed.
    
    I urge the authors to at least make fixes to the issues I have
    identified, and preferably find a technology-aware native speaker to
    review and update the text.
    
    ---
    
    The Abstract really needs to mention SDP
    
    I would prefer if the Introduction was also clearer sooner that this 
    document applies to SDP
    
    ---
    
    SDP is not a well-known acronym according to the RFC Editor
    (http://www.rfc-editor.org/rfc-style-guide/abbrev.expansion.txt)
    so should be expanded:
    - in the title
    - in the Abstract when you add it
    - on first use in the main text
    
    ---
    
    You should expunge all references to "draft" and replace with "document"
    (when published as an RFC, this will not be a draft!)                    
    
    ---
    
    In the Abstract...
    
       The draft also helps to maintain an optimal bitrate for video
       as only the image size that is desired by the receiver is
       transmitted.
    
    A nice trick if you can do it, but actually, I think that someone needs
    to implement something! How about...
    
       The mechanisms defined in this document can also be used to help
       maintain an optimal bitrate for video, as only the image size that is
       desired by the receiver is transmitted.
    
    ---
    
    Section 1
    
       This document proposes a new attribute to make it possible to
       negotiate different image attributes such as image size.  The term
       image size is defined here as it may differ from the physical screen
       size of for instance a hand-held terminal.
    
    I do not find the term "image size" defined.
    You may want s/defined/used/ or you may want to add the definition.
    
    ---
    
    Section 1
    
       There are a number of benefits with a possibility to negotiate the
       image size:
    
    /with a/to the/
    
    ---
    
    Section 1
    
       o  Optimal quality for the given bitrate: The sender does not need to
          encode an entire CIF (352x288) image if only an image size of
          288x256 is displayed on the receiver screen.  This alternatively
          gives a saving in bitrate.
    
    s/alternatively/alternative/  ?
    
    ---
    
    REQ-1
    s/wish/wishes/
    
    ---
    
    3.1.1
    
       o  The attribute typically contains a "send" and a "recv" keyword.
          These specify the preferences for the media once the session is
          set up, in the send and receive direction respectively from the
          point of view of the sender of the session description.  One of
          the keywords ("send" or "recv") MAY be omitted, see Section 3.2.4
          and Section 3.2.2 for a description of cases when this may be
          appropriate.
    
    I see this saying:
       The attribute MUST contain at least one of the keywords "send" and
       "recv".
    
    ---
    
    3.1.1
    
       o  For sendrecv streams both of the send and recv directions SHOULD
          BE present in the SDP.
    
    s/BE/be/
    
    ---
    
    3.1.1
    
       o  For inactive streams it is RECOMMENDED that both of the send and
          recv directions are present in the SDP.
    
    s/SDP/SDP message/ ?
    
    ---
    
    3.1.1.1
    
       Payload type number (PT):  The image attribute is bound to a specific
          codec by means of the payload type number.
    
    It may be obvious, but there is no statement of where the possible 
    values of PT can be found. I think you should add this.
    
  2. David Harrington: Comment [2011-01-18]:
    This document is well-written. These comments require no action by the authors,
    but if these fixes were applied, it might make for a cleaner document.
    
    1) in the first sentence of the introduction, s/attribute/SDP attribute/
    2) in
    the introduction, sar used without definitinon or reference
    3) in 3.1.1, for
    sendrecv streams you use SHOULD BE - BE is not an RFC2119 keyword. The next
    bullet uses RECOMMENDED. RECOMMENDED and SHOULD mean the same things in RFC2119.
    It woul dbe nice to be consistent so people ar enot in any way confused by the
    different language.
    4) in 3.1.1.1, the sentence starting "several image
    attributes can be defined" is a bit convoluted, and it makes it difficult to
    parse. "conditioned that" is an unusual wording that makes it harder to parse.
    It is unclear whether the "conditioned that" is part of the "for instance", or
    part of the "can be defined".
    5) payload type - what s the range? are these
    types defined in a registry someplace?
    6) preference - what is the range of q?
    is this 0.0-1.0, or are 100.0 and -65537.7 valid values? 
    7) sar - what is the
    range of values?
    7) sar - I am confused by the "(range)" in this sentence - do
    you mean it defines a specific range of sample aspect ratios associated to a
    given x and y image size?
    8) "The response MUST NOT include a sar parameter if
    there is no acceptable value given." - what does acceptable mean here?  
    9) how
    does one express a sar range? is it "0.1-0.7" or "0.1...0.7" or dx/dy "0.1/0.7"
    or 0.142857143?
    10) "The offerer must be able to support ... The exception is"
    Isn't MUST with an exception a SHOULD?
    11) Can we capitalize the RFC2119
    keywords?
    12) "to reduce this risk", why isn't this a MUST?
    13) in 3.2.2
    s/answer/answerer/
    14) in 3.2.2, if the third approach solves the problem and
    has no drawbacks, why not make that one a MUST, and make the other two options
    MUST NOT?
  3. Russ Housley: Comment [2011-01-20]:
      As noted in the Gen-ART Review by Avshalom Houri on 19-Jan-2011, the
      following lines in Section 4.2.4 need to be reworded:
      >
      > Neither part is required to rescale like this (sar may be ignored),
      > the consequence will of course be a distorted image.
    
      Also, please consider the editorial changes proposed in the Gen-ART
      Review by Avshalom Houri.
  4. Alexey Melnikov: Comment [2011-01-14]:
    I've done a detailed review of the document and overall I think it is fine. Some
    comments below:
    
    Last paragraph of section 3.1.1.1, last sentence:
    
          Where ratio_min and ratio_max are the min and max allowed picture
          aspect ratios.
          If sar and the sample aspect ratio that the receiver actually uses
          in the display are the same (or close), the relation between the x
          and y pixel resolution and the physical size of the image is
          straightforward.  If however sar differs from the sample aspect
          ratio of the receiver display this must be taken into
          consideration when the x and y pixel resolution alternatives are
          sorted out.
    
    This doesn't say how to achieve that.
    
    In 3.1.1.2:
    
      o  Answerer receiving the offer and sending the answer:
    
          *  The answerer should not include an image attribute in the
             answer if it was not present in the offer.
    
    s/should not/SHOULD NOT ?
    
    Also check if "may"s in this section should be MAYs.
    
    3.2.7.4.  Possible solutions
    
       o  2nd session-wide offer/answer round: In the 2nd offer/answer the
          codec payload format specific parameters are defined based on the
          outcome of the 'imageattr' negotiation.  The drawback with this is
          that set up of the entire session (including audio) may be delayed
          considerably, especially as the 'imageattr' negotiation can
          already itself cost up to two offer/answer rounds.  Also the
          conflict between the 'imageattr' negotiation and the payload
          format specific parameters is still present after the first offer/
          anser round and a fuzzy/buggy implementation may start media
    
    typo: answer
    
          before the second offer/answer is completed with unwanted results.
    
  5. Tim Polk: Discuss [2011-01-17]:
        This is mostly a discuss-discuss, but also is a reminder that the authors have
    agreed to add security considerations
    about DoS attacks after a discussion with
    the security directorate reviewer (Stephen Farrell).  Since no text has been
    proposed as yet, and I agree with his premise, I will hold the discuss as a
    placeholder even after the discussion
    takes place...
    
    Actionable part:
    When an offeror "sees no reason to use the image attribute",
    section 3.2.1 recommends including the attribute with
    the wildcard.  The
    security directorate review notes that an answerer could select attributes that
    would demand
    significant resources, resulting in a DOS attack.  To resolve this,
    I believe some text needs to be added noting
    that memory and other resource
    considerations need to be considered before accepting the response, even if the
    specified attributes can be supported/accepted.
    
    Here's the discuss-discuss part: the ABNF permits the attribute list to be a
    wild card for both send and recv.  Is there
    any good reason for the offeror to
    specify the wildcard (as opposed to an explicit list) for the send attribute
    list?  Are
    there really any systems that would not restrict the formats it was
    willing to send to a list?  Offering to send media
    without restricting the
    format seems to invite the kind of DoS attack that Stephen was thinking about.
    (Flexibility
    regarding reception of media seems more logical to me, although
    there is still a clear attack vector.) 
        
  6. Peter Saint-Andre: Comment [2011-01-18]:
    The technical content of this document appears to be acceptable.
    
    The document is difficult to read in numerous places because of run-on sentences
    and non-standard English.
    
    I suggest that the authors review the conformance terms in accordance with RFC
    2119, because sometimes lowercase keywords (lacking any conformance meaning) are
    used when uppercase keywords seem more appropriate. For example, in the
    following sentence "MUST" seems better than "must":
    
          *  The offerer must be able to support the image attributes that
             it offers.
    
    There are also several instances of uppercase keywords when no conformance
    meaning is in force. For example, in the following sentence "needs to" seems
    better than "MUST":
    
          *  If the image attribute is included in the SDP answer but none
             of the entries are usable or acceptable, the offerer MUST
             resort to other methods to determine the appropriate image
             size.
  7. Sean Turner: Comment [2011-01-19]:
    I support Tim's discuss.

draft-ietf-tls-rfc4347-bis

  1. Ron Bonica: Comment [2011-01-17]:
    Suport OPS-DIR DISCUSS
  2. Stewart Bryant: Comment [2011-01-19]:
     
  3. Adrian Farrel: Discuss [2011-01-20]:
        A small but important point, I think.
    
    Section 4.3 needs to inanding the factwithstclude a reference to RFC 5246 for
    the defnition of the syntax used. This is important (not that the changes are
    relative to 5246) because although the format looks like 'C' it is not 'C' 
        
  4. Adrian Farrel: Comment [2011-01-20]:
    I support Alexey's Discuss about description of the changes since/to 4347
    
    ---
    
    Should the version numbering be recorded by IANA?
    
    ---
    
    How is wrapping of epoch and sequence number handled? Or is it considered that
    they will never need to wrap?
    
    ---
    
    It might be valuable to repeat the UDP warning from 4.1.2.7 in section 5
    
    ---
    
    Section 4.3
    
       This section includes specifications for the data structures that
       have changed between TLS 1.2 and DTLS.
    
    I think s/DTLS/DTLS 1.2/
    
    ---
  5. Russ Housley: Discuss [2011-01-18]:
        
      The Gen-ART Review by Miguel Garcia on 12-Dec-2010 raised a question
      about Section 4.1 that deserves a response.  The reivew says:
    
      Section 4.1, previous last paragraph on page 8: The sentence requires
      implementations to compute the TCP maximum segment lifetime. If an
      implementation runs DTLS over UDP, how can it compute the TCP maximum
      segment lifetime, which is a parameter for a different protocol? I
      suspect DTLS implementations running over UDP (or even SCTP) will not
      have a clue of what is the TCP maximum segment lifetime. 
        
  6. Alexey Melnikov: Discuss [2011-01-02]:
        This is a fine document and I generally support its publication. However I have
    2 minor issues which I would like to discuss before recommending approval of
    this document:
    
    1). 7. IANA Considerations
    
       This document uses the same identifier space as TLS [TLS12], so no
       new IANA registries are required.  When new identifiers are assigned
       for TLS, authors MUST specify whether they are suitable for DTLS.
    
    Does this mean that this document Updates [TLS12]?
    Section 4.1.2.5 also confirms that.
    
    2). I don't see a section "changes since DTLS 1.0" required by ID-nits. Can you
    convince me that it is not needed? 
        
  7. Alexey Melnikov: Comment [2011-01-02]:
    SCTP, RC4, SCTP-AUTH should have Informative references.
    
  8. Tim Polk: Comment [2011-01-20]:
    placeholder for Charlie Kaufman's secdir review - this deserves a response.  I
    made this a comment since I know that the sponsoring AD intends to seem them
    addressed.
  9. Dan Romascanu: Discuss [2011-01-17]:
        The DISCUSS and COMMENT is largely based on the OPS-DIR review by Pekka Savola.
    I did not see the issues raised by Pekka answered and I believe that part of
    them (listed below) need to be addressed.
    
    1. The document does not describe how DTLS 1.2 will interwork with DTLS 1.0 (if
    it will). The TLS 1.2 spec (RFC5246, Appendix E.1) does have some that will
    apply, but there are likely some DTLS specifics as well.
    
    2. 
    
    > 3.2.3. Message Size
    
         TLS and DTLS handshake messages can be quite large (in theory up to
         2^24-1 bytes, in practice many kilobytes).  By contrast, UDP
         datagrams are often limited to <1500 bytes if fragmentation is not
         desired.  In order to compensate for this limitation, each DTLS
         handshake message may be fragmented over several DTLS records.  Each
         DTLS handshake message contains both a fragment offset and a fragment
         length.
    
    > 4.1.1. Transport Layer Mapping
    
         Each DTLS record MUST fit within a single datagram.  In order to
         avoid fragmentation, clients of the DTLS record layer SHOULD attempt
         to size records so that they fit within any PMTU estimates obtained
         from the record layer.
    
    ... these seem somewhat contradictory.  Maybe I'm missing something.  The latter
    seems to be saying that DTLS implementations should try to avoid IP
    fragmentation, but the former seems to imply that it's de-facto mode of
    operation.
    
    3. 
    >      If there is a transport protocol indication (either via ICMP or via a
         refusal to send the datagram as in DCCP Section 14), then DTLS record
         layer should inform the upper layer protocol of the error.
    
    Why a 'should'?  I've have thought that it would be natural that if DTSLS record
    layer gets this notification (which, in the case of ICMP and omitting
    information, is not necessarily given), it MUST pass this information up. Note
    that the refusal to send could also apply to UDP if packet is bigger than PMTU
    and DF bit is set or IPv6 is used.
    What is the alternative if it doesn't?  It
    would be fine if the alternative is that the DTLS record layer react to that
    information itself, but completely ignoring e.g. ICMP packet too big would lead
    to communication failure
    
    4. 
    
    > 7. IANA Considerations
    
         This document uses the same identifier space as TLS [TLS12], so no
         new IANA registries are required.  When new identifiers are assigned
         for TLS, authors MUST specify whether they are suitable for DTLS.
    
    ... this may be inadequate.  I was unable to find from the registry
    (tls-parameters) which of these parameters this applies to.  All of them?
    
    If I understand what you mean, 1) you should actually be asking IANA to reformat
    the registry so that there is an additional column in all the tables "DTLS-OK?"
    or some such, and possibly 2) modifying TLS 1.2 spec IANA registration
    guidelines (i.e. what should the IANA requesters know about when they're making
    their request), and also possibly 3) asking IANA to ask future registrants about
    DTLS-OK feature if the requestor fails to do so on their own. 
        
  10. Dan Romascanu: Comment [2011-01-17]:
    1. The document does not have a "Changes from DTLS 1.0 (RFC4347)" section which
    is customary in 'bis' documents. Why?
    
    2. For the completeness, when referring to PMTU discovery, in addition to
    RFC1191 one should probably also refer to RFC1981 (the IPv6 version).
    
         [WHYIPSEC] Bellovin, S., "Guidelines for Mandating the Use of IPsec",
                    Work in Progress, October 2003.
    
    ... this should probably be rfc5406?
    
         [IKEv2]    C. Kaufman (ed), "Internet Key Exchange (IKEv2) Protocol",
                    RFC 4306, December 2005.
    
         Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306,
                    December 2005.
    
    ... remove the latter 'reference' (edit glitch?)
    
  11. Peter Saint-Andre: Comment [2011-01-18]:
    I support Alexey's DISCUSS regarding the need for a section describing the
    changes from DTLS 1.0 (RFC 4347).

draft-ietf-xmpp-3921bis

  1. Lars Eggert: Comment [2011-01-17]:
    Section 2.3.3., paragraph 1:
    >    the roster get, or even <not-llowed/> if the server only allows
    
      Nit: s/<not-llowed/>/<not-allowed/>/
    
    Section 4., paragraph 7:
    >       presence, or an error occurs in relation to the proble, then the
    
      Nit: s/proble,/probe,/
    
  2. Adrian Farrel: Comment [2011-01-17]:
    I'm ballotting "no objection" based on selective reading of a few sections of
    this I-D and "trust" of the WG, the author, and the ADs who have ballotted
    "yes".
  3. Alexey Melnikov: Comment [2011-01-19]:
    I like Robert's comments, modulo the 4th point in his DISCUSS, which I think is
    already covered by rfc3920bis.
    
    In 4.3.2:
    
          Implementation Note: The handling of the 'id' attribute in
          relation to presence probes was unspecified in RFC 3921.  Although
          the pattern of "send a probe and receive a reply" might seem like
          a request-response protocol similar to the XMPP <iq/> stanza, in
          fact it is not because the response to a probe might consist of
          multiple presence stanzas (one for each available resource
          currently active for the contact).  For this reason, if the
          contact currently has available resources then the contact's
          server SHOULD preserve the 'id' attribute of the contact's
          original presence stanza (if any) when sending those presence
          notifications to the probing entity; however,
    
    Use of "however" can be read as if the 'id' attribute is not to be returned
    in the case specified below, however it is still returned. I suggest dropping
    "however" here.
    
          if the contact
          currently has no available resources, the probing entity is not
          authorized (via presence subscription) to see the contact's
          presence, or an error occurs in relation to the proble, then the
          contact's server SHOULD mirror the 'id' of the user's presence
          probe when replying to the probing entity.
    
    In 4.5.2:
    
       The user's server MUST also send the unavailable notification to all
       of the user's available resources (including the resource that
       generated the presence notification in the first place).
    
    Comment: The text in (): but the resource is unavailable :-).
    
       The <subject/> element MUST NOT contain mixed content (as defined in
       Section 3.2.2 of [XML]).
    
    Should the same be said about presence' <status> element?
    
    11.  Security Considerations
    
       o  A user's server MUST NOT leak the user's network availability to
          entities who are not authorized to know the user's presence,
          either via an explicit subscription as described herein or via an
          existing trust relationship (such as presence-enabled user
          directories within organizations).
    
    I don't understand this paragraph. If a user is subscribed to presence,
    then she is authorized to know user's presence?
    
  4. Robert Sparks: Discuss [2011-01-19]:
        DISCUSS
    In section 3.1.3 item 4, a server is required to keep a complete
    presence stanza for an unbounded amount of time (potentially forever).  This
    looks like a vector for a state-exhaustion attack. The restriction for keeping
    only one such stanza per sender helps, but a malicious attacking server could
    send stanzas from an arbitrary number of identites. I suggest providing
    implementation guidance on when it's ok to drop information that's truly stale,
    and call out the potential for this attack in the security considerations.
    
    Section 5.2.4 calls out "for the purpose of providing alternate versions of the
    same subject" when allowing multiple subjects to appear with different xml:lang
    attributes. Section 5.2.3 does not have analogous text constraining multiple
    bodies. Should it?
    
    Section 5.3 - Was the intent to constrain the contents of a message stanza to
    things intended to be rendered to a user? As written, this section would allow
    <message/> to be used as part of the framing of an arbitrary transport protocol.
    Section 5.3 - The document should say what an implementation receiving a child
    element in a namespace it doesn't understand should do with that child. 
        
  5. Robert Sparks: Comment [2011-01-19]:
    COMMENT
    
    In section 2.3.3, is the intent that error conditions listed earlier in the
    section take precedence over error conditions listed later in the section?
    What's the appropriate response if a message qualifies for both a <forbidden/>
    and a <bad-request/> as described in this section?
    
    When would an element choose not to follow the SHOULD in 3.1.2 item 1, and what
    are the consequences?
    
    The end of section 4.3 has an implementation note containing normative
    requirements. Can these be moved into the main prose?  This same implementation
    note may be easy to misinterpret. I don't believe it is meant to prevent an
    implementation from returning an error to a malformed presence probe, but it
    could be read that way.
    
    Section 5.2.5 does not prevent a thread from claiming it is its own parent
    (should that be allowed?), or warn implementations about the possibility of
    thread A indicating a parent of B, and thread B indicating a parent of A
    (generalize this to any kind of cycle). I don't think XEP-0201 calls this out
    either. Should it be mentioned as an implementation consideration? (A naive
    implementation would very likely crash or do something surprising with its UI.)
    
    In section 8.5.2.1, I encourage adding text explaining why delivering to all
    non-negative resources is SHOULD and not MUST. I understand from out-of-band
    communication that local policy may determine that some particular resource not
    receive the message, but the document does not say this. As written, I can see
    implementations that adopt a policy of delivering to the first non-negative
    resource and claim they've met the requirement.

draft-ietf-pwe3-oam-msg-map

  1. Adrian Farrel: Discuss [2011-01-03]:
        There are a couple of nits reported by idnits (an out of date reference,
    an old license statement). I think the license statement should be
    fixed and posted (to reflect the authors' intent) before the document is
    approved.
    
    ---
    
    I see IPR disclosed at http://datatracker.ietf.org/ipr/863/
    I don't see this declared in the proto write-up. More important, it is
    not present in the IETF last call announcement in datatracker.
    
    ---
    What is the situation wrt multi-segment PWs? I can understand that this
    document
    was developed before the WG turned to MS-PWs, but we now have
    RFC 5254 and RFC
    5659.
    
    I would prefer that this document fully addressed MS-PWs. That would not
    be hard because each PW segment at an S-PE regards the adjacent segments
    as ACs, so it could probably be addressed in just one or two paragraphs
    in a new section.
    
    However, an option is to declare MS-PW out of scope, and provide a
    forward
    reference to work being done on OAM message mapping for MS-PWs
    in the PWE3 WG.
    
    ---
    
    Section 4.2
    
       If LSP-Ping [RFC4379] is run over a PW as described in [RFC4377], it
       will be referred to as "VCCV-Ping".
    
    I believe s/RFC4377/RFC5085/
    
    ---
    
    Section 5
    You should add a note to explain why the CE ends of the ACs are not
    considered
    as possible defect locations. They are part of the emulated
    service, so a naif
    reader might expect to see them listed. Possibly you
    will want to explicitly
    include it in case (a).
    
    Additionally, your text does not match the figure:
       c. Defect on a PE1 PSN interface.
    But (c) also appears on the PE2-PSN interface in the figure.
    
    Furthermore, (e) and (f) appear tbe reversed in the figure compared to
    the text.
    
    ---
    
    Section 13
    
    RFC 5085 and RFC 4447 should be presented as references.
    
    I will let Security experts comment further, but:
    
     It seems to me that facilitating end-to-end coordination of PW status
     and fualt reporting provides an extra tool for attackers. I would
     expect this to be pointed out and held up as a reason for ensuring the
     use of the security mechanisms.
    
     I think that there are security coordination issues. Perhaps these are 
     already mentioned in the references. Consider carrying NS OAM from CE 
     to CE across the PSN in Single Emulated OAM Loop mode or Coupled OAM
     Loops mode. The security relationship perceived by the CEs would 
     presumably be between each other, but doesn't the PE need to 
     participate? 
        
  2. Adrian Farrel: Comment [2011-01-03]:
    Section 3                  
    s/whereby/where/
    
    ---
    
    The Introduction uses a number of acronyms without prior expansion.
    On the other hand, having defined acronyms in Section 4.1, you don't
    gave to expand them in subsequent sections.
    
    ---
    
    Section 4.1
    Several acronyms are not used in the rest of the document.
    BDI
    CPCS
    IWF
    
    s/label Switched Path/Label Switched Path/
    s/Operations, Administration and Maintenance/
      Operations, Administration, and Maintenance/
    
    ---
    
    Section 4.2
    
       The words "defect" and "fault" are used interchangeably to mean any
       condition that obstructs forwarding of user traffic between the CE
       endpoints of the PW service.
    
    I'm fine with this, but I think "obstructs" is ambiguous. Do you mean
    "impose a complete blockage", or do you mean to include degradation in
    some form? Perhaps you could add a clarification.
    
    ---
    
    Section 4.2
    
       If BFD is run over a PW as
       described in [RFC5885], it will be referred to as "VCCV-BFD".
    
    Add a reference to [RFC5880]
    
    ---
    
    Section 4.2
    
       A "transmit defect" is any defect that impacts traffic that is meant
       to be sent or relayed by the observing PE.  A "receive defect" is any
       defect that impacts traffic that is meant to be received by the
       observing PE.
    
    While "meant to be" is appropriate for the reception of data, I don't
    think it necessarily applies to transmission. Consider that the defect
    may be somewhat downstream of (and not yet notfied to) the upstream PE
    such that the traffic that is impaced is that which *has* been sent or
    relayed by the observing PE.
    
    Additionally, the term "observing PE" has not been defined and may
    clarify or complicate the meaning of the text.
    
    ---
    
    I had a few problems with Section 8.1. I think my issue is with the
    use of the control plane as an OAM exchange mechanism (this also shows
    up in Appendix B). I believe the section could benefit from some
    polishing.
    
       For MPLS and MPLS/IP PSNs, a PE that establishes a PW using Label
       Distribution Protocol [RFC3036] MUST use the LDP status TLV as the
       mechanism for AC and PW status and defect notification, as explained
       in [RFC4447].
    
    I don't think that this "MUST" is good or consitent with:
    - the text in Section 7 that is relaxed in saying "LDP or in the ACH"
    - the work in MPLS-TP
    
    It sounds like 3036 (or rather 5036) is a normative reference.
    
    While conveying PW status in LDP per 4447 is fine, it is not OAM with 
    the utility of rapid propagation of fault notifications. LDP, reliant
    as it is on TCP, is not suitable to that purpose.
    
    Wouldn't it be better to require the use of the ACH for OAM fault
    notification messages, and (if you must :-) mandate the use of LDP
    for status information propagation when LDP is present (but not as a
    replacement for real OAM).
    
    Additionally...
    
       Additionally, a PE MAY use VCCV-BFD Connectivity
       Verification (CV) for
    fault detection only (CV types 0x04 and 0x10
       [RFC5885]) but SHOULD notify the
    remote PE using the LDP Status TLV.
    The "SHOULD" here seems to be in conflict with te previous "MUST"
    
    And it goes on...
    
       A PE that establishes a PW using means other than LDP, e.g., by
       static configuration or by use of BGP, MAY use VCCV-BFD CV (CV types
       0x08 and 0x20 [RFC5885]) for AC and PW status and defect
       notification.  Note that these CV types SHOULD NOT be used when the
       PW is established with the LDP control plane.
    
    If you supply only a "MAY" you should probably describe how else the
    fault notification might work.
    
    As to the "SHOULD NOT" in the last sentence. Well, see my previous
    comments. And what possible harm could it do?
    
    ---   
    
    Section 6
    
       Generally, a PE cannot detect transmit defects directly and will
       therefore need to be notified of AC transmit or PW transmit defects
       by other devices.
    
    I think you mean s/directly/direct/
    
    ---
    
    Section 8.1.1
                                                                              
       [RFC4447] specifies that the "Pseudowire forwarding" code point is
       used to clear all faults.  It also specifies that the "Pseudowire Not
       Forwarding" code is used to convey any defect that cannot be
       represented by the other code points.
    
    The language seems rather week.
    The use of the code point does not clear the faults. It is used to 
    report (notify) that the faults have been cleared.
    Likewise, defects are not conveyed by the use of a control points, but
    existence of the defect can be reported (or conveyed, if you like).
  3. Russ Housley: Comment [2011-01-05]:
      Appendix B.3: s/Los/Loss/

draft-ietf-sipcore-keep

  1. Adrian Farrel: Comment [2011-01-17]:
    I found this a clear and well-written document, thanks. I have two
    smal points I would like the authors to think about, but nothing that
    blocks publication.
    
    Section 1.2
    
       In some cases all SIP entities that need to be able to negotiate the
       usage of keep-alives might not support SIP Outbound.  However, they
       might still support the keep-alive mechanisms defined in SIP
       Outbound, and need to be able to negotiate usage of them.
    
    Do you actually mean...
    
       In some cases not all SIP entities that need to be able to negotiate
       the use of keep-alives might support SIP Outbound.  However, they
       might still support the keep-alive mechanisms defined in SIP
       Outbound, and need to be able to negotiate usage of them.
    
    Or maybe more elegant as...
    
       In some cases some SIP entities that need to be able to negotiate
       the use of keep-alives might not support SIP Outbound.  However, they
       might still support the keep-alive mechanisms defined in SIP
       Outbound, and need to be able to negotiate usage of them.
    
  2. Alexey Melnikov: Comment [2011-01-12]:
    I read the whole document and in general I don't have any objections to
    publishing it as an RFC. However I have a minor complain:
    
    8.  Grammar
    
       This specification defines a new Via header field parameter, "keep".
    
       The ABNF [RFC5234] is:
    
       via-params =/ keep
    
       keep       = "keep" [ EQUAL 1*(DIGIT) ]
    
    This doesn't tell me where <via-params>, <EQUAL> or <DIGIT> is defined. Please
    add the references as either ABNF comments or in the text before the grammar.
  3. Peter Saint-Andre: Comment [2011-01-10]:
    This is a fine document. I have only a few comments.
    
    1. In second paragraph of the Security Considerations, please spell out "TLS"
    and "DTLS" on first use and add informative references for the relevant
    specifications.
    
    2. In the fourth paragraph of the Security Considerations, the specification
    says that a SIP entity MUST stop sending keep-alive requests if it does not
    receive responses to the STUN keep-alives that it sends to an adjacent
    downstream SIP entity. However, this does not take into account the fact that
    STUN requests and responses could be dropped, so it would be good to provide
    some more specific guidance here, e.g., stop sending STUN keep-alive requests if
    no STUN responses are received after sending two or more STUN requests (it seems
    suboptimal to stop sending STUN keep-alive requests if no response is received
    to only the very first STUN keep-alive request). Furthermore, no guidance is
    provided about the number of seconds the sender should wait before concluding
    that the adjacent downstream SIP entity has not responded. If these matters are
    covered in RFC 5389 then it would be helpful to cite the specific sections where
    they are discussed (e.g., Section 7.2.1 regarding retransmission timeouts).
  4. Sean Turner: Comment [2011-01-20]:
    Juergen Schoenwaelder spotted two editorial nits in the security considerations
    during his SECDIR review:
    
    a) [...]  This specification does not specify a connection
       reuse mechanism, and it does it address security issues related to
       connection reuse.  [...]
    
       s/it does it/it does not/
    
    b) [...]  They do not instruct the enity to
       place a value in a "keep" parameter of any request it forwards.  [...]
    
       s/enity/entity/
    

draft-ietf-martini-gin

  1. Adrian Farrel: Comment [2011-01-20]:
    AOR is used without expansion in the abstract.
  2. Alexey Melnikov: Comment [2011-01-19]:
    In Section 7.1.2:
    
       All base64 encoding discussed in the following sections MUST use the
       character set and encoding defined in RFC 2045 [1],
    
    RFC 4648 is a better reference here.
    
       except that any
       trailing "=" characters are discarded on encoding, and added as
       necessary to decode.
    
    In Section 7.1.2.1:
    
    SHA256-80 needs a reference and an explanation (i.e. that the output of the hash
    function
    is truncated to 80 bits).
    
    The first reference to TLS needs an Informative reference.
    
  3. Dan Romascanu: Comment [2011-01-18]:
    The OPS-DIR review by Warren Kumari signalled a number of nits which would be
    useful to fix:
    
    Abstract:
    In the abstract many acronyms are expanded (SIP, SIP-PBX, UA), but AOR
    is not. Having them all expanded (or none expanded) would be nice.
    
    Section 4:
    Globally Routable UA URI's (GRUU) are first mentioned, but the
    reference to the RFC is in section 7.1.
    
    Section 5.1:
    Acronym "UAC" not expanded / defined.
    
    Section 6:
    s/An SSP using this mechanism/A SSP using this mechanism/
    
    Section 7.1.2.1 (indented):
    s/The registrar maintains a counter, I. this
    counter is/The registrar maintains a counter, I. This counter is/
    (Capitalization of 't').
  4. Robert Sparks: Comment [2011-01-19]:
    The examples in section 8 have bugs that are important to fix before
    publication.
    The Call-ID changes unintentionally in each example. The messages
    that have two Via header field values have the values in the wrong order.
  5. Sean Turner: Discuss [2011-01-20]:
        #1) Section 7.1.2.2: The following threw me for a loop:
    
       A SIP-PBX that issues temporary GRUUs to its UAs MUST maintain an
       HMAC key, PK_a.  This value is used to validate that incoming GRUUs
       were generated by the SIP-PBX.
    
    I'm probably reading more in to "PK_a" than I ought to but it isn't a Public Key
    (PK) - right!?  It would be bad to use a public key as the HMAC secret.  SK_a is
    terminology used in Section 7.1.2.1 - can we use the same term or SK_SSP and
    SK_SIP-PBX?
    
    #2) The scenarios in Section 8.1 and 8.2  do not show the authentication step
    called.  I think it should or the text should say we left them out but you still
    need to do them.
    
    #3) Alexey caught the bit about HMAC-256-80 needing a reference.  I think it's a
    bigger deal because I don't which which parts of the output get used: 1st
    80bits, last 80bits, etc.?  It's hard to interoperate without knowing this.
    But, if a reference exists it'll be easy to clear. 
        
  6. Sean Turner: Comment [2011-01-20]:
    Section 7.1.2.2: Seems like there should be a pointer to RFC 4086 for the "D"
    method.

draft-ietf-multimob-pmipv6-base-solution

  1. Stewart Bryant: Comment [2011-01-19]:
    I agree with Lars.
  2. Ralph Droms: Discuss [2011-01-18]:
        If I'm reading the document correctly, the LMAs arrange to receive
    multicast streams and forward the streams to the MAGs, which then
    forward the streams to subscribed MNs.
    
    In figure 1, suppose MN1, associated with LMA1, and MN2, associated
    with LMA2, are both associated with multicast stream MC.  Will MAG1
    receive copies of MC from both LMA1 and LMA2?
    
    Was a design considered in which the MAG arrange directly for the
    delivery of multicast streams as required by attached MNs?
     
        
  3. Lars Eggert: Discuss [2011-01-17]:
        DISCUSS: I'm not getting why this document is going for BCP. Informational seems
    fully adequate to me. 
        
  4. Adrian Farrel: Discuss [2011-01-20]:
        The use of RFC 2119 language puzzles me. 
    Are statement like:
       As links connecting MNs and MAGs change under
       mobility, MLD proxies at MAGs MUST be able to dynamically add and
       remove downstream interfaces in its configuration.
    Making new definitions of behavior, or are they refering to existing
    norms specified elsewhere (that is, restating requirements)? In the
    former case, it looks like the document is actually Standards Track.
    In the latter case, I suggest inserting a reference and dropping to
    lower case.
    
    And other statements like:
       In summary, the following steps are executed on handover:
      [SNIP]
       4.  The MAG SHOULD determine whether the MN is admissible to
           multicast services, and stop here otherwise.
    In this case "SHOULD" is not indicative of a step that is executed.
     
        
  5. Adrian Farrel: Comment [2011-01-20]:
    MN-HNP is used without expansion
  6. Alexey Melnikov: Comment [2011-01-19]:
    I agree with Lars, although I don't have a strong opinion on the matter.
    
  7. Peter Saint-Andre: Comment [2011-01-18]:
    I concur with Lars's DISCUSS regarding the intended status of this document.
    Other than that, the document seems fine.

draft-ietf-roll-routing-metrics

  1. Jari Arkko: Discuss [2011-01-18]:
        I am concerned about the complexity of the RPL system. The set of attributes is
    relatively complex, 8 different attributes (The BGP parameters registry has 26,
    but RPL is expected to be run in environments where there is no experts to
    monitor its operation or fine-tune the parameters.) The large set of attributes,
    dynamically changing parameters, complex topologies, and unattended operation
    seems like a recipe for operational and interoperability problems. I do
    recognize the need to have dynamic metrics, power-aware routing, and many of the
    other things in this specification, however. My question is whether this is the
    absolute minimum set that we should define. Do we need Section 2.1 A field?
    Section 3.1 A or O flags? The mid-complexity solution from Section 3.2? Section
    4.3.1 *and* Section 4.3.2 reliability metrics?
    
    A few more specific concerns:
    
    Section 3.1:
    
       o  A Flag: data Aggregation Attribute.  Data fusion involves more
          complicated processing to improve the accuracy of the output data,
          while data aggregation mostly aims at reducing the amount of data.
    
    This is underspecified. And why do you talk about data fusion, if the
    attribute signals data aggregation. Please define what the semantics
    of the bit and the participant's behaviour is with respect to data
    aggregation, or point to a reference.
     
        
  2. Jari Arkko: Comment [2011-01-18]:
    I agree with Lars Eggert's Discuss.
    
    Section 4.3:
    
       In LLNs, link reliability is degraded by external interference and
       multi-path interference (wireless links).  Multipath typically
       affects both directions on the link equally, whereas external
       interference is sometimes unidirectional.
    
    I'm not sure I understand the term "multi-path interference" in this context.
    Perhaps you should use some other term. Multi-path usually refers to the use of
    multiple paths simultaneously. Radio interference from multiple links can
    certainly occur in ROLL networks. But I'm not sure why you call it "multi-path
    interference". I would probably just say "... degraded by attenuation (due to
    distance and objects) and interference (from external objects or within the RPL
    network)".
  3. Ron Bonica: Discuss [2011-01-19]:
        This may be a DISCUSS-DISCUSS.
    
    I believe that in order to achieve loop-free routing, the following conditions
    must be true:
    
    - all nodes must construct identical link state data bases (LSDB)
    - all nodes
    must run identical (or at least equivalent) SPF algorithms over that LSDB
    
    While I understand how ROLL devices might construct identical LSDBs, I don't
    understand how all nodes will run and identical (or even equivalent) SPF
    algorithms. The first problem is that all nodes don't neccessarily understand
    all metrics advertised with C-bit == 0. So, if all SPFs don't understand all of
    the same inputs, how can they be expected to produce the same outputs? THe
    second problem is an SPF with multiple inputs is pretty complex. Is it
    documented well enough that multiple vendors may produce interworking
    implementations? Finally, a node might advertise a metric with C-bit = 0 and
    then override that same metric with C-bit =1. When that happens, does the old
    advertisement disappear from the LSDB.
    
        
  4. Lars Eggert: Discuss [2011-01-17]:
          DISCUSS: My high-level concern with this document is that it focuses
      on how metrics are encoded in RPL TLVs, rather than giving formal and
      therefore unambiguous definitions of the metrics. Not in all cases,
      but in several. For example, the misnamed "throughput" metric doesn't
      make it clear whether it describes nominal link capacity or residual
      capacity, or whether it is an instantaneous metric or averaged over
      some period, etc. The "delay" metric leaves it open whether buffering
      delays are supposed to be included or not. The link reliability metric
      is much too open; when does e.g. a ZigBee link have a reliability of
      5? When of 6? Hat about a BT-LE link? And so on.
    
      The reason I'm bringing this up is that in oder to have route selection pick
      paths for end systems based on these metrics, it needs to be understood
      what these metrics concretely *mean*. I don't think that's currently
      possible, and I believe that makes them rather less useful that
      advertised. If IPPM has taught us anything it's that metrics really do
      need to be unambiguously defined for them to be useful.
    
      I realize this discuss isn't really actionable. I plan to clear it after
      discussing my concern with the IESG call. 
        
  5. Lars Eggert: Comment [2011-01-17]:
    Section 1., paragraph 16:
    >    flexibility to use link and node characterisics either as constraints
    
      Nit: s/characterisics/characteristics/
    
    Section 1., paragraph 21:
    >    and unneccessary routing changes.
    
      Nit: s/unneccessary/unnecessary/
    
    Section 3., paragraph 1:
    >    objet MUST silently be ignored.
    
      Nit: s/objet/object/
    
    Section 4.1., paragraph 0:
    > 4.1.  Throughput
    
      I think you mean (link) capacity here and not throughput. See the
      definition in RFC5136; could you adopt this definition here?
    
    Section 4.2., paragraph 0:
    > 4.2.  Latency
    
      See the definitions in RFC2679, can they be adopted here? Also, is
      this metric supposed to include buffering/queueing delay (which is
      load dependent) or is it purely supposed to capture the link
      transmission delay? If the former, that can vary quite a bit more...
    
    Section 4.3.2., paragraph 12:
    >    the path (cummulative path ETX calculated as the sum of the link ETX
    
      Nit: s/(cummulative/(cumulative/
    
    Section 7., paragraph 1:
    >    consist of making intermitment attacks on a link in an attempt to
    
      Nit: s/intermitment/intermittent/
    
    Section 8., paragraph 1:
    >    valuable comments.  Special thank to Adrian Farrel for his thourough
    
      Nit: s/thourough/thorough/
    
  6. Alexey Melnikov: Comment [2011-01-15]:
    In 2.1:
    
       The A field has no meaning when the C Flag is set (i.e. when the
       Routing Metric/Constraint object refers to a routing constraint) and
       he only valid when the R bit is cleared.  Otherwise, the A field MUST
    
    Is "he" should be here at all?
    
       be set to 0x00 and MUST be ignored on receipt.
    
    4.1.  Throughput
    
       Throughput: 32 bits.  The Throughput is encoded in 32 bits in
       unsigned integer format,
    
    In network byte order? (Also in 4.2)
    
       expressed in bytes per second.
    
  7. Dan Romascanu: Discuss [2011-01-18]:
        A few issues need to be addressed before I can ballot favorably this document: 
    
    1. Section 2.1 - Value: variable for Routing Metric/Constraint TLVs. What is the
    length range. 255 is maximum I assume, but is zero an acceptable length value?
    
    2. Section 3.1 - 
    
          An implementation MAY
          decide to add optional TLVs (not currently defined) to further
          describe the node traffic aggregator functionality.
    
    It is not clear to me how an implementation can make such a decision. Two
    different implementations would not be interoperable if this is not defined some
    place. Is this about extensibility?
    
    3. Section 3.2 - it is not clear from the text that estimating the 'energetic
    happiness' - actually the remaining power battery for battery operated devices
    is always possible, and if not how this metrics is being filled in. Will just
    the E bit be cleared and no estimation provided?
    
    4. Section 4.2 - the latency metric is unsufficiently defined. What is the
    measurement observation point? is buffering taken into consideration?
    
    5. Section 4.3.1
    
    > The Link Quality Level (LQL) object is used to quantify the link
       reliability using a discrete value, from 0 to 7 where 0 indicates
       that the link quality level is unknown and 1 reports the highest link
       quality level.  The mechanisms and algorithms used to compute the LQL
       are implementation specific and outside of the scope of this
       document.
    
    This seems broken. How can interoperability be ensured between two independent
    implementations if the metric is a discrete value whose algorithm of
    determination is implementation specific? 
        
  8. Dan Romascanu: Comment [2011-01-18]:
    1. The way the Flag field is defined in Figure 1 is confusing. The field is
    defined as length 16 bits, but then there are 5 bits labelled Flags on the
    diagram which are actually the currently reserved or un-allocated Flags. The A
    field and PRec filed are part of the Flag field, but there is no indication or
    indent to make this clear.
    
    2. Expand DIO at first occurence
    
    3. Section 4.1 - the Throughput object seems to be mis-named. Looks more like
    Link Capacity.
  9. Peter Saint-Andre: Comment [2011-01-19]:
    Based on the reviews provided by IESG members more expert than I in the
    technology under consideration, I am ballotting "No Objection". That said, based
    on my own review I concur with the DISCUSS raised by Jari Arkko regarding the
    complexity of the system.

draft-ietf-6lowpan-hc

  1. Jari Arkko: Comment [2011-01-19]:
    Ari Keränen reviewed this draft. His comments:
    
    Abstract
    
    Missing "updates RFC4944" text.
    
    Section 1
    
    Abbreviations ND & MAC should be expanded.
    
    Section 3.1.1.
    
    First time "ECN" and "DSCP" are used. Could move the expanded versions and
    references from Section 3.2.1 to here.
    
            01:  64 bits.  The address is derived using context information
               and the 64 bits carried in-line.  Any bits of the IID not
               covered by context information are taken directly from the
               corrseponding bits carried in-line.  Any remaining bits are
               zero.
    
    If the context defines some of the same bits as the in-line data, are context
    bits always used (and in-line bits ignored)? That could be said more explicitly
    too.
    
    Also: s/corrseponding/corresponding/
    
    Section 3.2.4
    
    Expand RIID.
    
        DAM = 01. Unicast-Prefix-based IPv6 Multicast Address Compression
    
    Should that be "DAM = 00"?
    
    Section 4.3.1
    
      This specification introduces a range of well-known ports (0xF0Bx)
    
    This is a bit strange way to express a port range, and the term "well-known
    ports" is already reserved for ports < 1024. You could say something like:
    
      This specification introduces a range of ports, 61616 - 61631 (0xF0B0 -
    0xF0BF), that can be compressed more efficiently, using only 4 bits.
    
      Transport Layer Security (TLS) Message Integrity Check (MIC) that
      validates that the content is expected and checked for integrity.
    
    "validates" and "is expected and checked" sound a bit strange here. Could use
    something like "makes sure" and "is what is expected and is checked"
    
    Section 4.3.2
    
    Expand PDU.
  2. Ron Bonica: Comment [2011-01-19]:
    I also support the GENART DISCUSS on the checksum
  3. Stewart Bryant: Comment [2011-01-19]:
    I support Russ' Discuss on the checksum.
    
    The mandatory use of checksum in IPv6 is controversial amongst some IETF
    communities (particularly the community using UDP as a tunnel type). Either this
    controversy needs to be resolved, or  draft-ietf-6lowpan-hc needs to deal
    correctly with the c/s /no c/s case. It could of course do this by always
    carrying the c/s, but it seems perverse to have to carry 16 bits of c/s to say
    that there is no c/s.
    
    
  4. Lars Eggert: Discuss [2011-01-17]:
        [Edited to include David Black's gen-art review, since I'm already holding a
    discuss on part of the issues he has raised.]
    
    Section 4.3.2., paragraph 1:
    >    The UDP checksum operation is mandatory with IPv6 [RFC2460] for all
    >    packets.  For that reason [RFC4944] disallows the compression of the
    >    UDP checksum.
    >    With this specification, a compressor in the source transport
    >    endpoint MAY elide the UDP checksum if it is authorized by the Upper
    >    Layer.  The compressor SHOULD NOT set the C bit unless it has
    >    received such authorization.  The Upper Layer SHOULD only provide the
    >    authorization in the following cases:
    
      DISCUSS: First, I think you want to use "MUST NOT" and "MAY only"
      here. Second, there are additional issues here (see
      draft-ietf-6man-udpzero). For example, even if there is an upper layer
      integrity check present for a given app, if the port number field gets
      corrupted and a message gets mis-delivered to an incorrect application
      (port), *that* application may not have an upper layer integrity check
      implemented to protect it. And so on. Have you run this part of the
      spec by 6MAN?
    
    Also, from David Black:
    
    >  A forwarding node MAY imply authorization from an incoming packet if
    > the C bit is set.  A forwarding node that cannot unambiguously derive
    >  such authorization SHOULD NOT elide the UDP checksum when performing
    >  6LoWPAN compression.
    
    This needs to be a MUST NOT. 
        
  5. Adrian Farrel: Discuss [2011-01-16]:
        Thanks for this document which I have reviewed in detail. I will 
    ballot "no objection" when one small point has been resolved.
    
    Section 4.3.1
                                                                                    
       This specification introduces a range of well-known ports (0xF0Bx)
       that can be compressed to 4 bits.
    
    I don't believe that these are "Well Known Ports". They would be in the
    range 0-1023.
    
    They appear to be "Dynamic and/or Private Ports"
    
    I guess you are trying to say that these ports are known by 6lowpan hc
    implementers. Maybe a complete rewriting of this sentence?
    
       This specification defines the use of range of ports from the 
       Dynamic and/or Private Ports range. Using only ports of the type
       0xF0Bx means that the port number can be compressed to 4 bits.
    
    But I am unclear that you are really using this range of port numbers!
    Are you not actually using 4 bits to encode up to 16 port number aliases
    and, as your text says, you require some mapping to be installed to
    expand those aliases back to real port numbers.
    
    If I am wrong (and you are really using ports in the range you state) 
    you need to add text to indicate how this is safe and will not clash 
    with other usage of these port numbers that might happen randomly as
    an application picks (dynamically or privately) some port number to
    use.
     
        
  6. Adrian Farrel: Comment [2011-01-16]:
    I found a few small points of house-keeping:
    
    ---
    
    I would like to see "6LowPAN" expanded in the title, Abstract, and
    Introduction. I think that you will find "6LowPAN network" includes
    tautology.
    
    ---
    
    Section 2
    
       New            
       implementations MAY implement compression according to Section 10 of
       [RFC4944], but SHOULD NOT send packets compressed according to
       Section 10 of [RFC4944].
    
    s/compression/decompression/  ?
    
    ---
    
    Figure 2
    
    You might replace
    OLD
           0   1   2   3   4   5   6   7   8   9   0   1   2   3   4   5
    NEW
           0                                       1
           0   1   2   3   4   5   6   7   8   9   0   1   2   3   4   5
    END
    
    ---
    
    The text in section 3.2.1 is correct and can be understood, but it 
    took me several readings to be sure that the text actually matched the
    figures. If the authors looked at this piece again and polished it, it
    would help the document.
    
    ---
    
    Section 3.2.2
    
       When the encapsulating header carries
       IPv6 addresses, bits for the source
    and destination addresses are
       copied verbatim from the source and destination
    addresses of the
       encapsulating IPv6 header.
    "verbatim" is incorrect in this context. And, anyway, it is redundant -
    "copied" is adequate.
    
    ---
    
    Section 3.2.2
    
    I think this section could usefully include a reference to 
    [IEEE 802.15.4]
    
    ---
    
    A number of figures are not numbered, which is mildly inconsistent.
    
    ---
    
    Section 4.2
    
       For the most part, the IPv6 Extension Header is carried verbatim in
       the bytes immediately following the LOWPAN_NHC octet, with two
       important exceptions: Length Field and Next Header Field.
    
    "verbatim" again :-)
    I think in this case you should use "unmodified"
    
    ---
    
    Seciotn 4.2
    
          1: The Next Header field is elided and the next header is encoded
             using LOWPAN_NHC, which is discussed in Section 4.
    
    s/4/4.1/
    
    ---
    
    Section 4.3.2
    
       A forwarding node MAY imply authorization from an incoming packet if
       the C bit is set.
    
    I think you mean "infer" not "imply".
  7. Russ Housley: Discuss [2011-01-18]:
        
      The Gen-ART Review by David Black on 17-Jan-2011 lead to a discussion
      about the use of checksums with UDP.  This discussion does not seem to
      be over.  The last thing that I saw was:
    
        I'm still unhappy since the text allows a middle point to recomputed
        the checksum which then might be delivered erroneously to the wrong
        IP or port.  This was done to ensure that a packet that flows on the
        Internet would 'look right' to middle boxes and end points.  It  is
        probably OK for most 802.15.4 cases since L2 security is almost
        always on and protects the frames a lot better than 2 octets of
        checksum.  But if there's no security at work, it would probably be
        better to let the packet go with a zero checksum and add some text
        on authorizing that an arbitrary end point.
    
      This discussion needs to reach a resolution before this document is
      approved. 
        
  8. Peter Saint-Andre: Comment [2011-01-10]:
    This is a fine document. I have only a few comments.
    
    1. According to Section 2, this document appears to update RFC 4944. However,
    the document header does not include "Updates: RFC 4944".
    
    2. In Section 6, please add an informative reference for Transport Layer
    Security (TLS).
  9. Sean Turner: Comment [2011-01-20]:
    I support Russ's discuss.

draft-ietf-isis-layer2

  1. Ron Bonica: Comment [2011-01-17]:
    Please run the nit-checker. There are a few missing and unused references.
  2. Ralph Droms: Discuss [2011-01-18]:
        IESG Writeup appears to be missing; will clear when
    I can review the background on WG review and
    consensus. 
        
  3. Ralph Droms: Comment [2011-01-18]:
    Extraordinarily pedantic nit: MAC address in section 2.1 is not to scale;
    suggested
    
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                          MAC (1)    (6 bytes)                 |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                   .................                           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                          MAC (N)    (6 bytes)                 |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    
  4. Lars Eggert: Comment [2011-01-17]:
    Section 2.2., paragraph 2:
    >    o  Type: TLV Type, set to MT-PORT-CAP TLV 143 [TBD].
    
      What's TBD here?
    
  5. Russ Housley: Comment [2011-01-19]:
      Please consider the editorial comments in the Gen-ART Review by
      Kathleen Moriarty on 19- Jan-2011.
  6. Alexey Melnikov: Comment [2011-01-14]:
    2.2.  Multi Topology aware Port Capability TLV
    
       o  Topology Identifier: MT ID is a 12-bit field containing the MT ID
          of the topology being announced.  This field when set to zero
          implies that it is being used to carry base topology information.
    
    Excuse my ignorance, but is this description actually sufficient for
    interoperability? Which values are valid here and where are they coming from?
    
    Also I don't think specifying exact values before they are assigned by IANA is
    a good idea.
  7. Dan Romascanu: Discuss [2011-01-18]:
        The OPS-DIR review by Menachem Dodge (posted in the tracker) raised a number of
    issues which I believe require clarification and edits. As the authors of the
    document answered that they will deal with the comments in a revised version of
    the document I am holding a DISCUSS until the comments are resolved by edits or
    detailed clarification answers. 
        

draft-ietf-isis-trill

  1. Ralph Droms: Discuss [2011-01-20]:
        
    This DISCUSS is a placeholder to ensure an issue with
    draft-ietf-trill-rbridge-protocol-16 is addressed before publication.
    I"ll clear as soon as updates to draft-ietf-trill-rbridge-protocol-16
    are agreed to and the RFC Editor is informed of the changes. 
    
    draft-ietf-trill-rbridge-protocol-16 was written before draft-ietf-isis-layer2
    was split into 3 documents.  A reference to draft-ietf-isis-trill
    needs to be added to draft-ietf-trill-rbridge-protocol-16, and
    citations to draft-ietf-isis-layer2 need to be checked against
    the split between draft-ietf-isis-layer2 and draft-ietf-isis-trill.
    
    This DISCUSS also applies to draft-ietf-isis-layer2, but there is no
    need to delay publication of draft-ietf-isis-layer2 while
    draft-ietf-trill-rbridge-protocol-16 is updated.
     
        
  2. Lars Eggert: Comment [2011-01-17]:
    Section 6.1, paragraph 6:
    >    are sub-TLVs of TLV #TBD [RFCisisLayer2], the MT-PORT-CAP TLV.  Thos
    
      Nit: s/Thos/Those/
    
  3. Alexey Melnikov: Comment [2011-01-16]:
    I only skimmed the document, but I have no objections.
    
    It might be worth mention the byte order used for fields longer than 1 byte.
    
  4. Dan Romascanu: Discuss [2011-01-17]:
        Before approving this document I believe that the following statement made in
    the Introduction section needs clarification:
    
    > Intermediate Systems
       (ISs) implementing TRILL are compatible with IEEE 802.1 customer
       bridges and can incrementally replace such bridges.
    
    What does 'compatible' mean in this context? 
    What are the IEEE 802.1 customer
    bridges that can incrementally be replaced by ISs implementing TRILL. Either a
    reference to the exact IEEE 802.1 standards or a reference to the IETF documents
    that specify these would be useful. 
        

draft-ietf-ccamp-gmpls-g-694-lambda-labels

  1. Stewart Bryant: Comment [2011-01-19]:
    "In the scenario of Figure 1, consider the setting up of a bidirectional LSP
    from ingress switch 1 to egress switch 9 using
     GMPLS RSVP-TE."
    
    Figure 1 shows them as nodes
    
    =======
    
    To deal with the widening scope of MPLS into the optical and time domains
    
    I think that you mean ... optical switching and time division multiplexing
    domains.
    
    ======= 
    In a case, the label indicates the wavelength to be used for the LSP. 
    
    Do you mean "In this case.." ?
    
    ======
  2. Alexey Melnikov: Comment [2011-01-20]:
    I am missing some text about byte order for 16bit fields.
    
    4. Security Considerations 
    
       This document introduces no new security considerations to 
       [RFC3471] and [RFC3473]. For a general discussion on MPLS and 
       GMPLS related security issues, see the MPLS/GMPLS security 
       framework [RFC5920].
    
    Surely lasers are dangerous weapons and kids shouldn't be allowed to play with
    them.

draft-ietf-l3vpn-mvpn-infra-addrs

  1. Stewart Bryant: Comment [2011-01-18]:
    From a very late review
    
    - In a couple of places, the word "route" occurs where it would be clearer
      to say "NLRI"
    
    - The paragraph on "VRF Route Import Extended Community" is misplaced, as it
      is an attribute of IP-VPN routes rather than of MCAST-VPN routes; this
      paragraph should probably be a top-level section of its own.
    
    - That paragraph contains the term "IPv6 Address Specific Route Target" when
      it should say "IPv6 Extended Community".  
  2. Lars Eggert: Comment [2011-01-17]:
    I agree with Alexey's discuss that this document is probably missing a bunch of
    "updates" relationships.
    
    Additionally, with regards to [MVPN-BGP], could some or maybe all of the content
    of this ID rolled into [MVPN-BGP]? (Since that isn't actually published yet?)
  3. Adrian Farrel: Comment [2011-01-16]:
    I have reviewed this I-D and support its publication as an RFC with the change
    proposed to resolve Alexey's Discuss.
  4. Russ Housley: Discuss [2011-01-18]:
        
      The Gen-ART Review by Suresh Krishnan on 17-Jan-2011 asks a question
      that deserves a response: will this document update 
      draft-ietf-l3vpn-2547bis-mcast-bgp-08, once it is published as an RFC? 
        
  5. Alexey Melnikov: Discuss [2011-01-16]:
        The document begs for "Updates: RFC XYZW", I am just not sure what this RFC XYZW
    needs to be. Maybe it would need to update multiple RFCs.
    
    For example, when I read this text:
    
    1.3. IPv4 and IPv6 Addresses in MCAST-VPN Routes
    
       [MVPN-BGP] defines a new set of BGP route types that are used by SPs
       to provide Multicast Virtual Private Network service to their
       customers.  These routes have a newly defined BGP NLRI, the "MCAST-
       VPN" NLRI.  MCAST-VPN NLRI is carried in the NLRI field of the
       MP_REACH_NLRI/MP_UNREACH_NLRI attributes defined in [BGP-MP].  The
       SAFI field of the MP_REACH_NLRI/MP_UNREACH_NLRI attribute is used to
       identify the NLRI as being an MCAST-VPN NLRI.
    
       When the SAFI field of an MP_REACH_NLRI/MP_UNREACH_NLRI attribute has
       the "MCAST-VPN" value, the AFI field has two defined values: 1 and 2.
       AFI 1 indicates that any customer multicast addresses occurring in
       the MP_REACH_NLRI/MP_UNREACH_NLRI attribute are IPv4 addresses; AFI 2
       indicates that any such addresses are IPv6 addresses.
    
       However, some of the MCAST-VPN routes also contain addresses of PE
       routers in the SP network.  An SP with an IPv4 network may provide
       MVPN service for customers that use IPv6, and an SP with an IPv6
       network may provide MVPN service for customers that use IPv4.
       Therefore the address family of the PE addresses MUST NOT be inferred
       from the AFI field of the associated MP_REACH_NLRI/MP_UNREACH_NLRI
       attribute.
    
    It looks to me that this document is fixing a deficiency in [MVPN-BGP] and/or
    [BGP-MP]. Thus it looks like it should be Updating at least one of them.
    
    As per reply from Eric Rosen: the document should use "Updates: [MVPN-BGP]"
     
        

draft-saintandre-tls-server-id-check

  1. Lars Eggert: Comment [2011-01-17]:
    Section 1.5., paragraph 8:
    >    These suggestions are not entirely consistent with all practices that
    >    are currently followed by certification authorities, client
    >    developers, and service providers.  However, they reflect the best
    >    aspects of current practices and are expected to become more widely
    >    adopted in the coming years.
    
      This seems to argue that the doc should be a BCP and not a PS?
    
    Section 1.8., paragraph 28:
    >       Transport Layer Security [TLS] negotiation; in this specfication
    
      Nit: s/specfication/specification/
    
    Appendix A., paragraph 1:
    >    recommendations in this specfication: email [EMAIL-SRV] and XMPP
    
      Nit: s/specfication:/specification:/
    
    Section 7.2., paragraph 1:
    >          Implemenations MUST NOT match any form of wildcard, such as a
    
      Nit: s/Implemenations/Implementations/
    
  2. Tim Polk: Discuss [2011-01-20]:
        This is a discuss-discuss.  I support publication as a BCP, but thought some of
    the guidance should be much stronger. 
        
  3. Robert Sparks: Discuss [2011-01-19]:
        I agree with the review comments supporting publishing this as PS and not as
    BCP.
    
    The majority of this document is specifying behavior that is appropriate to
    progress through the standards ladder. There is a small section providing
    guidance to certificate authorities that could be written as a BCP, encouraging
    "full and immediate instantiation" (see section 5.1 of RFC2026). If it's
    important to give that section BCP designation, I suggest placing it in a
    separate document. However, I think it will have the same effect in this
    document, published as PS.
    
    Assuming the consensus is to move forward as proposed standard, I expect to move
    to a "Yes" position. 
        

draft-schaad-smime-algorithm-attribute

  1. Lars Eggert: Comment [2011-01-17]:
    INTRODUCTION, paragraph 4:
    >               Signer Info Algorithm Protection Attribute
    >
    >    A new attribute is defined that allows for protection of the digest
    >    and signature algorithm structures in an authenticated data or a
    >    signer info structure.  Using the attribute includes the algorithm
    >    definition information in the integrity protection process.
    
      It's be good if the title and abstract had some context that this
      stuff is about CMS...
    
  2. Adrian Farrel: Comment [2011-01-18]:
    I have two issues with this document, but they are not large enough to form a
    Discuss. Nevertheless, I hope the authros will find time to address them.
    
    ---
    
    The use of the passive voice in the first sentence of the Abstract is
    disconcerting!
    
    There is also some missing context!
    
    The second sentence is pretty hard to parse.
    
    Why not write:
    
       This document defines a new attribute that allows for protection of
       the digest and signature algorithm structures in an authenticated 
       data or a signer info structure used in the Cryptographic Message
       Syntax (CMS).  When the new attribute is used, the algorithm
       definition information is included in the integrity protection 
       process.
    
    The introduction would benefit from a similar (but more verbose) fix.
    
    ---
    
    I think it is conventional to include a reference to the ASN.1 spec
    that defines the language you are using. Presumably X.208 (1988) and
    X.209 (1988) could be added as references.
    
  3. Russ Housley: Discuss [2011-01-19]:
        
      Some signature algorithms, such as RSA PKCS#1 v1.5, sign both the
      digest algorithm identifier and the message digest.  So, if the
      attacker changes the identifier, the signature will not
      validate. While this is not true of all signature algorithms, it does
      significantly diminish the scope of the concern being addressed by
      this document.  Please add this to the discussion. 
        
  4. Robert Sparks: Comment [2011-01-19]:
    Can the section on comparing fields in the verification process (2nd paragraph
    of section 3) be made more precise? Currently, it says "It is not required that
    a field which is absent in one case and present in another case  be compared as
    equivalent". Does that mean it's allowed to compare those as equivalent? Or was
    the intent that they MUST NOT be equivalent?

draft-ietf-sipcore-sec-flows

  1. Alexey Melnikov: Comment [2011-01-19]:
    6.  Additional Test Scenarios
    
          *  assure that the most specific CommonName in the Subject field
             matches if there are no dNSName entries in the subjectAltName
             at all (which is not the same as there being no matching
             dNSName entries).  This match can be either exact, or against
             an entry that uses the wildcard matching character '*'
    
    Anywhere in the domain pattern or only in the leftmost position?
    
    Nits: The usual (many acronyms are not spelled out on first use, etc.)
    
  2. Dan Romascanu: Comment [2011-01-18]:
    The 'Observed Interoperability Issues' section includes a number of example of
    implementation problems detected during the SIPit events. I can guess that this
    information canges in time, as interoperability problems due to implementation
    bugs or lack of clarity in documents are in the majority of the cases being
    fixed in the coming releases of the implementations. For this purpose it would
    be useful I think to mention what is the time reference (may be the indication
    of the SIPit event) when the problems were detected.
  3. Peter Saint-Andre: Comment [2011-01-18]:
    This is a fine document. My only nits are:
    
    1. Some of the acronyms are not expanded on first use.
    
    2. There are some trifling typos (e.g., "particulary").
    
    3. Some of the terms are used inconsistently or casually (e.g., "subjAltName"
    when "subjectAltName" is meant; it might be even better to re-use the
    terminology from draft-saintandre-tls-server-id-check).
    
    4. No rules are provided regarding the process of matching IP addresses (e.g.,
    matching of IPv4 addresses vs. IPv6 addresses); however, because use of IP
    addresses is deemed inadvisable, the lack of rules probably does not have
    implications for interoperability.
  4. Sean Turner: Discuss [2011-01-20]:
        #1) The AKIs seems to include all three possibilities.  RFC 5280 says:
    
       The identification MAY be based on either the
       key identifier (the subject key identifier in the issuer's
       certificate) or the issuer name and serial number.
    
    It also goes on to recommend using the keyIdentifier choice.  I'd remove the
    other two (authorityCertIssuer and authorityCertSerialNumber) they're just
    making the certificates bigger than they need to be.
    
    #2) User certificate subject names: look a lot like email addresses.   RFC 5280
    requires that new implementations put the email address in the SAN extension
    with the rfc822Name choice.  Shouldn't the last component of the user's common
    name be Cullen Jennings, Kumiko, etc and then put the email addresss in
    SAN:rfc822Name? 
        
  5. Sean Turner: Comment [2011-01-20]:
    Appendix A: Add an informative reference to PKCS#8 [RFC5958].
    
    ASN.1 dumps: The "hority" wraps around the line oddly.
    
    Section 5: Is it worth noting that the SHA2 algs also say don't include the
    parameters according to [RFC5754].

draft-ietf-roll-security-framework

  1. Russ Housley: Discuss [2011-01-19]:
        
      The Gen-ART Review by David Black raised a significant concern. The
      confidentiality and privacy requirements are SHOULD.  It seems to me
      that they ought to be "MUST implement" so that every implementation
      can be configured to make use of confidentiality and privacy.  An
      alternative would be "MUST implement" coupled with "SHOULD use when"
      statements, or "SHOULD" coupled with "geographic information MUST NOT
      be handled when confidentiality protection is not enabled." 
        
  2. Tim Polk: Discuss [2011-01-20]:
        I think this is a really good document, and support its publication.
    
    However, I think some of the issues I was persuaded to remove from my discuss on
    roll-rpl because they would be
    more appropriate in this document were omitted.
    I am specifically concerned about punting the details on public key
    distribution, then finding they are not covered here either.
    
    Did I get the wrong document?  Where are those issues going to be addressed?
    
    I will hold this discuss while we sort out the best place to address these
    issues... 
        
  3. Peter Saint-Andre: Comment [2011-01-19]:
    Overall this is a fine document. Several infelicities in the text might cause
    confusion:
    
    1. In Section 3.2, "the service of non-repudiation implies after-the-fact"
    sounds like it should be "the service of non-repudiation applies after-the-fact"
    but instead the authors seem to mean that "the service of non-repudiation
    implies that the attack occurs after the fact" or somesuch.
    
    2. In Section 3.3, "can all contribute to key management issues" could be
    construed as contributing to important or critical ("key") issues related to
    network management, not as "complicating the operations of key management" as in
    the previous paragraph; I suggest repeating the previously-used phrasing.
    
    There are also several unfortunate typographical errors (e.g., "fundament"
    instead of "fundamental" in Section 3.4, "undue utilization of exhaustion"
    instead of "undue utilization or exhaustion" in Section 4.3.4, "any device local
    or remote" instead of "any local or remote device" in Section 5.1.5,
    "compliment" instead of "complement" in Section 6.1, "aimed the manipulation"
    instead of "aimed at the manipulation" in Section 6.5).
    
    With regard to Denial of Service (DoS) in Section 4.3.3, please add a reference
    to RFC 4732.
    
    Please provide informative references for OSPF and ISIS in Section 5.2.5.
    
    In Section 6.1, is uppercase "MAY" meant in the text "new ciphering key may
    therefore be concurrently generated or updated"?
    
    In Section 6.4, is uppercase "MUST" meant in the text "a LLN must include a
    process for key and credential distribution"?
    
    In Section 6.4, is uppercase "SHOULD" meant in the text Correspondingly, the
    routing protocol(s) specified by the ROLL Working Group should assume that the
    system affords key management mechanisms consistent with the guidelines given in
    [RFC4107]"?
    
    In Section 6.5, is uppercase "SHOULD" meant in the text "   As routing is one
    component of a LLN system, the actual strength of the security services afforded
    to it should be made to conform to each system's security policy"?
    
    (And so on; in general, I suggest that the authors check all lowercase keywords
    throughout Section 6.)
    
    

draft-ietf-mpls-tp-uni-nni

  1. Russ Housley: Discuss [2011-01-19]:
        
      The Gen-ART Review by Ben Campbell on 21-Dec-2010 lead to a
      discussion.  The discussion of Figure 1 and Figure 2 does not seem to
      be finished.  The discussion needs to reach closure before this
      document is approved. 
        

draft-ietf-mptcp-threat

  1. Jari Arkko: Comment [2011-01-19]:
    This is an excellent document and I can warmly recommend its approval. Thank you
    for writing it, Marcelo.
    
    Some small comments:
    
    In Section 3, where the document discusses differences between MIPv6 RO and
    MPTCP situation I had a couple of comments. First, I'm not sure I understand
    what you mean with the bullet about MIPv6 relying on the original path always
    being available. MIPv6 certainly assumes that the path that we are using at that
    moment is working, and if it is not, the system will attempt to move to some
    other address or network attachment point. Secondly, I think you are missing one
    additional difference: in MIPv6 we assume that there's always a trusted third
    party (the home agent) that can help us with some of the security problems. In
    MPTCP there is no such entity. You might also be missing the difference that
    MPTCP intends to be able to use multiple paths simultaneously, which was not an
    original design goal of the MIPv6 work.
    
    In Section 6.3, the text discusses the effects of NAT on securing the implicitly
    reported new address. The text fails to explain that while explicit mode would
    allow better protection of the reported new address, such protection would be
    pointless because it would protect an address that is no longer relevant on the
    outside of the NAT. You actually *need* to report the address as changed by the
    NAT. And by the way, I see nothing wrong with that... that's is how current TCP
    works, too.
    
    I like the basic recommendations in Section 7. But I am unsure if the analysis
    in the document actually supports the advanced recommendation to have optional
    support for HMAC. Why would that needed? Also, should the conclusions say
    something about how MPTCP design should deal with sequence number spaces -- it
    seems that different choices here would result in different impacts.
  2. David Harrington: Comment [2011-01-19]:
    This document does a good job of analyzing the threats for MPTCP. Thanks you.
    
    While fully understandable, I found the text a bit wordy, with extra phrases and
    clauses thrown in where they really weren't needed. This document could be much
    more concise, and if you are doing a new revision, you might want to consider
    tightening up the text. But this is purely a style issue, and the authors are
    free to ignore this comment if they so choose.
    
    Some examples of things that can be tightened:
    "It should be noted that yada
    yada yada" - this implies that somebody should sometime in the future note this,
    but you are noting it now, so all you need is the yada yada yada without "It
    should be noted that".
    
    I recommend you check any "Note that" usages; they are almost always
    unnecessary.
    
    "Similarly to the MPTCP case, the Shim6 protocol is a layer 3
          protocol so all the communications involving the target address
          are at stake, as opposed to the MPTCP case, where the impact can
          be limited to a single TCP connection."
    would be much more concise as simply "The Shim6 protocol is a layer 3
          protocol so all the communications involving the target address
          are at stake; in MPTCP, the impact can
          be limited to a single TCP connection."
    
    s/behaviour of SCTP as defined/behaviour of SCTP/
    
    I recommend checking to see if removing some of these phrases actually changes
    the meaning of the sentence:
    s/as such//g
    s/So,//g
    s/As we stated earlier,//
    s/In order to do that,//
    s/This means that//
    s/In particular//g
    s/We assume
    that//g
    s/So, at least,//
    s/In addition,//
    s/the so called//
    s/It should be
    noted that/
    s/In other words,//
    s/namely//
    s/In this case,//
    s/basically//
    s/This implies that//
    s/It seems that/
    s/It seems reasonable to assume that//
    s/This per se,/This/
    s/The result is that/
    s/This means that//
    s/This basically
    means that//
    
    and some specific places:
    s/In addition, we have the target of the flooding
    attack, target T which has an IP address IPT./
       Target T has an IP address
    IPT./
    s/In the first step of this attack (depicted as step 1 in the figure), the
    attacker A/
      The attacker A/
    s/the second step of the attack (depicted as step
    2 in the figure)/
       the second step of the attack/
     or /step 2 of the attack/
    (to align it with the figure labels)
    
    s/The actual details of this/The details/
    s/somehow more secure/more secure/
    s/Similarly to the previous case,//
    s/As opposed to the previous one,//
    s/As we have described earlier,//
  3. Alexey Melnikov: Comment [2011-01-15]:
    In Section 1:
    
       This
       note includes a threat analysis for MPTCP.  It should be noted that
       there are there may other ways to provide multiple paths for a TCP
    
    This doesn't read well
    
       connection other than the usage of multiple addresses.  The threat
       analysis performed in this document is limited to the specific case
       of using multiple addresses per endpoint.
    
    In Section 3:
    
       o  Similarly to the MPTCP case,
    
    Did you mean "MIPv6 RO" here?
    
          the Shim6 protocol is a layer 3
          protocol so all the communications involving the target address
          are at stake, as opposed to the MPTCP case, where the impact can
          be limited to a single TCP connection.
    
  4. Dan Romascanu: Comment [2011-01-20]:
    In the OPS-DIR review  Lionel Morand raised the issue that it is recommended to
    allow the support of multiple security mechanisms but there is nothing about
    potential related mechanism negotiation  issues. I suggest that this be
    addressed before the publication of the document, even if it is not a blocking
    issue.

draft-ietf-mptcp-architecture

  1. Jari Arkko: Comment [2011-01-19]:
    An excellent document. Thanks for writing it.
    
    I would change the urgent data support to a MAY, however.
    
  2. David Harrington: Comment [2011-01-19]:
    I think this document is well-written and support its publication. 
    
    1)  The architecture document has no discussion of how MPTCP should be managed,
    or what types of information should be made accessible for management purposes.
    I believe it should - at an architectural level.
    
    However, since this is the architecture document for a protocol being put forth
    as Experimental, it would be beneficial to take the results of the experiment
    into consideration when designing an appropriate management solution. Therefore,
    I have reduced this to a comment.
    
    TCP is intrumented with a MIB that is widely implemented on devices and used by
    network management applications. MPTCP should share that MIB for aspects that
    are designed to be transparent to the application. However, there should be
    extensions specific to MPTCP so an operator can monitor the operational state
    and impact of MPTCP.
    For example, 
    a) MPTCP should be able to be
    enabled/disabled, the enabled/disabled state should be able to be queried, and
    the fallback mentioned in section 2.1 should be indicated in operational state.
    b) if there are errors or congestion on a path and MPTCP can detect those errors
    or congestion, it should make that information available to an operator via the
    MIB. 
    c) if MPTCP can determine the performance of each path, that information
    should be made available via the MIB for use by performance monitoring
    applications.
    d) if MPTCP can determine the different security state of
    different paths, that information should be made available via the MIB. It would
    probbaly be good if an operator can choose to provide a weight for different
    paths based on the security properties of the path.
    
    
  3. Russ Housley: Discuss [2011-01-19]:
        
      The Gen-ART Review by Joel Halpern on 14-Jan-2011 raises one concern
      that needs to be addressed.  That is, "break-before-make" is added in
      the security design decisions in section 5.8.  Even if this is merely
      a desirable behavior, it should be described in the behaviors before
      being referenced in the design decisions. 
        
  4. Alexey Melnikov: Comment [2011-01-16]:
    5.6.  Connection Identification
    
       Legacy applications will not, however, have access to this identifier
       and in such cases a MPTCP connection will be identified by the
       5-tuple of the first TCP subflow.  It is out of the scope of this
       document, however, to define the behaviour of the MPTCP
       implementation if the first TCP subflow later fails.  If there are
       MPTCP-unaware applications that make assumptions about continued
       existence of the initial address pair, their behaviour could be
       disrupted by carrying on regardless.  It is expected that this is a
       very small, possibly negligible, set of applications, however.  In
       the case of applications that have used an existing API call to bind
       to a specific address or interface, the MPTCP extension MUST NOT be
       used, since the applications are indicating a clear choice of path to
       use and thus will have expectations of behaviour that must be
       maintained, in order to adhere to the application compatibility
       goals.
    
    I am not convinced your use of MUST NOT is correct here. In fact, it seems that
    it is in direct conflict with the following paragraph:
    
       Since the requirements of applications are not clear at this stage,
       however, it is as yet unconfirmed what the best behaviour is.  It
       will be an implementation-specific solution, however, and as such the
       behaviour is expected to be chosen by implementors once more research
       has been undertaken to determine its impact.
    
    I.e., it is actually possible to know from the current socket API what is the
    application intent in this case?
  5. Dan Romascanu: Comment [2011-01-20]:
    I support David's COMMENT

draft-merrick-jms-uri

  1. Lars Eggert: Comment [2011-01-17]:
    INTRODUCTION, paragraph 4:
    >    The syntax of this 'jms' URI is not compatible with any known current
    >    vendor implementation, but the expressivity of the format should
    >    permit all vendors to use it.
    
      So are there vendor implementations of 'jms' already? If yes, what it
      the value in publishing a specification that is not compatible with
      any of them? Or do we have an indication that the vendors will adopt
      this spec?
    
  2. Alexey Melnikov: Comment [2011-01-14]:
    It looks like IANA issue was actually addressed in the last revision.
    

draft-nsri-tls-aria

  1. Adrian Farrel: Comment [2011-01-20]:
       This document proposes the addition of new cipher suites to the
       Transport Layer Security (TLS)
    
    Please don't be so timid. "This document defines/specifies ..."
  2. Dan Romascanu: Comment [2011-01-18]:
    Please expand PRF at first occurence. 

draft-schaad-smime-hash-experiment

  1. Lars Eggert: Discuss [2011-01-17]:
          DISCUSS: ID is missing the RFC2119 boilerplate and reference.
     
        
  2. Lars Eggert: Comment [2011-01-17]:
    INTRODUCTION, paragraph 4:
    >    algorithms with parameters, but anecdotic evidence suggests that
    
      Nit: s/anecdotic/anecdotal/
    
    INTRODUCTION, paragraph 13:
    > Internet-Draft            CMS Paramertized Hash             January 2011
    
      Nit: s/Paramertized/Parametrized/
    
    Section 8., paragraph 0:
    >      A.3.  Autenticated Data Example  . . . . . . . . . . . . . . . . 17
    
      Nit: s/Autenticated/Authenticated/
    
    Section 1., paragraph 9:
    >    The ASN.1 defined for the types DigestedData and AthenticatedData are
    
      Nit: s/AthenticatedData/AuthenticatedData/
    
    Section 1., paragraph 11:
    >    SignerInfo.digestedAlgorithm is not seen until the content has been
    
      Nit: s/SignerInfo.digestedAlgorithm/SignerInfo.digestAlgorithm/ (I
      think?)
    
    Appendix A., paragraph 7:
    >  To: BobRSA@examples.com
    
      "examples.com" is not one of the usual domain names set aside for
      documentation purposes. Do you mean "example.com"?
    
  3. Russ Housley: Discuss [2011-01-19]:
        
      There are many algorithm identifiers that specify a hash algorithm and
      a signature algorithm used in combination.  It is highly desirable
      that the same hash algorithm be used for computing the digest of the
      attributes and the content.  How would xor-md5WithRSAEncryption be
      handled?  
        
  4. Alexey Melnikov: Discuss [2011-01-19]:
        [Updated.]
    
    I generally support this experiment. However the MIME section contains several
    errors that need to be fixed before this document can be approved:
    
    >5.  MIME handling
    >
    >   This section defines the string that appears in the micalg parameter.
    >
    >   The algorithm is identified by the string xor-md5.  The parameters
    >   for the algorithm are the hex encoded DER ASN.1 encoding.  The
    >   parameters and the identifier string are separated by a colon.
    >   Arbitrary amounts of white space may be inserted between any two
    >   characters in the hex encoded string.
    
    I don't believe this comment is correct according to MIME, you should be using
    the mechanism defined in RFC 2231.
    
    >   An example content-type string
    >   would be:
    >
    > Content-Type: multipart/signed; protocol="application/pkcs7-signature";
    >      micalg=sha1, xor-md5:04400102030405060708090a0b0c0d0e0f00111213141
    >      5161718191a1b1c1d1e1f102122232425262728292a2b2c2d2e2f2031323334353
    >      63738393a3b3c3d3e3f30;
    >      boundary=boundar42
    
    According to RFC 1847, micalg is defined as:
    
       parameter := "micalg" "=" value
    
    which I believe is referencing the <value> ABNF production from MIME (RFC 2045):
    
        value := token / quoted-string
    
         token := 1*<any (US-ASCII) CHAR except SPACE, CTLs,
                     or tspecials>
    
         tspecials :=  "(" / ")" / "<" / ">" / "@" /
                       "," / ";" / ":" / "\" / <">
                       "/" / "[" / "]" / "?" / "="
                       ; Must be in quoted-string,
                       ; to use within parameter values
    
    So, neither spaces nor commas are allowed in the micalg parameter, unless it is
    quoted.
    
    quoted-string is defined in RFC 5322 (/2822/822). I don't remember of the top of
    my head
    how folding of lines interacts with quoted strings. I will research that
    as well.
    
    In Section A.2:
    
      MIME-Version: 1.0
      To: User2@examples.com
      From: BobRSA@examples.com
      Subject: MD5-XOR signing example
      Message-Id: <091218002550300.249@examples.com>
      Date: Fri, 18 Dec 2010 00:25:21 -0300
      Content-Type: multipart/signed;
          micalg=xor-md5: 0440010203405060708090a0b0c0d0e0f10
           111213415161718191a1b1c1d1e1f20212223425262728292a2b2c2d2e2f30
           313233435363738393a3b3c3d3e3f40
    
    I think the trailing ";" is missing on the above line (in addition to missing
    quoting).
    
          boundary="----=_NextBoundry____Fri,_18_Dec_2009_00:25:21";
          protocol="application/pkcs7-signature"
     
        
  5. Alexey Melnikov: Comment [2011-01-19]:
    RFC 1847 needs to be an Informative Reference. I think MIME as well.

draft-zorn-radius-keywrap

  1. Lars Eggert: Comment [2007-01-25]:
    Agree with Russ and Dan.
  2. Dan Romascanu: Comment [2011-01-13]:
    In the Abstract Section s/This attributes/These attributes/

draft-templin-iron

  1. Jari Arkko: Comment [2010-12-16]:
    
        
  2. Stewart Bryant: Comment [2010-12-15]:
    I am surprise that the document contains no reference to LISP which is
    operating broadly in this space.
    
    =======
    
    SRA is not a defined abbreviation.
    
    =======
    
    This needs a few words of clarification - presumably the "locator addresses" are
    the addresses learned from the relay.
    
      After the Client receives an SRA message from the nearby Relay
       listing the locator addresses of nearby Servers, it sends SRS test
       messages to one or more of the locator addresses to elicit SRA
       messages.
    
    =======
    				   
    If this Server fails, the Client will quickly select a new
       one which will automatically update the VPC overlay network mapping
       system with a new EP-to-Server mapping.
    
    "quickly" is a non-specific metric
    
    =======
    
    [I-D.templin-intarea-seal] looks like it should be normative
    [I-D.templin-intarea-vet]  looks like it should be normative
    
    Although the RFCeditor may wish to overlook this if there is a concern that
    these drafts will not be taken to completion.
    
    
  3. Ralph Droms: Comment [2010-12-16]:
    I have one suggestion about the content of the document.  I'd like to
    see an analysis of how IRON actually "provide[s] scalable PI
    addressing without changing the current BGP [RFC4271] routing system"
    along with costs incurred by IRON.  How does hiding the EPA addresses
    inside the IRON locator prefixes reduce the routes in the real
    Internet core?  What is the cost in the routing tables maintained by
    the relays?  How expensive is the anycast routing?  How does inter-VPC
    routing work and how expensive is it?
    
    The remainder of my COMMENTs are editorial.
    
    In Section 6.1, I think I understand what this text is trying to
    explain, but I don't think it's correct:
    
       It
       is therefore essential that the Client send the initial packets
       through its Server to avoid loss of SCMP messages that cannot
       traverse a NAT in the reverse direction.
    
    Does this mean to explain that the Client sends packets through its
    Server to establish NAT state so SCMP messages from the Server to the
    Client can traverse the NAT?
    
    In Section 6.2, this text uses "into the Internet" in a confusing way,
    assuming I'm understanding the meaning of the text correctly:
    
       The Server then
       forwards the revised packet into the Internet via a default or more-
       specific route, where it will be directed to the closest Relay within
       the destination VPC overlay network.
    
    Everywhere else in this section "into the Internet" is used to
    describe the forwarding of a decapsulated datagram, after the outer
    header with locator addresses have been removed, into the (non-IRON)
    Internet.  In the text quoted aboce, "into the Internet" seems to mean
    forwarding of an encapsulated datagram, which is described elsewhere
    in this section as simply "forwards" or "sends".  I suggest rewriting,
    for consistency, as
    
       The Server then
       forwards to the closest Relay within
       the destination VPC overlay network.
    
    In Figure 6, why would the anycast datagram from Server(A) be
    delivered to Relay(B) rather than Relay(A) (which presumably would be
    in the routing fabric for ISP A)?  Does it matter? 
    
    Once Server(B) receives the datagram to be forwarded to Client(B), is
    it possible for Server(B) to send a redirect to Client(A) so Client(A)
    can send traffic directly to Client(B)?
    
    Stylistic nit in section 6.4.1 (and elsewhere) - why start using the
    verb "releases" instead of the previously used "forwards" or "sends"?
    Seems like lots of unnecessary verbiage right after Figure 6; why not
    something like "..., host A sends packets to host B through its EUN.
    Client(A), as the defautl router for the EUN, receives the packets,
    encapsulates them in the IRON encapsulation and forwards them to
    Server(A). ..."  (etc.)  All the explanation of routing, etc., seems
    redundant at this point.
    
    Sorry, can't help myself; in section 6.6:
    
       The IRON approach to
       renumbering avoidance therefore depends on VPCs conducting ethical
       business practices and offering reasonable rates.
    
    ... as opposed to the unethical business practices and unreasonably
    high rates from those evil, greedy ISPs.
    
    Seriously, has the renumbering problem simply been moved from the ISPs
    to the VPCs?
    
  4. Adrian Farrel: Comment [2010-12-16]:
    Thank you for bringing this work forward as Experimental and so increasing the
    documentation and discussion of potential solutions.
    
    I feel that it would be helpful if the document contained a pointer to draft-
    irtf-rrg-recommendation so that the other ideas in the field can be easily found
    and compared.