IESG Narrative Minutes

Narrative Minutes of the IESG Teleconference on 2012-10-11. These are not an official record of the meeting.

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

Corrections from: Barry, Russ, Adrian

1 Administrivia

1. Roll Call 1134 EDT Amy:
   • Bernard Aboba---
   • Richard Barnes--- y
   • Ron Bonica--- y
   • Stewart Bryant--- y
   • Gonzalo Camarillo--- y
   • Benoit Claise--- y
   • Michelle Cotton--- y
   • Ralph Droms--- regrets
   • Wesley Eddy--- y
   • Adrian Farrel--- y
   • Stephen Farrell--- y
   • Heather Flanagan--- y
   • Sandy Ginoza--- y
   • Brian Haberman--- y
   • Joel Halpern--- y
   • Susan Hares--- y
   • Russ Housley--- y
   • Barry Leiba--- y
   • John Leslie--- y
   • Cindy Morgan--- y
   • Ray Pelletier--- regrets
   • Pete Resnick--- y
   • Robert Sparks--- y
   • Martin Stiemerling--- y
   • Sean Turner--- probable regrets
   • Amy Vezza--- y
2. Bash the Agenda
   • Amy: any new? any other changes?
3. Approval of the Minutes of the past telechat
   • September 27 minutes--- approved
   • September 27 narrative minutes--- approved
4. Review of Action Items from last Telechat
   • (none)

2. Protocol Actions

2.1 WG Submissions

2.1.1 New Items

• iSCSI Protocol (Consolidated) (Proposed Standard)
  draft-ietf-storm-iscsi-cons [txt]
  Token: Martin Stiemerling (tsv area)
  Note: David Black (david.black@emc.com) is the document shepherd.
  Discusses/comments [ballot]:
  • Stephen Farrell: Discuss [2012-10-09 09:12]:
    (1) Is IPsec mandatory to implement or not? While it might be ok to omit that detail for an initiator running on a standard OS, it needs to be clear for e.g. a LUN that runs on an embedded OS.
    (2) p153, 2nd last para: how can an implementation above TCP verify that IPsec encryption is being used? Same at the end of setion 9.3.
    (3) Why are sections 2.4.x and the intro to 11 both needed? Do they even say the same thing? Having text like that twice is bad. Section 11 seems clearer.
    (4) If there is a conflict between the text in section 11/12/13 and earlier text, which wins? Where's that stated? I think you need that given how much overlap there is.
    (5) 12.1.1: how are the krb-ap-req & rep encoded? Those are binary messages. I don't get how that's handled. (Same for 12.1.2)
  • Stephen Farrell: Comment [2012-10-09 09:12]:
    - There's a lot of repetition which is a pain in such a long document. That's a pity.
    - This is too long. It may have seemed like a good plan to merge a lot into one document, but this goes beyond what's useful IMO.
    - There seem to be many cases of terms being used that are not (well) defined. 4.2.3.2 refers to [SPC3] for 'task set' which is the basis for a bunch of definitions I can't understand, not having access to [SPC3]. And for example, response fencing is all over section 4 but never defined. I think a general pass for this probably would be worthwhile.
    - Can you explain how a 2nd TCP connection for a session is as secure as the first? I think that the login phase has to be repeated but wasn't sure.
    - 4.2.5 says that a connection is in full feature phase if some (possibly other) connection has successfully passed through the login phase. That seems to imply that only IP level security can work for iSCSI (since TLS would be connection specific) and that MPTCP couldn't be just substutited for TCP. Is that correct? Where is that stated?
    - 6.3.5 - I don't quite get the security model for session reinstatement. It appears to be the case that if any user that can login (if that's needed) could guess and ISID then they could take over someone else's session - is that right? If not, what prevents that occurring? If so, where does it say that ISID's MUST/SHOULD be hard to guess?
    - Is it clear how iSCSI names are mapped to X.509 certs used in IPsec?
    - Just wondering if anyone's look at the recovery features to check if flipping a bit in an ecrypted packet could trigger any bad behaviour?
    - section 7: What if IPsec goes wrong? Any specific recovery for that?
    - p158/9 is it not now time to make 3DES a SHOULD and AES a MUST?
    - CHAP has some weaknesses, but MUST only be used here when sent via IPsec, is that correct? How would an implementation know that IPsec is in use?
    From the secdir review [1]:
    - 9.3.1 - RFC 2404 defines HMAC-SHA-1-96 not HMAC-SHA1. is the reference correct?
    - 4.2.3.2. Notion of Affected Tasks, LOGICAL UNIT RESET: All outstanding tasks from all initiators for the LU identified by the LUN field in the LOGICAL UNIT RESET Request PDU. Are there any access control facilities for this operation?
    (Please also consider the other comments from the secdir review as well.)
    nitty comments (20 items)
  • Pete Resnick: Comment [2012-10-10 13:32]:
    2.2: "- SCSI Port Name: A name made up as UTF-8 characters and includes the iSCSI Name + 'i' or 't' + ISID or Portal Group Tag."
    s/made up as/encoded as
    4.2.3.5: "If the issuing session is a FastAbort session, the iSCSI target implementation is FastAbort-capable, and the third-party affected session is an RFC 3720 session, the following behavior MUST be exhibited by the iSCSI target layer: Asynchronous Message PDUs MUST NOT be sent on the third-party session to prompt the FastAbort behavior."
    I don't understand what counts as 'following' in 'the following behavior MUST be exhibited'. Why not simplify to:
    "If the issuing session is a FastAbort session, the iSCSI target implementation is FastAbort-capable, and the third-party affected session is an RFC 3720 session, the iSCSI target layer MUST NOT send Asynchronous Message PDUs on the third-party session to prompt the FastAbort behavior."
    Is there something else 'following' that needs to be accounted for?
    (The following is about text that was in the original document. Because of that, I will not put a DISCUS on this, but gee would I like to see this clarified.
    4.2.7.1 says: "- iSCSI names are composed only of displayable characters. iSCSI names allow the use of international character sets but are not case sensitive. No whitespace characters are used in iSCSI names."
    and 4.2.7.2 says:
    "- It is in Normalization Form C (see 'Unicode Normalization Forms' [UNICODE]).
    "- It only contains characters allowed by the output of the iSCSI stringprep template (described in [RFC3722])."
    'not case sensitive' in 4.2.7.1 is weird. That would seem to imply that you *can* have uppercase characters, but that they compare equally to lowercase characters. But 4.2.7.2 (and in particular 3722) says that it's only going to be lowercase. Something seems amiss. Do you mean only ASCII characters are compared case-insensitively?
    All this said, I am bummed that we didn't get PRECIS far enough along to include in this version. Ah, well.
  • Benoit Claise: Comment [2012-10-10 16:43]:
    I am voting no objection on the basis that a quick review indicates no implications for OPS for this draft, and that the OPS aspects will be covered in draft-ietf-storm-iscsimib.
  • Barry Leiba: Comment [2012-10-10 12:56]:
    I haven't been able to give this a full review. Some non-blocking comments here, based on what I've had time to cover. If I get more before tomorrow's telechat, I'll add them and re-send this.
    -- Section 4.2.4 -- "To protect the TCP connection, an IPsec security association MAY be established before the Login request."
    Related to Stephen's DISUCSS point (1), why is *use* of IPSec a MAY? It's clear to me why neither authentication nor connection-level security is always needed (for example, using iSCSI to access a read-only repository of public information), so performing login is a SHOULD. Why isn't IPSec also SHOULD?
    -- Section 6.1 --
    You give Unicode code points for the non-alphanumeric characters, but not for the alphanumeric ones. Just to be complete, and to recognize that there are multiple Unicode characters that look like 'a', for example, you should probably do this:
    OLD
    (a-z, A-Z) - letters
    (0-9) - digits
    NEW
    (a-z, A-Z) (0x61-0x7a, 0x41-0x5a) - letters
    (0-9) (0x30-0x39) - digits
    Consider whether RFC 4648 would be a better reference for base64 encoding than RFC 2045.
    I see that Mallikarjun and Alexey are engaged in conversation about Alexey's AppsDir review, with resultant changes. And my esteemed colleague from Illinois has said that he's covering the stringprep stuff and related issues. Apart from that, I don't see any App-layer issues raised here, and trust that the ADs at the lower layers will handle those.
  • Stewart Bryant: Comment [2012-10-07 20:50]:
    I am voting no objection on the basis that a quick review indicates no implications for the routing system.
  • Brian Haberman: Discuss [2012-10-09 13:40]:
    * In section 4.2.2.3.4, the first paragraph states : 'This Section lists the situations in which fenced response behavior is REQUIRED in iSCSI target implementations. However, this is not an exhaustive enumeration.'
    Is the list of use cases exhaustive as currently known within the existing implementations? If it is, the second sentence is not needed. No one should expect a spec to be able to address use cases created after its publication. If it is not, why not?
    * Section 6.2 states : 'The proper way to handle a NotUnderstood response depends on where the key is specified and whether the key is declarative vs. negotiated. An iSCSI implementation MUST comprehend all text keys defined in iSCSI Protocol specifications from RFC 3720 through the RFC associated with the highest protocol version that the implementation has offered (or has negotiated, in the case of an acceptor) for the iSCSIProtocolLevel key in a negotiation.
    If I understand all of the relevant RFCs and this draft, iSCSIProtocolLevel is still 1. Is there a spec for level 0? I am unsure why this draft would reference back to 3720, when it is making that RFC obsolete and subsuming all of its functionality. The above text is making assumptions about what future iSCSI specifications may or may not require. Why is the requirement for handling NotUnderstood responses not more concrete and contained within this spec?
    * This spec states that it is updating RFCs 3721 and 3723. If that is the case, why is RFC 3721 listed as an Informative reference while 3723 is a Normative reference?
  • Brian Haberman: Comment [2012-10-09 13:40]:
    * The text in section 2.3 is useful, but it does not discuss what is being updated in RFCs 3721 and 3723.
    * The References section is un-numbered and not included in the TOC.
    * Section 4.2.7 makes a reference to SLP. The acronym is not expanded and RFC 2608 is not referenced.
    * Section 4.2.7.3 (way minor typo) : s/assists.in/assists in/
    * Section 9.4 : s/wellknown/well-known/
  • Sean Turner: Discuss [2012-10-10 08:15]:
    CHAP has long been known to be vulnerable to dictionary attacks (prior to '07). You've got considerations for how to use it, but can we please put something in to support will be dropped in the next version?
  • Sean Turner: Comment [2012-10-10 08:15]:
    I support Stephen's discuss positions.

  Telechat:

  • Amy: open not here; number of discusses
  • Martin: working on it offline
  • Stewart: level of review? 350 pages, not enough time, looked for routing, found nothing
  • Martin: big document, review is appreciated; revised-ID needed
  • Barry: HTTP was split, but if you have to review all at once, this is perhaps easier
• Simple LDPC-Staircase Forward Error Correction (FEC) Scheme for FECFRAME (Proposed Standard)
  draft-ietf-fecframe-ldpc [txt]
  Token: Martin Stiemerling (tsv area)
  Note: Greg Shepherd (gjshep@gmail.com) is the document shepherd
  Discusses/comments [ballot]:
  • Russ Housley: Comment [2012-10-08 08:08]:
    Please consider the comments provided in the Gen-ART Review by Meral Shirazipour on 1-Oct-2012.
  • Stephen Farrell: Discuss [2012-10-11 04:56]:
    I'm confused that there's no IPR declaration given that RFC 5170 has a bunch, yet is a normative reference that defines the actual mechanism used here, yet the writeup says 'there is no IPR.' How's that possible?
    Maybe this is really a DISCUSS-DISCUSS about transitive IPR declarations, but I'm not sure because of the write-up. If its considered ok that implemeters of this will have to read and thus be aware of the IPR in 5170, then I guess I'll clear but I figure its best to ask.
  • Pete Resnick: Discuss [2012-10-10 18:22]:
    I plan to clear on the telechat given an appropriate response; this is more for the shepherd than for the authors:
    The document writeup says: "There is consensus within the FECFrame WG to publish this document."
    But this gives no explanation as to why FECFrame wishes to publish this document. No answer in the shepherd report was given to the question of whether there are implementations of this protocol or whether there is interest by potential implementers in this work. The only references appear to be to research in this area, not an actual requirement for interoperability. Is there any interest in actually implementing this protocol, or is this simply another academic publication without community interest?
  • Barry Leiba: Comment [2012-10-02 16:24]:
    I have no objection to this document, and no blocking comments. These are non-blocking, but please consider them seriously, and feel free to chat with me about them:
    Throughout:
    All of the 'MAY' words in here seem wrong: they're describing conditions that might exist, not specifying directives for making choices (unless I'm mis-reading it). You MUST consider various things when you construct an ADU block. One of those various things may or might (but not MAY) be factor A. I think all the 'MAY's in the document should be lower case (or be replaced by 'might'):
    - the target use-case MAY have real-time constraints
    - [the real-time constraints] MAY define a maximum ADU block size
    - a codec MAY impose other limitations on the maximum source block size
    - The source ADU flows MAY have real-time constraints.
    - Reed-Solomon codes or 2D parity check codes MAY be more appropriate.
    -- Section 8 -- "Values of FEC Encoding IDs are subject to IANA registration. [RFC6363] defines general guidelines on IANA considerations. In particular it defines a registry called FEC Framework (FECFRAME) FEC Encoding IDs whose values are granted on an IETF Consensus basis."
    IANA notes that 'IETF Review' is the right term and suggests changing this. I suggest just removing the paragraph; it's not necessary, and it doesn't seem to have any value at all. You can move the reference to RFC 6363 to the next paragraph, which can otherwise remain as it is.

  Telechat:

  • Amy: no open, couple of discusses
  • Martin: Pete, author's answer OK
  • Pete: OK, used by one vendor, others interested, please clear for me
  • Barry: request we push back on Shepherds' writeups that fail to show discusion
  • Stephen: assuming no new IPR, we probably don't need another IPR for this; clearing
  • Martin: approved, point raised please
  • Barry: please push back on shepherds which leave out related IPR
  • Amy: approved, point raised
• The Optimized Link State Routing Protocol version 2 (Proposed Standard)
  draft-ietf-manet-olsrv2 [txt]
  Token: Adrian Farrel (rtg area)
  Note: Stan Ratliff (sratliff@cisco.com) is the document shepherd.
  Discusses/comments [ballot]:
  • Stephen Farrell: Discuss [2012-10-11 05:12]:
    Why are 'guidelines' for securing OLSRv2 sufficient and how does that meet BCPs 61 and 107? ROLL has been stuck on this due to punting on the defintion of key management mechanisms and lots of work is having to be done to retro-fit security for routing in sidr and karp so why is it ok for us to perhaps make the same mistake (punting on security for routing) again?
    Is there even a proof-of-concept that OLSRv2 can be used with RFC6622 TLVs to produce a "secure" solution for routing in at least some MANETs?
    If there were at some 'SHOUL implement' statements about some flavour of use of RFC6622 and where an accompanying key managment solution actually exists then this might be fine, but as-is, it looks like nobody is going to get interop for security without more work being done, and experiene with ROLL seems to show that getting that done can be hard to impossible.
  • Martin Stiemerling: Discuss [2012-10-10 08:26]:
    This is a good document and I do not object in principle to the publication of the document.
    However, there is a broader question about congestion potentially caused by this which isn't addressed in the document, especially not since it is on the Standards Track.
    Everything in OLSRv2 about congestion control is copied from RFC 3626. RFC 3626 is Experimental, so far so good.
    1) Is there any guidance on congestion avoidance and control that was learned from deployments of RFC 3626?
    2) The timers for the Message Interval Parameters (TC_INTERVAL and TC_MIN_INTERVAL) are fixed to
    o TC_INTERVAL := 5 seconds
    o TC_MIN_INTERVAL := TC_INTERVAL/4
    Is there any recommendation to change the values for very low bandwidth links? Such as being used in MANETS? The point is that on very low bandwidth links the messages carrying the OSLRv2 information could already take most of the share of the available bandwidth.
    3) What would be the recommendation to an OLSRv2 instance experiencing congestion? And the resulting effects for the routing.
  • Pete Resnick: Comment [2012-10-10 18:12]:
    Throughout the document, there are references to assorted 'time' values, but nowhere that I can find is there an explicit granularity requirement. Is the granularity documented elsewhere and therefore so obviously understood to be seconds by the MANET community that it is not worth mentioning in this document? If not, it might be worth mentioning.
    I find all of the MUSTs and MAYs in the definitions of section 2 weird. For example:
    "A router MUST be able to distinguish a routable address from a non-routable address by direct inspection of the network address, based on global scope address allocations by IANA and/or administrative configuration. Broadcast and multicast addresses, and addresses which are limited in scope to less than the entire MANET, MUST NOT be considered as routable addresses. Anycast addresses may be considered as routable addresses."
    I'm trying to figure out what it would mean for a router to be unable to distinguish routable from non-routable addresses. What are the interoperability considerations here? 'Considering broadcast and multicast addresses as routable' seems problematic in general, not just for this protocol. Aren't you simply saying that routers that implement this protocol will need to distinguish routable and non-routable addresses? Either way, why is this protocol instruction in the definitions section? Sounds like it should be in a 'Basic Requirements' section if it needs to be a protocol requirement.
    5.1: "TC messages and HELLO messages [RFC6130] MUST, in a given MANET, both be using the same of either of IP or UDP, in order that it is..."
    Don't you mean, 'TC messages and HELLO messages [RFC6130] will all use either IP or UDP in a given MANET in order that it be...'? I don't see what the MUST is doing in this sentence. The sentence is a statement of fact, not a protocol directive.
    16.3.3.1 - 16.3.3.4: 'The router MUST update its...'. I always find MUSTs of this sort weird. It's not really a protocol requirement to update the internal state of the router. It's the behavior of the router that's the protocol requirement. These probably simply don't need MUSTs, though perhaps rewording is in order. But these sorts of MUSTs seem to appear throughout sections 7 through 12 anyway (requirements for local implementation of information bases), so perhaps this ship has sailed long ago in the MANET work.
  • Barry Leiba: Discuss [2012-10-07 14:55]:
    This is a very well written, clear document. Despite its length (or perhaps because of it), it was very easy to understand, even for an Apps guy. I'll be happy to enter a 'yes' ballot after discussing one concern:
    -- Section 16.3.1 -- "A router MAY recognize additional reasons for identifying that a message is invalid. An invalid message MUST be silently discarded, without updating the router's Information Bases."
    Does this cause any interoperability artifacts? It seems to be saying that I can consider a message invalid for any reason I decide to come up with, and therefore silently discard any message for basically any reason. Is that right? If there are some criteria or limitations relating to those additional reasons, it'd be helpful to give them. If it really is at a whim, how does that work? (I see that Section 23.2 suggests some additional reasons, but this section just seems to leave it entirely open.)
    I understand that this might just be a quality of implementation issue: if your router picks bogus reasons for discarding otherwise-valid messages, it'll suck and no one will use it. In that case, is there a way that such a rogue router could be used to attack or DoS a MANET?
  • Barry Leiba: Comment [2012-10-07 14:55]:
    I also have a few non-blocking comments that I'd like you to consider, and to feel free to chat with me about.
    It seems odd to me that this document doesn't Obsolete 3626. Can you tell me why it doesn't? Is it expected that people will continue to experiment with or otherwise use OLSR (v1) after OLSRv2 is published as a Proposed Standard?
    -- Section 3 --
    This isn't really an Applicability Statement, at least not in the sense described in RFC 2026, Section 3.2. This is a list of features of this protocol. It's a fine section to have in here, but it doesn't talk about how this protocol can be used in any particular situations.
    -- Section 5.1 --: "This protocol specifies TC messages, which are included in packets as defined by [RFC5444]. These packets MAY be sent either using the 'manet' protocol number or the 'manet' UDP well-known port number, as specified in [RFC5498]."
    I don't think this is the right use of 'MAY'. As I read it, it says that use of either the protocol number or the port number is entirely optional. You might well do neither, as you please. Somehow, I don't think that's what you mean (though I've been wrong before, so just tell me so). I think you really want a 'MUST' here: if those are the only two choices, and you MUST pick one or the other, then MUST is your guy.
    The next paragraph after that is a little malformed, 'the same of either of' is very awkward. I think you mean this, yes?:
    NEW
    TC messages and HELLO messages [RFC6130] MUST, in a given MANET, either both be using IP or both be using UDP, in order that it is
    -- Section 5.4.3 --: "o If TLVs with Type = INTERVAL_TIME, as defined in [RFC5497], are included in TC messages, then TC_INTERVAL MUST be representable as described in [RFC5497]."
    Two questions on this:
    1. As described *where* in RFC 5497. I think it's Section 5, but I had to look around. Please say that ('as described in [RFC5497], Section 5,' or wherever).
    2. TC_INTERVAL is a number -- what does it mean for it *not* to be 'representABLE' as described there? Do you mean that it must be 'representED' that way? Or something else?
    (1) and (2) also apply to T_HOLD_TIME in 5.4.4.
    -- Section 5.4.8 --: "A MANET using this protocol with too many routers having either willingness value equal to WILL_NEVER will not function; it MUST be ensured, by administrative or other means, that this does not happen."
    Well said. But is there any guidance that will help determine what 'too many' means? Any way to recommend (non-normatively) some percentage of routers that need to be willing to be selected as flooding and routing MPRs? Or if not percentage, then at least some other quantitative guidance?
    The following constraints apply to these parameters:
    o WILL_FLOODING >= WILL_NEVER
    o WILL_FLOODING <= WILL_ALWAYS
    o WILL_ROUTING >= WILL_NEVER
    o WILL_ROUTING <= WILL_ALWAYS
    This is a take-it-or-leave-it comment: we often use this mechanism to indicate this sort of 'this value must be in between these other two' relationship, and I think it makes the relationship even clearer:
    The following constraints apply to these parameters:
    o WILL_NEVER <= WILL_FLOODING <= WILL_ALWAYS
    o WILL_NEVER <= WILL_ROUTING <= WILL_ALWAYS
    This also could apply to 5.4.3:
    The following constraints apply to these parameters:
    o TC_INTERVAL > 0
    o 0 <= TC_MIN_INTERVAL <= TC_INTERVAL
    -- Section 6.1 --: "Link metrics are reported in messages using a compressed representation that occupies 12 bits, a 4 bit field and an 8 bit field."
    This sounds like it's three things. I think you mean this:
    NEW
    Link metrics are reported in messages using a compressed representation that occupies 12 bits, comprising a 4 bit field and an 8 bit field.
    -- Section 7.2 --: "The Local Attached Network Set is not modified by this protocol. This protocol MAY respond to changes to the Local Attached Network Set, which MUST reflect corresponding changes in the router's status."
    The last line invites imprecision and uncertain interpretation as to the antecedent of 'which'. What is it that MUST reflect corresponding changes in the router's status?
    - Is it the Local Attached Network Set? That doesn't seem right, because you just said that it's not modified here, so a new MUST can't be applied to it, can it?
    - Is it the *changes* to the Local Attached Network Set? That doesn't seem to make semantic sense; how can it be changes that reflect corresponding changes?
    - Is it this protocol? That makes sense, but doesn't come out of the sentence that's written.
    Can you re-write these sentences to make this clearer? And then I presume that the 'it' at the start of the next sentence is 'The Local Attached Network Set'.
    -- Section 14.3 --
    The logic here seems to be (if I'm reading it right):

    if (1) then discard
    else (2) {
       if (2.1) then discard
       else (2.2) {
          do 2.2.1
          if (2.2.2) then discard
          else {
             if (2.2.3) {
                do 2.2.3.1
                do 2.2.3.2
                do 2.2.3.3
             }
             else *** there is no else ***
          }
       }
    }
    

    
    What must happen when the 'otherwise if' in 2.2.3 is not true?
    -- Section 16.2 --: "When sending a TC message in response to a change of advertised network addresses, a router MUST respect a minimum interval of TC_MIN_INTERVAL between generated TC messages. Sending an incomplete TC message MUST NOT cause the interval between complete TC messages to be increased, and thus a router MUST NOT send an incomplete TC message if within TC_MIN_INTERVAL of the next scheduled complete TC message."
    The first part of the second sentence confused me for a while, and it wasn't until I started typing this comment that I think I figured it out. You're saying that if you send an incomplete TC message when a complete TC message would be expected in less than TC_MIN_INTERVAL from now, then the complete TC message would be required to wait, and that would be bad -- so don't do that. Is that right?
    I think that second sentence is hard to understand as written (at least, it took me several readings and some intervening misunderstandings), and I wonder if you can try to re-phrase it.
    -- Appendix D --
    I worry slightly that this appendix is normative, but comes after three non-normative example appendixes. Perhaps that's fine, and I worry unnecessarily. Would it be at all worthwhile to say something where Appendix D is cited, in the first bullet in Section 22 ? Maybe something as simple as adding the word 'normative'?: 'All updates to the elements specified in this specification are subject to the normative constraints specified in [RFC6130] and Appendix D.'

  Telechat:

  • Amy: one open, not here, number of discusses
  • Adrian: briefly, will be revised-ID needed; Barry, did email satisfy you?
  • Barry: satisfied with a little bit of text
  • Stephen: is it hard to fix
  • Adrian: easy, Mandatory-to-Implement, usage should be configurable
  • Stephen: not clear how to use...
  • Adrian: needs to be made clear, from management standpoint, it's easy; intent that Security TLV can be dropped into any MANET packet...
  • Amy: revised-ID needed
• Duplicate Address Detection Proxy (Proposed Standard)
  draft-ietf-6man-dad-proxy [txt]
  Token: Brian Haberman (int area)
  Note: Bob Hinden (bob.hinden@gmail.com) is the Document Shepherd.
  Discusses/comments [ballot]:
  • Stephen Farrell: Discuss [2012-10-11 04:46]:
    Does the deployment model for this actually fit the SAVI charter which is limited to systems on the same IP link? Its not clear to me that it does, and if it doesn't then I'm not sure how SAVI 'MAY be used' to protect against address spoofing. (It could be that this does fit with SAVI, I'm just not sure.)
  • Stephen Farrell: Comment [2012-10-11 04:46]:
    - The last sentence in the abstract confused me, what's 'this last one' mean?
    - I agree with Martin and Sean's DISCUSSes.
  • Martin Stiemerling: Comment [2012-10-09 05:44]:
    1) I have no general concern about the publication of the draft, but I doubt that it is for the Internet in general.
    It is more adding support for a very specific set of deployments, e.g., DSL access networks. This is somehow stated in the abstract 'point-to-multipoint architecture with 'split-horizon' forwarding scheme.' but it is hard to understand and the proposed solution probably does not work in other settings that use the same description or claim similar ground.
    Can we add a more specific wording right upfront that this is primarly for 'Digital Subscriber Line (DSL) and Fiber access architectures' as noted in Section 2?
    This would also be inline with the rest of the document which uses very specific terminology out of broadband access networks, e.g., BNG. The Internet itself does not has BNGs, but routers or first hop routers (AKA BNG in this context)
    Also in this context:
    Section 3.2., paragraph 3: "As the BNG must not forward link-local scoped messages sent from a CPE to other CPEs, ND Proxy cannot be implemented in the BNG."
    This seems to be the restriction of a very specific deployment scenario, but is not a limitation per se. Other people could allow this in their architecture.
    2) Section 4.1., paragraph 1: "A BNG needs to store in a Binding Table information related to the IPv6 addresses generated by any CPE. This Binding Table MAY be distinct from the Neighbor Cache. This must be done per point to"
    This 'MAY' does not look correct here, but a 'can' would just do the job, as this is implementation specific, isn't it?
    3) Appendix A., paragraph 1: "This appendix contains a summary (cf. Table 1) of the actions done by the BNG when it receives a DAD based NS (DAD-NS) message. The tentative address in this message is IPv6-CPE1 and the associated Link-layer address is Link-layer-CPE2. The actions are precisely specified in Section 4.2."
    Is this appendix normative or not? What takes precedence: the text or the table?
  • Barry Leiba: Discuss [2012-09-28 12:07]:
    Section 6.1: "To keep the same level of security, Secure Proxy ND Support for SEND [RFC6496] SHOULD be used and implemented on the BNG and the CPEs."
    SHOULD, and not MUST? How is it possible to 'keep the same level of security' with SEND if you *don't* use Secure Proxy ND Support?
  • Sean Turner: Discuss [2012-10-04 14:28]:
    s6.1, para 1: When won't using SEND without a proxy break the security? I think what you're trying to say is that using plain old SEND won't work you've got to use SEND with the proxy - right?
  • Sean Turner: Comment [2012-10-04 14:28]:
    1) Is the word 'proxy' missing from the following in the abstract:
    "The document describes a mechanism allowing the use of Duplicate Address Detection (DAD) by IPv6 nodes in a point-to-multipoint architecture with 'split-horizon' forwarding scheme."
    s1 use 'proxy' after DAD and then s1 para 2 says:
    "This document explains also why DAD mechanism [RFC4862] cannot be used in a point-to-multipoint architecture with 'split-horizon' forwarding scheme (IPv6 over PPP [RFC5072] is not affected)."
    And could we make it clear that a proxy is needed:
    "This document explains also why DAD mechanism [RFC4862] without a proxy cannot be used in a point-to-multipoint architecture with 'split-horizon' forwarding scheme (IPv6 over PPP [RFC5072] is not affected)."
    2) s4.2: Some minor wording tweaks because I don't know what the MUST pertains to:
    OLD: perform actions depending on the information in the Binding Table.
    NEW: perform actions specified in the following sections based on the information in the Binding Table.
    3) s4.2.1/s4.2.2: What happens if the BNG does reply/forward?
    4) s4.1/s4.2.2: Is the neighborhood cache in s4.2.2 the same thing as the binding table in s4.1?
    5) s4.2.3.2: L2 header: Which link-layer address is returned to CPE2? Is it it's own or the one from CPE1?
    6) s6.1: Agree with Barry's SHOULD vs MUST discuss.
    7) s6.2: r/To ensure a protection/To ensure protection
    8) s6.2: not sure you really need the MAY. Maybe r/MAY/can

  Telechat:

  • Amy: no open, number of discusses
  • Brian: quickly, no big issue; Barry, proxy not MUST
  • Barry: way it's worded is confusing, perhaps phrasing needs to change
  • Brian: suspect authors are waiting for direction before responding; Stephen, key is SAVI should be usable, but needs additional discussion
  • Stephen: understood SAVI was not intended for those environments
  • Brian: Adrian, binding table
  • Adrian: concerned what happens when binding table fills
  • Brian: I would consider that an implementation issue
  • Adrian: nothing in protocol to report it filling
  • Brian: not reliable, may time out, may replace another at next use
  • Adrian: I'll check that
  • Pete: can you criticize the shepherd for a poor writeup
  • Brian: will do; revised-ID needed
