IESG Narrative Minutes

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

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

Corrections from: Barry

1 Administrivia

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

2. Protocol Actions

2.1 WG Submissions

2.1.1 New Items

  1. Updated Specification of the IPv4 ID Field (Proposed Standard)
    draft-ietf-intarea-ipv4-id-update-05
    Token: Brian Haberman
    Note: The Document Shepherd is Julien Laganier (julien.ietf@gmail.com).
    Discusses/comments (from ballot draft-ietf-intarea-ipv4-id-update):
    1. Stewart Bryant: Discuss [2012-07-03]:
      RFC791 is one of the most fundamental protocols in the Internet that is now 31 years old, and I do not think that it should be changed (or clarified) unless there is some major issue that jeopardizes the operation of the Internet. The author makes a case for housekeeping, but does not make a case that we have a catastrophic problem that demands addressing. I am therefore concerned that publishing this is an unnecessary risk to the Internet.
      My rational for the above is that we have no idea of the behavior of all of the applications and protocols in the wild, and can never be completely sure that there will be no unforeseen consequences of the proposed changes in this draft.
      The following are some examples that bare further thought given the fundamental nature of IPv4.
      "IPv4 ID field MUST NOT be used for purposes other than fragmentation and reassembly."
      "All devices that examine IPv4 headers MUST ignore the IPv4 ID field of atomic datagrams."
      We have no idea what this field might be used for in atomic packets and hence we cannot be sure we are making some application non-compliant.
      "Deprecating the use of the IPv4 ID field for non-reassembly uses should have little - if any - impact."
      For a protocol this fundamental to the Internet, "should" is insufficient.
      "Sources of non-atomic IPv4 datagrams MUST rate-limit their output to comply with the ID uniqueness requirements."
      What is the situation today - do all existing, functioning devices comply with this rule?
      "o IPv4 ID uniqueness applies to only non-atomic datagrams."
      "o Retransmitted non-atomic IPv4 datagrams are no longer permitted to reuse the ID value."
      "o Retransmitted non-atomic IPv4 datagrams are no longer permitted to reuse the ID value."
      Can we be sure that there is no protocol anywhere on the Internet, using atomic datagrams, that is also using the feature being deprecated?
      "Datagram de-duplication mechanisms MUST ignore the ID values on atomic datagrams."
      Are we certain that no device used this feature for anything?
    2. Stewart Bryant: Comment [2012-07-03]:
      In IPv4, the Identification (ID) field is a 16-bit value that is unique for every datagram for a given source address, destination address, and protocol, such that it does not repeat within the Maximum Segment Lifetime (MSL) [RFC791][RFC1122]. As currently specified, all datagrams between a source and destination of a given protocol must have unique IPv4 ID values over a period of this MSL, which is typically interpreted as two minutes (120 seconds).
      I just could looked at RFC791 and RFC1122, and as far as I can see RFC791 does not say two mins and RFC1122 is quoting from TCP which it notes is arbitrary.
    3. Ralph Droms: Discuss [2012-07-04]:
      1. Throughout this document, "MSL" is confused with "time the datagram (or any fragment of it) could be alive in the internet" (from RFC 791) or "typical maximum delay across the Internet" (from RFC 1122). While the TCP MSL "sets an upper limit on a reasonable reassembly timeout value" (from RFC 1122), there is no mention of "MSL" in RFC 791 and there is no explicit discussion of the uniqueness properties of the ID field in RFC 1122.
      For clarity and correctness, I would like the description of the ID field in the Introduction to quote the text from RFC 791, with no mention of "MSL", and the discussion of the speed limits - esp. the 6.4 Mbps number - to be replaced with a simple pointer to RFC 4963, which has a more complete and accurate discussion of the topic. I also think section 5 can simply be omitted.
      The details are unimportant in this document (and I consider the document to be misleading about the details). All that needs to be concluded is that high speed interfaces have to violate the uniqueness requirement, even for maximum delays across the Interent of 1 second.
      All other references to "MSL" should be replaced, perhaps with "maximum datagram lifetime".
      2. This requirement in section 6.3 does NOT derive exactly as stated from RFC 791:
      "Sources emitting non-atomic datagrams MUST NOT repeat IPv4 ID values within one MSL for a given source address/destination address/protocol triple."
      The actual requirement, quoted elsewhere in the document, makes no direct reference to "MSL".
    4. Ralph Droms: Comment [2012-07-04]:
      1. In this text from section 4:
      "The IPv4 ID field can be useful for other purposes. The field has been proposed as a way to detect and remove duplicate datagrams, e.g., at congested routers (noted in Sec. 3.2.1.5 of [RFC1122]) or in network accelerators. It can similarly be used at end hosts to reduce the impact of duplication on higher-layer protocols (e.g., additional processing in TCP, or the need for application-layer duplicate suppression in UDP)."
      Is the ID field actually used in the ways suggested?
      2. In section 9.2:
      "Some such devices reportedly feature datagram de-duplication, which relies on IP ID uniqueness to identify duplicates."
      Normally, I wouldn't raise a pedantic fuss about "which" versus "that". But, in this case, I think it's important because the following sentence is, I think, correct while the sentence about is not:
      "Some such devices reportedly feature datagram de-duplication that relies on IP ID uniqueness to identify duplicates."
    5. Adrian Farrel: Comment [2012-07-05]:
      I understand why this document was written, and support the intent of clarifying what is really in the wild. However, this document worries me for the reasons listed in Stewart's Discuss. Thus, I support Stewart's Discuss.
      But my concerns would be satisfied if the authors would consider repositioning the document as an applicability or informational document that describes what some implementations do in order to support faster line speeds?
    6. Stephen Farrell: Comment [2012-07-02]:
      Minor comments, feel free to take 'em or leave 'em.
      (Updated: I'd forgotten to note the secdir review.)
      - A reference for a hash-based de-duplication scheme mentioned in 6.1 might be useful, even if only as an illustration.
      - The reference to SEAL (RFC 5320) is a bit unclear. You have a "SHOULD verify integrity" requirement but then say "as in SEAL." I'm not clear if you're saying that SEAL is a SHOULD, and if you are, then would that be ok? (SEAL being an experimental RFC.) I assume that you don't mean SEAL is a SHOULD-implement though, and since its given as an example in the next para, I think you could delete the reference from the SHOULD requirement bullet in section 7.
      - The discussion of entropy in section 11 is a little opaque, you could say why the entropy of a datagram is interesting. (Is it that people sometimes use datagram fields to seen PRNGs?). Steve Kent's secdir review [1] also suggested maybe changing or removing this.
      [1] http://www.ietf.org/mail-archive/web/secdir/current/msg03358.html
      - Typo: s/now adds much less entropy of the header/ now adds much less to the entropy of the header/?
    7. Barry Leiba: Comment [2012-06-30]:
      Very clear, understandable document. Thanks.
    8. Pete Resnick: Comment [2012-07-03]:
      I share Stewart's concern about the lack of data to support this document. The document does not have a section on how current implementations actually do this, and that lack is worrying. (The shepherd writeup has *no* information on implementation, and that's a problem. The shepherd should have asked.) All things being equal, I would have silently balloted "No Objection", but I given his comments, I do support Stewart's DISCUSS.
    9. Sean Turner: Comment [2012-07-03]:
      As noted in Steve Kent's secdir review, the security considerations section should indicate whether the change proposed in this document may adversely affect availability, if middleboxes are not updated to account for this change.

    Telechat:

  2. Measurement Identity and information Reporting using SDES item and XR Block (Proposed Standard)
    draft-ietf-xrblock-rtcp-xr-meas-identity-07
    Token: Gonzalo Camarillo
    Note: Charles Eckel (eckelcu@cisco.com) is the Document Shepherd.
    Discusses/comments (from ballot draft-ietf-xrblock-rtcp-xr-meas-identity):
    1. Brian Haberman: Comment [2012-06-26]:
      I have no problems with the publication of this document. I do have one, non-blocking, question...
      Section 3.1 describes the APSI and provides the following statement: "If no identifier is provided, the length field MUST be set to zero."
      Is there a scenario where the APSI SDES item would be included without an ID being provided?
    2. Pete Resnick: Comment [2012-07-04]:
      3.1 "This item MUST be ignored by applications that are not configured to make use of it." That's a very odd construction. It sounds like you're saying that if I'm configured to ignore it, I MUST ignore it. What are the circumstances you are trying to prevent here? I don't understand.
      4.2 "The length of this report block in 32-bit words minus one." Perhaps this is an RTCP thing, but this seems like it's destined for confusion. First, instead of using length in bytes, you're using length in words. Do you really think that it is likely for a future block to be longer than 16K 32-bit words? Also, calling it the "block length" but then not having it be the length of the block seems like it's going to cause confusion. If you're going to stick with count of 32-bit words, call it "extension word count" or something like that.
    3. Robert Sparks: Discuss [2012-07-02]:
      Section 3.1, while defining the APSI SDES item says "If no identifier is provided, the length field MUST be set to zero." Why would you provide this item at all if the no identifier is to be provided? If there's a case where that makes sense, could you describe it in the document?
      In the new XR block, the Measurement Duration (Cumulative) field as defined can only represent intervals up to about 18.2 hours. What is an implementation supposed to do if the stream it's reporting on has been active longer than that? (Using the example from the monarch document, say you were reporting the total number of RTP packets lost since the start of the RTP session.)
    4. Robert Sparks: Comment [2012-07-02]:
      The short-title that shows in the header of each page beyond the first could be more descriptive. Perhaps "Measurement Identity and Duration"?
      In section 1.1, "This document defines a new Extended Report block that must be used as defined in..." says "this block must be used". You are trying to say "if you use this block, you must follow the rules in ....". Perhaps this could be replaced with "This document defines a new Extended Report block. The use of Extended Report blocks is defined by RFC 3611.

    Telechat:

2.1.2 Returning Items

  1. TRILL: Clarifications, Corrections, and Updates (Proposed Standard)
    draft-ietf-trill-clear-correct-04
    Token: Ralph Droms
    Note: Erik Nordmark (nordmark@acm.org) is the document shepherd.
    Discusses/comments (from ballot draft-ietf-trill-clear-correct):
    1. Stewart Bryant: Discuss [2012-07-02]:
      The following points are derived from the RTG-DIR review by Mike Shand.
      Section 2.1 states "Frames are not least cost routed through an overloaded TRILL Switch if any other path is available..."
      However, ISO/IEC precludes the routing of frames through an overloaded router, even when no other path is available. (see clause 7.2.8.1) [ note all references to ISO/IEC 10589 are to the second edition ]
      Please clarify in the text that there is no intention for TRILL to deviate from the specified ISO/IEC 10589 behaviour.
      Section 2.3.1 seems relevant here, but I don't understand the description. I must be missing something, since it would appear that a data frame forwarded to RB2 MUST attempt to forward the frame to ANY non-overloaded neighbor (other than the one it was received from). However, surely that non overloaded neighbor might then have RB2 as its next hop, and forward the frame back to RB2, which would then be required to forward the frame possibly back to the original RBridge from which it was received. Clearly this is not the desired operation, so the text needs clarifying to make it clear what is really supposed to happen.
      Section 4 bullet 4
      I THINK this is saying that the check must be made on any "new" LSP even if the RBridge is in overload state, and cannot store the received "new" LSP. It may be clearer to explicitly say it must do this even when overloaded. The existing parenthetical remark doesn't seem adequate.
      The following issue was raised:
      Section 5 2nd para
      I don't understand the term "refragment LSPs".
      Is this saying that an RBridge may start with some value of originatingL1LSPBufferSize, and then be required to change to a lower value, thus necessitating that it re-generates all its LSPs which were previously larger than this new value?
      In a subsequent discussion with the reviewer the a some clarification was provided. Please add this clarification to the text.
      Section 2.2 second para
      "...and Bridge RB1 can similarly...."
      Can is ambiguous. Is that MAY or MUST?
    2. Stewart Bryant: Comment [2012-07-02]:
      Section 2.
      There are two instances of "pseudo node". The ISO/IEC 10589 term is pseudonode. (note this is correctly used in section 4)
      Section 2.2 first line
      s/A RBridge/An RBridge/
      Section 10.1 para below bullet 2.
      s/Two different encoding are providing above/Two different encodings are provided above/ (I assume)
      The instances of "encoding" look like they should "encoding mechanisms" ?
    3. Adrian Farrel: Comment [2012-07-05]:
      Section 1.2 is a useful section to have at the top of the document. I would have liked it more had it:
      - listed each non-backward compatible feature (with a section reference) instead of saying "several"
      - explained in summary how non-compatiblity is handle in general
    4. Stephen Farrell: Comment [2012-06-19]:
      - typo in abstract: s/provide/provides/ (same sentence is correct in intro:-)
      - 2nd para of section 5 is odd, it says its about the case where nothing is known, but then says "if it is known that other..." I'd say replacing the opening phrase with some more specific might work, e.g. "If not all MTU information is known for the entire campus..."
      - 10.1: "...in the Down state out a port..." is an odd phrase, maybe s/out/for/ or something?
      - 10.1: What is a DRB?
      - 10.2: I think this needs rephrasing/fixing: "Therefore, the DRB SHOULD NOT appointed an RBridge in overload as Appointed Forwarder for an VLAN unless there is no alternative." I'm not sure what it means really.
    5. Barry Leiba: Comment [2012-06-14]:
      As this document incorporates errata reported against the other three RFCs, but leaves those three current (not Obsoleted), it would be nice to list the RFC-numbers+errata-numbers that are resolved by this document. How hard would that be to add?
    6. Pete Resnick: Comment [2012-07-04]:
      This is strictly a procedural point for the chair/shepherd; The authors may ignore this.
      The ballot writeup makes me very grumpy and it makes me concerned that the chair/shepherd did not do their due diligence in passing this document to the IESG. The chair/shepherd being a former AD, I have to assume that this was just a sloppy writeup and not a real problem. But I would like to see a real writeup for the record. I did not make this a DISCUSS since I am sure this COMMENT will generate the right outcome.
      The writeup template says for "Working Group Summary":
      "Was there anything in WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough?"
      Your response was:
      "There was consensus in the working group in favor of the document."
      That's all you're going to say? Perhaps you'd like to add, "Unlike every other document which has gotten serious review in the IETF, this one generated no controversy at all and there were no points of contention. At the end of each face-to-face meeting, the entire WG held hands and sang songs together." :-) Seriously, we all assume there was consensus since you are submitting the document; you would not have submitted it otherwise. To make sure that due diligence was done, the answer the IESG is interested in is what the nature of the consensus was. At the very least say, "There was nothing particularly noteworthy about the consensus around this document. In the end, there was no roughness apparent for any part of the consensus." At least then we could see that you answered the question.
      Then in the "Document Quality", it asks:
      "Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues?"
      Your answer was:
      "The document has been carefully reviewed in the WG and by the document shepherd. The document was forwarded to the IS-IS WG mailing list, which resulted in some additional improvements."
      First of all, the document itself says that it is making non-backward-compatible changes to a protocol. I would *hope* that there is a fair bit of implementation of the new stuff already that would justify such changes. But you mention no existing implementations, nor any indication of vendors taking on such implementations, in your writeup. And as far as "reviewers that merit special mention", you call out "the WG and the document shepherd". If the WG and the document shepherd *hadn't* done thorough reviews, that would be worthy of mention; that they have done their jobs is not. (On the other hand, the IS-IS WG *is* worthy of mention.)
      This document is outside of my area of expertise. The only serious review I do is look through the document for Applications impacts and look to the writeup to see that no procedural nonsense was missed. This writeup is a pretty serious miss. Please give at least some indication on the implementation question.

    Telechat:

2.2 Individual Submissions

2.2.1 New Items

  1. (none)

2.2.2 Returning Items

  1. (none)

3. Document Actions

3.1 WG Submissions