• Stateless Source Address Mapping for ICMPv6 Packets (Best Current Practice)
  draft-ietf-v6ops-ivi-icmp-address [txt]
  Token: Ronald Bonica (ops area)
  Note: Fred Baker (fred@cisco.com) is the document shepherd.
  Discusses/comments [ballot]:
  • Wesley Eddy: Comment [2012-10-10 18:29]:
    It seems like 'Updates: 6145' might be considered, and I support Robert's question regarding BCP vs PS in that respect.
  • Ralph Droms: Comment [2012-10-11 05:06]:
    I understand that the third paragraph of section 3.1 states that the address translation should provide additional information about the source address, and suggests that a pool of IPv4 addresses could be used to provide that additional information. Yet, the mechanism described in section 5 randomly chooses an IPv4 address from a pool of IPv4 addresses. I don't see how the random selection of the IPv4 address provides any information. I recognize that the IPv6 source address is carried in the ICMP extension.
    If the IPv4 address is chosen at random from a pool of addresses, what is the advantage over just using, as suggested in section 4, a single IPv4 address as the source address in all translated ICMP messages?
    In the interests of matching what I would think of as the meaning of the title and the actual mechanism, I would call this mechanism a 'random selection mechanism'. There is no mapping, as I would understand the word, involved.
    If, on the other hand, the pool were composed of IPv4 addresses that in some way convey topology information to the receiver, and the IPv4 source address were chosen based on the non-translatable IPv6 address, I would consider this mechanism to be a 'mapping'.
    I support Brian's Discuss about 'What constitutes a non-translatable address?'
  • Martin Stiemerling: Comment [2012-10-10 01:33]:
    A nit:...
  • Pete Resnick: Comment [2012-10-10 18:25]:
    Agree with Robert's DISCUSS.
  • Benoit Claise: Comment [2012-10-08 15:02]:
    No objection to the publication of this document, but a few points anyway
    1.
    OLD: [RFC6145] section 5.2 of the 'IP/ICMP Translation Algorithm' document. states that 'the IPv6 addresses in the ICMPv6 header may not be IPv4-translatable addresses and there will be no corresponding IPv4 addresses representing this IPv6 address.
    NEW: [RFC6145] section 5.3 of the 'IP/ICMP Translation Algorithm' document. states that 'the IPv6 addresses in the ICMPv6 header may not be IPv4-translatable addresses and there will be no corresponding IPv4 addresses representing this IPv6 address.
    2. 'The recommended approach to source selection is to use the a single'
    3. From the write-up:
    "(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?
    " This document is proposed as a Best Current Practice. The argument for that status is as follows. The original authors, from CERNET, observed an operational problem in their network, which uses a stateful IPv4/IPv6 Translator between an IPv4-only domain (CERNET) and an IPv6-only domain (CERNET2)."
    I guess it's a typo: statefull -> stateless
    4. <RANT>
    That's a typical IETF document that contains all the information required, but ONLY contains the minimum piece of information. Sure if you have all the background (RFC 6145, RFC 6052, ICMP, stateless/statefull, IPv6 & IPv4), this draft is a piece of cake. However, I wonder: are we doing a good service to new comers by reducing the content to the minimum? No, we're simply adding to the argument that RFCs are a pain to read. An extra diagram with an example, in the introduction, with the following pieces of information, would have been so much easier:
    - IPv6 domain,
    - IPv4 domain,
    - request goes in one direction (indicate the IP address, before and after the translation),
    - ICMPv6 comes in the other direction (indicate the IP address before the translation),
    - src IP address as ???
    - etc...
    And also explaining why it's not an issue with statefull (or simply a reference to http://tools.ietf.org/html/rfc6145#section-1.3) would be useful information </RANT>
  • Brian Haberman: Discuss [2012-10-08 08:03]:
    What constitutes a non-translatable address? That term is used multiple times in this specification and in RFC 6145 without any definition. How does an IP stack know if the address is translatable?
  • Brian Haberman: Comment [2012-10-08 08:03]:
    I am not sure what assistance Henrik gave on this document, but I doubt he needs to be in the Acknowledgements section twice.
  • Robert Sparks: Discuss [2012-10-08 10:28]:
    Question for the sponsoring AD: Why is the intended status BCP instead of PS? Code would have to be written to implement this, and it looks like there is the opportunity to learn things that would affect that code going forward. The explanation in the shepherd writeup supports PS more than it supports BCP. Why _shouldn't_ this be PS?
  • Sean Turner: Comment [2012-10-04 13:19]:
    1) s1: r/document. states/document states
    2) s2: The nits checker is complaining. I believe it's because the keywords aren't in quotes.
    3) s3.1: slight rewording:
    OLD: The source address used, should not cause the ICMP packet to be a candidate for discarding.
    NEW: The source address used, should not cause the ICMP packet to be discarded.
    4) s3.1: I find the the 2nd sentence in s3.1 odd - is 6145 only applicable to private internets? Isn't not using 1918-addresses really about not using these addresses on the internet as per RF 5735? Maybe:
    OLD: The possibility of uRPF filters in the path are a critical consideration [RFC3704] which precludes the use of private IPv4 address space [RFC1918] in this context.
    NEW: Private IPv4 address space [RFC1918] SHOULD NOT be used as the source addresses because they should not appear on the internet [RFC5735].
    5) s3.1: I think this is missing a verb
    OLD: Another consideration for source selection is that it be possible for the IPv4 recipients of the ICMP message to be able to distinguish ...
    NEW: Another consideration for source selection is that it should be possible for the IPv4 recipients of the ICMP message to be able to distinguish ...
    6) s3.2: Once more with feeling ;) it's a BCP after all
    OLD: The recommended approach to source …
    NEW: The RECOMMENDED approach to source …
    7) s4: Is the last sentence in s4 needed? If you're going to do the extension just do it.
    8) s5: Need some motherhood an apple pie about picking a random number. Add a pointer to RFC 4086.

  Telechat:

  • Amy: no open, couple of discusses
  • Ron: both discusses easy to take care of; will you clear and let me take care of it in a revised-ID?
  • Ron: Robert, will you trust me to change it to PS? I'll do that right now... Comments to be addressed, point-raised if both clear
  • Amy: approved, point-raised
• Domain Name System (DNS) IANA Considerations (Best Current Practice)
  draft-ietf-dnsext-rfc6195bis [txt]
  Token: Ralph Droms (int area)
  Note: Olafur Gudmundsson (ogud@ogud.com) is the document shepherd.
  Discusses/comments [ballot]:
  • Russ Housley: Comment [2012-10-10 10:24]:
    Please consider the comments from the Gen-ART Review by Dan Romascanu on 9-Oct-2012.
  • Pete Resnick: Comment [2012-10-10 18:35]:
    The only 2119 keyword in this thing is in section 2.3 where it says:
    "With the existing exceptions of error numbers 9 and 16, the same error number MUST NOT be assigned for different errors even if they would only occur in different RR types."
    That doesn't need a 2119 keyword. Lowercase it, delete the 2119 template and reference, and be done with it.
  • Barry Leiba: Comment [2012-10-09 16:18]:
    While you're tweaking the instructions for the Designated Expert:
    -- Section 3.1.2 --: "The Expert should normally reject any RRTYPE allocation request that meets one or more of the following criteria:"
    I presume that means that the Expert should normally approve any requests that do not meet those criteria, and it'd be nice if this said that, or something related to it that connects to what you have in mind. In other words, it would be good to say whether you want the Designated Expert to be lenient or strict. So perhaps something like this (or whatever variant is suitable)?:
    "The Designated Expert should normally be lenient, preferring to approve most requests. However, the Expert should normally reject any RRTYPE allocation request that meets one or more of the following criteria:"
  • Sean Turner: Comment [2012-10-03 09:38]:
    Nicely done!
    In deference to the bygone era of low bandwidth, I believe s2.1 should be retitled: 'Brother, can you spare a bit?' ;)
    s3.1.1: Should the rejection also go back to the dns-rrtype-applications@ietf.org mailing list so the other experts in the pool can see whether it was approved/rejected? Only sending to dnsext@ietf.org kind of assumes all the experts are on the dnsext@ietf.org list.
    s3.1.1: Should rejected applications also be tracked for historical purposes and so experts can say no we already no before to this?

  Telechat:

  • Amy: out of last-call tomorrow, one discuss now (from Barry)
  • Barry: IANA requested it
  • Michelle: out review should come out later today
  • Barry: Michelle, let me know if I should clear my discuss
  • Amy: probably into AD-followup when it comes out of last-call
• Mechanism to indicate support of features and capabilities in the Session Initiation Protocol (SIP) (Proposed Standard)
  draft-ietf-sipcore-proxy-feature [txt]
  Token: Robert Sparks (rai area)
  Note: Paul Kyzivat (pkyzivat@alum.mit.edu) is the Document Shepherd
  Discusses/comments [ballot]:
  • Adrian Farrel: Comment [2012-10-08 07:27]:
    I have no objection to the publication of this document.
    Note that it has become customary to include a reference to the normative definition of the ABNF variant used.
  • Stephen Farrell: Comment [2012-10-11 05:31]:
    - Is the consumer of the information in feature-capabilities well-defined? Is it intended just for the recipient of the SIP message or is it ok for it to really be intended e.g. for one SIP proxy to tell stuf to a downstream proxy but not to the final recipient? (I may have missed where you said that, in which case, sorry:-)
    The remainder of my comments are really security points, but given that we're not going to solve e2e (never mind middle-to-end) security for SIP now, these are just comments. I'd still be very interested in answers though.
    - Are SIP proxies allowed to remove feature capabilities added upstream? Presumably they MUST NOT re-order them?
    - I suspect the last paragraph of section 9 is wishful thinking at best as it relates to confidentiality. Defining a solution for middle-to-end or middle-to-middle confidentiality like that seems like its just not going to happen (and is quite hard in any case). I think you'd be better to say that you SHOULD NOT define feature capabilities that need confidentiality that's better than hop-by-hop as provided by TLS.
    - I wondered what'd happen if someone defined a DKIM-like signature scheme for SIP messages. Has anyone thought about that?
  • Pete Resnick: Comment [2012-10-10 19:01]:
    I find the 2119 keywords in sections 5 & 8 to be completely superfluous. This is about documentation, not about interoperability or network damage. I think they should all be gotten rid of.
  • Barry Leiba: Comment [2012-10-02 16:53]:
    I have no objection to this document, and no blocking comments. These are non-blocking, but please consider them, and feel free to chat with me about them:
    -- Section 4.2.1 --: "When a SIP entity adds a Feature-Caps header field to a SIP message, it MUST place the header field before any existing Feature-Caps header field in the message to be forwarded, so that the added header field becomes the top-most one. Then, when another SIP entity receives a SIP request or the response, the SIP feature capability indicators in the top-most Feature-Caps header field will represent the supported features and capabilities 'closest' to the entity."
    I understand the mandatory ordering, and I'm not asking about that. But addressing the last point in particular, why is it important to know about supported features and capabilities 'closest' to me? Suppose the entities involved are A -> B -> C -> D, and suppose that A and B put Feature-Caps header fields on but C does not. Will there be any issue when D sees the field that B put on and 'thinks' that it was put there by C? (I suspect that's not a problem, but I wanted to ask.)
    -- Section 5.3.6 --: "If there are specific security considerations that apply to the feature capability indicator, the feature capability indicator specification MUST document such considerations."
    That seems an odd requirement. If a feature capability indicator specification comes in that has nothing for its security considerations, how does anyone know whether that's because the authors thought that none applied, or that they just decided to skip this item? Why not just this?:
    NEW: The feature capability indicator specification MUST document any specific security considerations that apply to the feature capability indicator.
    And similarly for Section 5.3.5, about interop considerations.

  Telechat:

  • Amy: open not here; no discusses, hearing no objection, approved
  • Robert: no notes needed
• BGP Prefix Origin Validation (Proposed Standard)
  draft-ietf-sidr-pfx-validate [txt]
  Token: Stewart Bryant (rtg area)
  Note: Chris Morrow (morrowc@ops-netman.net) is the document shepherd.
  IPR: Cisco's Statement of IPR Related to draft-ietf-sidr-pfx-validate-01
  Discusses/comments [ballot]:
  • Adrian Farrel: Comment [2012-10-06 04:41]:
    I support the publication of this document.
    It seemed strange to me that this was positioned on the standards track since it describes an internal implementation issue for individual BGP speakers (akin to other policy-based choices about which routes to select and advertise,or reject). This doesn't affect protocol behavior per se.
    I turned to the Shepherd write-up for an explanation of the thought behind this decision, but sadly Question 1 of the write-up hasnot been answered in full, so no hints there.
    However, since we hope that this function will become widly available in implementations to factilitate deployment and use of the RPKI system by inter-domain routing, I don't think this is a big issue.
  • Benoit Claise: Comment [2012-10-08 13:06]:
    Just echoing Barry's point:
    Just some little non-blocking stuff that needs no response:
    Really a nit: you're taking what we usually call a 'man-in-the-middle attack' and calling it a 'monkey-in-the-middle' attack. While that might seem cute, I find it distracting -- mostly because one wonders whether there's a technical reason for choosing an unusual term.
    I had to search for the differences between man-in-the-middle and monkey-in-the-middle attacks. Note that rfc4593 speaks about 'man-in-the-middle'
  • Barry Leiba: Comment [2012-10-07 15:51]:
    Just some little non-blocking stuff that needs no response:
    Really a nit: you're taking what we usually call a 'man-in-the-middle attack' and calling it a 'monkey-in-the-middle' attack. While that might seem cute, I find it distracting -- mostly because one wonders whether there's a technical reason for choosing an unusual term.
    A few comments on the shepherd writeup -- no action for the authors, and the only action for the shepherd is to please consider this sort of stuff next time; thanks:
    1. I agree with Adrian's comments. Some discussion in the writeup of why the WG decided to put this as Standards Track would have been helpful, and question 1 does ask that (albeit not as clearly as it might).
    2. In the Working Group Summary in response to question 2, the writeup says that 'there was a fairly lengthy discussion in several in-person meetings as well as on-list,' but gives no clue as to what issues the discussion was about. Again, a few brief words on some key issues would have been helpful, especially for items that were primarily discussed off list.
    3. The response to question 8 says, 'Yes, there is an IPR disclosure. The WG has seen this and comments were made at an in-person meeting. There wasn't a blocking comment, however.' The question asks to 'summarize any WG discussion and conclusion regarding the IPR disclosures,' and this isn't a useful summary of the comments. Such a summary is made more important by the fact that it was in person, and not on the mailing list, so there is no record we can go back to look at.
    4. Adrian is NOT a 'galactic policeman'. He is an INTERgalactic policeman. You're selling him short.
  • Sean Turner: Comment [2012-10-05 14:22]:
    Thanks for a clearly written draft.

  Telechat:

  • Amy: no open, no active discusses, hearing no objection, approved
  • Stewart: RFCed note needs cleanup... question for Security ADs, is "monkey-in-the-middle" an issue?
  • Stephen: "monkey-in-the-middle" is OK
  • Stewart: point-raised, please
• Name Attributes for the GSS-API EAP mechanism (Proposed Standard)
  draft-ietf-abfab-gss-eap-naming [txt]
  Token: Stephen Farrell (sec area)
  Discusses/comments [ballot]:
  • Russ Housley: Comment [2012-10-10 10:52]:
    The authors have agreed to implement the suggestions from the Gen-ART Review by Suresh Krishnan on 8-Oct-2012. These have not been folded into the draft yet, but I am confident this will happen.

  Telechat:

  • Amy: open not here, no discusses, hearing no objection, approved
  • Stephen: point-raised, please
• UDP Checksums for Tunneled Packets (Proposed Standard)
  draft-ietf-6man-udpchecksums [txt]
  Token: Brian Haberman (int area)
  Discusses/comments [ballot]:
  • Ronald Bonica: Discuss [2012-10-09 11:59]:
    This DISCUSS is related to my DISCUSS on the udpzero document. As soon as that DISCUSS is addressed, I will clear this one.
  • Russ Housley: Comment [2012-10-08 08:26]:
    Please consider the non-blocking comments from the Gen-ART Review by Peter Yee on 30-Sep-2012.
  • Stephen Farrell: Comment [2012-10-11 04:14]:
    - The DCCP-UDP tunnel draft [1] says you MUST have a non-zero UDP checksum. Does that conflict with this or need to be called out as an exception? (And if so, does anything else?)
    [1] http://datatracker.ietf.org/doc/draft-ietf-dccp-udpencap/
    - Ought 6man-udpzero be a normative reference? Seems odd to say this "requires" that (top of p7) but for the referred thing to be informative and an informational RFC. Is all the right text in the right places?
    - The secdir review [2] suggested calling more stuff out to application developers, which seems worth considering.
    [2] http://www.ietf.org/mail-archive/web/secdir/current/msg03555.html
  • Benoit Claise: Comment [2012-10-09 13:41]:
    No objection to the publication of this document, but I really would like to have the following requirement clarified.
    2. Implementations MUST provide a way to signal the set of ports that will be enabled to receive UDP datagrams with a zero checksum.
    What is an implementation? The application running over the tunnel? You refer to 'An encapsulating protocol' in the sentence before the bullet points, is this what you mean? If yes, signal from where to whom? Or maybe by 'implementation' you mean 'IPv6 protocol stack implementation'
  • Barry Leiba: Discuss [2012-10-04 10:50]:
    This is a combined DISCUSS on udpchecksums and udpzero. First, let me say that I have no actual objection to publishing either of these documents. What I'm concerned about is whether we're saying what we want to stay as a 'standard', so let's discuss that:
    The issue comes when I look at udpzero Section 5.1 and udpchecksums section 5. The numbered list in the latter is essentially a word-for-word copy of the numbered list in the former, with the 'must's and 'may's and 'should not's changed to upper case. It always bothers me when a significant amount of important text is duplicated like that, but the real problem comes when I look at what this *says*.
    Because udpzero is informational, when it says, 'If a zero checksum approach were to be adopted by the IETF, the specification should consider adding the following constraints on usage,' that makes no normative requirement on any future protocol that runs on UDP and decides to bypass the UDP checksums. Now, of course, we also have a document, udpchecksums, which defines what to do if you do tunneling on UDP and you want to skip the outer checksums (because you have inner ones). *That* document makes this list normative.
    But what happens if, later, someone decides to document how to do, let's say, media streaming over UDP with zero checksums. The analysis in udpzero applies, of course, but the new document is under no obligation to consider it or any of those usage restrictions in Section 5.1. (It might be that such a document could never get past the current community and ADs, but I'm not sure we want to leave that to chance.)
    So the question comes to what we want to say normatively. Which is it that we want a standard saying?
    1. If you tunnel packets over UDP and want to avoid the UDP checksums, you need to use this list of restrictions. But other applications over UDP that want to avoid the UDP checksums can make entirely different decisions.
    or
    2. If you do *anything* over UDP and want to avoid the UDP checksums, you need to use this list of restrictions. And here's how tunneling over UDP works.
    I think (2) is right, but the way the documents are structured now says (1).
    Discussion, please....
  • Stewart Bryant: Discuss [2012-10-07 20:37]:
    Please see my discuss on draft-ietf-6man-udpzero, and note that I hope to get to yes on this draft also, since I support the liberalization of this protocol design when used for tunnelling. Specifically point 6 in this draft is relevant to this discussion.
    Additionally a tunnel may not have any way of knowing if the payload is protected (as you suggest), since normally a tunnel has no knowledge of the payload characteristics.
    In point 7 you suggest that an application cannot rely on packet length. When PWs are used for tunneling we rely on exactly that (except in the case of packets shorter than 64 octets for Ethenet padding reasons), and I am not aware of any reported issues. Thus when the application is tunnel encap/decap there is a body of evidence that suggests that this OK.
  • Stewart Bryant: Comment [2012-10-07 20:37]:
    There is some text in the earlier part of document that looks like it should be written in RFC2119 format. In this case it is not important because the normative change is later and this used RFC2119 directives, however the authors should consider making the document self consistent in this regard.

  Telechat:

  • Amy: open not here, number of discusses
  • Brian: shall we discuss both 6man documents together?
  • Brian: udpzero intended to lay out guidelines for zero UDP checksums in IPv6; Barry, applicability statement?
  • Barry: real concern is udpzero says there are issues which cause us to recommend restrictions, but they're not normative... these limitations would not limit future methods... I'd prefer "these are things you need to deal with", and it not be Informative
  • Brian: to me, document is only about tunneling situation
  • Barry: if that's the case, make it clear what restrictions we want
  • Stewart: ...
  • Ron: may be moot... reference to section 5.1... problem is you can't understand the text without the reference -- it should be a normative reference
  • Barry: was hoping for more response from authors
  • Brian: there are ways to address this, I'll push on chairs to resolve the relationship between these two documents
  • Brian: Stewart, you're looking for more liberalized rules, what checks need to be done
  • Stewart: this is legitimizing situation already in the wild, people have realized UDP is better tunneling than GRE (which has no checksums at all); people are applying... we should be writing the document as people will use it: they'll just turn of checsums... we should save our comments for cases where it's more important
  • Brian: endpoints know nothing about LISP? you have tunnel endpoints running on desktop machines
  • Stewart: routers can't do checksums at line speed... document ought to be as liberal as GRE when running tunnel
  • Brian: would transport ADs have a problem with that?
  • Wes: no strong opinions
  • Martin: no strong opinion either
  • Stewart: engineers are going to act according to their judgment; to me, benchmark should be equivalent to GRE
  • Brian: both document to revised-ID needed
  • Ron: my other discuss
  • Brian: I'm waiting on author to respond to your proposed text

2.1.2 Returning Items

• (none)

2.2 Individual Submissions

2.2.1 New Items

• (none)

2.2.2 Returning Items

• (none)

3. Document Actions

3.1 WG Submissions

3.1.1 New Items

• Pseudo Content Delivery Protocol (CDP) for Protecting Multiple Source Flows in FEC Framework (Informational)
  draft-ietf-fecframe-pseudo-cdp [txt]
  Token: Martin Stiemerling (tsv area)
  Note: Greg Shepherd (gjshep@gmail.com) is the document shepherd
  Discusses/comments [ballot]:
  • Russ Housley: Comment [2012-10-08 08:30]:
    The authors agreed to make some changes based on the comments provided in the Gen-ART Review by Miguel Garcia on 27-Sep-2012, but they have not appeared yet.
  • Wesley Eddy: Comment [2012-10-01 18:47]:
    I didn't find a very clear description of why doing this is a good thing, rather than just keeping separate repair flows. For instance, is it intended to have a savings in packet count, does it impact latency, does it minimize encoder/decoder state to be kept, etc?
    It was not clear to me whether the rates of the N source flows come into play or need to be aligned in some way (i.e. if they don't have fixed rates, have odd harmoics, or could have phase issues in how they present bits into the encoder). For instance, if some flows stall and others don't, does the encoder need to idle fill in order to have enough input to produce the repair blocks? If there are some assumptions on this, it really should be made clear, as it could impact the effectiveness or latency of the FEC.
  • Benoit Claise: Comment [2012-10-09 15:10]:
    Same question as Wes':
    'I didn't find a very clear description of why doing this is a good thing, rather than just keeping separate repair flows. For instance, is it intended to have a savings in packet count, does it impact latency, does it minimize encoder/decoder state to be kept, etc?'
  • Brian Haberman: Comment [2012-10-02 08:42]:
    I have no problem with the publication of this document, but do have some non-blocking comments/questions...
    1. I support Wes' comments on this draft.
    2. The abstract refers to a 'full-pledged' protocol, I assume this should be a 'full-fledged' protocol.
    3. The last sentence of the abstract seems odd. Do you really mean for this approach to 'design a protocol'? I would think that it would make more sense to say form/develop/implement a CDP.
    4. I am curious if there is a well-accepted definition of what a CDP provides. How can a reader determine if this approach really provides the necessary functions needed for a CDP? Are there aspects of CDPs that this approach does not provide?
    5. Section 3 states that both the source and destination need to know the Flow ID and that the Flow ID is generated from header fields such as IP addresses and transport-layer port numbers. Are there implications for this approach introduced by NATs and other types of middleboxes?
    6. The Security Considerations section references the Security Considerations in RFC 6363, which is good. Would any of the security issues in RFC 6364 also apply?
  • Sean Turner: Comment [2012-10-04 12:28]:
    1) no action required - I have to admit that when I first read this draft I thought it odd that it's called a pseudo CDP, but I now get that this draft is supposed to be like a cookbook for how to put everything together to get a CDP.
    2) a: r/full-pledged/full-fledged
    3) s1: (let's assume it does ;) r/aims at providing/provides
    4) s2: Probably nit picking here a bit, but are you also importing the 2119 language at the end of s2 in RFC 6363? If not maybe:
    "This document uses all the definitions and abbreviations from Section 2 of [RFC6363] minus the 2119-requirements language."
    or something like that.
    5) Where's the bit about how the security protocol gets picked!? I guess I'm just saying an even better non-trivial scenario would have included security.

  Telechat:

  • Amy: no discusses, hearing no objection, approved
  • Martin: point-raised, please