3.1.1 New Items

  1. Content Distribution Network Interconnection (CDNI) Problem Statement (Informational)
    draft-ietf-cdni-problem-statement-08
    Token: Martin Stiemerling
    Note: Richard Woundy (richard_woundy@cable.comcast.com) is the Document Shepherd.
    Discusses/comments (from ballot draft-ietf-cdni-problem-statement):
    1. Ronald Bonica: Comment [2012-06-20]:
      Sorry for the late defer. I really want to read this document and I won't get to it tonight.
    2. Benoit Claise: Comment [2012-06-25]:
      [Thanks for addressing my DISCUSS and COMMENT, which I kept for the record below, since this draft will be on the next IESG telechat]
      (see link)
    3. Adrian Farrel: Comment [2012-07-05]:
      I found Appendix A a little suspect. While it demonstrates that the problem could be solved, it also seems to end-run the discussion of which protocol solution should be developed. I would like it if the introduction indicated that the content of the Appendix is purely examples and that further analysis will be made before the WG decides on the correct solutions.
    4. Russ Housley: Comment [2012-06-20]:
      As suggested in the Gen-ART Review by Wassim Haddad, please define "Quality of Experience". This phrase is mentioned four times in the document.
    5. Barry Leiba: Comment [2012-06-23]:
      All comments addressed in the -07 version. Thanks for taking the time!

    Telechat:

  2. The Line Identification Destination Option (Experimental)
    draft-ietf-6man-lineid-05
    Token: Brian Haberman
    Note: Bob Hinden (bob.hinden@gmail.com) is the Document Shepherd.
    Discusses/comments (from ballot draft-ietf-6man-lineid):
    1. Ralph Droms: Discuss [2012-07-04]:
      1. In section 4:
      "This document recommends tunneling Neighbor discovery packets inside another IPv6 packet that uses a destination option to convey line identification information."
      Is this an RFC 2119 recommendation? Under what circumstances would a device not encapsulate the original RS as recommended, and what are the consequences of not using encapsulation?
      2. Following up on point 1, throughout the rest of the document there is text that is conditional on, e.g., "receives a tunneled Router Solicitation". What is the behavior in the case of a non-tunneled RS that includes an LIO?
      3. Is the link between an AN and the Edge Router a point-to-point link? If not, it seems to me that the Line ID MUST be unique across all ANs that share a link to the Edge Router.
      In the case where an AN sends an encapsulated RS to the Edge Router with the source address set to the unspecified address, the Edge Router will multicast the corresponding RA, and the RA will be received by all the ANs on that link. If two different ANs happen to use the same Line ID, they will both then forward that RA on the identified subscriber line (and one of the ANs will be wrong).
      4. For completeness, the document should have text requiring the AN to join the All-BBF-Access-Nodes multicast group.
      5. In section 6.2, is the "circuit identifier corresponding to the logical access loop port of the Access Node to which the RA MUST be sent" the same as the Line ID field from the received RS? If not, where does that circuit identifier come from?
      6. Also in section 6.2, there are two potentially contradictory requirements on the "link-layer destination address of the tunneled RA" (I assume the "tunneled RA" is the outer IPv6 datagram):
      "The link-layer destination address of the tunneled RA MUST be resolved using regular Neighbour Discovery procedures.
      "The link-layer destination address of the tunneled RA MUST be set to the unicast link-layer address of the Access Node that sent the tunneled Router Solicitation which is being responded to."
      7. I don't see any text in section 6.2 about how a prefix is associated with the Line ID in an LIO. Section 8 describes reclamation of allocated prefixes, which implies there is a mechanism for allocating prefixes, but section 6.2 seems to simply assume that there is a prefix that corresponds to the received LIO.
    2. Ralph Droms: Comment [2012-07-04]:
      (five items)
    3. Wesley Eddy: Comment [2012-07-05]:
      I agree with Pete's DISCUSS.
    4. Adrian Farrel: Comment [2012-07-05]:
      I am balloting "yes" but there are some minor comments from Dave Sinicrope's Routing Directorate review. Please consider them before advancing the document for publication.
      1. Section 1.1 Terminology & all related sections: Throughout several sections of the document the term "subscriber" is used. It is not defined in the Terminology. It seems this is often used synonimously with End-device which is defined. This is particularly true of section 2. Applicability Statement. Please define "subscriber" or substitute a defined term (e.g., "end device") for "subscriber" throughout the document.
      2. Section 1.1 Terminology & all related sections: Throughout several sections of the document the term "host" is used. While "host" is defined in the Terminology, it seems this is often used synonimously with End-device where it would be better to use the latter term. This is particularly true of section 2. Applicability Statement paras 3 and 5. Please substitute "end device" for "host" throughout the document where this is applicable.
      3. Section 2. Applicability Statement: This section focuses on the limitations of the draft, but it should elaborate more on the applicability and usefulness of the draft to support stateless auto configuration.
      4. Section 2. Applicability Statement, para 3, last 2 sentences: These statements make it appear that all broadband networks rely on the [end device] MAC address and that it is not recommended that this draft be used for networks that require the [end device] MAC address, leading the reader to the possible conclusion that this draft has little use. In practice some broadband networks use the [end device] MAC address, but not all making the draft far more applicable than indicated. Please qualify the penultimate sentence of paragraph 3 "currently used in <"some" or "many"> Broadband networks"
      5. Section 2 Applicability Statement: The document would benefit from a brief flow diagram showing the Router Solicitation & Router Advertisement flows between the nodes shown in Figure 1.
      6. Section 4 Basic Operation, last sentence: The last sentence is not clear as to why a packet with a hop limit not set to 255 is discarded. Please briefly elaborate (e.g., "because they appear to be more than a single hop away.")
      7. Section 5.1 On receiving a Router Solicitation: Add a figure showing the construction of a tunneled Router Solicitation. Add "See Figure X" within the paragraph to reference the figure.
      8. Section 5.2.1 Identifying tunneled Router Advertisements: It is unclear, at least initially, what is meant by "All BBF Access Nodes". Please clarify its use as done in section 6.2, noting that it is a well known, link-local scoped multicast address.
      9. Section 5.3 On detecting a subscriber circuit coming up, para 1, "When the access node": I believe what is meant by "When the access node detects that a subscriber circuit has come up" is really "Each time the access node detects that a subscriber circuit has come up". "When the" could be misinterpreted as meaning "the first time". Please change "When the" to "Each time" in this sentence.
      10. Section 6.1 On receiving a Tunneled Router Solicitation: It is not clear how the edge router recognizes a tunneled RS. Please briefly elaborate on how this datagram is identified by the edge router.
      11. Section 6.1 On receiving a Tunneled Router Solicitation, "The link-layer destination address of the tunneled RA MUST". There are two statements in this paragraph that start with this clause that seem to be contradictory. Please reconcile and clarify.
      12. Section 6.3 Sending periodic unsolicited Router Advertisements: This section would benefit from a forward reference to section 8 Garbage collection of unused prefixes to help the reader understand when and how the prefixes are eventually removed or cleared.
      13. Section 7 Line Identification Destination Option (LIO): Change "no alignment requirement." to "… no byte alignment requirement."
      14. Section 7.1 Encoding of Line ID, para 3: It is not clear why compatibility with DHCP is needed as these are two independent protocols. The section notes the derivation of the option from DHCP. It seems to be implied that compatibility is kept to allow the same processing to be used. If this is the case it should be stated. If it is not the case, the rationale would help the reader understand better why compatibility must be kept and the relation to the install base which would seem to need a software upgrade to support this draft.
      Nits: (three items)
    5. Stephen Farrell: Comment [2012-07-02]:
      - Just want to check, I'm fairly sure no change is needed but just in case... Is there any way in which the LIO for one subscriber can leak out so as to be visible to another subscriber?
      - Wouldn't it be better to say that the LIO identifies the subscriber premises or account rather than the subscriber? That is, its not a person, being identified, e.g. the title of section 3 reads like there might be something privacy sensitive here, but I don't think there is really.
      - Some fixes due to Dan Harkins' secdir review [1] comments seem to be agreed by the authors.
      [1] http://www.ietf.org/mail-archive/web/secdir/current/msg03361.html
    6. Barry Leiba: Comment [2012-07-04]:
      Former DISCUSS points, now resolved [3 July]:
      1. Suresh has confirmed that the NOT RECOMMENDED text in Section 2 is correctly meant in the 2119 sense, and shouldn't be MUST NOT.
      2. Suresh has confirmed that the AN is not physically accessible to the subscriber, so securing the network beginning at that point and continuing out is sufficient.
      Non-blocking comments; no need to respond to these:
      Authors: Thank you for being very clear in the IANA Considerations.
      *** A note to the document shepherd about the writeup: You say, in responses to writeup questions (1) and (2), that there was a great deal of discussion and disagreement about this document in the WG:
      (1) Experimental as indicated in the header. This designation was reached after a long discussion in the working group.
      (2) Working Group Summary: It was difficult reaching a consensus on this document, hence the two w.g. last calls. This approach was requested by the Broad Band Forum. The issues were resolved by some changes in the document and an agreement to have it be an experimental RFC.
      It would have been helpful to have had more explanation (perhaps in the response to question (9)) of what the issues were, why they were considered difficult problems, and how that led to Experimental status rather than... what status was it intended for before? A lot of discussion happened about why this is problematic or questionable, and how that got resolved, and ADs from other areas have to review it without any of that background. These writeups aren't just meant to say "yes" and "no", and "yeh, there were issues." This one is pretty perfunctory.
    7. Pete Resnick: Discuss [2012-07-05]:
      This is strictly for the shepherd and the IESG; authors don't need to do anything about this. Further, my intention is to clear this DISCUSS during the telechat today; this is simply a placeholder to make sure that it gets DISCUSSed on the IESG call:
      Could we get some further explanation about this document being "Experimental"? As far as I can tell, the only reason for Experimental instead of Proposed Standard is that it has limited applicability. However, that is taken care of in the Applicability Statement at the top of the document. I see no indication in the document about how the experiment might take place, what the results of such an experiment might be, or anything at all to indicate that there is an experiment of any sort going on here. I *hate* using document status as some sort of punishment, or worse as an indication that the WG did not *really* have consensus on this document. Please explain.
    8. Sean Turner: Comment [2012-07-04]:
      Picking up on Stephen's point about referring the LIO referring to "subscriber premise." The last sentence of s3 does use this term so maybe just sprinkling premise in s2/s3 title?

    Telechat:

3.1.2 Returning Items

  1. (none)

3.2 Individual Submissions Via AD

3.2.1 New Items

  1. (none)

3.2.2 Returning Items

  1. (none)

3.3 IRTF and Independent Submission Stream Documents

3.3.1 New Items

  1. 6to4 Provider Managed Tunnels (Informational)
    draft-kuarsingh-v6ops-6to4-provider-managed-tunnel-06
    Token: Ronald Bonica
    Note: ISE Submission
    IPR: Juniper's Statement of IPR Related to draft-kuarsingh-v6ops-6to4-provider-managed-tunnel-00
    Discusses/comments (from ballot draft-kuarsingh-v6ops-6to4-provider-managed-tunnel):
    1. Adrian Farrel: Comment [2012-07-04]:
      You will need to remove the two citations from the Abstract (converting them to normal text).
    2. Stephen Farrell: Discuss [2012-07-05]:
      two discuss-discussses (for the IESG, not the authors/ISE, and should be sorted out on the call):
      1) what's the story with ISE or IETF submissions where the patent application can't yet be seen (is that the case here? I couldn't see it anyway). Even with a MAD declaration, how could someone know what things from the RFC are relevant before the RFC issues if the patent application isn't (yet) public? This was recently discussed on apps-discuss about another I-D and opinions were stated that appsawg ought wait until the patent applicaiton in that case was published before adopting a draft. I guess one might argue that having the ISE put out an encumbered RFC might impinge on the IETF if we can't know detalis of the encumbrence before the RFC issues, in that the RRC might get widely deployed then come back to the IETF with the encumbrance now a fait accompli. So I just want to check if that particular wrinke has been thrashed out before or not.
      2) Was this on the agenda "for-action" but is now on for approval? Given the author/AD/IPR confluence perhaps this ought not be taken a telechat earlier than usual, just to avoid any impression of something encumbered being fast tracked? I'm fine with that given the light agenda, but it might still be worth a 2-week wait just so this isn't an oddity if someone ever looks back to the history?
    3. Stephen Farrell: Comment [2012-07-05]:
      I am personally amazed that there's anything here that can be patented without leading to frequent embarassed silences in the presence of the "inventors". They (the "inventors") have my sympathy for when they suffer that. Either that, or else the invention is so good its not obvious to someone skilled in the art even after reading the draft, but I tend to wonder. (Again, no action required here, just a comment in passing on a lamentable part of how our industry is generally behaving these days.)

    Telechat:

3.3.2 Returning Items

  1. KX509 Kerberized Certificate Issuance Protocol in Use in 2012 (Informational)
    draft-hotz-kx509-05
    Token: Stephen Farrell
    Discusses/comments (from ballot draft-hotz-kx509):
    1. Adrian Farrel: Comment [2012-06-11]:
      Nice capture of issues by Stephen in the IESG note in the write-up. (Not sure this is the right place to capture it, but so long as the ISE finds it, who cares?)
    2. Brian Haberman: Comment [2012-06-12]:
      I support Barry's DISCUSS on this document.
    3. Barry Leiba: Comment [2012-06-25]:
      [*** Update: the following comment has been addressed in the -05 version; thanks! ***]
      Stephen notes my concern about the "not (previously) standardized" bit in the abstract. But I want to elevate it above a kinda-sorta comment, and say that this document *does* constitute an end run around krb-wg if "(previously)" is not removed, in that it tries to mislead readers about the standard status of this document, and only krb-wg can write a kerberos standard. (I'm sure that's not the intent, and that the author will likely be happy to remove the word; I just want to be sure about keeping it on the record.)

    Telechat:

1244 EDT break

1250 EDT back

4 Working Group Actions

4.1 WG Creation

4.1.1 Proposed for IETF Review

  1. (none)

4.1.2 Proposed for Approval

  1. Sip Traversal Required for Applications to Work (straw)
    Token: Gonzalo

    Telechat:

4.2 WG Rechartering

4.2.1 Under evaluation for IETF Review

  1. (none)

4.2.2 Proposed for Approval

  1. (none)

5. IAB News We can use