• IPv6 UDP Checksum Considerations (Informational)
  draft-ietf-6man-udpzero [txt]
  Token: Brian Haberman (int area)
  Discusses/comments [ballot]:
  • Ronald Bonica: Discuss [2012-10-09 11:57]:
    This is a two-part DISCUSS-DISCUSS. Both parts relate to bullet points in Section 5.1.
    Bullet 5
    'Tunnels that encapsulate IP may rely on the inner packet integrity checks provided that the tunnel will not significantly increase the rate of corruption of the inner IP packet.'
    - What does it mean to *significantly* increase the rate of corruption of the inner IP packet?
    - Shouldn't we also be concerned about corruption of the UDP header and any additional encapsulation that comes between the UDP header and the inner IP packet?
    - How does a tunnel ingress node know whether the tunnel will significantly increase the rate of corruption of the inner IP packet?
    Bullet 7
    ' UDP applications that support use of a zero-checksum, should not rely upon correct reception of the IP and UDP protocol information (including the length of the packet) when decoding and processing the packet payload. In particular, the application must be designed so that corruption of this information does not result in accumulated state or incorrect processing of a tunneled payload.'
    - How could any application achieve this goal? Possibly by analyzing the consequences if any field in the IPv6 or UDP header were corrupted? (draft-ietf-6man-udpchecksums begins this analysis.) Again, wouldn't the analysis have to include any additional encapsulation that comes between the UDP header and the inner IP header?
    - Wouldn't the analysis, mentioned above, have to include assurances regarding the case when the destination port is corrupted? Specifically, would it have to include a guarantee that if the encapsulated inner packet were delivered to any randomly chosen port, it would not cause any harm to the application listening on that port?
  • Adrian Farrel: Comment [2012-10-11 07:28]:
    A couple of thughts about this document which I am not raising as a Discuss, but I hope the authors will have a look at.
    Section 5.1
    "2. Implementations must provide a way to signal the set of ports that will be enabled to receive UDP datagrams with a zero checksum. An IPv6 node that enables reception of UDP packets with a zero-checksum, must enable this only for a specific port or port-range. This may be implemented via a socket API call, or similar mechanism."
    I believe 'signal' is a confusing word here. Signalling means (to me) that the implementation builds a message and sends it to the remote end. So, 'implementations' cannot provide this mechanism - it is the protocol specification that must do it. And a sockets API call provides a way for an implementation to request the zero-checksum feature locally, but it does not provide a way to 'signal the set of ports that will ...'
    Probably, the consistancy of this requirement would be most easily obtained by s/signal/register/
    However, that change would leave open the question of how two end points coordinate (i.e. signal) on which ports they will use zero checksum. That is a requirement on the specification of transported protocols, which is exactly what this section is about.
    Section 9 seems to make a valid point, so I am surprised that no conclusions are drawn from what it says.
    It also seems to me that it is important to drop and log corrupted packets as early as possible. This offers three benefits:
    1. Corruptions in the tunnelling encapsulation are detected so that mis-delivery of the tunnelled packets is less likely
    2. Causes of corruption can be more effectively isolated (for example, was it the encapsulation mechanism, the transmission, or the storage of the tunnelled packet that introduced the corruption). In particular, where the corruption is the result of an attack, this may be valuable information.
    3. The later the corruption is detected and the packet dropped, the more processing has been 'wasted' handling the packet. Thus, late detection offers a way to waste transmission/receiver resources.
    I found some of these points hinted at in the body of the document and in the Summary. Maybe Section 9 is just positioned a little late in the document meaning that the authors didn't feel there was muych to say by the time the reader got there? Might be nice to beef up the Section a little and arrange for it to come before the Summary.
  • Ralph Droms: Comment [2012-10-09 06:47]:
    In section 4.1, is there a reference to the 'proposal to simply ignore the UDP checksum value on reception at the tunnel egress' that can be cited to give more background?
    In section 4.2.1, 'The methods that ignores the checksum has an additional downside' needs to be plural or singular throughout.
    The first paragraph of section 5 tells me it identifies requirements for protocols carried without UDP checksum. Section 5.1 talks only about 'zero checksum'; does the proposal to ignore the checksum at the tunnel egress also fit here? Also, stylistically, I think the section header for 5.1 can simply be dropped.
    In section 5.1, I can't parse out what list item 5 is trying to convey. What is the 'tunnel layer' and is it always recommended and required for some tunnel mechanisms?
  • Benoit Claise: Comment [2012-10-09 13:43]:
    No objection to the publication of this document, but I really would like to have the following points clarified.
    - 2. Implementations MUST provide a way to signal the set of ports that will be enabled to receive UDP datagrams with a zero checksum.
    What is an implementation? The application running over the tunnel? You refer to 'An encapsulating protocol' in the sentence before the bullet points, is this what you mean? If yes, signal from where to whom? Or maybe by 'implementation' you mean 'IPv6 protocol stack implementation'
    - Section 3.1.2 Corruption of the source IP address
    Please mention Unicast Reverse Path Forwarding, which might discard packets.
  • Barry Leiba: Discuss [2012-10-04 10:50]:
    See my DISCUSS for draft-ietf-6man-udpchecksums:
  • Stewart Bryant: Discuss [2012-10-07 20:25]:
    This discuss applies to both this draft and draft-ietf-6man-udpchecksums-04
    Fundamentally I support the liberalization of the position regarding IPv6 UDP checksums when UDP is used for tunnels and hope to get to a yes position on both drafts. However, there is some text that needs discussion, and then we need to discuss the consequences of that discussion. The rational for the slightly conservative position taken in the case of tunnels seems to based on the following text:
    'IP packets may be corrupted as they traverse an Internet path. Evidence has been presented [Sigcomm2000] to show that this was once an issue with IPv4 routers, and occasional corruption could result from bad internal router processing in routers or hosts. These errors are not detected by the strong frame checksums employed at the link-layer [RFC3819]. There is no current evidence that such cases are rare in the modern Internet, nor that they may not be applicable to IPv6. It therefore seems prudent not to relax this constraint. The emergence of low-end IPv6 routers and the proposed use of NAT with IPv6 further motivate the need to protect from this type of error.'
    However we do have a body of evidence that is not discussed in the document. Firstly we have a decade of experience with MPLS VPNs where the VPN Identifier label, which is used to steer the traffic to a particular customer network (i.e. is functionally equivalent to an address), is not protected by a checksum. I am not aware of any concerns expressed by operators in this regard, and I am not aware of any work in the MPLS WG to introduce checksum like protection.
    We also have a decade of experience with pseudowires. With one exception that we will discuss in a minute, none of the PW designs have any form of data integrity protection other than the CRC imposed by the network datalink at each hop. In the specific case of the Ethernet PW, there are two modes: one in which the CRC is stripped at ingress to the PW and recalculated at egress, and another where it is preserved end to end. There is very little, if any, deployment of the end to end CRC preservation mode. Given that there must be some low level of corruption of the frames, I would conclude that the protocols that are likely to be tunneled are sufficiently hardened that the occasional corruption is of no practical consequence.
    Thus I would conclude that the level of corruption is sufficiently rare and of sufficiently minor consequence that at least in the case of service provider networks implementing UDP tunneling, it is safe to omit the UDP checksum without analysis of the application.
    I would propose that the text should include some acknowledgement of this recent body of evidence and that the recommendation be aligned in consequence to unconditionally allow C/S free tunneling, at least within a well managed domain without additional consideration.
    Section 5.1 seems to be duplicated in the two drafts. It would be better if the text were just in one RFC and the other pointed to it.
  • Stewart Bryant: Comment [2012-10-07 20:25]:
    You also note that an application may rely on the checksum to protect it against packets that may damage it. I find this very weak argument, since such an application would be vulnerable to packets deliberately malformed by an attacker, or malformed by a software bug in a peer. The correct approach is surely to harden the application, and thus the checksum argument is not persuasive.
    You note the need to signal the agreement not to use c/s, I think that you need to include the configuration of this property as an alternative, and note that configuration may be implicit in the definition of the UDP payload.

  Telechat:

  • (discussed above)

3.1.2 Returning Items

• Content Splicing for RTP Sessions (Informational)
  draft-ietf-avtext-splicing-for-rtp [txt]
  Token: Gonzalo Camarillo (rai area)
  Note: Magnus Westerlund (magnus.westerlund@ericsson.com) is the document shepherd.
  Discusses/comments [ballot]:
  • Adrian Farrel: Comment [2012-10-08 08:05]:
    I am ballotting No Objection on this document although I am not convinced by the Security thoughts. It doesn't seem to me to be impossible to construct a three-way security arrangement for source, splicer, and destination. But maybe the point here is that the very act of splicing *is* a violaiton of the source-destination relationship. Thus the destination correctly only has a relationship with the splicer.
  • Stephen Farrell: Comment [2012-08-27 02:10]:
    Thanks for addressing my discuss points. I think the current version's truth-in-advertising approach to the fact that it breaks e2e security is much better. (Though it'd be even better if you could figure a way to do this that would not break e2e security. I'd encourage folks wanting to insert advertisements to try think about that.)
  • Martin Stiemerling: Comment [2012-10-10 02:30]:
    Thank you for addressing my concerns!
  • Pete Resnick: Discuss [2012-10-08 21:49]:
    REQ-7: There at least needs to be a forward reference to section 4.5 in this section. That said, I am still bothered by this section. The first sentence is written in the passive voice, so I can't tell what it's saying: Is it saying that splicing should not be easily detected *by the RTP receiving implementation* (in which case section 4.5 is really all that this is talking about), or is it saying that splicing should not be easily detected *by the RTP stream end-user* (in which case it's talking about section 4.3, which I think is bogus)? The second half of REQ-7 talks about both, but then goes on to say that this memo is only concerned with the RTP layer. Please rewrite this section to make it clear that you are only talking about the protocol, not the user experience.
    Section 4.3: Similar to the above, this is really all user experience, not protocol clipping. I think this section should simply be dropped.
    Section 4.5: 'User Invisibility' is not the requirement in 4.5; it is 'Receiving implementation invisibility.' Section 4.5 does not address user experience invisibility and should be re-titled.
    With regard to all of the above, if the WG insists on talking about user experience in this document, I will simply Abstain on it.
  • Benoit Claise: Comment [2012-05-10 01:55]:
    Much has been said already with the multiple DISCUSS feedback on this draft. So, no need to repeat the information: I'll trust the other ADs will take care of this one.
  • Barry Leiba: Comment [2012-10-09 11:50]:
    Thank you for the extensive work on this document since the -07 version. This is *much* clearer, and addresses all my significant concerns.
    Only one, small, non-blocking point: I suggest expanding 'SSRC' and 'CSRC' on first use.
    For the record, I have no issue with Section 4.3 -- I see nothing wrong with a non-normative section that calls out an issue (including a user-experience issue) that's likely to come up in implementations, and warns them about it. If it tried to be normative, or if it went into a lot of detail about user interface design, I might agree that it's a problem... but it doesn't, and I don't.
  • Stewart Bryant: Discuss [2012-10-07 20:43]:
    I have a concern regarding requirement 4, since in some cases exposing the content in the clear at the ad insertion point would be considered a service security vulnerability. The basis for this vulnerability seems to be the need to provide access to the keying indicators. Surely it is possible to design an out of band, or a semi-out of band, indication system and not expose the content itself to this vulnerability?
  • Robert Sparks: Comment [2012-10-09 07:22]:
    Thanks for addressing my concerns.
    Please consider adding (or pointing to) a discussion of what the impact of having a loop is.
  • Sean Turner: Comment [2012-05-10 03:48]:
    I support the discuss positions from the other ADs.

  Telechat:

  • Amy: updated this morning, version 10; couple of discusses
  • Gonzalo: Pete, authors answered re how to detect, proposed text; have you had a chance to look at it
  • Pete: still a weird question, trying to hide at RTP layer, I assume we mean no obvious sign of the change, simply protocol... 4.3 now completely about RTP, why do we have a 4.5?
  • Gonzalo: 4.3 about user (not protocol); if I understand...
  • Pete: added a paragraph to 4.3...
  • Gonzalo: you want media-clipping separate
  • Pete: if this is about user experience, it should be in an Appendix if at all; he's not answering whether he wants to do that
  • Gonzalo: I'll check with author and propose text
  • Gonzalo: Stewart, Magnus answered current security mechanisms limit what we can do
  • Stewart: I have concern, "must expect"
  • Gonzalo: for that, we'd need new security mechanism, I'll send you the email; handle via email; revised-ID needed anyway
  • Stephen: authors put in text, could be another security mechanism...

3.2 Individual Submissions Via AD

3.2.1 New Items

• (none)

3.2.2 Returning Items

• (none)

3.3 IRTF and Independent Submission Stream Documents

3.3.1 New Items

• IETF conflict review for draft-pornin-deterministic-dsa (None)
  conflict-review-pornin-deterministic-dsa [txt]
  Token: Sean Turner (ietf area)
  Discusses/comments [ballot]:
  • Stephen Farrell: Comment [2012-10-11 05:57]:
    There was a bunch of mail discussing this on the CFRG list but I'm not clear if that reached closure or not. It would be good if the ISE wanted to check with the chairs of the CFRG to see if they think there are any comments there that might usefully be addressed before this becomes an RFC. (In particular I don't think I saw the author answering those comments but perhaps he's not on the CFRG list?)
  • Pete Resnick: Discuss [2012-10-08 17:56]:
    The header of the document is as follows:

      Internet Engineering Task Force                                T. Pornin
      Internet-Draft                                           August 27, 2012
      Intended status: Informational
      Expires: February 28, 2013
    

    
    Note the 'Internet Engineering Task Force' on the top line. That's just wrong. Do we assume that the RFC Editor will fix that and I move to 'No Objection' or shall I hold the 'Discuss' until that is corrected?

  Telechat:

  • Amy: a discuss
  • Barry: Sean not here, RFCed will take care of it (no note needed)
  • Pete: I'm clearing
  • Stephen: I'd like to check with Sean, can we do point-raised
  • Amy: approved for no-problem, with point-raised
• IETF conflict review for draft-mme-trill-fcoe (None)
  conflict-review-mme-trill-fcoe [txt]
  Token: Ralph Droms (ietf area)
  Discusses/comments [ballot]:
  • Adrian Farrel: Comment [2012-10-06 04:14]:
    My Comments are by way of a mutter that I hope the ISE will note and consider for future documents on the Independent Stream. No action from the IESG or the document authors is requested.
    The ISE's note says:"This draft was discussed on the trill list, no objections to the publication of this draft in the Independent Stream were raised."
    This is probably a little simplistic. It is true that the WG was notified of the existence of the draft and offered the chance to object to publication. But the I-D was not discussed in any sense. There are a total of 3 emails about the draft in the archive and they are all notifications from the authors.
    While I don't disapprove of publication of this I-D on the Independent Stream, I have become accustomed to notes explaining why documents are presented via the ISE rather than through the working group.
  • Stewart Bryant: Comment [2012-10-09 12:10]:
    I feel that I need to know why this is an independent draft rather than a Trill draft before I am in a position to take a position on whether this is a conflict or not.

  Telechat:

  • Amy: no discusses, hearing no objection, approved, Ralph requested point-raised
  • Stewart: I believe Ralph wanted to discuss this... what happens if we end up not approving
  • Adrian: I commented for "thought by RFCed, not blocking
  • Stewart: I thought we were limited from putting a discuss on it
  • Pete: you put a discuss on the conflict-review, not on the document
  • Stewart: I would prefer the WG state they don't see a conflict
  • Russ: not clear to me it's in-charter for that WG
  • Stewart: please put a discuss (on the conflict-review) for me
  • Amy: AD-followup (or equivalent)... will stay in IESG-evaluation

3.3.2 Returning Items

• (none)

1237 EDT break

1243 EDT back

• Bernard Aboba---
• Richard Barnes--- y
• Ron Bonica--- y
• Stewart Bryant--- y
• Gonzalo Camarillo--- y
• Benoit Claise--- y
• Michelle Cotton--- y
• Ralph Droms---
• Wesley Eddy--- y
• Adrian Farrel--- y
• Stephen Farrell--- y
• Heather Flanagan--- y
• Sandy Ginoza--- y
• Brian Haberman--- y
• Joel Halpern--- y
• Susan Hares--- y
• Russ Housley--- y
• Barry Leiba--- y
• John Leslie--- y
• Cindy Morgan--- y
• Ray Pelletier--- regrets
• Pete Resnick--- y
• Robert Sparks--- y
• Martin Stiemerling--- y
• Sean Turner---
• Amy Vezza--- y

4 Working Group Actions

4.1 WG Creation

4.1.1 Proposed for IETF Review

1. (none)

4.1.2 Proposed for Approval

1. (none)

4.2 WG Rechartering

4.2.1 Under evaluation for IETF Review

1. Bidirectional Forwarding Detection (bfd)
   Token: Adrian

   Telechat:

   • Amy: no objection to external review, Adrian, does this need external review
   • Adrian: yes, change very specific to IEEE
   • Amy: hearing no objection, external review approved, back on next agenda

4.2.2 Proposed for Approval

1. Operations and Management Area Working Group (opsawg)
   Token: Benoit

   Telechat:

   • Amy: no blocking comments, hearing no objection, approved

5. IAB News We can use

• Joel: nothing to report this week, working on technical plenary and usual stuff
• Russ: I thought you would talk about retreat
• Joel: wondering if we could schedule before new members... different opinions... can we match with IESG retreat
• Russ: we said it's important to have an overlap, nearly impossible last time; thing we can only have a overlap day if we schedule early; we didn't try to nail down day/location until we knew the actual players
• Pete: know there are potential IAB members from Asia
• Russ: my belief is early-scheduling is the only way to get an overlap day; if we make a target-date known to all candidates, they could hold that day open
• Stephen: if we choose a date, and a new member can't make it, what happens?
• Russ: we can at least share the date with all candidates on the open-list
• Stewart: difficult for new members
• Barry: set up a tentative date, revise only if necessary after new members chosen

6. Management Issues

1. Approval of the IESG Statement regarding Ethertype assignments (Russ Housley)

   Telechat:

   • Russ: Glenn hasn't gotten back to me
   • Amy: we'll come back to this on the 25th

2. Early code point allocation by IESG review for BFD over LAG (Adrian Farrel)

   Telechat:

   • Adrian: BFD WG behind the curve... communicating with IEEE... we now need to revise the charter; thus we need early allocation; I've worked with Designated Expert to OK,
   • Russ: confident that MAC address allocation is OK; less confident the other will survive without change
   • Adrian: content may change, but I believe one port number will be needed anyway... these numbers have to go in hardware, will be relatively stable; thus codepoint allocations should be stable
   • Stewart: could they use Experimental
   • Adrian: no, if not burned into hardware, at least close to that
   • Stewart: what's the problem trying Experimental first
   • Adrian: less convenient... probably relatively stable; IANA, how to make this happen
   • Russ: Adrian write the note, Secretariat will send it
   • Michelle: template for port number; I'll check on the other one
   • Amy: discussed, IESG approved early allocation, will send note to IANA when Adrian forwards it

3. Designated Expert for RTP RTCP Control Packet Types (PT) [IANA #615825] (Michelle Cotton)

   Telechat:

   • Michelle: need expert, can an AD review now until we appoint
   • Robert: talked with (two names), think we should appoint both; for this request, the specification is not yet stable
   • Michelle: what note will come from Secretariat
   • Robert: not approved _yet_
   • Amy: note to IANA appointing (two names); and this request not approved _at_this_time_

4. Joint CCAMP / ITU-T SG15 Q6 meeting in Orlando (Adrian Farrel)

   Telechat:

   • Adrian: control plane work... flexible grid wavelength... data-plane still being worked on in another group, desire for joint meeting, Orlando would work well; suggestion to run on final Friday of that IETF week; my understanding if we formally ask Secretariat, they can arrange room, cost covered by IETF; how do we handle participants who want to attend CCAMP part
   • Russ: some of them get a free pass; others could use day-pass
   • Adrian: if they organize a meeting, generally a sponsor carries the cost, neither they nor we would pay; expect the order of 15 people
   • Russ: if they only go to that session, I'm willing to accept that; but if they attend other sessions, they should pay our registration fee; I'd like to talk with Alexa on the logistics
   • Pete: it amounts to a day-pass for Friday: they spend the entire day in those sessions
   • Stewart: if IEEE ran this "next door" there would be no charge
   • Pete: I'm not talking the charge, but how to handle the registration
   • Stewart: sometimes, they do charge for the room
   • Russ: roughly $5,000 -- a sponsor for the room would probably pay that -- is there a sponsor to cover 15 day-passes?
   • Adrian: I'll take an action item to talk with the folks, and coordinate with Secretariat; and look into sponsor
   • Stewart: what NoteWell
   • Adrian: in morning, IETF NoteWell, in afternoon ITU-T NoteWell;
   • Stewart: is there a problem with a person not employed by sector member attending the afternoon
   • Adrian: the whole IETF is invited
   • Amy: discussed, action item for Adrian

5. Appoint a designated expert for the Structured Syntax Suffix registry (Barry Leiba)

   Telechat:

   • Barry: media-type stuff; recommend Ned Freed; any opposed?
   • Amy: discussed, approved Ned Freed, Secretariat will send note to IANA

6. Moving RFC 4743 to HISTORIC status (Benoit Claise)

   Telechat:

   • Benoit: no feedback on LastCall
   • Russ: roll-call here: (all no-obj except yes by Stephen)
   • Russ: minutes to show approved, Secretariat will send note to community and RFCed
   • Amy: will send protocol action probably Tuesday

7. Moving RFC 4744 to HISTORIC status (Benoit Claise)

   Telechat:

   • Amy: the same situation
   • Russ: would anyone enter a different ballot position for moving this document to historic? hearing none, please record the same ballot positions and take the same action
   • Amy: carbon-copy of the previous item

8. Does the IESG wish to provide comments to ICANN on Global Policy for Post Exhaustion IPv4 Allocation Mechanisms (Russ Housley)

   Telechat:

   • Russ: I saw no email, what are we thinking? do we want to provide comment? I take silence to mean we don't want to; minutes to show discussed
   • Michelle: individuals can comment in public-comment period
   • Russ: add, IESG decided not to comment as a group

9. Reclassify HTTP status code 425 as "Unassigned" (Barry Leiba)

   Telechat:

   • Barry: credible request to rescind an early allocation which was never used, nothing in policy on how to rescind
   • Russ: what is the value of "never" in "never used"; in the past, we have sent a note to community, we're considering this action...
   • Barry: should I send out such a note?
   • Russ: needs to come from Secretariat as a four-week LastCall
   • Barry: I will send note to Secretariat
   • Amy: discussed, official LastCall to go out, text from Barry, come back in November

10. Designated Expert for RFC3230 (HTTP Digest Algorithm Values) [IANA #615445] (Michelle Cotton)

    Telechat:

    • Michelle: Barry responded... can be either Expert or RFC... requester requested "as specified in RFC 1950"
    • Barry: two things, RFC 3230 said "stable specification, but FCFS"; I think the IANA rule should make it clear that RFCs don't need to be reviewed by the Expert; but in this case, Expert should review
    • Michelle: this is an after-the-fact assignment, we will have Expert review (just) this one; and we will change the procedure required to "RFC Required of Specification Required"

7. Agenda Working Group News

• Pete Resnick (Apps)--- ??, publish what they have as Informational
• Robert Sparks (RAI)--- no
• Martin Stiemerling (Transport)--- no
• Sean Turner (Security)---
• Ron Bonica (O & M)--- nothing
• Stewart Bryant (Routing)--- no WG, but SIDR prefix-validate now approved, RFCed note set
• Gonzalo Camarillo (RAI)--- nothing
• Benoit Claise (O & M)--- no
• Ralph Droms (Internet)---
• Wesley Eddy (Transport)--- not today
• Adrian Farrel (Routing)--- MPLS-TP progress discussed
• Stephen Farrell (Security)--- ?? WG, discussion of ??
• Brian Hamerman (Internet)--- LISP WG agreed to deliver existing charter items before adding more
• Russ Housley (General)--- proposed update on text re withdrawal of I-D, I'd like email responses by tomorrow
  Pete: new text is significant change
  Barry: traded for a more general thing, have to read it again
  Russ: trying to say this won't be done lightly
  Pete: I prefer this to the other alternative; consider making in stream-specific?
  Russ: what about draft-surname? this is a historical record, please don't mess with it without good reason
• Barry Leiba (Applications)--- nothing

1347 EDT Adjourned

Appendix: Snapshot of discusses/comments

(at 2012-10-11 07:30:02 PDT)

draft-ietf-storm-iscsi-cons

• Stephen Farrell: Discuss [2012-10-09 09:12]:
  

  (1) Is IPsec mandatory to implement or not? While it might
  be ok to omit that detail for an initiator running on a
  standard OS, it needs to be clear for e.g. a LUN that runs
  on an embedded OS.
  
  (2) p153, 2nd last para: how can an implementation above
  TCP verify that IPsec encryption is being used?  Same at
  the end of setion 9.3.
  
  (3) Why are sections 2.4.x and the intro to 11 both needed?
  Do they even say the same thing? Having text like that
  twice is bad. Section 11 seems clearer.
  
  (4) If there is a conflict between the text in section
  11/12/13 and earlier text, which wins? Where's that stated?
  I think you need that given how much overlap there is.
  
  (5) 12.1.1: how are the krb-ap-req & rep encoded? Those are
  binary messages. I don't get how that's handled.  (Same for
  12.1.2)

• Stephen Farrell: Comment [2012-10-09 09:12]:
  

  - There's a lot of repetition which is a pain in such a
  long document. That's a pity.
  
  - This is too long. It may have seemed like a good plan
  to merge a lot into one document, but this goes beyond
  what's useful IMO.
  
  - There seem to be many cases of terms being used that are
  not (well) defined.  4.2.3.2 refers to [SPC3] for "task
  set" which is the basis for a bunch of definitions I can't
  understand, not having access to [SPC3].  And for example,
  response fencing is all over section 4 but never defined. I
  think a general pass for this probably would be worthwhile.
  
  - Can you explain how a 2nd TCP connection for a session is
  as secure as the first? I think that the login phase has to
  be repeated but wasn't sure.
  
  - 4.2.5 says that a connection is in full feature phase if
  some (possibly other) connection has successfully passed
  through the login phase. That seems to imply that only IP
  level security can work for iSCSI (since TLS would be
  connection specific) and that MPTCP couldn't be just
  substutited for TCP. Is that correct? Where is that stated?
  
  - 6.3.5 - I don't quite get the security model for session
  reinstatement. It appears to be the case that if any user
  that can login (if that's needed) could guess and ISID then
  they could take over someone else's session - is that
  right?  If not, what prevents that occurring? If so, where
  does it say that ISID's MUST/SHOULD be hard to guess?
  
  - Is it clear how iSCSI names are mapped to X.509 certs
  used in IPsec?
  
  - Just wondering if anyone's look at the recovery features
  to check if flipping a bit in an ecrypted packet could
  trigger any bad behaviour?
  
  - section 7: What if IPsec goes wrong? Any specific
  recovery for that?
  
  - p158/9 is it not now time to make 3DES a SHOULD and AES a
  MUST?
  
  - CHAP has some weaknesses, but MUST only be used here when
  sent via IPsec, is that correct? How would an
  implementation know that IPsec is in use?
  
  From the secdir review [1]:
  
  - 9.3.1 - RFC 2404 defines HMAC-SHA-1-96 not HMAC-SHA1.  is
  the reference correct?
  
  - 4.2.3.2. Notion of Affected Tasks, LOGICAL UNIT RESET:
  All outstanding tasks from all initiators for the LU
  identified by the LUN field in the LOGICAL UNIT RESET
  Request PDU.  Are there any access control facilities for
  this operation?
  
  (Please also consider the other comments from the secdir
  review as well.)
  
     [1]
  http://www.ietf.org/mail-archive/web/secdir/current/msg03556.html
  
  nitty comments
  
  - abstract: funny use of "standardized" - isn't that what
  we're doing here?
  
  - abstract: "difference in semantics" isn't all, I assume
  this wins for all differences incl. syntax, prose etc.
  
  - There's a lot of repetitive text. I think I read about
  the direction of transfer 4-5 times in the first 30 pages.
  
  - 2.2, initiator name: "woldwide unique" hmm, odd phrase.
  What if a node is on the ISS or the Moon? Or if you have a
  bad PRNG? (CHECK)
  
  - 2.2, NAA - could I implement this without access to
  [FC-FS3]? That appears to be a paywalled spec - is it?  I
  guess there are others too.
  
  - 2.2, "Recovery R2T" is defined by not R2T (and R2TSN is
  used inside the definition)
  
  - 2.2, "Third-party" - this definition is not
  understandable.
  
  - 4.2.2.3.2, "response fence" is used without definition
  
  - 4.2.2.3.3, "I_T_L nexus" isn't defined.
  
  - 4.2.2.3.4, what is a FastAbort? a TaskReporting key?
  what are UA, TMF, ACA...
  
  - At this point I gave up on noting use of undefined terms.
  ("TTT" was the straw for this camel's back:-)
  
  - 4.2.4, saying that a security association can be built in
  "many different" ways is a bad idea. Surely the only ways
  are those for which you have defined mechanisms?
  
  - 4.2.4, "The login PDU includes..." why is it enough to
  say what this includes without specifying precisely what it
  is? (I include carbon atoms but am not a diamond;-)
  
  - 4.2.5, "...is authorized to do so..." is vague. I think
  you mean something succeeded but you've not defined what.
  
  - 4.2.5.2, you don't say how the length of the first
  unsolicited burst can be negotiated.
  
  - 4.6.2 is an odd section with no text and just one 4 line
  subsection. So is section 5. If you're following the
  structure of some other document(s) it'd be nice to say
  which. (If you did, I've already forgotten;-)
  
  - section 6, is the continuation bit "C" really needed when
  sending over TCP?
  
  - p95, "new public keys" registerded with IANA trips up the
  crypto geek in me:-) suggest s/public// and the same with
  "private key"
  
  - 9.2.2: is SRP really in use with iSCSI? If not, it'd
  probaly be good to say so.
  
  - p213, I don't get what Parameter1,2,3 are.

• Pete Resnick: Comment [2012-10-10 13:32]:
  

  2.2:
  
    - SCSI Port Name: A name made up as UTF-8 characters and includes
    the iSCSI Name + 'i' or 't' + ISID or Portal Group Tag.
  
  s/made up as/encoded as
  
  4.2.3.5:
  
     If the issuing session is a FastAbort session, the iSCSI target
     implementation is FastAbort-capable, and the third-party affected
     session is an RFC 3720 session, the following behavior MUST be
     exhibited by the iSCSI target layer: Asynchronous Message PDUs
     MUST NOT be sent on the third-party session to prompt the
     FastAbort behavior.
  
  I don't understand what counts as "following" in "the following behavior MUST
  be exhibited". Why not simplify to:
  
     If the issuing session is a FastAbort session, the iSCSI target
     implementation is FastAbort-capable, and the third-party affected
     session is an RFC 3720 session, the iSCSI target layer MUST NOT
     send Asynchronous Message PDUs on the third-party session to prompt
     the FastAbort behavior.
  
  Is there something else "following" that needs to be accounted for?
  
  (The following is about text that was in the original document. Because of
  that, I will not put a DISCUS on this, but gee would I like to see this
  clarified.
  
  4.2.7.1 says:
  
       - iSCSI names are composed only of displayable characters.
         iSCSI names allow the use of international character sets
         but are not case sensitive. No whitespace characters are
         used in iSCSI names.
  
  and 4.2.7.2 says:
  
       - It is in Normalization Form C (see "Unicode Normalization
         Forms" [UNICODE]).
  
       - It only contains characters allowed by the output of the
         iSCSI stringprep template (described in [RFC3722]).
  
  "not case sensitive" in 4.2.7.1 is weird. That would seem to imply that you
  *can* have uppercase characters, but that they compare equally to lowercase
  characters. But 4.2.7.2 (and in particular 3722) says that it's only going to
  be lowercase. Something seems amiss. Do you mean only ASCII characters are
  compared case-insensitively?
  
  All this said, I am bummed that we didn't get PRECIS far enough along to
  include in this version. Ah, well.

• Benoit Claise: Comment [2012-10-10 16:43]:
  

  I am voting no objection on the basis that a quick review indicates no
  implications for OPS for this draft, and that the OPS aspects will be covered
  in draft-ietf-storm-iscsimib.

• Barry Leiba: Comment [2012-10-10 12:56]:
  

  I haven't been able to give this a full review.  Some non-blocking comments
  here, based on what I've had time to cover.  If I get more before tomorrow's
  telechat, I'll add them and re-send this.
  
  -- Section 4.2.4 --
     To protect the TCP connection, an IPsec security association MAY
     be established before the Login request.
  
  Related to Stephen's DISUCSS point (1), why is *use* of IPSec a MAY?  It's
  clear to me why neither authentication nor connection-level security is always
  needed (for example, using iSCSI to access a read-only repository of public
  information), so performing login is a SHOULD.  Why isn't IPSec also SHOULD?
  
  -- Section 6.1 --
  You give Unicode code points for the non-alphanumeric characters, but not for
  the alphanumeric ones.  Just to be complete, and to recognize that there are
  multiple Unicode characters that look like "a", for example, you should
  probably do this:
  
  OLD
     (a-z, A-Z) - letters
     (0-9) - digits
  NEW
     (a-z, A-Z) (0x61-0x7a, 0x41-0x5a) - letters
     (0-9) (0x30-0x39) - digits
  
  Consider whether RFC 4648 would be a better reference for base64 encoding than
  RFC 2045.
  
  I see that Mallikarjun and Alexey are engaged in conversation about Alexey's
  AppsDir review, with resultant changes.  And my esteemed colleague from
  Illinois has said that he's covering the stringprep stuff and related issues. 
  Apart from that, I don't see any App-layer issues raised here, and trust that
  the ADs at the lower layers will handle those.

• Stewart Bryant: Comment [2012-10-07 20:50]:
  

  I am voting no objection on the basis that a quick review indicates no
  implications for the routing system.

• Brian Haberman: Discuss [2012-10-09 13:40]:
  

  * In section 4.2.2.3.4, the first paragraph states : "This Section lists the
  situations in which fenced response behavior is REQUIRED in iSCSI target
  implementations. However, this is not an exhaustive enumeration."
  
  Is the list of use cases exhaustive as currently known within the existing
  implementations?  If it is, the second sentence is not needed.  No one should
  expect a spec to be able to address use cases created after its publication. 
  If it is not, why not?
  
  * Section 6.2 states : "The proper way to handle a NotUnderstood response
  depends on where the key is specified and whether the key is declarative vs.
  negotiated. An iSCSI implementation MUST comprehend all text keys defined in
  iSCSI Protocol specifications from RFC 3720 through the RFC associated with the
  highest protocol version that the implementation has offered (or has
  negotiated, in the case of an acceptor) for the iSCSIProtocolLevel key in a
  negotiation.
  
  If I understand all of the relevant RFCs and this draft, iSCSIProtocolLevel is
  still 1.  Is there a spec for level 0?  I am unsure why this draft would
  reference back to 3720, when it is making that RFC obsolete and subsuming all
  of its functionality.  The above text is making assumptions about what future
  iSCSI specifications may or may not require.  Why is the requirement for
  handling NotUnderstood responses not more concrete and contained within this
  spec?
  
  * This spec states that it is updating RFCs 3721 and 3723.  If that is the
  case, why is RFC 3721 listed as an Informative reference while 3723 is a
  Normative reference?

• Brian Haberman: Comment [2012-10-09 13:40]:
  

  * The text in section 2.3 is useful, but it does not discuss what is being
  updated in RFCs 3721 and 3723.
  
  * The References section is un-numbered and not included in the TOC.
  
  * Section 4.2.7 makes a reference to SLP.  The acronym is not expanded and RFC
  2608 is not referenced.
  
  * Section 4.2.7.3 (way minor typo) : s/assists.in/assists in/
  
  * Section 9.4 : s/wellknown/well-known/

• Sean Turner: Discuss [2012-10-10 08:15]:
  

  CHAP has long been known to be vulnerable to dictionary attacks (prior to '07).
   You've got considerations for how to use it, but can we please put something
  in to support will be dropped in the next version?

• Sean Turner: Comment [2012-10-10 08:15]:
  

  I support Stephen's discuss positions.

draft-ietf-fecframe-ldpc

• Russ Housley: Comment [2012-10-08 08:08]:
  

    Please consider the comments provided in the Gen-ART Review by
    Meral Shirazipour on 1-Oct-2012.  You can find it here:
    http://www.ietf.org/mail-archive/web/gen-art/current/msg07805.html

• Stephen Farrell: Discuss [2012-10-11 04:56]:
  

  
  I'm confused that there's no IPR declaration given that RFC
  5170 has a bunch, yet is a normative reference that defines the
  actual mechanism used here, yet the writeup says "there is no
  IPR." How's that possible?
  
  Maybe this is really a DISCUSS-DISCUSS about transitive IPR
  declarations, but I'm not sure because of the write-up. If its
  considered ok that implemeters of this will have to read and
  thus be aware of the IPR in 5170, then I guess I'll clear but
  I figure its best to ask.

• Pete Resnick: Discuss [2012-10-10 18:22]:
  

  I plan to clear on the telechat given an appropriate response; this is more for
  the shepherd than for the authors:
  
  The document writeup says:
  
     There is consensus within the FECFrame WG to publish this document.
  
  But this gives no explanation as to why FECFrame wishes to publish this
  document. No answer in the shepherd report was given to the question of whether
  there are implementations of this protocol or whether there is interest by
  potential implementers in this work. The only references appear to be to
  research in this area, not an actual requirement for interoperability. Is there
  any interest in actually implementing this protocol, or is this simply another
  academic publication without community interest?

• Barry Leiba: Comment [2012-10-02 16:24]:
  

  I have no objection to this document, and no blocking comments.  These are
  non-blocking, but please consider them seriously, and feel free to chat with me
  about them:
  
  Throughout:
  All of the "MAY" words in here seem wrong: they're describing conditions that
  might exist, not specifying directives for making choices (unless I'm
  mis-reading it).  You MUST consider various things when you construct an ADU
  block.  One of those various things may or might (but not MAY) be factor A.  I
  think all the "MAY"s in the document should be lower case (or be replaced by
  "might"):
    - the target use-case MAY have real-time constraints
    - [the real-time constraints] MAY define a maximum ADU block size
    - a codec MAY impose other limitations on the maximum source block size
    - The source ADU flows MAY have real-time constraints.
    - Reed-Solomon codes or 2D parity check codes MAY be more appropriate.
  
  -- Section 8 --
     Values of FEC Encoding IDs are subject to IANA registration.
     [RFC6363] defines general guidelines on IANA considerations.  In
     particular it defines a registry called FEC Framework (FECFRAME) FEC
     Encoding IDs whose values are granted on an IETF Consensus basis.
  
  IANA notes that "IETF Review" is the right term and suggests changing this.  I
  suggest just removing the paragraph; it's not necessary, and it doesn't seem to
  have any value at all.  You can move the reference to RFC 6363 to the next
  paragraph, which can otherwise remain as it is.

draft-ietf-manet-olsrv2

• Stephen Farrell: Discuss [2012-10-11 05:12]:
  

  Why are "guidelines" for securing OLSRv2 sufficient and how
  does that meet BCPs 61 and 107? ROLL has been stuck on this due
  to punting on the defintion of key management mechanisms and
  lots of work is having to be done to retro-fit security for
  routing in sidr and karp so why is it ok for us to perhaps make
  the same mistake (punting on security for routing) again?
  
  Is there even a proof-of-concept that OLSRv2 can be used with
  RFC6622 TLVs to produce a "secure" solution for routing in at
  least some MANETs?
  
  If there were at some "SHOUL implement" statements about some
  flavour of use of RFC6622 and where an accompanying key
  managment solution actually exists then this might be fine, but
  as-is, it looks like nobody is going to get interop for
  security without more work being done, and experiene with ROLL
  seems to show that getting that done can be hard to impossible.

• Martin Stiemerling: Discuss [2012-10-10 08:26]:
  

  This is a good document and I do not object in principle to the publication of
  the document.
  
  However, there is a broader question about congestion potentially caused by
  this which isn't addressed in the document, especially not since it is on the
  Standards Track.
  
  Everything in OLSRv2 about congestion control is copied from RFC 3626. RFC 3626
  is Experimental,  so far so good.
  
  1) Is there any guidance on congestion avoidance and control that was learned
  from deployments of RFC 3626?
  
  2) The timers for the Message Interval Parameters (TC_INTERVAL and
  TC_MIN_INTERVAL) are fixed to o  TC_INTERVAL := 5 seconds o  TC_MIN_INTERVAL :=
  TC_INTERVAL/4 Is there any recommendation to change the values for very low
  bandwidth links? Such as being used in MANETS? The point is that on very low
  bandwidth links the messages carrying the OSLRv2 information could already take
  most of the share of the available bandwidth.
  
  3) What would be the recommendation to an OLSRv2 instance experiencing
  congestion? And the resulting effects for the routing.

• Pete Resnick: Comment [2012-10-10 18:12]:
  

  Throughout the document, there are references to assorted "time" values, but
  nowhere that I can find is there an explicit granularity requirement. Is the
  granularity documented elsewhere and therefore so obviously understood to be
  seconds by the MANET community that it is not worth mentioning in this
  document? If not, it might be worth mentioning.
  
  I find all of the MUSTs and MAYs in the definitions of section 2 weird. For
  example:
  
        A router MUST be able to distinguish a routable address
        from a non-routable address by direct inspection of the network
        address, based on global scope address allocations by IANA and/or
        administrative configuration.  Broadcast and multicast addresses,
        and addresses which are limited in scope to less than the entire
        MANET, MUST NOT be considered as routable addresses.  Anycast
        addresses may be considered as routable addresses.
  
  I'm trying to figure out what it would mean for a router to be unable to
  distinguish routable from non-routable addresses. What are the interoperability
  considerations here? "Considering broadcast and multicast addresses as
  routable" seems problematic in general, not just for this protocol. Aren't you
  simply saying that routers that implement this protocol will need to
  distinguish routable and non-routable addresses? Either way, why is this
  protocol instruction in the definitions section? Sounds like it should be in a
  "Basic Requirements" section if it needs to be a protocol requirement.
  
  5.1
  
     TC messages and HELLO messages [RFC6130] MUST, in a given MANET, both
     be using the same of either of IP or UDP, in order that it is...
  
  Don't you mean, "TC messages and HELLO messages [RFC6130] will all use either
  IP or UDP in a given MANET in order that it be..."? I don't see what the MUST
  is doing in this sentence. The sentence is a statement of fact, not a protocol
  directive.
  
  16.3.3.1 - 16.3.3.4: "The router MUST update its...". I always find MUSTs of
  this sort weird. It's not really a protocol requirement to update the internal
  state of the router. It's the behavior of the router that's the protocol
  requirement. These probably simply don't need MUSTs, though perhaps rewording
  is in order. But these sorts of MUSTs seem to appear throughout sections 7
  through 12 anyway (requirements for local implementation of information bases),
  so perhaps this ship has sailed long ago in the MANET work.

• Barry Leiba: Discuss [2012-10-07 14:55]:
  

  This is a very well written, clear document.  Despite its length (or perhaps
  because of it), it was very easy to understand, even for an Apps guy.  I'll be
  happy to enter a "yes" ballot after discussing one concern:
  
  -- Section 16.3.1 --
     A router MAY recognize additional reasons for identifying that a
     message is invalid.  An invalid message MUST be silently discarded,
     without updating the router's Information Bases.
  
  Does this cause any interoperability artifacts?  It seems to be saying that I
  can consider a message invalid for any reason I decide to come up with, and
  therefore silently discard any message for basically any reason.  Is that
  right?  If there are some criteria or limitations relating to those additional
  reasons, it'd be helpful to give them.  If it really is at a whim, how does
  that work?  (I see that Section 23.2 suggests some additional reasons, but this
  section just seems to leave it entirely open.)
  
  I understand that this might just be a quality of implementation issue: if your
  router picks bogus reasons for discarding otherwise-valid messages, it'll suck
  and no one will use it.  In that case, is there a way that such a rogue router
  could be used to attack or DoS a MANET?

• Barry Leiba: Comment [2012-10-07 14:55]:
  

  I also have a few non-blocking comments that I'd like you to consider, and to
  feel free to chat with me about.
  
  It seems odd to me that this document doesn't Obsolete 3626.  Can you tell me
  why it doesn't?  Is it expected that people will continue to experiment with or
  otherwise use OLSR (v1) after OLSRv2 is published as a Proposed Standard?
  
  -- Section 3 --
  This isn't really an Applicability Statement, at least not in the sense
  described in RFC 2026, Section 3.2.  This is a list of features of this
  protocol.  It's a fine section to have in here, but it doesn't talk about how
  this protocol can be used in any particular situations.
  
  -- Section 5.1 --
     This protocol specifies TC messages, which are included in packets as
     defined by [RFC5444].  These packets MAY be sent either using the
     "manet" protocol number or the "manet" UDP well-known port number, as
     specified in [RFC5498].
  
  I don't think this is the right use of "MAY".  As I read it, it says that use
  of either the protocol number or the port number is entirely optional.  You
  might well do neither, as you please.  Somehow, I don't think that's what you
  mean (though I've been wrong before, so just tell me so).  I think you really
  want a "MUST" here: if those are the only two choices, and you MUST pick one or
  the other, then MUST is your guy.
  
  The next paragraph after that is a little malformed, "the same of either of" is
  very awkward.  I think you mean this, yes?: NEW
     TC messages and HELLO messages [RFC6130] MUST, in a given MANET,
     either both be using IP or both be using UDP, in order that it is
  
  -- Section 5.4.3 --
     o  If TLVs with Type = INTERVAL_TIME, as defined in [RFC5497], are
        included in TC messages, then TC_INTERVAL MUST be representable as
        described in [RFC5497].
  
  Two questions on this:
  1. As described *where* in RFC 5497.  I think it's Section 5, but I had to look
  around.  Please say that ("as described in [RFC5497], Section 5," or wherever).
  
  2. TC_INTERVAL is a number -- what does it mean for it *not* to be
  "representABLE" as described there?  Do you mean that it must be "representED"
  that way?  Or something else?
  
  (1) and (2) also apply to T_HOLD_TIME in 5.4.4.
  
  -- Section 5.4.8 --
     A MANET using
     this protocol with too many routers having either willingness value
     equal to WILL_NEVER will not function; it MUST be ensured, by
     administrative or other means, that this does not happen.
  
  Well said.  But is there any guidance that will help determine what "too many"
  means?  Any way to recommend (non-normatively) some percentage of routers that
  need to be willing to be selected as flooding and routing MPRs?  Or if not
  percentage, then at least some other quantitative guidance?
  
     The following constraints apply to these parameters:
     o  WILL_FLOODING >= WILL_NEVER
     o  WILL_FLOODING <= WILL_ALWAYS
     o  WILL_ROUTING >= WILL_NEVER
     o  WILL_ROUTING <= WILL_ALWAYS
  
  This is a take-it-or-leave-it comment: we often use this mechanism to indicate
  this sort of "this value must be in between these other two" relationship, and
  I think it makes the relationship even clearer:
  
     The following constraints apply to these parameters:
     o  WILL_NEVER <= WILL_FLOODING <= WILL_ALWAYS
     o  WILL_NEVER <= WILL_ROUTING <= WILL_ALWAYS
  
  This also could apply to 5.4.3:
  
     The following constraints apply to these parameters:
     o  TC_INTERVAL > 0
     o  0 <= TC_MIN_INTERVAL <= TC_INTERVAL
  
  -- Section 6.1 --
     Link metrics are reported in messages using a compressed
     representation that occupies 12 bits, a 4 bit field and an 8 bit
     field.
  
  This sounds like it's three things.  I think you mean this:
  
  NEW
     Link metrics are reported in messages using a compressed
     representation that occupies 12 bits, comprising a 4 bit
     field and an 8 bit field.
  
  -- Section 7.2 --
     The
     Local Attached Network Set is not modified by this protocol.  This
     protocol MAY respond to changes to the Local Attached Network Set,
     which MUST reflect corresponding changes in the router's status.
  
  The last line invites imprecision and uncertain interpretation as to the
  antecedent of "which".  What is it that MUST reflect corresponding changes in
  the router's status?
  
  - Is it the Local Attached Network Set?  That doesn't seem right, because you
  just said that it's not modified here, so a new MUST can't be applied to it,
  can it?
  
  - Is it the *changes* to the Local Attached Network Set?  That doesn't seem to
  make semantic sense; how can it be changes that reflect corresponding changes?
  
  - Is it this protocol?  That makes sense, but doesn't come out of the sentence
  that's written.
  
  Can you re-write these sentences to make this clearer?  And then I presume that
  the "it" at the start of the next sentence is "The Local Attached Network Set".
  
  -- Section 14.3 --
  
  The logic here seems to be (if I'm reading it right):
  
  if (1) then discard
  else (2) {
     if (2.1) then discard
     else (2.2) {
        do 2.2.1
        if (2.2.2) then discard
        else {
           if (2.2.3) {
              do 2.2.3.1
              do 2.2.3.2
              do 2.2.3.3
           }
           else *** there is no else ***
        }
     }
  }
  
  What must happen when the "otherwise if" in 2.2.3 is not true?
  
  -- Section 16.2 --
     When sending a TC message in response to a change of advertised
     network addresses, a router MUST respect a minimum interval of
     TC_MIN_INTERVAL between generated TC messages.  Sending an incomplete
     TC message MUST NOT cause the interval between complete TC messages
     to be increased, and thus a router MUST NOT send an incomplete TC
     message if within TC_MIN_INTERVAL of the next scheduled complete TC
     message.
  
  The first part of the second sentence confused me for a while, and it wasn't
  until I started typing this comment that I think I figured it out.  You're
  saying that if you send an incomplete TC message when a complete TC message
  would be expected in less than TC_MIN_INTERVAL from now, then the complete TC
  message would be required to wait, and that would be bad -- so don't do that. 
  Is that right?
  
  I think that second sentence is hard to understand as written (at least, it
  took me several readings and some intervening misunderstandings), and I wonder
  if you can try to re-phrase it.
  
  -- Appendix D --
  I worry slightly that this appendix is normative, but comes after three
  non-normative example appendixes.  Perhaps that's fine, and I worry
  unnecessarily.  Would it be at all worthwhile to say something where Appendix D
  is cited, in the first bullet in Section 22 ?  Maybe something as simple as
  adding the word "normative"?: "All updates to the elements specified in this
  specification are subject to the normative constraints specified in [RFC6130]
  and Appendix D."

draft-ietf-6man-dad-proxy

• Stephen Farrell: Discuss [2012-10-11 04:46]:
  

  Does the deployment model for this actually fit the SAVI
  charter which is limited to systems on the same IP link? Its
  not clear to me that it does, and if it doesn't then I'm not
  sure how SAVI "MAY be used" to protect against address
  spoofing. (It could be that this does fit with SAVI, I'm just
  not sure.)

• Stephen Farrell: Comment [2012-10-11 04:46]:
  

  
  - The last sentence in the abstract confused me, what's
  "this last one" mean?
  
  - I agree with Martin and Sean's DISCUSSes.

• Martin Stiemerling: Comment [2012-10-09 05:44]:
  

  1)
  I have no general concern about the publication of the draft, but I doubt that
  it is for the Internet in general.
  
  It is more adding support for a very specific set of deployments, e.g., DSL
  access networks. This is somehow stated in the abstract "point-to-multipoint
  architecture with "split-horizon" forwarding scheme." but it is hard to
  understand and the proposed solution probably does not work in other settings
  that use the same description or claim similar ground.
  
  Can we add a more specific wording right upfront that this is primarly for
  "Digital Subscriber Line (DSL) and Fiber access architectures" as noted in
  Section 2?
  
  This would also be inline with the rest of the document which uses very
  specific terminology out of broadband access networks, e.g., BNG. The Internet
  itself does not has BNGs, but routers or first hop routers (AKA BNG in this
  context)
  
  Also in this context:
  Section 3.2., paragraph 3:
  
  >    As the BNG must not forward link-local scoped messages sent from a
  >    CPE to other CPEs, ND Proxy cannot be implemented in the BNG.
  
    This seems to be the restriction of a very specific deployment
    scenario, but is not a limitation per se. Other people could allow this in
    their architecture.
  
  2)
  Section 4.1., paragraph 1:
  
  >    A BNG needs to store in a Binding Table information related to the
  >    IPv6 addresses generated by any CPE.  This Binding Table MAY be
  >    distinct from the Neighbor Cache.  This must be done per point to
  
    This 'MAY' does not look correct here, but a 'can' would just do the job,
    as this is implementation specific, isn't it?
  
  3)
  Appendix A., paragraph 1:
  
  >    This appendix contains a summary (cf. Table 1) of the actions done by
  >    the BNG when it receives a DAD based NS (DAD-NS) message.  The
  >    tentative address in this message is IPv6-CPE1 and the associated
  >    Link-layer address is Link-layer-CPE2.  The actions are precisely
  >    specified in Section 4.2.
  
    Is this appendix normative or not? What takes precedence: the text or the
    table?

• Barry Leiba: Discuss [2012-09-28 12:07]:
  

  Section 6.1
     To keep the same level of security, Secure Proxy ND Support for SEND
     [RFC6496] SHOULD be used and implemented on the BNG and the CPEs.
  
  SHOULD, and not MUST?  How is it possible to "keep the same level of security"
  with SEND if you *don't* use Secure Proxy ND Support?

• Sean Turner: Discuss [2012-10-04 14:28]:
  

  s6.1, para 1: When won't using SEND without a proxy break the security?  I
  think what you're trying to say is that using plain old SEND won't work you've
  got to use SEND with the proxy - right?

• Sean Turner: Comment [2012-10-04 14:28]:
  

  1) Is the word "proxy" missing from the following in the abstract:
  
   The document describes a mechanism allowing the use of Duplicate
   Address Detection (DAD) by IPv6 nodes in a point-to-multipoint
   architecture with "split-horizon" forwarding scheme.
  
  s1 use "proxy" after DAD and then s1 para 2 says:
  
    This document explains also why DAD mechanism [RFC4862] cannot be
    used in a point-to-multipoint architecture with "split-horizon"
    forwarding scheme (IPv6 over PPP [RFC5072] is not affected).
  
  And could we make it clear that a proxy is needed:
  
    This document explains also why DAD mechanism [RFC4862] without a proxy
    cannot be
    used in a point-to-multipoint architecture with "split-horizon"
    forwarding scheme (IPv6 over PPP [RFC5072] is not affected).
  
  2) s4.2: Some minor wording tweaks because I don't know what the MUST pertains
  to:
  
  OLD:
  
    perform actions depending on the information in the Binding Table.
  
  NEW:
  
    perform actions specified in the following sections based on
    the information in the Binding Table.
  
  3) s4.2.1/s4.2.2: What happens if the BNG does reply/forward?
  
  4) s4.1/s4.2.2: Is the neighborhood cache in s4.2.2 the same thing as the
  binding table in s4.1?
  
  5) s4.2.3.2: L2 header: Which link-layer address is returned to CPE2?  Is it
  it's own or the one from CPE1?
  
  6) s6.1: Agree with Barry's SHOULD vs MUST discuss.
  
  7) s6.2: r/To ensure a protection/To ensure protection
  
  8) s6.2: not sure you really need the MAY.  Maybe r/MAY/can