6. Management Issues

  1. Note Well (Barry Leiba / Pete Resnick)

    Telechat:

  2. Move RFCs 3340, 3341, 3342, 3343 (APEX) to Historic (Barry Leiba)

    Telechat:

  3. List of Standards Organizations that have registered Media Types in the Standards Tree [IANA #587115] (Michelle Cotton)

    Telechat:

  4. Short Briefing on the ITU-T TSAG Meeting (Russ Housley)

    Telechat:

7. Agenda Working Group News

1323 EDT Adjourned


Valid HTML 4.01 Strict


Appendix: Snapshot of discusses/comments

(at 2012-07-05 07:29:52 PDT)

draft-ietf-intarea-ipv4-id-update

  1. Stewart Bryant: Discuss [2012-07-03]:
    RFC791 is one of the most fundamental protocols in the Internet that is now 31
    years old, and I do not think that it should be changed (or clarified) unless
    there  is some major issue that jeopardizes the operation of the Internet. The
    author makes a case for housekeeping, but does not make a case that we have a
    catastrophic problem that demands addressing. I am therefore concerned that
    publishing this is an unnecessary risk to the Internet.
    
    My rational for the above is that we have no idea of the behavior of all of the
    applications and protocols in the wild, and can never be completely sure that
    there will be no unforeseen consequences of the proposed changes in this draft.
    
    The following are some examples that bare further thought given the fundamental
    nature of IPv4.
    
    ">> IPv4 ID field MUST NOT be used for purposes other than fragmentation and
    reassembly."
    
    ">> All devices that examine IPv4 headers MUST ignore the IPv4 ID field of
    atomic datagrams.
    
    We have no idea what this field might be used for in atomic packets and hence
    we cannot be sure we are making some application non-compliant.
    
    "Deprecating the use of the IPv4 ID field for non-reassembly uses should have
    little - if any - impact."
    
    For a protocol this fundamental to the Internet, "should" is insufficient.
    
     ">> Sources of non-atomic IPv4 datagrams MUST rate-limit their output to
     comply with the ID uniqueness requirements."
    
    What is the situation today - do all existing, functioning devices comply with
    this rule?
    
    " o  IPv4 ID uniqueness applies to only non-atomic datagrams."
    
    " o  Retransmitted non-atomic IPv4 datagrams are no longer permitted to
          reuse the ID value."
    
    "o  Retransmitted non-atomic IPv4 datagrams are no longer permitted to
          reuse the ID value."
    
    Can we be sure that there is no protocol anywhere on the Internet, using atomic
    datagrams, that is also using the feature being deprecated?
    
    " >> Datagram de-duplication mechanisms MUST ignore the ID values on atomic
    datagrams."
    
    Are we certain that no device used this feature for anything?
  2. Stewart Bryant: Comment [2012-07-03]:
    In IPv4, the Identification (ID) field is a 16-bit value that is
    unique for every datagram for a given source address, destination
    address, and protocol, such that it does not repeat within the
    Maximum Segment Lifetime (MSL) [RFC791][RFC1122]. As currently
    specified, all datagrams between a source and destination of a given
    protocol must have unique IPv4 ID values over a period of this MSL,
    which is typically interpreted as two minutes (120 seconds).
    
    I just could looked at RFC791 and RFC1122, and as far as I can see
    RFC791 does not say two mins and RFC1122 is quoting from TCP
    which it notes is arbitrary.
  3. Ralph Droms: Discuss [2012-07-04]:
    1. Throughout this document, "MSL" is confused with "time
    the datagram (or any fragment of it) could be alive in the internet"
    (from RFC 791) or "typical maximum delay across the Internet" (from
    RFC 1122).  While the TCP MSL "sets an upper limit on a reasonable
    reassembly timeout value" (from RFC 1122), there is no mention of
    "MSL" in RFC 791 and there is no explicit discussion of the uniqueness
    properties of the ID field in RFC 1122.
    
    For clarity and correctness, I would like the description of the ID
    field in the Introduction to quote the text from RFC 791, with no
    mention of "MSL", and the discussion of the speed limits - esp. the
    6.4 Mbps number - to be replaced with a simple pointer to RFC 4963,
    which has a more complete and accurate discussion of the topic.  I
    also think section 5 can simply be omitted.
    
    The details are unimportant in this document (and I consider the
    document to be misleading about the details).  All that needs to be
    concluded is that high speed interfaces have to violate the uniqueness
    requirement, even for maximum delays across the Interent of 1 second.
    
    All other references to "MSL" should be replaced, perhaps with
    "maximum datagram lifetime".
    
    2. This requirement in section 6.3 does NOT derive exactly as stated
    from RFC 791:
    
       >> Sources emitting non-atomic datagrams MUST NOT repeat IPv4 ID
       values within one MSL for a given source address/destination
       address/protocol triple.
    
    The actual requirement, quoted elsewhere in the document, makes no
    direct reference to "MSL".
  4. Ralph Droms: Comment [2012-07-04]:
    1. In this text from section 4:
    
       The IPv4 ID field can be useful for other purposes. The field has
       been proposed as a way to detect and remove duplicate datagrams,
       e.g., at congested routers (noted in Sec. 3.2.1.5 of [RFC1122]) or in
       network accelerators. It can similarly be used at end hosts to reduce
       the impact of duplication on higher-layer protocols (e.g., additional
       processing in TCP, or the need for application-layer duplicate
       suppression in UDP).
    
    Is the ID field actually used in the ways suggested?
    
    2. In section 9.2:
    
       Some such devices reportedly
       feature datagram de-duplication, which relies on IP ID uniqueness to
       identify duplicates.
    
    Normally, I wouldn't raise a pedantic fuss about "which" versus
    "that".  But, in this case, I think it's important because the
    following sentence is, I think, correct while the sentence about is
    not:
    
       Some such devices reportedly
       feature datagram de-duplication that relies on IP ID uniqueness to
       identify duplicates.
  5. Adrian Farrel: Comment [2012-07-05]:
    I understand why this document was written, and support the intent of
    clarifying what is really in the wild. However, this document worries me for
    the reasons listed in Stewart's Discuss. Thus, I support Stewart's Discuss.
    
    But my concerns would be satisfied if the authors would consider repositioning
    the document as an applicability or informational document that describes what
    some implementations do in order to support faster line speeds?
  6. Stephen Farrell: Comment [2012-07-02]:
    Minor comments, feel free to take 'em or leave 'em.
    
    (Updated: I'd forgotten to note the secdir review.)
    
    - A reference for a hash-based de-duplication scheme mentioned
    in 6.1 might be useful, even if only as an illustration.
    
    - The reference to SEAL (RFC 5320) is a bit unclear.  You have
    a "SHOULD verify integrity" requirement but then say "as in
    SEAL." I'm not clear if you're saying that SEAL is a SHOULD,
    and if you are, then would that be ok? (SEAL being an
    experimental RFC.) I assume that you don't mean SEAL is a
    SHOULD-implement though, and since its given as an example in
    the next para, I think you could delete the reference from the
    SHOULD requirement bullet in section 7.
    
    - The discussion of entropy in section 11 is a little opaque,
    you could say why the entropy of a datagram is interesting. (Is
    it that people sometimes use datagram fields to seen PRNGs?).
    Steve Kent's secdir review [1] also suggested maybe changing
    or removing this.
    
       [1] http://www.ietf.org/mail-archive/web/secdir/current/msg03358.html
    
    - Typo: s/now adds much less entropy of the header/ now adds
    much less to the entropy of the header/?
  7. Barry Leiba: Comment [2012-06-30]:
    Very clear, understandable document.  Thanks.
  8. Pete Resnick: Comment [2012-07-03]:
    I share Stewart's concern about the lack of data to support this document. The
    document does not have a section on how current implementations actually do
    this, and that lack is worrying. (The shepherd writeup has *no* information on
    implementation, and that's a problem. The shepherd should have asked.) All
    things being equal, I would have silently balloted "No Objection", but I given
    his comments, I do support Stewart's DISCUSS.
  9. Sean Turner: Comment [2012-07-03]:
    As noted in Steve Kent's secdir review, the security considerations section
    should indicate whether the change proposed in this document may adversely
    affect availability, if middleboxes are not updated to account for this change.

draft-ietf-xrblock-rtcp-xr-meas-identity

  1. Brian Haberman: Comment [2012-06-26]:
    I have no problems with the publication of this document.  I do have one,
    non-blocking, question...
    
    Section 3.1 describes the APSI and provides the following statement : "If no
    identifier is provided, the length field
       MUST be set to zero."
    
    Is there a scenario where the APSI SDES item would be included without an ID
    being provided?
  2. Pete Resnick: Comment [2012-07-04]:
    3.1 "This item MUST be ignored by applications that are not configured to make
    use of it." That's a very odd construction. It sounds like you're saying that
    if I'm configured to ignore it, I MUST ignore it. What are the circumstances
    you are trying to prevent here? I don't understand.
    
    4.2 "The length of this report block in 32-bit words minus one." Perhaps this
    is an RTCP thing, but this seems like it's destined for confusion. First,
    instead of using length in bytes, you're using length in words. Do you really
    think that it is likely for a future block to be longer than 16K 32-bit words?
    Also, calling it the "block length" but then not having it be the length of the
    block seems like it's going to cause confusion. If you're going to stick with
    count of 32-bit words, call it "extension word count" or something like that.
  3. Robert Sparks: Discuss [2012-07-02]:
    Section 3.1, while defining the APSI SDES item says "If no identifier is
    provided, the length field MUST be set to zero." Why would you provide this
    item at all if the no identifier is to be provided? If there's a case where
    that makes sense, could you describe it in the document?
    
    In the new XR block, the Measurement Duration (Cumulative) field as defined can
    only represent intervals up to about 18.2 hours. What is an implementation
    supposed to do if the stream it's reporting on has been active longer than
    that? (Using the example from the monarch document, say you were reporting the
    total number of RTP packets lost since the start of the RTP session.)
  4. Robert Sparks: Comment [2012-07-02]:
    The short-title that shows in the header of each page beyond the first could be
    more descriptive. Perhaps "Measurement Identity and Duration"?
    
    In section 1.1, "This document defines a new Extended Report block that must be
    used as defined in..."  says "this block must be used". You are trying to say
    "if you use this block, you must follow the rules in ....". Perhaps this could
    be replaces with "This document defines a new Extended Report block. The use of
    Extended Report blocks is defined by RFC 3611.

draft-ietf-trill-clear-correct

  1. Stewart Bryant: Discuss [2012-07-02]:
    The following points are derived from the RTG-DIR review by Mike Shand.
    
    ===
    Section 2.1 states "Frames are not least cost routed through an
    overloaded TRILL Switch if any other path is available..."
    
    However, ISO/IEC precludes the routing of frames through an
    overloaded router, even when no other path is available.
    (see clause 7.2.8.1) [ note all references to ISO/IEC 10589 are to
    the second edition ]
    
    Please clarify in the text that there is no intention for TRILL to
    deviate from the specified  ISO/IEC 10589 behaviour.
    
    ===
    
    Section 2.3.1 seems relevant here, but I don't understand the
    description. I must be missing something, since it would appear that
    a data frame forwarded to RB2 MUST attempt to forward the frame to
    ANY non-overloaded neighbor (other than the one it was received
    from). However, surely that non overloaded neighbor might then have
    RB2 as its next hop, and forward the frame back to RB2, which would
    then be required to forward the frame possibly back to the original
    RBridge from which it was received. Clearly this is not the desired
    operation, so the text needs clarifying to make it clear what is
    really supposed to happen.
    
    ===
    
    Section 4 bullet 4
    
    I THINK this is saying that the check must be made on any "new" LSP
    even if the RBridge is in overload state, and cannot store the
    received "new" LSP.  It may be clearer to explicitly say it must do
    this even when overloaded.  The existing parenthetical remark
    doesn't seem adequate.
    
    ===
    
    The following issue was raised:
       Section 5 2nd para
    
       I don't understand the term "refragment LSPs".
    
       Is this saying that an RBridge may start with some value of
       originatingL1LSPBufferSize, and then be required to change to a
       lower value, thus necessitating that it re-generates all its LSPs
       which were previously larger than this new value?
    
    In a subsequent discussion with the reviewer the a some clarification
    was provided. Please add this clarification to the text.
    
    ===
    Section 2.2 second para
    "...and Bridge RB1 can similarly...."
    
    Can is ambiguous. Is that MAY or MUST?
  2. Stewart Bryant: Comment [2012-07-02]:
    Section 2.
    There are two instances of "pseudo node". The ISO/IEC 10589 term is pseudonode.
    (note this is correctly used in section 4)
    
    Section 2.2 first line
    s/A RBridge/An RBridge/
    
    Section 10.1 para below bullet 2.
    
    s/Two different encoding are providing above/Two different encodings are
    provided above/  (I assume)
    
    The instances of "encoding" look like they should  "encoding mechanisms" ?
  3. Adrian Farrel: Comment [2012-07-05]:
    Section 1.2 is a useful section to have at the top of the document.
    I would have liked it more had it:
    
    - listed each non-backward compatible feature (with a section
      reference) instead of saying "several"
    
    - explained in summary how non-compatiblity is handle in
      general
  4. Stephen Farrell: Comment [2012-06-19]:
    - typo in abstract: s/provide/provides/ (same sentence is
    correct in intro:-)
    
    - 2nd para of section 5 is odd, it says its about the case
    where nothing is known, but then says "if it is known that
    other..." I'd say replacing the opening phrase with some
    more specific might work, e.g. "If not all MTU information
    is known for the entire campus..."
    
    - 10.1: "...in the Down state out a port..." is an odd
    phrase, maybe s/out/for/ or something?
    
    - 10.1: What is a DRB?
    
    - 10.2: I think this needs rephrasing/fixing: "Therefore, the DRB
    SHOULD NOT appointed an RBridge in overload as Appointed Forwarder for
    an VLAN unless there is no alternative." I'm not sure what it
    means really.
  5. Barry Leiba: Comment [2012-06-14]:
    As this document incorporates errata reported against the other three RFCs, but
    leaves those three current (not Obsoleted), it would be nice to list the
    RFC-numbers+errata-numbers that are resolved by this document.  How hard would
    that be to add?
  6. Pete Resnick: Comment [2012-07-04]:
    This is strictly a procedural point for the chair/shepherd; The authors may
    ignore this.
    
    The ballot writeup makes me very grumpy and it makes me concerned that the
    chair/shepherd did not do their due diligence in passing this document to the
    IESG. The chair/shepherd being a former AD, I have to assume that this was just
    a sloppy writeup and not a real problem. But I would like to see a real writeup
    for the record. I did not make this a DISCUSS since I am sure this COMMENT will
    generate the right outcome.
    
    The writeup template says for "Working Group Summary":
    
      Was there anything in WG process that is worth noting? For
      example, was there controversy about particular points or
      were there decisions where the consensus was particularly
      rough?
    
    Your response was:
    
      There was consensus in the working group in favor of the document.
    
    That's all you're going to say? Perhaps you'd like to add, "Unlike every other
    document which has gotten serious review in the IETF, this one generated no
    controversy at all and there were no points of contention. At the end of each
    face-to-face meeting, the entire WG held hands and sang songs together." :-)
    Seriously, we all assume there was consensus since you are submitting the
    document; you would not have submitted it otherwise. To make sure that due
    diligence was done, the answer the IESG is interested in is what the nature of
    the consensus was. At the very least say, "There was nothing particularly
    noteworthy about the consensus around this document. In the end, there was no
    roughness apparent for any part of the consensus." At least then we could see
    that you answered the question.
    
    Then in the "Document Quality", it asks:
    
      Are there existing implementations of the protocol? Have a
      significant number of vendors indicated their plan to
      implement the specification? Are there any reviewers that
      merit special mention as having done a thorough review,
      e.g., one that resulted in important changes or a
      conclusion that the document had no substantive issues?
    
    Your answer was:
    
      The document has been carefully reviewed in the WG and by the
      document shepherd.
      The document was forwarded to the IS-IS WG mailing list, which
      resulted in some additional improvements.
    
    First of all, the document itself says that it is making
    non-backward-compatible changes to a protocol. I would *hope* that there is a
    fair bit of implementation of the new stuff already that would justify such
    changes. But you mention no existing implementations, nor any indication of
    vendors taking on such implementations, in your writeup. And as far as
    "reviewers that merit special mention", you call out "the WG and the document
    shepherd". If the WG and the document shepherd *hadn't* done thorough reviews,
    that would be worthy of mention; that they have done their jobs is not. (On the
    other hand, the IS-IS WG *is* worthy of mention.)
    
    This document is outside of my area of expertise. The only serious review I do
    is look through the document for Applications impacts and look to the writeup
    to see that no procedural nonsense was missed. This writeup is a pretty serious
    miss. Please give at least some indication on the implementation question.

draft-ietf-cdni-problem-statement

  1. Ronald Bonica: Comment [2012-06-20]:
    Sorry for the late defer. I really want to read this document and I won't get
    to it tonight.
  2. Benoit Claise: Comment [2012-06-25]:
    [Thanks for addressing my DISCUSS and COMMENT, which I kept for the record
    below, since this draft will be on the next IESG telechat]
    
    DISCUSS:
    
    Preliminary note: between the 3 different chartered items (problem statement,
    uses cases, and requirement), I'll be specifically checking for the
    manageability and operational requirements in the requirement document. So
    hopefully the uses cases document will not only address what the use cases are,
    but how the operators plan on supporting those use cases.
    
    The only manageability aspect concern I noticed is
    
       o  CDNI Logging interface: This interface allows the Logging system
          in interconnected CDNs to communicate the relevant activity logs
          in order to allow log consuming applications to operate in a
          multi-CDN environments.  For example, an upstream CDN may collect
          delivery logs from a downstream CDN in order to perform
          consolidated charging of the CSP or for settlement purposes across
          CDNs.  Similarly, an upstream CDN may collect delivery logs from a
          downstream CDN in order to provide consolidated reporting and
          monitoring to the CSP.
    
    The Logging System doesn't mention fault management, which is consistent with
    the above text. However, the problem I have is that section 4.3 "CDNI Logging
    Interface" mentions "events" for the first time.
    
       The CDNI Logging interface enables details of logs or events to be
       exchanged between interconnected CDNs, where events could be for
       example log records related to the delivery of content (similar to
       the log records recorded in a web server's access log) as well as
       real-time or near-real time events before, during or after content
       delivery and operations and diagnostic messages.
    
    So clearly, the intend here is that you want to cover fault management as well,
    right? Please be consistent between the Logging System definition, the CDNI
    Logging Interface and this section 4.3
    
    COMMENT:
    
    - the terminology order seemed weird initially when I had to search for a
    specific item. However, while reading through it, the order nicely helps the
    reader. Thanks.
    
    - the surrogate definition could be improved to express that the device can be
    caching content. This is mentioned later on in the draft:
    
       CDNs allow caching of content closer to the edge of a network so that
       a given item of content can be delivered by a CDN Surrogate (i.e. a
       cache) to multiple User Agents (and their End Users) without
       transiting multiple times through the network core (i.e from the
       content origin to the surrogate).
    
    - In the Appendix B table of content, there is:
    
       Appendix B.  Additional Material . . . . . . . . . . . . . . . . . 27
         B.1.  Non-Goals for IETF . . . . . . . . . . . . . . . . . . . . 27
         B.2.  Related standardization activites  . . . . . . . . . . . . 29
           B.2.1.  IETF CDI Working Group (Concluded) . . . . . . . . . . 30
           B.2.2.  3GPP . . . . . . . . . . . . . . . . . . . . . . . . . 30
           B.2.3.  ISO MPEG . . . . . . . . . . . . . . . . . . . . . . . 31
           B.2.4.  ATIS IIF . . . . . . . . . . . . . . . . . . . . . . . 32
           B.2.5.  CableLabs  . . . . . . . . . . . . . . . . . . . . . . 32
           B.2.6.  ETSI MCD . . . . . . . . . . . . . . . . . . . . . . . 32
           B.2.7.  ETSI TISPAN  . . . . . . . . . . . . . . . . . . . . . 32
           B.2.8.  ITU-T  . . . . . . . . . . . . . . . . . . . . . . . . 33
           B.2.9.  Open IPTV Forum (OIPF) . . . . . . . . . . . . . . . . 33
           B.2.10. TV-Anytime Forum . . . . . . . . . . . . . . . . . . . 33
           B.2.11. SNIA . . . . . . . . . . . . . . . . . . . . . . . . . 34
           B.2.12. Summary of existing standardization work . . . . . . . 34
         B.3.  Related Research Projects  . . . . . . . . . . . . . . . . 36
           B.3.1.  IRTF P2P Research Group  . . . . . . . . . . . . . . . 36
           B.3.2.  OCEAN  . . . . . . . . . . . . . . . . . . . . . . . . 36
           B.3.3.  Eurescom P1955 . . . . . . . . . . . . . . . . . . . . 36
         B.4.  Relationship to relevant IETF Working Groups . . . . . . . 37
    
    B.1 is useful: too many times we don't express which problem(s) we don't plan
    on addressing Note that there is a little important line in there that is worth
    stressing: "Element management interfaces" B.2 will be obsolete in a year from
    now. Personally I would not include this one. No strong feelings though B.3 is
    not interesting, except maybe the IRTF P2P which could go in B.4 B.4 is very
    important to us.
    
    Conclusion: I would definitively keep B1 and B4, maybe B2, and not B3 (except
    IRTF)
  3. Adrian Farrel: Comment [2012-07-05]:
    I found Appendix A a little suspect. While it demonstrates that the problem
    could be solved, it also seems to end-run the discussion of which protocol
    solution should be developed. I would like it if the introduction indicated
    that the content of the Appendix is purely examples and that further analysis
    will be made before the WG decides on the correct solutions.
  4. Russ Housley: Comment [2012-06-20]:
      As suggested in the Gen-ART Review by Wassim Haddad, please define
      "Quality of Experience".  This phrase is mentioned four times in the
      document.
  5. Barry Leiba: Comment [2012-06-23]:
    All comments addressed in the -07 version.  Thanks for taking the time!

draft-ietf-6man-lineid

  1. Ralph Droms: Discuss [2012-07-04]:
    1. In section 4:
    
       This document recommends tunneling Neighbor discovery packets inside
       another IPv6 packet that uses a destination option to convey line
       identification information.
    
    Is this an RFC 2119 recommendation?  Under what circumstances would a
    device not encapsulate the original RS as recommended, and what are
    the consequences of not using encapsulation?
    
    2. Following up on point 1, throughout the rest of the document there
    is text that is conditional on, e.g., "receives a tunneled Router
    Solicitation".  What is the behavior in the case of a non-tunneled RS
    that includes an LIO?
    
    3. Is the link between an AN and the Edge Router a point-to-point
    link?  If not, it seems to me that the Line ID MUST be unique across
    all ANs that share a link to the Edge Router.
    
    In the case where an AN
    sends an encapsulated RS to the Edge Router with the source address
    set to the unspecified address, the Edge Router will multicast the
    corresponding RA, and the RA will be received by all the ANs on that
    link.  If two different ANs happen to use the same Line ID, they will
    both then forward that RA on the identified subscriber line (and one
    of the ANs will be wrong).
    
    4. For completeness, the document should have text requiring the AN to
    join the All-BBF-Access-Nodes multicast group.
    
    5. In section 6.2, is the "circuit identifier corresponding to the
    logical access loop port of the Access Node to which the RA MUST be
    sent" the same as the Line ID field from the received RS?  If not,
    where does that circuit identifier come from?
    
    6. Also in section 6.2, there are two potentially contradictory
    requirements on the "link-layer destination address of the tunneled
    RA" (I assume the "tunneled RA" is the outer IPv6 datagram):
    
       The link-layer destination
       address of the tunneled RA MUST be resolved using regular Neighbour
       Discovery procedures.
    
       The link-layer destination address of the tunneled RA MUST
       be set to the unicast link-layer address of the Access Node that sent
       the tunneled Router Solicitation which is being responded to.
    
    7. I don't see any text in section 6.2 about how a prefix is
    associated with the Line ID in an LIO.  Section 8 describes
    reclamation of allocated prefixes, which implies there is a mechanism
    for allocating prefixes, but section 6.2 seems to simply assume that
    there is a prefix that corresponds to the received LIO.
  2. Ralph Droms: Comment [2012-07-04]:
    1. I'm curious about the use of "Ethernet" as an adjective
    throughout the document.  For example, in the abstract, what does
    "Ethernet" mean in the phrase "Ethernet based aggregation networks",
    and does "Ethernet" add anything to the understanding of the sentence?
    
    2. From section 2:
    
       While this protocol improves
       the the robustness of relying on Router Solicitations in lieu of
       DHCP, this results on some limitations specified below.
    
    In addition to the typo "the the" in the second line, I found the
    sentence a little confusing.  Perhaps:
    
       While this option improves the reliability of operation in
       deployments that use Router Solicitations rather than DHCP, there
       are some limitations as specified below.
    
    3. In section 5.1:
    
       Otherwise, when the end-device sends out a Router Solicitation and
       uses a link-local address in the Source Address field, the AN MUST
       copy this address into the Source Address field of the outer IPv6
       datagram.  In all other cases, the AN MUST use the unspecified
       address as the Source Address of the outer IPv6 datagram.
    
    This text is a little confusing to me, because of the "link-local"
    qualifier in the second line.  Is it just the case that the AN copies
    the Source Address from the received RS, regardless of whether or not
    it is the unspecified address?
    
    4. Two questions about this text from section 6.2:
    
       If the Source Address field of the received IPv6 datagram
       was not the unspecified address, the Edge router MUST copy this
       address into the Destination Address field of the outer IPv6 datagram
       sent back towards the Access Node.  The link-layer destination
       address of the tunneled RA MUST be resolved using regular Neighbour
       Discovery procedures.  Otherwise, the destination address of the
       outer IPv6 datagram MUST be set to the well-known link-local scope
       All-BBF-Access-Nodes multicast address [to be allocated].
    
    Is the "tunneled RA" the "outer IPv6 datagram"?
    
    Does the "Otherwise" apply to the first "If" in the quoted text?
    
    5. Also in section 6.2, it would be clearer to move the text about the
    destination address of the inner RA up to the first paragraph, where
    the RA is specified as constructed according to RFC 4861.
  3. Wesley Eddy: Comment [2012-07-05]:
    I agree with Pete's DISCUSS.
  4. Adrian Farrel: Comment [2012-07-05]:
    I am balloting "yes" but there are some minor comments from Dave
    Sinicrope's Routing Directorate review. Please consider them
    before advancing the document for publication.
    
     1.  Section 1.1 Terminology & all related sections:  Throughout
         several sections of the document the term "subscriber" is used.
         It is not defined in the Terminology.  It seems this is often
         used synonimously with End-device which is defined.  This is
         particularly true of section 2. Applicability Statement.
         Please define "subscriber" or substitute a defined term (e.g.,
         "end device") for "subscriber" throughout the document.
    
     2.  Section 1.1 Terminology & all related sections:  Throughout
         several sections of the document the term "host" is used. While
         "host" is defined in the Terminology, it seems this is often
         used synonimously with End-device where it would be better to
         use the latter term.  This is particularly true of section 2.
         Applicability Statement paras 3 and 5.  Please substitute "end
         device" for "host" throughout the document where this is
         applicable.
    
     3.  Section 2. Applicability Statement: This section focuses on the
         limitations of the draft, but it should elaborate more on the
         applicability and usefulness of the draft to support stateless
         auto configuration.
    
     4.  Section 2. Applicability Statement, para 3, last 2 sentences:
         These statements make it appear that all broadband networks rely
         on the [end device] MAC address and that it is not recommended
         that this draft be used for networks that require the [end
         device] MAC address, leading the reader to the possible conclusion
         that this draft has little use.  In practice some broadband
         networks use the [end device] MAC address, but not all making the
         draft far more applicable than indicated.  Please qualify the
         penultimate sentence of paragraph 3 "currently used in <"some"
         or "many"> Broadband networks"
    
     5.  Section 2 Applicability Statement: The document would benefit
         from a brief flow diagram showing the Router Solicitation &
         Router Advertisement flows between the nodes shown in Figure 1.
    
     6.  Section 4 Basic Operation, last sentence:  The last sentence is
         not clear as to why a packet with a hop limit not set to 255 is
         discarded.  Please briefly elaborate (e.g., "because they appear
         to be more than a single hop away.")
    
     7.  Section 5.1 On receiving a Router Solicitation: Add a figure
         showing the construction of a tunneled Router Solicitation.  Add
         "See Figure X" within the paragraph to reference the figure.
    
     8.  Section 5.2.1 Identifying tunneled Router Advertisements: It is
         unclear, at least initially, what is meant by "All BBF Access
         Nodes".  Please clarify its use as done in section 6.2, noting
         that it is a well known, link-local scoped multicast address.
    
     9.  Section 5.3 On detecting a subscriber circuit coming up, para 1,
         "When the access node": I believe what is meant by "When the
         access node detects that a subscriber circuit has come up" is
         really "Each time the access node detects that a subscriber
         circuit has come up".  "When the" could be misinterpreted as
         meaning "the first time".  Please change "When the" to "Each
         time" in this sentence.
    
     10. Section 6.1 On receiving a Tunneled Router Solicitation: It is
         not clear how the edge router recognizes a tunneled RS. Please
         briefly elaborate on how this datagram is identified by the
         edge router.
    
     11. Section 6.1 On receiving a Tunneled Router Solicitation, "The
         link-layer destination address of the tunneled RA MUST".  There
         are two statements in this paragraph that start with this clause
         that seem to be contradictory.  Please reconcile and clarify.
    
     12. Section 6.3 Sending periodic unsolicited Router Advertisements:
         This section would benefit from a forward reference to section 8
         Garbage collection of unused prefixes to help the reader
         understand when and how the prefixes are eventually removed or
         cleared.
    
     13. Section 7 Line Identification Destination Option (LIO): Change
         "no alignment requirement." to "… no byte alignment
         requirement."
    
     14. Section 7.1 Encoding of Line ID, para 3: It is not clear why
         compatibility with DHCP is needed as these are two independent
         protocols.  The section notes the derivation of the option from
         DHCP.  It seems to be implied that compatibility is kept to allow
         the same processing to be used.  If this is the case it should be
         stated.  If it is not the case, the rationale would help the
         reader understand better why compatibility must be kept and the
         relation to the install base which would seem to need a software
         upgrade to support this draft.
    
    Nits:
    
     1.  Section 2 Applicability Statement, para 3: This paragraph should
         be broken into two paragraphs as the latter sentences explain
         limitations and recommendations of the draft itself while the
         earlier sentences explain operation of Router Solicitation and
         Advertisement.
    
     2.  Section 5.1 On receiving a Router Solicitation:  Clarify the use
         of "the unspecified address", with a reference or context. (e.g.,
         "the unspecified address defined in RFC"
    
     3.  General: inconsistent use of capitalization on "Edge Router"/"edge
         router"/"Edge router"
  5. Stephen Farrell: Comment [2012-07-02]:
    - Just want to check, I'm fairly sure no change is needed but
    just in case... Is there any way in which the LIO for one
    subscriber can leak out so as to be visible to another
    subscriber?
    
    - Wouldn't it be better to say that the LIO identifies the
    subscriber premises or account rather than the subscriber?
    That is, its not a person, being identified, e.g. the title of
    section 3 reads like there might be something privacy
    sensitive here, but I don't think there is really.
    
    - Some fixes due to Dan Harkins' secdir review [1] comments
    seem to be agreed by the authors.
    
       [1] http://www.ietf.org/mail-archive/web/secdir/current/msg03361.html
  6. Barry Leiba: Comment [2012-07-04]:
    Former DISCUSS points, now resolved [3 July]:
    
    1. Suresh has confirmed that the NOT RECOMMENDED text in Section 2 is correctly
    meant in the 2119 sense, and shouldn't be MUST NOT.
    
    2. Suresh has confirmed that the AN is not physically accessible to the
    subscriber, so securing the network beginning at that point and continuing out
    is sufficient.
    
    ========
    Non-blocking comments;  no need to respond to these:
    
    Authors:
    Thank you for being very clear in the IANA Considerations.
    
    *** A note to the document shepherd about the writeup:
    You say, in responses to writeup questions (1) and (2), that there was a great
    deal of discussion and disagreement about this document in the WG:
    
    > (1) Experimental as indicated in the header. This designation
    > was reached after a long discussion in the working group.
    
    > (2) Working Group Summary
    > It was difficult reaching a consensus on this document, hence the two w.g.
    last > calls. This approach was requested by the Broad Band Forum. The issues
    were > resolved by some changes in the document and an agreement to have it be
    an > experimental RFC.
    
    It would have been helpful to have had more explanation (perhaps in the
    response to question (9)) of what the issues were, why they were considered
    difficult problems, and how that led to Experimental status rather than... what
    status was it intended for before?  A lot of discussion happened about why this
    is problematic or questionable, and how that got resolved, and ADs from other
    areas have to review it without any of that background.  These writeups aren't
    just meant to say "yes" and "no", and "yeh, there were issues."  This one is
    pretty perfunctory.
  7. Pete Resnick: Discuss [2012-07-05]:
    This is strictly for the shepherd and the IESG; authors don't need to do
    anything about this. Further, my intention is to clear this DISCUSS during the
    telechat today; this is simply a placeholder to make sure that it gets
    DISCUSSed on the IESG call:
    
    Could we get some further explanation about this document being "Experimental"?
    As far as I can tell, the only reason for Experimental instead of Proposed
    Standard is that it has limited applicability. However, that is taken care of
    in the Applicability Statement at the top of the document. I see no indication
    in the document about how the experiment might take place, what the results of
    such an experiment might be, or anything at all to indicate that there is an
    experiment of any sort going on here. I *hate* using document status as some
    sort of punishment, or worse as an indication that the WG did not *really* have
    consensus on this document. Please explain.
  8. Sean Turner: Comment [2012-07-04]:
    Picking up on Stephen's point about referring the LIO referring to "subscriber
    premise."  The last sentence of s3 does use this term so maybe just sprinkling
    premise in s2/s3 title?

draft-kuarsingh-v6ops-6to4-provider-managed-tunnel

  1. Adrian Farrel: Comment [2012-07-04]:
    You will need to remove the two citations from the Abstract (converting
    them to normal text).
  2. Stephen Farrell: Discuss [2012-07-05]:
    2 discuss-discussses (for the IESG, not the authors/ISE, and should be
    sorted out on the call):
    
    1) what's the story with ISE or IETF submissions where the patent application
    can't yet be seen (is that the case here? I couldn't see it anyway). Even with
    a MAD declaration, how could someone know what things from the RFC are relevant
    before the RFC issues if the patent application isn't (yet) public? This was
    recently discussed on apps-discuss about another I-D and opinions were stated
    that appsawg ought wait until the patent applicaiton in that case was published
    before adopting a draft. I guess one might argue that having the ISE put out an
    encumbered RFC might impinge on the IETF if we can't know detalis of the
    encumbrence before the RFC issues, in that the RRC might get widely deployed
    then come back to the IETF with the encumbrance now a fait accompli. So I just
    want to check if that particular wrinke has been thrashed out before or not.
    
    2) Was this on the agenda "for-action" but is now on for approval? Given the
    author/AD/IPR confluence perhaps this ought not be taken a telechat earlier
    than usual, just to avoid any impression of something encumbered being fast
    tracked?  I'm fine with that given the light agenda, but it might still be
    worth a 2-week wait just so this isn't an oddity if someone ever looks back to
    the history?
  3. Stephen Farrell: Comment [2012-07-05]:
    I am personally amazed that there's anything here that can be patented
    without leading to frequent embarassed silences in the presence of the
    "inventors". They (the "inventors") have my sympathy for when they suffer
    that. Either that, or else the invention is so good its not obvious to someone
    skilled in the art even after reading the draft, but I tend to wonder. (Again,
    no action required here, just a comment in passing on a lamentable part
    of how our industry is generally behaving these days.)

draft-hotz-kx509

  1. Adrian Farrel: Comment [2012-06-11]:
    Nice capture of issues by Stephen in the IESG note in the write-up. (Not sure
    this is the right place to capture it, but so long as the ISE finds it, who
    cares?)
  2. Brian Haberman: Comment [2012-06-12]:
    I support Barry's DISCUSS on this document.
  3. Barry Leiba: Comment [2012-06-25]:
    [*** Update: the following comment has been addressed in the -05 version;
    thanks! ***]
    
    Stephen notes my concern about the "not (previously) standardized" bit in the
    abstract.  But I want to elevate it above a kinda-sorta comment, and say that
    this document *does* constitute an end run around krb-wg if "(previously)" is
    not removed, in that it tries to mislead readers about the standard status of
    this document, and only krb-wg can write a kerberos standard.  (I'm sure that's
    not the intent, and that the author will likely be happy to remove the word; I
    just want to be sure about keeping it on the record.)