draft-ietf-v6ops-ivi-icmp-address

• Wesley Eddy: Comment [2012-10-10 18:29]:
  

  It seems like "Updates: 6145" might be considered, and I support Robert's
  question regarding BCP vs PS in that respect.

• Ralph Droms: Comment [2012-10-11 05:06]:
  

  I understand that the third paragraph of section 3.1 states that the
  address translation should provide additional information about the
  source address, and suggests that a pool of IPv4 addresses could be
  used to provide that additional information.  Yet, the mechanism
  described in section 5 randomly chooses an IPv4 address from a pool of
  IPv4 addresses.  I don't see how the random selection of the IPv4
  address provides any information.  I recognize that the IPv6 source
  address is carried in the ICMP extension.
  
  If the IPv4 address is chosen at random from a pool of addresses, what
  is the advantage over just using, as suggested in section 4, a single
  IPv4 address as the source address in all translated ICMP messages?
  
  In the interests of matching what I would think of as the meaning of
  the title and the actual mechanism, I would call this mechanism a
  "random selection mechanism".  There is no mapping, as I would
  understand the word, involved.
  
  If, on the other hand, the pool were composed of IPv4 addresses that
  in some way convey topology information to the receiver, and the
  IPv4 source address were chosen based on the non-translatable IPv6
  address, I would consider this mechanism to be a "mapping".
  
  I support Brian's Discuss about "What constitutes a non-translatable
  address?"

• Martin Stiemerling: Comment [2012-10-10 01:33]:
  

  A nit:
  
  Section 5., paragraph 1:
  
  >    If a pool of public IPv4 addresses is configured on the translator,
  >    it is RECOMMENDED to randomly select the IPv4 source address from the
  >    pool.  Random selection reduces the probability that two ICMP
  >    messages elicited by the same TRACEROUTE might specify the same
  >    source address and, therefore, erroneously present the appearance of
  >    a routing loop.  An enhanced traceroute application is RECOMMENDED in
  >    order to obtain the IPv6 source addresses which generated the ICMPv6
  >    messages.
  
    What is the RECOMMENDED about the application? Does it say that one
    should use such enhanced application? If yes, I do not see that
    the RECOMMENDED is the right term here, as it is nothing about
    the protocol, but more a recommendation for the user of such a
    traceroute application.

• Pete Resnick: Comment [2012-10-10 18:25]:
  

  Agree with Robert's DISCUSS.

• Benoit Claise: Comment [2012-10-08 15:02]:
  

  No objection to the publication of this document, but a few points anyway
  
  1.
  OLD:
  
   [RFC6145] section 5.2 of the "IP/ICMP Translation Algorithm"
     document. states that "the IPv6 addresses in the ICMPv6 header may
     not be IPv4-translatable addresses and there will be no corresponding
     IPv4 addresses representing this IPv6 address.
  
  NEW:
   [RFC6145] section 5.3 of the "IP/ICMP Translation Algorithm"
     document. states that "the IPv6 addresses in the ICMPv6 header may
     not be IPv4-translatable addresses and there will be no corresponding
     IPv4 addresses representing this IPv6 address.
  
  2. "The recommended approach to source selection is to use the a single"
  
  3. From the write-up:
  
     (1) What type of RFC is being requested (BCP, Proposed Standard,
     Internet Standard, Informational, Experimental, or Historic)? Why is
     this the proper type of RFC? Is this type of RFC indicated in the title
     page header?
  
     This document is proposed as a Best Current Practice. The argument
     for that status is as follows. The original authors, from CERNET,
     observed an operational problem in their network, which uses a stateful
     IPv4/IPv6 Translator between an IPv4-only domain (CERNET) and an
     IPv6-only domain (CERNET2).
  
  I guess it's a typo: statefull -> stateless
  
  4.  <RANT>
  That's a typical IETF document that contains all the information required, but
  ONLY contains the minimum piece of information. Sure if you have all the
  background (RFC 6145, RFC 6052, ICMP, stateless/statefull, IPv6 & IPv4), this
  draft is a piece of cake. However, I wonder: are we doing a good service to new
  comers by reducing the content to the minimum? No, we're simply adding to the
  argument that RFCs are a pain to read. An extra diagram with an example, in the
  introduction, with the following pieces of information, would have been so much
  easier:
          - IPv6 domain,
          - IPv4 domain,
          - request goes in one direction (indicate the IP address, before and
          after the translation), - ICMPv6 comes in the other direction (indicate
          the IP address before the translation), - src IP address as ??? - etc...
  And also explaining why it's not an issue with statefull (or simply a reference
  to http://tools.ietf.org/html/rfc6145#section-1.3) would be useful information
  </RANT>
  
  Regards, Benoit

• Brian Haberman: Discuss [2012-10-08 08:03]:
  

  What constitutes a non-translatable address?  That term is used multiple times
  in this specification and in RFC 6145 without any definition.  How does an IP
  stack know if the address is translatable?

• Brian Haberman: Comment [2012-10-08 08:03]:
  

  I am not sure what assistance Henrik gave on this document, but I doubt he
  needs to be in the Acknowledgements section twice.

• Robert Sparks: Discuss [2012-10-08 10:28]:
  

  Question for the sponsoring AD: Why is the intended status BCP instead of PS?
  Code would have to be written to implement this, and it looks like there is the
  opportunity to learn things that would affect that code going forward. The
  explanation in the shepherd writeup supports PS more than it supports BCP. Why
  _shouldn't_ this be PS?

• Sean Turner: Comment [2012-10-04 13:19]:
  

  1) s1: r/document. states/document states
  
  2) s2: The nits checker is complaining.  I believe it's because the keywords
  aren't in quotes.
  
  3) s3.1: slight rewording:
  
  OLD:
  
   The source address used, should not cause the ICMP packet to be a
   candidate for discarding.
  
  NEW:
  
   The source address used, should not cause the ICMP packet to be
   discarded.
  
  4) s3.1: I find the the 2nd sentence in s3.1 odd - is 6145 only applicable to
  private internets?  Isn't not using 1918-addresses really about not using these
  addresses on the internet as per RF 5735?  Maybe:
  
  OLD:
  
   The possibility of uRPF filters in the
   path are a critical consideration [RFC3704] which precludes the use
   of private IPv4 address space [RFC1918] in this context.
  
  NEW:
  
    Private IPv4 address space [RFC1918] SHOULD NOT be used as the
    source addresses because they should not appear on the internet
    [RFC5735].
  
  5) s3.1: I think this is missing a verb
  
  OLD:
  
   Another consideration for source selection is that it be possible for
   the IPv4 recipients of the ICMP message to be able to distinguish ...
  
  NEW:
  
   Another consideration for source selection is that it should be possible
   for the IPv4 recipients of the ICMP message to be able to distinguish ...
  
  6) s3.2: Once more with feeling ;) it's a BCP after all
  
  OLD:
  
   The recommended approach to source …
  
  NEW:
  
   The RECOMMENDED approach to source …
  
  7) s4: Is the last sentence in s4 needed?  If you're going to do the extension
  just do it.
  
  8) s5: Need some motherhood an apple pie about picking a random number.  Add a
  pointer to RFC 4086.

draft-ietf-dnsext-rfc6195bis

• Russ Housley: Comment [2012-10-10 10:24]:
  

    Please consider the comments from the Gen-ART Review by Dan Romascanu
    on 9-Oct-2012.  You can find the review here:
    http://www.ietf.org/mail-archive/web/gen-art/current/msg07830.html

• Pete Resnick: Comment [2012-10-10 18:35]:
  

  The only 2119 keyword in this thing is in section 2.3 where it says:
  
     With the existing exceptions of
     error numbers 9 and 16, the same error number MUST NOT be assigned
     for different errors even if they would only occur in different RR
     types.
  
  That doesn't need a 2119 keyword. Lowercase it, delete the 2119 template and
  reference, and be done with it.

• Barry Leiba: Comment [2012-10-09 16:18]:
  

  While you're tweaking the instructions for the Designated Expert:
  
  -- Section 3.1.2 --
     The Expert should normally reject any RRTYPE allocation request that
     meets one or more of the following criteria:
  
  I presume that means that the Expert should normally approve any requests that
  do not meet those criteria, and it'd be nice if this said that, or something
  related to it that connects to what you have in mind.  In other words, it would
  be good to say whether you want the Designated Expert to be lenient or strict. 
  So perhaps something like this (or whatever variant is suitable)?:
  
     The Designated Expert should normally be lenient, preferring
     to approve most requests.  However, the Expert should normally
     reject any RRTYPE allocation request that meets one or more of
     the following criteria:

• Sean Turner: Comment [2012-10-03 09:38]:
  

  Nicely done!
  
  In deference to the bygone era of low bandwidth, I believe s2.1 should be
  retitled:  "Brother, can you spare a bit?" ;)
  
  s3.1.1: Should the rejection also go back to the
  dns-rrtype-applications@ietf.org mailing list so the other experts in the pool
  can see whether it was approved/rejected?  Only sending to dnsext@ietf.org kind
  of assumes all the experts are on the dnsext@ietf.org list.
  
  s3.1.1: Should rejected applications also be tracked for historical purposes
  and so experts can say no we already no before to this?

draft-ietf-sipcore-proxy-feature

• Adrian Farrel: Comment [2012-10-08 07:27]:
  

  I have no objection to the publication of this document.
  
  Note that it has become customary to include a reference to the normative
  definition of the ABNF variant used.

• Stephen Farrell: Comment [2012-10-11 05:31]:
  

  - Is the consumer of the information in feature-capabilities
  well-defined? Is it intended just for the recipient of the SIP
  message or is it ok for it to really be intended e.g.  for one
  SIP proxy to tell stuf to a downstream proxy but not to the
  final recipient? (I may have missed where you said that, in
  which case, sorry:-)
  
  The remainder of my comments are really security points, but
  given that we're not going to solve e2e (never mind
  middle-to-end) security for SIP now, these are just comments.
  I'd still be very interested in answers though.
  
  - Are SIP proxies allowed to remove feature capabilities added
  upstream? Presumably they MUST NOT re-order them?
  
  - I suspect the last paragraph of section 9 is wishful thinking
  at best as it relates to confidentiality. Defining a solution
  for middle-to-end or middle-to-middle confidentiality like that
  seems like its just not going to happen (and is quite hard in
  any case). I think you'd be better to say that you SHOULD NOT
  define feature capabilities that need confidentiality that's
  better than hop-by-hop as provided by TLS.
  
  - I wondered what'd happen if someone defined a DKIM-like
  signature scheme for SIP messages. Has anyone thought about
  that?

• Pete Resnick: Comment [2012-10-10 19:01]:
  

  I find the 2119 keywords in sections 5 & 8 to be completely superfluous. This
  is about documentation, not about interoperability or network damage. I think
  they should all be gotten rid of.

• Barry Leiba: Comment [2012-10-02 16:53]:
  

  I have no objection to this document, and no blocking comments.  These are
  non-blocking, but please consider them, and feel free to chat with me about
  them:
  
  -- Section 4.2.1 --
     When a SIP entity adds a Feature-Caps header field to a SIP message,
     it MUST place the header field before any existing Feature-Caps
     header field in the message to be forwarded, so that the added header
     field becomes the top-most one.  Then, when another SIP entity
     receives a SIP request or the response, the SIP feature capability
     indicators in the top-most Feature-Caps header field will represent
     the supported features and capabilities "closest" to the entity.
  
  I understand the mandatory ordering, and I'm not asking about that.  But
  addressing the last point in particular, why is it important to know about
  supported features and capabilities "closest" to me?  Suppose the entities
  involved are A -> B -> C -> D, and suppose that A and B put Feature-Caps header
  fields on but C does not.  Will there be any issue when D sees the field that B
  put on and "thinks" that it was put there by C?  (I suspect that's not a
  problem, but I wanted to ask.)
  
  -- Section 5.3.6 --
  
     If there are specific security considerations that apply to the
     feature capability indicator, the feature capability indicator
     specification MUST document such considerations.
  
  That seems an odd requirement.  If a feature capability indicator specification
  comes in that has nothing for its security considerations, how does anyone know
  whether that's because the authors thought that none applied, or that they just
  decided to skip this item?  Why not just this?:
  
  NEW
     The feature capability indicator specification MUST document
     any specific security considerations that apply to the
     feature capability indicator.
  
  And similarly for Section 5.3.5, about interop considerations.

draft-ietf-sidr-pfx-validate

• Adrian Farrel: Comment [2012-10-06 04:41]:
  

  I support the publication of this document.
  
  It seemed strange to me that this was positioned on the standards track since
  it describes an internal implementation issue for individual BGP speakers (akin
  to other policy-based choices about which routes to select and advertise,or
  reject). This doesn't affect protocol behavior per se.
  
  I turned to the Shepherd write-up for an explanation of the thought behind this
  decision, but sadly Question 1 of the write-up hasnot been answered in full, so
  no hints there.
  
  However, since we hope that this function will become widly available in
  implementations to factilitate deployment and use of the RPKI system by
  inter-domain routing, I don't think this is a big issue.

• Benoit Claise: Comment [2012-10-08 13:06]:
  

  Just echoing Barry's point:
      Just some little non-blocking stuff that needs no response:
  
     Really a nit: you're taking what we usually call a "man-in-the-middle attack"
     and calling it a "monkey-in-the-middle" attack.  While that might seem cute,
     I find it distracting -- mostly because one wonders whether there's a
     technical reason for choosing an unusual term.
  
  I had to search for the differences between man-in-the-middle and
  monkey-in-the-middle attacks. Note that rfc4593 speaks about "man-in-the-middle"
  
  Regards, Benoit.

• Barry Leiba: Comment [2012-10-07 15:51]:
  

  Just some little non-blocking stuff that needs no response:
  
  Really a nit: you're taking what we usually call a "man-in-the-middle attack"
  and calling it a "monkey-in-the-middle" attack.  While that might seem cute, I
  find it distracting -- mostly because one wonders whether there's a technical
  reason for choosing an unusual term.
  
  ---
  
  A few comments on the shepherd writeup -- no action for the authors, and the
  only action for the shepherd is to please consider this sort of stuff next
  time; thanks:
  
  1. I agree with Adrian's comments.  Some discussion in the writeup of why the
  WG decided to put this as Standards Track would have been helpful, and question
  1 does ask that (albeit not as clearly as it might).
  
  2. In the Working Group Summary in response to question 2, the writeup says
  that "there was a fairly lengthy discussion in several in-person meetings as
  well as on-list," but gives no clue as to what issues the discussion was about.
   Again, a few brief words on some key issues would have been helpful,
  especially for items that were primarily discussed off list.
  
  3. The response to question 8 says, "Yes, there is an IPR disclosure. The WG
  has seen this and comments were made at an in-person meeting. There wasn't a
  blocking comment, however."  The question asks to "summarize any WG discussion
  and conclusion regarding the IPR disclosures," and this isn't a useful summary
  of the comments.  Such a summary is made more important by the fact that it was
  in person, and not on the mailing list, so there is no record we can go back to
  look at.
  
  4. Adrian is NOT a "galactic policeman".  He is an INTERgalactic policeman. 
  You're selling him short.

• Sean Turner: Comment [2012-10-05 14:22]:
  

  Thanks for a clearly written draft.

draft-ietf-abfab-gss-eap-naming

• Russ Housley: Comment [2012-10-10 10:52]:
  

    The authors have agreed to implement the suggestions from the Gen-ART
    Review by Suresh Krishnan on 8-Oct-2012.  These have not been folded
    into the draft yet, but I am confident this will happen.

draft-ietf-6man-udpchecksums

• Ronald Bonica: Discuss [2012-10-09 11:59]:
  

  This DISCUSS is related to my DISCUSS on the udpzero document. As soon as that
  DISCUSS is addressed, I will clear this one.

• Russ Housley: Comment [2012-10-08 08:26]:
  

    Please consider the non-blocking comments from the Gen-ART Review by
    Peter Yee on 30-Sep-2012.  You can find the review here:
    http://www.ietf.org/mail-archive/web/gen-art/current/msg07809.html

• Stephen Farrell: Comment [2012-10-11 04:14]:
  

  - The DCCP-UDP tunnel draft [1] says you MUST have a non-zero
  UDP checksum. Does that conflict with this or need to be called out
  as an exception? (And if so, does anything else?)
  
     [1] http://datatracker.ietf.org/doc/draft-ietf-dccp-udpencap/
  
  - Ought 6man-udpzero be a normative reference? Seems odd to say
  this "requires" that (top of p7) but for the referred thing to
  be informative and an informational RFC. Is all the right text
  in the right places?
  
  - The secdir review [2] suggested calling more stuff out to
  application developers, which seems worth considering.
  
     [2] http://www.ietf.org/mail-archive/web/secdir/current/msg03555.html

• Benoit Claise: Comment [2012-10-09 13:41]:
  

  No objection to the publication of this document, but I really would like to
  have the following requirement clarified.
  
   2.  Implementations MUST provide a way to signal the set of ports
            that will be enabled to receive UDP datagrams with a zero
            checksum.
  
  What is an implementation? The application running over the tunnel? You refer
  to "An encapsulating protocol" in the sentence before the bullet points, is
  this what you mean? If yes, signal from where to whom? Or maybe by
  "implementation" you mean "IPv6 protocol stack implementation"

• Barry Leiba: Discuss [2012-10-04 10:50]:
  

  This is a combined DISCUSS on udpchecksums and udpzero.  First, let me say that
  I have no actual objection to publishing either of these documents.  What I'm
  concerned about is whether we're saying what we want to stay as a "standard",
  so let's discuss that:
  
  The issue comes when I look at udpzero Section 5.1 and udpchecksums section 5. 
  The numbered list in the latter is essentially a word-for-word copy of the
  numbered list in the former, with the "must"s and "may"s and "should not"s
  changed to upper case.  It always bothers me when a significant amount of
  important text is duplicated like that, but the real problem comes when I look
  at what this *says*.
  
  Because udpzero is informational, when it says, "If a zero checksum approach
  were to be adopted by the IETF, the specification should consider adding the
  following constraints on usage," that makes no normative requirement on any
  future protocol that runs on UDP and decides to bypass the UDP checksums.  Now,
  of course, we also have a document, udpchecksums, which defines what to do if
  you do tunneling on UDP and you want to skip the outer checksums (because you
  have inner ones).  *That* document makes this list normative.
  
  But what happens if, later, someone decides to document how to do, let's say,
  media streaming over UDP with zero checksums.  The analysis in udpzero applies,
  of course, but the new document is under no obligation to consider it or any of
  those usage restrictions in Section 5.1.  (It might be that such a document
  could never get past the current community and ADs, but I'm not sure we want to
  leave that to chance.)
  
  So the question comes to what we want to say normatively.  Which is it that we
  want a standard saying?
  
  1. If you tunnel packets over UDP and want to avoid the UDP checksums, you need
  to use this list of restrictions.  But other applications over UDP that want to
  avoid the UDP checksums can make entirely different decisions.
  
  or
  
  2. If you do *anything* over UDP and want to avoid the UDP checksums, you need
  to use this list of restrictions.  And here's how tunneling over UDP works.
  
  I think (2) is right, but the way the documents are structured now says (1).
  
  Discussion, please....

• Stewart Bryant: Discuss [2012-10-07 20:37]:
  

  Please see my discuss on draft-ietf-6man-udpzero, and note that I hope to get
  to yes on this draft also, since I support the liberalization of this protocol
  design when used for tunnelling. Specifically point 6 in this draft is relevant
  to this discussion. Additionally a tunnel may not have any way of knowing if
  the payload is protected (as you suggest), since normally a tunnel has no
  knowledge of the payload characteristics.
  
  In point 7 you suggest that an application cannot rely on packet length. When
  PWs are used for tunneling we rely on exactly that (except in the case of
  packets shorter than 64 octets for Ethenet padding reasons), and I am not aware
  of any reported issues. Thus when the application is tunnel encap/decap there
  is a body of evidence that suggests that this OK.

• Stewart Bryant: Comment [2012-10-07 20:37]:
  

  There is some text in the earlier part of document that looks like it should be
  written in RFC2119 format. In this case it is not important because the
  normative change is later and this used RFC2119 directives, however the authors
  should consider making the document self consistent in this regard.

draft-ietf-fecframe-pseudo-cdp

• Russ Housley: Comment [2012-10-08 08:30]:
  

    The authors agreed to make some changes based on the comments provided
    in the Gen-ART Review by Miguel Garcia on 27-Sep-2012, but they have
    not appeared yet.

• Wesley Eddy: Comment [2012-10-01 18:47]:
  

  I didn't find a very clear description of why doing this is a good thing,
  rather than just keeping separate repair flows.  For instance, is it intended
  to have a savings in packet count, does it impact latency, does it minimize
  encoder/decoder state to be kept, etc?
  
  It was not clear to me whether the rates of the N source flows come into play
  or need to be aligned in some way (i.e. if they don't have fixed rates, have
  odd harmoics, or could have phase issues in how they present bits into the
  encoder).  For instance, if some flows stall and others don't, does the encoder
  need to idle fill in order to have enough input to produce the repair blocks?
  If there are some assumptions on this, it really should be made clear, as it
  could impact the effectiveness or latency of the FEC.

• Benoit Claise: Comment [2012-10-09 15:10]:
  

  Same question as Wes':
  "I didn't find a very clear description of why doing this is a good thing,
  rather than just keeping separate repair flows.  For instance, is it intended
  to have a savings in packet count, does it impact latency, does it minimize
  encoder/decoder state to be kept, etc?"

• Brian Haberman: Comment [2012-10-02 08:42]:
  

  I have no problem with the publication of this document, but do have some
  non-blocking comments/questions...
  
  1. I support Wes' comments on this draft.
  
  2. The abstract refers to a "full-pledged" protocol, I assume this should be a
  "full-fledged" protocol.
  
  3. The last sentence of the abstract seems odd.  Do you really mean for this
  approach to "design a protocol"?  I would think that it would make more sense
  to say form/develop/implement a CDP.
  
  4. I am curious if there is a well-accepted definition of what a CDP provides. 
  How can a reader determine if this approach really provides the necessary
  functions needed for a CDP?  Are there aspects of CDPs that this approach does
  not provide?
  
  5. Section 3 states that both the source and destination need to know the Flow
  ID and that the Flow ID is generated from header fields such as IP addresses
  and transport-layer port numbers.  Are there implications for this approach
  introduced by NATs and other types of middleboxes?
  
  6. The Security Considerations section references the Security Considerations
  in RFC 6363, which is good.  Would any of the security issues in RFC 6364 also
  apply?

• Sean Turner: Comment [2012-10-04 12:28]:
  

  1) no action required - I have to admit that when I first read this draft I
  thought it odd that it's called a pseudo CDP, but I now get that this draft is
  supposed to be like a cookbook for how to put everything together to get a CDP.
  
  2) a: r/full-pledged/full-fledged
  
  3) s1: (let's assume it does ;) r/aims at providing/provides
  
  4) s2: Probably nit picking here a bit, but are you also importing the 2119
  language at the end of s2 in RFC 6363?  If not maybe:
  
     This document uses all the definitions and abbreviations from Section
     2 of [RFC6363] minus the 2119-requirements language.
  
  or something like that.
  
  5) Where's the bit about how the security protocol gets picked!?  I guess I'm
  just saying an even better non-trivial scenario would have included security.

draft-ietf-6man-udpzero

• Ronald Bonica: Discuss [2012-10-09 11:57]:
  

  This is a two-part DISCUSS-DISCUSS. Both parts relate to bullet points in
  Section 5.1.
  
  Bullet 5
  ======
  "Tunnels that encapsulate IP may rely on the inner packet
    integrity checks provided that the tunnel will not significantly
    increase the rate of corruption of the inner IP packet."
  
  - What does it mean to *significantly* increase the rate of corruption of the
  inner IP packet? - Shouldn't we also be concerned about corruption of the UDP
  header and any additional encapsulation that comes between the UDP header and
  the inner IP packet? - How does a tunnel ingress node know whether the tunnel
  will significantly increase the rate of corruption of the inner IP packet?
  
  Bullet 7
  =====-
     " UDP applications that support use of a zero-checksum, should not
         rely upon correct reception of the IP and UDP protocol
         information (including the length of the packet) when decoding
         and processing the packet payload.  In particular, the
         application must be designed so that corruption of this
         information does not result in accumulated state or incorrect
         processing of a tunneled payload."
  
  - How could any application achieve this goal? Possibly by analyzing the
  consequences if any field in the IPv6 or UDP header were corrupted?
  (draft-ietf-6man-udpchecksums begins this analysis.)  Again, wouldn't the
  analysis have to include any additional encapsulation that comes between the
  UDP header and the inner IP header?
  
  - Wouldn't the analysis, mentioned above, have to include assurances regarding
  the case when the destination port is corrupted? Specifically, would it have to
  include a guarantee that if the encapsulated inner packet were delivered to any
  randomly chosen port, it would not cause any harm to the application listening
  on that port?

• Adrian Farrel: Comment [2012-10-11 07:28]:
  

  A couple of thughts about this document which I am not raising as a
  Discuss, but I hope the authors will have a look at.
  
  ---
  
  Section 5.1
  
     2.  Implementations must provide a way to signal the set of ports
         that will be enabled to receive UDP datagrams with a zero
         checksum.  An IPv6 node that enables reception of UDP packets
         with a zero-checksum, must enable this only for a specific port
         or port-range.  This may be implemented via a socket API call, or
         similar mechanism.
  
  I believe "signal" is a confusing word here. Signalling means (to me)
  that the implementation builds a message and sends it to the remote end.
  So, "implementations" cannot provide this mechanism - it is the protocol
  specification that must do it. And a sockets API call provides a way for
  an implementation to request the zero-checksum feature locally, but it
  does not provide a way to "signal the set of ports that will ..."
  
  Probably, the consistancy of this requirement would be most easily
  obtained by s/signal/register/
  
  However, that change would leave open the question of how two end points
  coordinate (i.e. signal) on which ports they will use zero checksum.
  That is a requirement on the specification of transported protocols,
  which is exactly what this section is about.
  
  ---
  
  Section 9 seems to make a valid point, so I am surprised that no
  conclusions are drawn from what it says.
  
  It also seems to me that it is important to drop and log corrupted
  packets as early as possible. This offers three benefits:
  1. Corruptions in the tunnelling encapsulation are detected so that
     mis-delivery of the tunnelled packets is less likely
  2. Causes of corruption can be more effectively isolated (for example,
     was it the encapsulation mechanism, the transmission, or the
     storage of the tunnelled packet that introduced the corruption). In
     particular, where the corruption is the result of an attack, this may
     be valuable information.
  3. The later the corruption is detected and the packet dropped, the more
     processing has been "wasted" handling the packet. Thus, late
     detection offers a way to waste transmission/receiver resources.
  
  I found some of these points hinted at in the body of the document and
  in the Summary. Maybe Section 9 is just positioned a little late in the
  document meaning that the authors didn't feel there was muych to say by
  the time the reader got there? Might be nice to beef up the Section a
  little and arrange for it to come before the Summary.

• Ralph Droms: Comment [2012-10-09 06:47]:
  

  In section 4.1, is there a reference to the "proposal to simply ignore
  the UDP checksum value on reception at the tunnel egress" that can be
  cited to give more background?
  
  In section 4.2.1, "The methods that ignores the checksum has an
  additional downside" needs to be plural or singular throughout.
  
  The first paragraph of section 5 tells me it identifies requirements
  for protocols carried without UDP checksum.  Section 5.1 talks only
  about "zero checksum"; does the proposal to ignore the checksum at the
  tunnel egress also fit here?  Also, stylistically, I think the section
  header for 5.1 can simply be dropped.
  
  In section 5.1, I can't parse out what list item 5 is trying to
  convey.  What is the "tunnel layer" and is it always recommended and
  required for some tunnel mechanisms?

• Benoit Claise: Comment [2012-10-09 13:43]:
  

  No objection to the publication of this document, but I really would
  like to have the following points clarified.
  
  -  2.  Implementations MUST provide a way to signal the set of ports
            that will be enabled to receive UDP datagrams with a zero
            checksum.
  
  What is an implementation? The application running over the tunnel? You
  refer to "An encapsulating protocol" in the sentence before the bullet
  points, is this what you mean?
  If yes, signal from where to whom?
  Or maybe by "implementation" you mean "IPv6 protocol stack implementation"
  
  - Section 3.1.2  Corruption of the source IP address
  
  Please mention Unicast Reverse Path Forwarding, which might discard packets.

• Barry Leiba: Discuss [2012-10-04 10:50]:
  

  See my DISCUSS for draft-ietf-6man-udpchecksums:
  http://datatracker.ietf.org/doc/draft-ietf-6man-udpchecksums/ballot/

• Stewart Bryant: Discuss [2012-10-07 20:25]:
  

  This discuss applies to both this draft and draft-ietf-6man-udpchecksums-04
  
  Fundamentally I support the liberalization of the position regarding IPv6 UDP
  checksums  when UDP is used for tunnels and hope to get to a yes position on
  both drafts. However, there is some text  that needs discussion, and then we
  need to discuss the consequences of that discussion. The rational for the
  slightly conservative position taken in the case of tunnels seems to based on
  the following text:
  
  "IP packets may be corrupted as they traverse an Internet path.
  Evidence has been presented [Sigcomm2000] to show that this was once
  an issue with IPv4 routers, and occasional corruption could result
  from bad internal router processing in routers or hosts.  These
  errors are not detected by the strong frame checksums employed at the
  link-layer [RFC3819].  There is no current evidence that such cases
  are rare in the modern Internet, nor that they may not be applicable
  to IPv6. It therefore seems prudent not to relax this constraint.
  The emergence of low-end IPv6 routers and the proposed use of NAT
  with IPv6 further motivate the need to protect from this type of
  error."
  
  However we do have a body of evidence that is not discussed in the document.
  Firstly we have a decade of experience with MPLS VPNs where the VPN Identifier
  label, which is used to steer the traffic to a particular customer network
  (i.e. is functionally equivalent to an address), is not protected by a
  checksum. I am not aware of any concerns expressed by operators in this regard,
  and I am not aware of any work in the MPLS WG to introduce checksum like
  protection.
  
  We also have a decade of experience with pseudowires. With one exception that
  we will discuss in a minute, none of the PW designs have any form of data
  integrity protection other than the CRC imposed by the network datalink at each
  hop. In the specific case of the Ethernet PW, there are two modes: one in which
  the CRC is stripped at ingress to the PW and recalculated at egress, and
  another where it is preserved end to end. There is very little, if any,
  deployment of the end to end CRC preservation mode. Given that there must be
  some low level of corruption of the frames, I would conclude that the protocols
  that are likely to be tunneled are sufficiently hardened that the occasional
  corruption is of no practical consequence.
  
  Thus I would conclude that the level of corruption is sufficiently rare and of
  sufficiently minor consequence that at least in the case of service provider
  networks implementing UDP tunneling, it is safe to omit the UDP checksum
  without analysis of the application.
  
  I would propose that the text should include some acknowledgement of this
  recent body of evidence and that the recommendation be aligned in consequence
  to unconditionally allow C/S free tunneling, at least within a well managed
  domain without additional consideration.
  
  Section 5.1 seems to be duplicated in the two drafts. It would be better if the
  text were just in one RFC and the other pointed to it.

• Stewart Bryant: Comment [2012-10-07 20:25]:
  

  You also note that an application may rely on the checksum to protect it
  against packets that may damage it. I find this very weak argument, since such
  an application would be vulnerable to packets deliberately malformed by an
  attacker, or malformed by a software bug in a peer. The correct approach is
  surely to harden the application, and thus the checksum argument is not
  persuasive.
  
  You note the need to signal the agreement not to use c/s, I think that you need
  to include the configuration of this property as an alternative, and note that
  configuration may be implicit in the definition of the UDP payload.

draft-ietf-avtext-splicing-for-rtp

• Adrian Farrel: Comment [2012-10-08 08:05]:
  

  I am ballotting No Objection on this document although I am not convinced by
  the Security thoughts. It doesn't seem to me to be impossible to construct a
  three-way security arrangement for source, splicer, and destination. But maybe
  the point here is that the very act of splicing *is* a violaiton of the
  source-destination relationship. Thus the destination correctly only has a
  relationship with the splicer.

• Stephen Farrell: Comment [2012-08-27 02:10]:
  

  Thanks for addressing my discuss points. I think the current
  version's truth-in-advertising approach to the fact that it
  breaks e2e security is much better. (Though it'd be even better
  if you could figure a way to do this that would not break e2e
  security. I'd encourage folks wanting to insert advertisements
  to try think about that.)

• Martin Stiemerling: Comment [2012-10-10 02:30]:
  

  Thank you for addressing my concerns!

• Pete Resnick: Discuss [2012-10-08 21:49]:
  

  REQ-7: There at least needs to be a forward reference to section 4.5 in this
  section. That said, I am still bothered by this section. The first sentence is
  written in the passive voice, so I can't tell what it's saying: Is it saying
  that splicing should not be easily detected *by the RTP receiving
  implementation* (in which case section 4.5 is really all that this is talking
  about), or is it saying that splicing should not be easily detected *by the RTP
  stream end-user* (in which case it's talking about section 4.3, which I think
  is bogus)? The second half of REQ-7 talks about both, but then goes on to say
  that this memo is only concerned with the RTP layer. Please rewrite this
  section to make it clear that you are only talking about the protocol, not the
  user experience.
  
  Section 4.3: Similar to the above, this is really all user experience, not
  protocol clipping. I think this section should simply be dropped.
  
  Section 4.5: "User Invisibility" is not the requirement in 4.5; it is
  "Receiving implementation invisibility." Section 4.5 does not address user
  experience invisibility and should be re-titled.
  
  With regard to all of the above, if the WG insists on talking about user
  experience in this document, I will simply Abstain on it.

• Benoit Claise: Comment [2012-05-10 01:55]:
  

  Much has been said already with the multiple DISCUSS feedback on this draft.
  So, no need to repeat the information: I'll trust the other ADs will take care
  of this one.

• Barry Leiba: Comment [2012-10-09 11:50]:
  

  Thank you for the extensive work on this document since the -07 version.  This
  is *much* clearer, and addresses all my significant concerns.
  
  Only one, small, non-blocking point: I suggest expanding "SSRC" and "CSRC" on
  first use.
  
  For the record, I have no issue with Section 4.3 -- I see nothing wrong with a
  non-normative section that calls out an issue (including a user-experience
  issue) that's likely to come up in implementations, and warns them about it. 
  If it tried to be normative, or if it went into a lot of detail about user
  interface design, I might agree that it's a problem... but it doesn't, and I
  don't.

• Stewart Bryant: Discuss [2012-10-07 20:43]:
  

  I have a concern regarding requirement 4, since in some cases exposing the
  content in the clear at the ad insertion point would be considered a service
  security vulnerability. The basis for this vulnerability seems to be the need
  to provide access to the keying indicators. Surely it is possible to design an
  out of band, or a semi-out of band, indication system and not expose the
  content itself to this vulnerability?

• Robert Sparks: Comment [2012-10-09 07:22]:
  

  Thanks for addressing my concerns.
  
  Please consider adding (or pointing to) a discussion of what the impact of
  having a loop is.

• Sean Turner: Comment [2012-05-10 03:48]:
  

  I support the discuss positions from the other ADs.

conflict-review-pornin-deterministic-dsa

• Stephen Farrell: Comment [2012-10-11 05:57]:
  

  There was a bunch of mail discussing this on the CFRG list but
  I'm not clear if that reached closure or not. It would be good if
  the ISE wanted to check with the chairs of the CFRG to see if
  they think there are any comments there that might usefully be
  addressed before this becomes an RFC. (In particular I don't
  think I saw the author answering those comments but perhaps
  he's not on the CFRG list?)

• Pete Resnick: Discuss [2012-10-08 17:56]:
  

  The header of the document is as follows:
  
    Internet Engineering Task Force                                T. Pornin
    Internet-Draft                                           August 27, 2012
    Intended status: Informational
    Expires: February 28, 2013
  
  Note the "Internet Engineering Task Force" on the top line. That's just wrong.
  Do we assume that the RFC Editor will fix that and I move to "No Objection" or
  shall I hold the "Discuss" until that is corrected?

conflict-review-mme-trill-fcoe

• Adrian Farrel: Comment [2012-10-06 04:14]:
  

  My Comments are by way of a mutter that I hope the ISE will note and
  consider for future documents on the Independent Stream. No action from
  the IESG or the document authors is requested.
  
  ---
  
  The ISE's note says:
  > This draft was discussed on the trill list, no objections
  > to the publication of this draft in the Independent Stream
  > were raised.
  
  This is probably a little simplistic. It is true that the WG was
  notified of the existence of the draft and offered the chance to
  object to publication. But the I-D was not discussed in any sense.
  There are a total of 3 emails about the draft in the archive and
  they are all notifications from the authors.
  
  ---
  
  While I don't disapprove of publication of this I-D on the Independent
  Stream, I have become accustomed to notes explaining why documents are
  presented via the ISE rather than through the working group.

• Stewart Bryant: Comment [2012-10-09 12:10]:
  

  I feel that I need to know why this is an independent draft rather than a Trill
  draft before I am in a position to take a position on whether this is a
  conflict or not.