IESG Narrative Minutes

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

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

Corrections from: Pete

1 Administrivia

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

2. Protocol Actions

2.1 WG Submissions

2.1.1 New Items

  1. EAP Re-authentication Protocol Extensions for Authenticated Anticipatory Keying (ERP/AAK) (Proposed Standard)
    draft-ietf-hokey-erp-aak-09
    Token: Stephen Farrell
    IPR: Huawei Technologies Co.,Ltd's Statement about IPR related to draft-ietf-hokey-erp-aak-03
    Discusses/comments (from ballot 4022):
    1. Adrian Farrel: Comment [2012-02-14]:
      Please think about wether it would be useful to create a registry for the flags fields in the packets so that it is easier to track them if/when future extensions come along.
    2. Sean Turner: Discuss [2012-02-15]:
      s5.4 and 9: Need to register CAP-Identifier.
    3. Sean Turner: Comment [2012-02-15]:
      some nits:

    Telechat:

  2. Diameter Support for Proxy Mobile IPv6 Localized Routing (Proposed Standard)
    draft-ietf-dime-pmip6-lr-09
    Token: Dan Romascanu
    Note: Lionel Morand (lionel.morand@orange.com) is the document shepherd.
    Discusses/comments (from ballot 4055):
    1. Stephen Farrell: Comment [2012-02-14]:
      A question and two comments, that could become discusses, depending on the answer to the question. At present, I'm not sure if there is a real issue here or not.
      There could be a use-case where the MN's MAG is under the MN's control. If there were, or if a MAG were compromised, or a bad-actor, then this protocol could be used to track any participating CN (whose address is known) at the level of the MAG to which it is anchored, but I'm not sure how much of a concern that ought be. Note: I think (but am not sure) that this is different from a "normally" bad MAG in most of pmipv6, in that it could impact on a whole bunch of CN's and not just on the MN anchored to the bad-MAG.
      So, the question: How fine-grained a location would me knowing your current MAG give me and is such potential tracking by a bad-MAG a concern?
      1. If this is a concern maybe it'd be useful to add something like the following to the security considerations:
      "An authorised MAG could in principle track the movement of any participating CN at the level of the MAG to which they are anchored. If such a MAG were compromised, or under the control of a bad-actor, then such tracking could represent a privacy breach for the set of tracked CN's. In such a case the traffic pattern from the compromised MAG might be notable so monitoring for e.g. excessive queries from MAGs might be worth while."
      2. Assuming again that the answer to my question is that it is a concern, ought there be some way in which e.g. MN2 in figure 6 could be part of the authorisation process for this kind of feature? Perhaps one could note that deployments that wanted to be privacy friendly could provide some way to allow for a user to consent to this? And going further of course any such consent might change over time I guess.
    2. Russ Housley: Discuss [2012-02-13]:
      The authors have agreed to make some changes based on the Gen-ART Review by Elwyn Davies on 2-Feb-2012. The changes have not been posted yet.
    3. Peter Saint-Andre: Comment [2012-02-15]:
      The term "Fully Qualified Domain Name" is undefined (specifically, it's unclear whether internationalized domain names are supported), but it appears that's the fault of RFC 5779 and RFC 5447.
    4. Robert Sparks: Discuss [2012-02-14]:
      The relationship between this and the document specifying "Localized Routing for Proxy Mobile IPv6" <https://datatracker.ietf.org/doc/draft-ietf-netext-pmip-lr/> (currently in last call) is not clear. What level of coordination exists between DIME and NETEXT on these documents? Are the authorization steps described in this document actually part of the protocol being specified by netext?
      Note that neither document currently references the other.
    5. Sean Turner: Comment [2012-02-15]:
      Curious to hear the response to Stephen's question.

    Telechat:

  3. Bulk DHCPv4 Lease Query (Proposed Standard)
    draft-ietf-dhc-dhcpv4-bulk-leasequery-05
    Token: Ralph Droms
    Note: Ted Lemon (ted.lemon@nominum.com) is the document shepherd.
    Discusses/comments (from ballot 4062):
    1. Stewart Bryant: Discuss [2012-02-14]:
      This is a Discuss because I want the opportunity to discuss with other members of the IESG on the call.
      This document has seven front page authors, against a strong guideline of five. Other document teams have had to make very painful choices as a consequence of this policy. Unless there are exceptional reasons the number of authors on the number of front page authors should be reduced to conform to the guideline.
    2. Wesley Eddy: Discuss [2012-02-15]:
      The TSVDIR review comments from Joe Touch need to be addressed:
    3. Stephen Farrell: Discuss [2012-02-13]:
      #1 How does the TCP framing interact with DHCP authentication which only partly covers individual messages, was not designed for this kind of bulk usage, and hence probably allows various bad things to happen? E.g. re-ordering or snipping out individual messages seems to be possible or moving DHCPLEASEQUERYDONE earlier in the sequence. I think that needs to be understood, and maybe it is, but I don't get it from reading this nor from the referenced RFCs, at least not without doing a lot more work that, presumably the WG/coders already did and that could be documented here. (If you ended up saying "yes" to SSH or TLS in #3 below, this would be moot.)
      #2 Maybe replay is possible too if xid is predictable or always starts at 1 or whatever. I'd suggest putting in a MUST for xid to be hard to guess and very unlikely to collide over the life of a DHCP authentication key at least. (If you ended up saying "yes" to SSH or TLS in #3 below, this would be moot.)
      #3 If DHCP auth is actually mythical, in terms of real usage (is it?) then wouldn't it be better to just run this over mutually-authenticated SSH or TLS? (Possibly with a PSK ciphersuite if you don't like private keys on the relay.) If not, why not? If its likely that the boxes in the main use-case for this (server, relay-agent) use SSH or TLS for something else (e.g. netconf or whatever) then that might not be very hard to do at all. Did the WG consider this?
      #4 The secdir review raised the issue of a query like this coming from a DHCP client (or elsewhere); the response [1] was that you could firewall that, which should I guess be noted in the security considerations, but I think the potential privacy consequences of answering these queries, esp without authentication should also be noted as in the reviewer's comment.
      [1] http://www.ietf.org/mail-archive/web/secdir/current/msg03100.html
    4. Stephen Farrell: Comment [2012-02-13]:
      - The write up's technical and working group summaries are the same. If that's a cut'n'paste accident, it might be worth putting the right working group summary back there.
      - Would it be worthwhile noting that this protocol is not intended to be used to produce evidence (i.e. to be used in court) as to who had what IP address when? (And is that actually the case? Would it be possibly bad/misleading evidence if so used?)
      - Is it right, in section 4, to say that bindings are returned in DHCPv4 "packets"? Maybe messages would be better?
      - What are the consequences of having guessable "Relay Identifier" or "remote ID" or "vpn-id" values in queries? The concern is whether such guessable values might allow for a lot of probing.
      - 6.2.8 "when 2 or more servers work together" I'm not sure if there's an implied MUST or SHOULD for including this option in this case. If not then a requestor can't really know for sure they've got the full info on an IP address. That may well be ok, but I think it'd be good to be clear about it.
      - Do the query by MAC address or client-id options means that personally identifying information about a user might be sent further upstream that normal? I don't think so but just wanna check. If it did, that might be worth a note to the effect that its another potential privacy issue that operators should worry about. (But with no change to the spec otherwise I'd guess.)
      - server-identifier in only 1st response seems slightly fragile if the overall session doesn't have data integrity (e.g. via TLS) but I guess that's a fairly minor issue.
    5. Peter Saint-Andre: Comment [2012-02-15]:
      Please consider adding references for "NTP" and "UTF-8".
      What is a "UTF-8 ASCII VPN identifier"??
    6. Robert Sparks: Comment [2012-02-13]:
      In Section 7.7 the requirement "MUST interleave replies" is not clear. It could be read to mean an implementation has to wait to send additional replies to the first query until it has the information it needs to start answering a second (at the extreme, a strict round-robin of the responses). Is the requirement you are really trying to capture "MUST NOT block sending replies on new queries until all replies for the existing query are complete."?
      Is there a way for a server to say "the response to your query is too big, please ask again for a subset"? Consider adding a discussion to the document about what a client could do if a server is sending it more data than it is prepared to deal with.
      RFC5226 defines "IETF Review" as the well-known IANA policy name you are using in section 10. (That RFC notes that this was formerly called "IETF Consensus" in RFC2434.) The document should use that name. RFC5226 is clear on what that policy name means - you invite argument by attempting to restate or clarify the policy in this document. Please consider removing the sentences that start "Basically, this means...".

    Telechat:

  4. Prefix Exclude Option for DHCPv6-based Prefix Delegation (Proposed Standard)
    draft-ietf-dhc-pd-exclude-04
    Token: Ralph Droms
    Note: Ted Lemon (ted.lemon@nominum.com) is the document shepherd.
    Discusses/comments (from ballot 4064):
    1. Jari Arkko: Comment [2012-02-16]:
      Thanks for writing this draft, it is very important addition to DHCPv6.

    Telechat:

  5. Forcerenew Nonce Authentication (Proposed Standard)
    draft-ietf-dhc-forcerenew-nonce-04
    Token: Ralph Droms
    Note: Ted Lemon (ted.lemon@nominum.com) is the document shepherd.
    Discusses/comments (from ballot 4065):
    1. Jari Arkko: Comment [2012-02-16]:
      Thanks for writing this document. I believe it is ready to move forward, despite the unsubstantiated worries about weakening RFC 3118 security :-)
      One small comment: "The server SHOULD NOT include the nonce in an ACK when responding to a renew unless a nonce was generated."
      ... unless a *new* nonce was generated ...?
    2. Adrian Farrel: Comment [2012-02-14]:
      Should you describe a mechanism whereby the nonce can be changed?
      Section 6: Please don't refer to this as a "proposal". It is just about to become an RFC. Use "document".
    3. Stephen Farrell: Comment [2012-02-13]:
      - I agree with Russ' discuss based on the gen-art review.
      - I like the idea as explained in the response to the gen-art review, but didn't get that from the abstract or writeup so I think fixing those to make the purpose of this clear (make off-path attacks hard) would be good.
      - What is an RDM? (3.1.3) Better to spell that out rather than force the reader off to rfc 3115.
      - Shouldn't there be a requirement to use a different "reconfigure key value" every single time? If those are re-used, then a client could pretend to be the server.
      - I guess I wondered if you can do this, why can't the server just sign the response with a private key?
      - Should there be an IANA registry for the type field here in case you ever want more than hmac-md5?
    4. Russ Housley: Discuss [2012-02-12]:
      The Gen-ART Review by Ben Campbell on 6-Feb-2012 raised some significant concerns, and the authors agree that some updates to the document are needed.
    5. Pete Resnick: Comment [2012-02-14]:
      The portion of 3.1.2 which starts "The following fields are set in an DHCP authentication option for the Forcerenew Nonce Authentication Protocol:" is poorly written. The fields are not listed in order, the explanation for length is incorrect. This needs to be rewritten.
    6. Peter Saint-Andre: Comment [2012-02-15]:
      I concur with the DISCUSS that Russ lodged (based on the Gen-ART review).
    7. Robert Sparks: Discuss [2012-02-13]:
      The introduction motivates this extension by claiming there are specialized environments in which the mandatory coupling between FORCERENEW and 3118 DHCP Authentication could be relaxed, but doesn't restrict the mechanism discussed in this document to those environments. There is some discussion already taking place in response to the genart review touching on this topic indicating there should be a restriction, but it's not clear yet what that the intended restriction is.
      Doesn't the client's computation confirming the same HMAC-MD5 over the message need to be performed the same way the server computes the value (as described in the last paragraph of 3.1.3)? Should the instructions for zeroing the HMAC-MD5 field in the message fed into the computation be repeated here?
    8. Sean Turner: Discuss [2012-02-15]:
      Seems the DHCP option needs to indicate the algorithm(s) supported by the server/client? If HMAC-CoolNewAlg gets registered for use with DHCP won't you need to indicate whether HMAC-CoolNewAlg and/or HMAC-MD5 is supported?
      Assuming we always use HMAC-MD5 then you'll have an output of 128 bits, but what happens if DHCP starts to use HMAC-SHA-256 - i.e., are we always going to use HMAC-CoolNewAlg-128?
    9. Sean Turner: Comment [2012-02-15]:
      A couple 2119 issues maybe:
      s3: r/The FORCERENEW message must be authenticated/The FORCERENEW message MUST be authenticated ?
      s3.1.1: r/authentication should ignore/authentication SHOULD ignore ?
      And for the algs supported:
      s3.1.2: Maybe for the algorithm you should point to the IANA registry for DHCP Algorithm Name Space Values (http://www.iana.org/assignments/auth-namespaces/auth-namespaces.xml) but say that currently only HMAC-MD5 is supported? The alg used in this wouldn't ever differ right?

    Telechat:

  6. RTP Payload Format for SMPTE 336M Encoded Data (Proposed Standard)
    draft-ietf-payload-rtp-klv-03
    Token: Robert Sparks
    Note: The document shepherd is Ali Begen (abegen@cisco.com).
    Discusses/comments (from ballot 4073):
    1. Ron Bonica: Comment [2012-02-15]:
      I strongly support Adrian's DISCUSS. In fact, the IESG should probably issue guidance about this issue.
    2. Adrian Farrel: Discuss [2012-02-14]:
      It bothers me somewhat that a normative reference is only available for review by paying $100 [SMPTE336M].
      It may be worth considering placing sufficient text in this document to make review and implementation possible (maybe that is already the case) and moving the reference to Informative.
    3. Stephen Farrell: Comment [2012-02-14]:
      - What happens if the RTP packet with M=1 gets lost? It may be in there but I either missed it or didn't get it.
      - The normative [SMPTE336M] document costs $100 so I cannot check it. Maybe that's considered ok in this space but its quite odd for a standards-track RFC in general. Is there no way that that specification could be made available for free so that people can implement IETF standards without having to pay? That's highly desirable at least. (I assume the WG did specifically consider this and decided they were ok with it. Consider this an exhortation from outside the WG.)
    4. Pete Resnick: Discuss [2012-02-14]:
      The text in the bullets in 4.3.1.1 is ambiguous. In the first bullet, I took the "KLVunit presently being received" to mean the KLVunit associated with the RTP packet that was just received. That's not what was intended. What was really intended was the KLVunit that was was being processed, i.e. the one that was partially received before the lost packet. In the second bullet, "all subsequent packets" was intended to mean all packets after the *lost* one. However, I took it to mean anything subsequent to (i.e., not including) the currently received packet. That would end up throwing away a perfectly good KLVunit.
      May I suggest some replacement text:
      o MUST consider the KLVunit partially received before a lost packet as damaged. This damaged KLVunit includes all packets prior to the lost one (in sequence number order) back to, but not including, the most recent packet in which the M-bit in the RTP header was set to '1'.
      o MUST consider the first KLVunit received after a lost packet as damaged. This damaged KLVunit includes the first packet after the lost one (in sequence number order) and, if the first packet has its M-bit in the RTP header is set to '0', all subsequent packets up to and including the next one with the M-bit in the RTP header set to '1'.
    5. Pete Resnick: Comment [2012-02-14]:
      From the table in 4.1:
      "The timestamp clock frequency SHALL be defined as a parameter to the payload format (Section 6)."
      I don't believe this is an implementation requirement, and therefore the SHALL is not necessary. I suggest instead, "The timestamp clock frequency is defined as a parameter to the payload format (see section 6.1)."
      "The RTP header marker bit (M) SHALL be set to '1' for any RTP packet which contains the final byte of a KLVunit. For all other packets, the RTP header marker bit SHALL be set to '0'."
      The passive voice confused me. I suggest instead, "The RTP header marker bit (M) is used to demarcate KLVunits. Senders MUST set the marker bit to '1' for any RTP packet which contains the final byte of a KLVunit. For all other packets, senders must set the RTP header marker bit to '0'."
      The instruction in 4.2.2, "A receiver MUST consider a KLVunit to be completed when it receives either a packet with M=1 or a packet with a new timestamp", is not necessary: You are telling receivers that they must look at the timestamp. Instead, they should stick to only looking at RTP sequence numbers and the M-bit to determine KLVunit completion. Unless you want receivers to handle the edge case of losing a single lost packet this you know has a marker bit, they never need to look at the timestamp.
      If you do want them to handle that edge case (and I don't think they need to), you can insert the following bullet into 4.3.1.1:
      o MAY consider the first KLVunit received after a lost packet as undamaged if and only if there was only a single packet was lost and the M-bit in the RTP header of the packet prior to the lost one was set to '0' and the timestamp of the packet prior to the lost one is different than the time stamp of the packet received after the last one. If any of those conditions are not met (or if the receiver does not implement this option), then the receiver:
    6. Peter Saint-Andre: Comment [2012-02-15]:
      Although I agree that the $100 charge to obtain a copy of SMPTE 336M is unpleasant, RFC 3497 provides a precedent of normatively referencing a specification (SMPTE 292M) for which payment is required. Therefore I am balloting "No Objection".

    Telechat:

  7. xNAME RCODE and Status Bits Clarification (Proposed Standard)
    draft-ietf-dnsext-xnamercode-00
    Token: Ralph Droms
    Note: Andrew Sullivan (ajs@anvilwalrusden.com) is the document shepherd.
    Discusses/comments (from ballot 4086):
    1. Adrian Farrel: Comment [2012-02-14]:
      The Abstract says:
      "This document clarifies, in the case of such redirected queries, how the RCODE and status bits correspond to the initial query cycle (where the CNAME or the like was detected) and subsequent or final query cycles."
      A standards track document that "clarifies" an existing RFC looks awfully like an "update".
      This seems to be confirmed in Section 3.
      As Pete channels Murray, please consider whether this document *does* update any existing RFCs.
    2. Pete Resnick: Comment [2012-02-11]:
      Please address the concerns of Murray Kucherawy's AppsDir review and SM's IETF list comment:
      1. Please add an appropriate "Updates" list to this document. Murray mentioned 1035, 2308, and 2672. 1034 and 4035 might also be on the list. I will leave it to the judgement of the authors and WG to figure out what's appropriate.
      2. Please give some context for section 2. In particular, Andrew Sullivan's reply to Murray on the IETF list seems to have appropriate explanation that there are implementations that failed to correctly implement the current specs. A mention of that in section 2 would be useful.

    Telechat:

2.1.2 Returning Items

  1. (none)

2.2 Individual Submissions

2.2.1 New Items

  1. Use of SHA-256 Algorithm with RSA, DSA and ECDSA in SSHFP Resource Records (Proposed Standard)
    draft-os-ietf-sshfp-ecdsa-sha2-07
    Token: Stephen Farrell
    Discusses/comments (from ballot 4036):
    1. Peter Saint-Andre: Comment [2012-02-15]:
      It might be helpful to mention that line breaks are not significant in the examples.
    2. Sean Turner: Discuss [2012-02-14]:
      Curious if there ought to be a stronger constraint about not using SHA-1 on ecdsa-sha2-* public keys? If the implementations are going to need to support SHA2 algs to process the signatures won't they also need it to process the fingerprint (i.e., if you're verifying the fingerprint to use the key then you're going to need to support the non-SHA-1 alg anyway)? To take it a bit further, why wouldn't you define the SHA-384/512 algs too and link them to the type ecdsa-sha2-* public key?

    Telechat:

  2. Authentication-Results Registration Update for SPF Results (Proposed Standard)
    draft-kucherawy-authres-spf-erratum-02
    Token: Peter Saint-Andre
    Discusses/comments (from ballot 4071):
    1. Adrian Farrel: Comment [2012-02-14]:
      What happens to Erratum 2617 now?

    Telechat:

2.2.2 Returning Items

  1. IANA Reserved IPv4 Prefix for Shared Address Space (BCP)
    draft-weil-shared-transition-space-request-14
    Token: Ron Bonica
    Discusses/comments (from ballot 3933):
    1. Jari Arkko: Comment [2011-12-01]:
      FWIW, the issue that I had with the previous incarnation of this document has been resolved. Thanks for working through the measurements and evidence about risks, and documenting them.
      However, my fellow AD colleagues have raised other issues (including status of IETF consensus for this document). I defer to them on those issues.
    2. Ron Bonica: Discuss [2011-11-29]:
      I will change this ballot to "YES" when a /10 has been allocated for this space.
    3. Stewart Bryant: Discuss [2012-02-11]:
      I understand the commercial imperatives that the ISPs face, and appreciate this is a dilemma.
      However, the authors have not so far generated an adequate degree of consensus (as evidenced by discussions on the IETF list) that the deployment of this technology "makes the Internet work better". Indeed section 5 indicates that the deployment of this technology makes the Internet worse by reducing it to a network that only supports a limited range of services (Web, Mail and IM) sanctioned by the ISP. This seems contra to the mission of the IETF.
      If this were a clearly defined limited application network, a case could be developed for accepting restrictions, but the application described here is connectivity to the Internet and hence access to new innovative services.
      The authors need to gain consensus in the IETF, that there is no other solution to the problem in hand, and hence that the significant restriction on the type of user application supported is justified.
      In addition this text should state that ANY system using this address space MUST be capable of supporting the same address space inside and outside (i.e. not just CPEs).
      Shared Address Space is distinct from [RFC1918] private address space because it is intended for use on Service Provider networks. However, it may be used as [RFC1918] private address space when at least one of the following conditions is true:
      o Shared Address Space is not also used on the Service Provider side of the CPE.
      o CPE routers behave correctly when using the same address block on both the internal and external interfaces.
    4. Ralph Droms: Comment [2012-02-15]:
      My thinking has evolved through the last call discussions. I now have no objection to publishing this document.
      In my original Discuss, I raised a few questions ... here are my answers to those questions:
      "Is the IESG the appropriate body to make the decision? If no, where should the decision be made, perhaps with technical advice from the IETF?"
      Yes. The IETF should make the decision about ARIN's assignment of the requested address block.
      "Should the IESG identify any specific /10 for use as Shared CGN Space? If no, do not approve the document."
      Yes, identification of a specific /10 will avoid squatting or multiple assignments of address blocks to individual service providers.
      "Does this document describe the usage scenarios, constraints and caveats sufficiently well to allow the use of a /10 as Shared CGN Space? If no, ask for a revision."
      The text describing the usage of this /10 has evolved through the various discussions and there appears to be consensus for the current text.
      "Should the IESG approve a request to IANA for a /10 as described in the document? If yes, publish the document."
      There appears to be rough consensus for approval at this point in time.
      "Should the IESG request that IANA identify some other /10 (or similar address block), such as 172.16.0.0/12, 10.64.0.0/10 or 240.0.0.0/10 for use as Shared CGN Space?"
      Yes.
      One last point has been discussed: whether this address block assignment is appropriate because it will be used only for extending the lifetime of IPv4. My opinion now is that this consideration is a non-issue. We need to do something to keep the Internet running today. IPv6 is the long-term solution, regardless of what bandaids service providers choose to spend money on today.
    5. Wesley Eddy: Comment [2011-11-30]:
      I agree with the comments and discuss positions from others that say there is not IETF consensus on this document.
    6. Adrian Farrel: Comment [2011-11-30]:
      I concur with Stewart that there does not appear to be IETF consensus around this I-D.
      I am concerned that the alternative to this has been presented as "if you don't allocate the address space, the ISPs will just squat on another space." However, this also seems to be less worser than any other proposal on the table.
    7. Stephen Farrell: Comment [2012-02-14]:
      Based on more and more and more and more discussion I'm reluctantly ok with this. (Still)
      In December I said:
      "I think additionally allocating part of 240/4 would be a fine thing to do at the same time within the same document. I would not be that keen on punting on the 240/4 part allocation until later since that would engender most of the same discussion."
      I still think that'd be good but it doesn't seem to have gotten traction so I'm in the end also ok to go ahead without that.
    8. Pete Resnick: Comment [2012-01-27]:
      I am satisfied from the discussion on the IETF list that there is at least a reasonable risk to use current 1918 address space for this purpose, and though I do not believe that the proponents of making this new allocation have done enough due diligence to determine whether that risk is serious, I also believe that their fear of using 1918 space will cause them to either squat on a block, or use a private allocation for these purposes that is not documented. I would rather see a block set aside *and* documented rather than some other choice.
      I also believe that the rewrite of this document in terms of Shared Address Space that can be used like any other 1918 address space *with the caveat* that it can be used in places that are normally reserved for public addresses sufficiently answers my concerns that we are making a technology-specific allocation for CGNs. This is general-use Shared Address Space, and I think the expansion of 1918 for these specific purposes is reasonable.
      I still agree with Stewart's DISCUSS that sufficient consensus has not been established on the IETF list. I think this document (and the arguments I have laid out above) may hopefully move toward some consensus, but that has yet to be seen. However, I will allow Stewart to hold that DISCUSS. I would like to see this document back on a telechat at some point after we have a better handle on how rough the consensus on it is.
      I have a few minor comments on the new revision, most of which I believe are vestiges of the earlier drafts:
      Section 4: "Shared Address Space MUST NOT be used for any purpose other than those stated above."
      I think that sentence is incorrect. What I think you mean is that Shared Address Space MUST NOT be used unless the above conditions are met. I don't think you have to repeat that with 2119 language since it is already said above, so I suggest just dropping the sentence.
      "Because CGN service requires non-overlapping address space on each side of the home NAT and CGN, entities using Shared Address Space for purposes other than for CGN service, as described in this document, are likely to experience problems implementing or connecting to CGN service at such time as they exhaust their supply of public IPv4 addresses."
      I also disagree with the above. Entities using Shared Address space *without following the above guidance* may experience problems, but not just because they're not CGNs. Again, I suggest you drop the above paragraph.
      Section 5.2: "As described in [RFC6269] and [I-D.donley-nat444-impacts], CGNs offer a reasonable quality of experience for many basic services including web, email, and Instant Messaging. This is true regardless of whether the address range between the CGN and CPE is globally unique, Shared Address Space, or [RFC1918] space. However, CGNs do adversely impact some advanced services, in particular:"
      I think the above is too much marketing for CGNs. A suggested reword:
      "The primary motivation for the allocation of Shared Address Space is CGNs, and the use and impact of CGNs has been previously described in [RFC6269] and [I-D.donley-nat444-impacts]. Some of the services adversely impacted by CGNs are:"
      I think that sounds less defensive.
    9. Peter Saint-Andre: Comment [2011-12-08]:
      Based on list discussion, I have come to the conclusion that this is the least worst workaround (not "solution") available to us at this time.
    10. Robert Sparks: Comment [2012-02-15]:
      (blank)
    11. Sean Turner: Comment [2011-12-01]:
      I agree with Ralph.

    Telechat:

3. Document Actions

3.1 WG Submissions

3.1.1 New Items

  1. Multiprotocol Label Switching Transport Profile (MPLS-TP) MIB-based Management Overview (Informational)
    draft-ietf-mpls-tp-mib-management-overview-06
    Token: Stewart Bryant
    Note: Loa Andersson (loa@pi.nu) is the document shepherd.
    Discusses/comments (from ballot 3947):
    1. Stephen Farrell: Comment [2012-02-14]:
      Is there no way to call something PAC-MAN and get that onto page 12? :-)
    2. David Harrington: Comment [2012-02-13]:
      1) "The below modules only support the SNMP based MIB management"
      The MIB modules can be used with any protocol that can read a MIB. RFC1052 describes the separation of MIB data models from protocols that carry MIB data. Hence, it is considered incorrect to say "SNMP based MIB". Yes, SNMP is the most widely-used protocol to access a MIB, but it is not the only one; CLIs often access MIB information, and there is ongoing work to develop
      a) a MIB-to-YANG translation for netconf;
      b) a MIB-to-syslog SDE translation for syslog;
      c) a MIB-to-IE translation for ipfix;
      d) a MIB-to-XMLSchema translation for translating MIB data to XML format.
      I suggest the correct wording would be "The below MIB modules support MPLS resiliency."
      2) "can be achieved" might be better as "might be achieved", since the devil is in the details for MIB design, and until it is done saying it can be don eight be incorrect.
      3) in 7, you might want to remove ", if SNMP is used in the management interface", for the same reasons mentioned in #1.
    3. Dan Romascanu: Discuss [2012-02-12]:
      I like this document, but before I cast a 'Yes' vote I would like to clarify and possibly fix one issue (more may come as the document was forwarded to the MIB Doctors list).
      I do not think we need to detail at this point where the OIDs for future work need to be defined. For the mpls-tp stuff (section 6.1.1) it can be argued that mpls-tp being a variant of mpls the OIDs may be grouped together for consistency under mplsStdMIB. This is not the case with the other future MIB modules. Allocation under the transmission branch is problematic, as this typically is associated with an ifType and the MIB module describes ifType specific augmentations. There is no ifType (as I understand) with PWE3, BFD or OAM for MPLS-TP, so the location of these MIB modules should rather be under mib-2.
      At least let us be mute about these, no need to describe under what branch will be located future MIB modules at this point.

    Telechat:

  2. Elliptic Curve DSA for DNSSEC (Informational)
    draft-ietf-dnsext-ecdsa-06
    Token: Ralph Droms
    Note: Olafur Gudmundsson (ogud@ogud.com) is the document shepherd.
    IPR: Certicom Corp's Statement of IPR Related to draft-ietf-dnsext-ecdsa-00
    Discusses/comments (from ballot 4087):
    1. Wesley Eddy: Comment [2012-02-14]:
      I support Russ and PSA's DISCUSS points
    2. Adrian Farrel: Comment [2012-02-14]:
      I presume that Section 6 needs to be updated as this document goes through the publication process. I think you should provide instructions to the RFC Editor on what should be done to this section.
      A way to do this would be to supply an RFC Editor note that fixes the section consistent with the actual IANA allocations, but will not show in the document until published as an RFC.
    3. Stephen Farrell: Comment [2012-02-13]:
      Section 4 says you MUST support signing "and/or" validation with both lengths. I think that is not quite clear enough as the requirement differs for different players in the DNSSEC game. Aside from basic clarity, which is the most important thing, there is also an IPR declaration here that distinguishes between things that are needed and things that are optional so I think expressing it in a way that makes clear that there are no optional-to-implement bits for anyone would be an improvement. I'd say that it'd be better to spell it out that implementations that create DNSSEC values to put into the DNS MUST implement signing and verification for both lengths, and that DNSSEC clients MUST implement verification for both lengths. (Or whatever is the right way to say thing.)
      Will the examples be re-done after IANA have allocated codes? Be more than nice if that were to be the case.
      An informational pointer to RFC 6090 might be no harm here (and everywhere that uses ECC).
    4. Russ Housley: Discuss [2012-02-13]:
      The Gen-ART Review by Roni Even on 29-Jan-2012 raised a major concern. The IANA action in this document updates a registry that requires standard action for adding values: http://www.iana.org/assignments/ds-rr-types/ds-rr-types.txt
    5. Peter Saint-Andre: Discuss [2012-02-14]:
      The AppsDir review by William Mills raised one major issue, about the formatting and generation of the integers and octet strings described in Section 4. A response would be appreciated.
    6. Sean Turner: Comment [2012-02-13]:
      (blank)

    Telechat:

3.1.2 Returning Items

  1. Considerations for Transitioning Content to IPv6 (Informational)
    draft-ietf-v6ops-v6-aaaa-whitelisting-implications-08
    Token: Ron Bonica
    Note: Joel Jaeggli (joelja@bogus.com) is the document shepherd.
    Discusses/comments (from ballot 3741):
    1. Jari Arkko: Comment [2012-01-25]:
      I have cleared my Discuss. Thank for such a major edit of the document.
      (FWIW I think the document should be re-reviewed in the IESG before approval and I don't know if various last calls have been completed with the document, but I'm happy with it.)
    2. Ralph Droms: Comment [2012-01-20]:
      I cleared my Discuss.
      Updated on 2012/1/20.
      1. (cleared)
      2. Throughout section 5, "domains" are anthropomorphized to "choose to use [whitelisting]," "view DNS Whitelisting [...]," "transition to IPv6," etc. At the risk of pedantic clunkiness of style, as an example I suggest:
      OLD: "However, there is clear consensus that DNS Whitelisting can be a useful tactic a domain may choose to use as they transition to IPv6."
      NEW: "However, there is clear consensus that DNS Whitelisting can be a useful tactic an administrator can use during the transition of a domain to the use of IPv6 transport."
      or NEW: "However, there is clear consensus that DNS Whitelisting can be a useful tactic for use during the transition of a domain to IPv6 transport."
    3. Wesley Eddy: Comment [2011-05-31]:
      (blank)
    4. Adrian Farrel: Comment [2011-04-24]:
      Thanks for a document that was both informative and easy to read.
      One tiny nit:
      Section 3: "someone slower than usual"
      s/someone/somewhat/
    5. Stephen Farrell: Comment [2011-05-30]:
      - Spaces in references are odd and may break some tools. Be better not do to that I think. Example: "[Evaluating IPv6 Adoption]"
      - I'm not sure the reference to world IPv6 day should stay, it'll be outdated just after an RFC issues so why bother? (Describing what happens in June in retrospect will be very interesting but this bit isn't.)
    6. Robert Sparks: Comment [2011-05-30]:
      (blank)

    Telechat:

3.2 Individual Submissions Via AD

3.2.1 New Items

  1. A URN Namespace For The ucode (Informational)
    draft-ishikawa-yrpunl-ucode-urn-02
    Token: Peter Saint-Andre
    Discusses/comments (from ballot 4081):
    1. Wesley Eddy: Comment [2012-02-14]:
      I agree with Stephen's DISCUSS that the language on IoT could be tightened up. IoT is more of a concept than something concrete, and there are different approaches to IoT, not all of which necessarily involve ucode.
    2. Adrian Farrel: Comment [2012-02-14]:
      I agree with the concern about the term "Internet of Things". I don't think the use of that term is needed to justify this work, and I believe the I-D would be easier to read and more compelling if the term was left out. It is good enough to say "ucode exists and is use din many applications. This document provides a URN namespace for ucode to enable its use in Internet-related devices and software."
    3. Stephen Farrell: Discuss [2012-02-14]:
      (updated discuss as per mail discussion)
      - Is the the first occurrence of the "Internet of Things" marketing/fund-raising buzzword in an RFC? If so, then maybe we should discourage that? In any case, please add or reference a definition that makes technical sense or avoid the (ill-defined) term.
    4. Stephen Farrell: Comment [2012-02-14]:
      - Can someone tell me if uidcenter.org is ok as an SDO for a normative reference or not? I've never heard of 'em but this may be outside my normal sphere of operation.
      - Even if uidcenter.org is ok, their normaive July 28 2009 document (with a 2010 copyright?) or white paper or working draft doesn't seem like a very stable document as a normative reference for an RFC.
      - Even if it were, then it appears that this I-D a) repeats the text from the [UCODE] ref - if uidcenter.org are a bona-fide SDO why is an RFC needed that says the same thing?) and b) has no new substantive technical content, so I'm puzzled by that.
      - If "Applications that use ucode take advantage of the Internet extensively" is true, then what applications are those and why are there no references to them?
      - What is a "small user"?
    5. Pete Resnick: Comment [2012-02-13]:
      Instead of creating a new hex-decimal, please use HEXDIG from RFC 5234.

    Telechat:

3.2.2 Returning Items

  1. Transmission of Syslog Messages over TCP (Historic)
    draft-gerhards-syslog-plain-tcp-14
    Token: Dan Romascanu
    Discusses/comments (from ballot 3840):
    1. Adrian Farrel: Comment [2011-12-11]:
      It would be good if the Introduction included a brief paragraph on the purpose/content of this document. The first paragraph of Section 4 contains roughly the necessary material.
      I am uncomfortable (but not quite to the point of a Discuss) by the way that this I-D flies in the face of IETF consensus to recommend the use of TLS. I believe this could be resolved by a slightly stronger statement on the intent of the document to facilitate interoperability with legacy deployments whild continuing to recommend the use of TLS. I.e. "this document does not recommend that new implementations or deployments use syslog over TCP except for the explicit purpose of interoperating with existing deployments."
      I am surprised that section 5 does not mention TCP/AO.
    2. Stephen Farrell: Comment [2011-12-14]:
      - I agree with Dave's discuss points 1,2 and 4 and sympathise with his point 3.
      - Be nice to add the hex values that go with %d32 and %d126 just to be super-clear
      - 3.1 mentions "relays" but those weren't mentioned in the intro - be nice to say what those are in section 1.
      - What does "not available" mean at the end of section 5? I think it would be better to say "This protocol SHOULD NOT be used unless syslog/tls [RFC5425] has been tried and failed, e.g. because there is no listener on port 6514."
      - I think you could note that falling back to this if syslog/tls fails could in principle indicate that an attack is happening. If there's a sensible action to take there (e.g. some local logging of the failure of the TLS handshake or whatever in addition to remote logging using this) that'd maybe be worth saying.
    3. David Harrington: Comment [2012-02-11]:
      I cleared. Thank you for addressing my concerns.
    4. Pete Resnick: Comment [2011-12-13]:
      I must agree with Robert's comment that the port allocation seems inappropriate. However, it concerns me that the port that is chosen some of the time is the rsh port. If there is an unregistered port that is widely used for this, it should be registered.
      I agree with Adrian's comment that some of the contents of section 4 would be terribly helpful in the intro.
      I think Peter's comment regarding character terminology is important, and I'm happy to see you're addressing it.
      I am ambivalent as to whether the document should be Informational or Historic. I lean slightly toward Informational since it is describing widespread current practice.
      [Updated to add:]
      Please re-use ABNF constructs defined in RFC 5234 instead of redefining them here:
      3.4.1 - DIGIT and SP are already defined in 5234.
      3.4.2 - LF is already in 5234.
    5. Peter Saint-Andre: Comment [2011-12-08]:
      According to BCP 166 (RFC 6365): "The terms "charset", or "character encoding scheme" and "coded character set", are strongly preferred over the term "character set" because "character set" has other definitions in other contexts, particularly outside the IETF."
      Please consider changing the term used in Section 3.1 of this I-D to match BCP 166.
    6. Robert Sparks: Comment [2012-02-02]:
      (blank)
    7. Sean Turner: Comment [2011-12-14]:
      I tend to agree with Dave here.

    Telechat:

3.3 IRTF and Independent Submission Stream Documents

3.3.1 New Items

  1. DHCPv6 Prefix Delegation in Long Term Evolution (LTE) Networks (Informational)
    draft-sarikaya-v6ops-prefix-delegation-11
    Token: Jari Arkko
    Note: ISE Stream
    Discusses/comments (from ballot 4093):
    1. (none)

    Telechat:

3.3.2 Returning Items

  1. (none)

1231 EST no break

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. Hypertext Transfer Protocol Bis (httpbis)
    Token: Peter

    Telechat:

4.2.2 Proposed for Approval

  1. Basic Level of Interoperability for SIP Services (bliss)
    Token: Robert

    Telechat:

  2. BiDirectional or Server-Initiated HTTP (hybi)
    Token: Peter

    Telechat:

5. IAB News We can use

6. Management Issues

  1. Expert for RFC 6520 registries [IANA #543350] (Michelle Cotton)

    Telechat:

  2. Major upgrade to the IETF Datatracker (Russ Housley)

    Telechat:

7. Agenda Working Group News

Stewart: Dan, can you look at RFCed text, maybe clear on call
Dan: I will look in next few minutes
Peter: HTTPBIS charter is fine
Amy: Jari's item 1254 recording stopped

1254 EST Discussion: "sausage-making"

Appendix: Snapshot of discusses/comments

(at 2012-02-16 05:42:13 PST)

draft-ietf-hokey-erp-aak

  1. Adrian Farrel: Comment [2012-02-14]:
    Please think about wether it would be useful to create a registry for 
the flags fields in the packets so that it is easier to track them if/
when future extensions come along.
  2. Sean Turner: Discuss [2012-02-15]:
        s5.4 and 9: Need to register CAP-Identifier.
  3. Sean Turner: Comment [2012-02-15]:
    And now for some nits:

1) f1: Is there an extra "[" or is a "]" missing in the following:

   a. | [EAP-Initiate/ |              |                   |

I think a "]" is missing because a is optional. Note this is a total nit and
shouldn't require you to post another version.

2) s3: r/thus message/this message

3) s4.1: Should this:

 The pMSK label is the 8-bit ASCII string:

      Early-Authentication Master Session Key@ietf.org

be:

 The pMSK label is the 8-bit ASCII string:

      EAP Early-Authentication Master Session Key@ietf.org

to match the earlier ASCII string?

4) s4.1: My assumption is that the pMSK ASCII string is coming from the same
place and the KDF is also defined in 5295.  Worth repeating for the pMSK?

5) s5.1, s5.2, s5.3: I know this is minor but r/changed parameters/new
parameters

6) s5.2 and s5.3: Shouldn't you say something about L? It's mentioned later in
s5.3 so something ought to at least be said about it even if it's just "L" see
5296 like for the SEQ field.

7) s5.3: r/HMAC-SHA256-128 is mandatory/HMAC-SHA256-128 is REQUIRED - just to
make it match s5.2

draft-ietf-dime-pmip6-lr

  1. Stephen Farrell: Comment [2012-02-14]:
    A question and two comments, that could become discusses, 
depending on the answer to the question. At present, I'm not 
sure if there is a real issue here or not.

There could be a use-case where the MN's MAG is under the MN's
control. If there were, or if a MAG were compromised, or a
bad-actor, then this protocol could be used to track any
participating CN (whose address is known) at the level of the MAG 
to which it is anchored, but I'm not sure how much of a concern 
that ought be.  Note: I think (but am not sure) that this is different 
from a "normally" bad MAG in most of pmipv6, in that it could 
impact on a whole bunch of CN's and not just on the MN anchored 
to the bad-MAG.

So, the question: How fine-grained a location would me knowing your
current MAG give me and is such potential tracking by a bad-MAG a
concern?

1. If this is a concern maybe it'd be useful to add something like
the following to the security considerations:

"An authorised MAG could in principle track the movement of any
participating CN at the level of the MAG to which they are anchored.
If such a MAG were compromised, or under the control of a bad-actor,
then such tracking could represent a privacy breach for the set of
tracked CN's. In such a case the traffic pattern from the
compromised MAG might be notable so monitoring for e.g. excessive
queries from MAGs might be worth while."

2. Assuming again that the answer to my question is that it is a
concern, ought there be some way in which e.g. MN2 in figure 6 could
be part of the authorisation process for this kind of feature?
Perhaps one could note that deployments that wanted to be privacy
friendly could provide some way to allow for a user to consent to
this? And going further of course any such consent might change
over time I guess.
  2. Russ Housley: Discuss [2012-02-13]:
        
  The authors have agreed to make some changes based on the Gen-ART
  Review by Elwyn Davies on 2-Feb-2012.  The changes have not been
  posted yet.
  3. Peter Saint-Andre: Comment [2012-02-15]:
    The term "Fully Qualified Domain Name" is undefined (specifically, it's unclear
whether internationalized domain names are supported), but it appears that's the
fault of RFC 5779 and RFC 5447.
  4. Robert Sparks: Discuss [2012-02-14]:
        The relationship between this and the document specifying "Localized Routing for
Proxy Mobile IPv6"
<https://datatracker.ietf.org/doc/draft-ietf-netext-pmip-lr/>
(currently in last call) is not clear. What level of coordination exists between
DIME and NETEXT on these documents? Are the authorization steps described in
this document actually part of the protocol being specified by netext?

Note that neither document currently references the other.
  5. Sean Turner: Comment [2012-02-15]:
    Curious to hear the response to Stephen's question.

draft-ietf-dhc-dhcpv4-bulk-leasequery

  1. Stewart Bryant: Discuss [2012-02-14]:
        This is a Discuss because I want the opportunity to discuss with other members
of the IESG on the call.

This document has seven front page authors, against a strong guideline of five.
Other document teams have had to make very painful choices as a consequence of
this policy. Unless there are exceptional reasons the number of authors  on the
number of front page authors should be reduced to conform to the guideline.
  2. Wesley Eddy: Discuss [2012-02-15]:
        The TSVDIR review comments from Joe Touch need to be addressed:
http://www.ietf.org/mail-archive/web/ietf/current/msg71733.html
  3. Stephen Farrell: Discuss [2012-02-13]:
        #1 How does the TCP framing interact with DHCP authentication
which only partly covers individual messages, was not designed for
this kind of bulk usage, and hence probably allows various bad
things to happen? E.g.  re-ordering or snipping out individual
messages seems to be possible or moving DHCPLEASEQUERYDONE earlier
in the sequence. I think that needs to be understood, and maybe it
is, but I don't get it from reading this nor from the referenced
RFCs, at least not without doing a lot more work that, presumably
the WG/coders already did and that could be documented here.  (If
you ended up saying "yes" to SSH or TLS in #3 below, this would be
moot.)

#2 Maybe replay is possible too if xid is predictable or always
starts at 1 or whatever. I'd suggest putting in a MUST for xid to
be hard to guess and very unlikely to collide over the life of a
DHCP authentication key at least.  (If you ended up saying "yes"
to SSH or TLS in #3 below, this would be moot.)

#3 If DHCP auth is actually mythical, in terms of real usage (is
it?) then wouldn't it be better to just run this over
mutually-authenticated SSH or TLS? (Possibly with a PSK
ciphersuite if you don't like private keys on the relay.) If not,
why not? If its likely that the boxes in the main use-case for
this (server, relay-agent) use SSH or TLS for something else (e.g.
netconf or whatever) then that might not be very hard to do at
all. Did the WG consider this?

#4 The secdir review raised the issue of a query like this coming
from a DHCP client (or elsewhere); the response [1] was that you
could firewall that, which should I guess be noted in the security
considerations, but I think the potential privacy consequences of
answering these queries, esp without authentication should also be
noted as in the reviewer's comment.

   [1] http://www.ietf.org/mail-archive/web/secdir/current/msg03100.html
  4. Stephen Farrell: Comment [2012-02-13]:
    - The write up's technical and working group summaries are the
same. If that's a cut'n'paste accident, it might be worth putting
the right working group summary back there.

- Would it be worthwhile noting that this protocol is not
intended to be used to produce evidence (i.e. to be used in court)
as to who had what IP address when?  (And is that actually the
case? Would it be possibly bad/misleading evidence if so used?) 

- Is it right, in section 4, to say that bindings are returned in
DHCPv4 "packets"? Maybe messages would be better?

- What are the consequences of having guessable "Relay
Identifier"  or "remote ID" or "vpn-id" values in queries? The
concern is whether such guessable values might allow for a lot of
probing.

- 6.2.8 "when 2 or more servers work together" I'm not sure if
there's an implied MUST or SHOULD for including this option in
this case. If not then a requestor can't really know for sure
they've got the full info on an IP address. That may well be ok,
but I think it'd be good to be clear about it.

- Do the query by MAC address or client-id options means that
personally identifying information about a user might be sent
further upstream that normal?  I don't think so but just wanna
check. If it did, that might be worth a note to the effect that
its another potential privacy issue that operators should worry
about.  (But with no change to the spec otherwise I'd guess.)

- server-identifier in only 1st response seems slightly fragile if
the overall session doesn't have data integrity (e.g. via TLS) but
I guess that's a fairly minor issue.
  5. Peter Saint-Andre: Comment [2012-02-15]:
    Please consider adding references for "NTP" and "UTF-8".

What is a "UTF-8 ASCII VPN identifier"??
  6. Robert Sparks: Comment [2012-02-13]:
    In Section 7.7 the requirement "MUST interleave replies" is not clear.  It could
be read to mean an implementation has to wait to send additional replies to the
first query until it has the information it needs to start answering a second
(at the extreme, a strict round-robin of the responses).  Is the requirement you
are really trying to capture "MUST NOT block sending replies on new queries
until all replies for the existing query are complete."?

Is there a way for a server to say "the response to your query is too big,
please ask again for a subset"? Consider adding a discussion to the document
about what a client could do if a server is sending it more data
 than it is
prepared to deal with.

RFC5226 defines "IETF Review" as the well-known IANA policy name you are using
in section 10. (That RFC notes that this was formerly called "IETF Consensus" in
RFC2434.) The document should use that name.  RFC5226 is clear on what that
policy name means - you invite argument by attempting to restate or clarify the
policy in this document. Please consider removing the sentences that start
"Basically, this means...".

draft-ietf-dhc-pd-exclude

  1. Jari Arkko: Comment [2012-02-16]:
    Thanks for writing this draft, it is very important addition to DHCPv6.

draft-ietf-dhc-forcerenew-nonce

  1. Jari Arkko: Comment [2012-02-16]:
    Thanks for writing this document. I believe it is ready to move forward, despite
the unsubstantiated worries about weakening RFC 3118 security :-)

One small comment:

>   The server SHOULD NOT include the nonce in an ACK when responding to
>   a renew unless a nonce was generated. 

... unless a *new* nonce was generated ...?
  2. Adrian Farrel: Comment [2012-02-14]:
    Should you describe a mechanism whereby the nonce can be changed?

---

Section 6
Please don;t refer to this as a "proposal". It is just about to become
an RFC. Use "document".
  3. Stephen Farrell: Comment [2012-02-13]:
    - I agree with Russ' discuss based on the gen-art review.

- I like the idea as explained in the response to the gen-art
review, but didn't get that from the abstract or writeup so I
think fixing those to make the purpose of this clear (make
off-path attacks hard) would be good.

- What is an RDM? (3.1.3) Better to spell that out rather
than force the reader off to rfc 3115.

- Shouldn't there be a requirement to use a different "reconfigure
key value" every single time? If those are re-used, then a client
could pretend to be the server.

- I guess I wondered if you can do this, why can't the server just
sign the response with a private key? 

- Should there be an IANA registry for the type field here in
case you ever want more than hmac-md5?
  4. Russ Housley: Discuss [2012-02-12]:
        
  The Gen-ART Review by Ben Campbell on 6-Feb-2012 raised some
  significant concerns, and the authors agree that some updates to the
  document are needed.  The review can be found at this URL:
  http://www.ietf.org/mail-archive/web/gen-art/current/msg07161.html
  5. Pete Resnick: Comment [2012-02-14]:
    The portion of 3.1.2 which starts "The following fields are set in an DHCP
authentication option for the Forcerenew Nonce Authentication Protocol:" is
poorly written. The fields are not listed in order, the explanation for length
is incorrect. This needs to be rewritten.
  6. Peter Saint-Andre: Comment [2012-02-15]:
    I concur with the DISCUSS that Russ lodged (based on the Gen-ART review).
  7. Robert Sparks: Discuss [2012-02-13]:
        The introduction motivates this extension by claiming there are specialized
environments in which the mandatory coupling between FORCERENEW and 3118 DHCP
Authentication could be relaxed, but doesn't restrict the mechanism discussed in
this document to those environments. There is some discussion already taking
place in response to the genart review touching on this topic indicating there
should be a restriction, but it's not clear yet what that the intended
restriction is.

Doesn't the client's computation confirming the same HMAC-MD5 over the message
need to be performed the same way the server computes the value (as described in
the last paragraph of 3.1.3)? Should the instructions for zeroing the HMAC-MD5
field in the message fed into the computation be repeated here?
  8. Sean Turner: Discuss [2012-02-15]:
        Seems the DHCP option needs to indicate the algorithm(s) supported by the
server/client?  If HMAC-CoolNewAlg gets registered for use with DHCP won't you
need to indicate whether HMAC-CoolNewAlg and/or HMAC-MD5 is supported?

Assuming we always use HMAC-MD5 then you'll have an output of 128 bits, but what
happens if DHCP starts to use HMAC-SHA-256 - i.e., are we always going to use
HMAC-CoolNewAlg-128?
  9. Sean Turner: Comment [2012-02-15]:
    A couple 2119 issues maybe:

s3: r/The FORCERENEW message must be authenticated/The FORCERENEW message MUST
be authenticated ?

s3.1.1: r/authentication should ignore/authentication SHOULD ignore ?

And for the algs supported:

s3.1.2: Maybe for the algorithm you should point to the IANA registry for DHCP
Algorithm Name Space Values (http://www.iana.org/assignments/auth-namespaces
/auth-namespaces.xml) but say that currently only HMAC-MD5 is supported?  The
alg used in this wouldn't ever differ right?

draft-ietf-payload-rtp-klv

  1. Ron Bonica: Comment [2012-02-15]:
    I strongly support Adrian's DISCUSS. In fact, the IESG should probably issue
guidance about this issue.
  2. Adrian Farrel: Discuss [2012-02-14]:
        It bothers me somewhat that a normative reference is only available for
review by paying $100 [SMPTE336M].

It may be worth considering placing sufficient text in this document to
make review and implementation possible (maybe that is already the case)
and moving the reference to Informative.
  3. Stephen Farrell: Comment [2012-02-14]:
    -  What happens if the RTP packet with M=1 gets lost? It may
be in there but I either missed it or didn't get it.

- The normative [SMPTE336M] document costs $100 so I cannot
check it. Maybe that's considered ok in this space but its quite odd 
for a standards-track RFC in general. Is there no way that that 
specification could be made available for free so that people can 
implement IETF standards without having to pay? That's highly 
desirable at least.  (I assume the WG did specifically consider this 
and decided they were ok with it. Consider this an exhortation 
from outside the WG.)
  4. Pete Resnick: Discuss [2012-02-14]:
        The text in the bullets in 4.3.1.1 is ambiguous. In the first bullet, I took the
"KLVunit presently being received" to mean the KLVunit associated with the RTP
packet that was just received. That's not what was intended. What was really
intended was the KLVunit that was was being processed, i.e. the one that was
partially received before the lost packet. In the second bullet, "all subsequent
packets" was intended to mean all packets after the *lost* one. However, I took
it to mean anything subsequent to (i.e., not including) the currently received
packet. That would end up throwing away a perfectly good KLVunit.

May I suggest some replacement text:

   o  MUST consider the KLVunit partially received before a lost packet
      as damaged. This damaged KLVunit includes all packets prior to the
      lost one (in sequence number order) back to, but not including,
      the most recent packet in which the M-bit in the RTP header was
      set to '1'.

   o  MUST consider the first KLVunit received after a lost packet as
      damaged. This damaged KLVunit includes the first packet after the
      lost one (in sequence number order) and, if the first packet has
      its M-bit in the RTP header is set to '0', all subsequent packets
      up to and including the next one with the M-bit in the RTP header
      set to '1'.
  5. Pete Resnick: Comment [2012-02-14]:
    From the table in 4.1:

"The timestamp clock frequency SHALL be defined as a parameter to the payload
format (Section 6)."

I don't believe this is an implementation requirement, and therefore the SHALL
is not necessary. I suggest instead, "The timestamp clock frequency is defined
as a parameter to the payload format (see section 6.1)."

"The RTP header marker bit (M) SHALL be set to '1' for any RTP packet which
contains the final byte of a KLVunit. For all other packets, the RTP header
marker bit SHALL be set to '0'."

The passive voice confused me. I suggest instead, "The RTP header marker bit (M)
is used to demarcate KLVunits. Senders MUST set the marker bit to '1' for any
RTP packet which contains the final  byte of a KLVunit. For all other packets,
senders must set the RTP header marker bit to '0'."

The instruction in 4.2.2, "A receiver MUST consider a KLVunit to be completed
when it receives either a packet with M=1 or a packet with a new timestamp", is
not necessary: You are telling receivers that they must look at the timestamp.
Instead, they should stick to only looking at RTP sequence numbers and the M-bit
to determine KLVunit completion. Unless you want receivers to handle the edge
case of losing a single lost packet this you know has a marker bit, they never
need to look at the timestamp.

If you do want them to handle that edge case (and I don't think they need to),
you can insert the following bullet into 4.3.1.1:

   o  MAY consider the first KLVunit received after a lost packet as
      undamaged if and only if there was only a single packet was lost
      and the M-bit in the RTP header of the packet prior to the lost
      one was set to '0' and the timestamp of the packet prior to the
      lost one is different than the time stamp of the packet received
      after the last one. If any of those conditions are not met (or if
      the receiver does not implement this option), then the receiver:
  6. Peter Saint-Andre: Comment [2012-02-15]:
    Although I agree that the $100 charge to obtain a copy of SMPTE 336M is
unpleasant, RFC 3497 provides a precedent of normatively referencing a
specification (SMPTE 292M) for which payment is required. Therefore I am
balloting "No Objection".

draft-ietf-dnsext-xnamercode

  1. Adrian Farrel: Comment [2012-02-14]:
    The Abstract says:

   This document
   clarifies, in the case of such redirected queries, how the RCODE and
   status bits correspond to the initial query cycle (where the CNAME or
   the like was detected) and subsequent or final query cycles.

A standards track document that "clarifies" an existing RFC looks
awfully like an "update".

This seems to be confirmed in Section 3.

As Pete channels Murray, please consider whether this document *does* 
update any existing RFCs.
  2. Pete Resnick: Comment [2012-02-11]:
    Please address the concerns of Murray Kucherawy's AppsDir review and SM's IETF
list comment:

1. Please add an appropriate "Updates" list to this document. Murray mentioned
1035, 2308, and 2672. 1034 and 4035 might also be on the list. I will leave it
to the judgement of the authors and WG to figure out what's appropriate.

2. Please give some context for section 2. In particular, Andrew Sullivan's
reply to Murray on the IETF list seems to have appropriate explanation that
there are implementations that failed to correctly implement the current specs.
A mention of that in section 2 would be useful.

draft-os-ietf-sshfp-ecdsa-sha2

  1. Peter Saint-Andre: Comment [2012-02-15]:
    It might be helpful to mention that line breaks are not significant in the
examples.
  2. Sean Turner: Discuss [2012-02-14]:
        Curious if there ought to be a stronger constraint about not using SHA-1 on
ecdsa-sha2-* public keys?  If the implementations are going to need to support
SHA2 algs to process the signatures won't they also need it to process the
fingerprint (i.e., if you're verifying the fingerprint to use the key then
you're going to need to support the non-SHA-1 alg anyway)?  To take it a bit
further, why wouldn't you define the SHA-384/512 algs too and link them to the
type ecdsa-sha2-* public key?

draft-kucherawy-authres-spf-erratum

  1. Adrian Farrel: Comment [2012-02-14]:
    What happens to Erratum 2617 now?

draft-weil-shared-transition-space-request

  1. Jari Arkko: Comment [2011-12-01]:
    FWIW, the issue that I had with the previous incarnation of this document has
been resolved. Thanks for working through the measurements and evidence about
risks, and documenting them.

However, my fellow AD colleagues have raised other issues (including status of
IETF consensus for this document). I defer to them on those issues.
  2. Ron Bonica: Discuss [2011-11-29]:
        I will change this ballot to "YES" when a /10 has been allocated for this space.
  3. Stewart Bryant: Discuss [2012-02-11]:
        I understand the commercial imperatives that the ISPs face, and appreciate this
is a dilemma.

However, the authors have not so far generated an adequate degree of consensus
(as evidenced by discussions on the IETF list) that the deployment of this
technology "makes the Internet work better". Indeed section 5 indicates that the
deployment of this technology makes the Internet worse by reducing it to a
network that only supports a limited range of services (Web, Mail and IM)
sanctioned by the ISP. This seems contra to the mission of the IETF.

If this were a clearly defined limited application network, a case could be
developed for accepting restrictions, but the application described here is
connectivity to the Internet and hence access to new innovative services.

The authors need to gain consensus in the IETF, that there is no other solution
to the problem in hand, and hence that the significant restriction on the type
of user application supported is justified.

=====

In addition this text should state that ANY system using this address
space MUST be capable of supporting the same address space
inside and outside (i.e. not just CPEs).  

Shared Address Space is distinct from [RFC1918] private address space
   because it is intended for use on Service Provider networks.
   However, it may be used as [RFC1918] private address space when at
   least one of the following conditions is true:

   o  Shared Address Space is not also used on the Service Provider side
      of the CPE.

   o  CPE routers behave correctly when using the same address block on
      both the internal and external interfaces.
  4. Ralph Droms: Comment [2012-02-15]:
    My thinking has evolved through the last call discussions.  I now
have no objection to publishing this document.

In my original Discuss, I raised a few questions ... here are my
answers to those questions:

  Is the IESG the appropriate body to make the decision?  If no, where
  should the decision be made, perhaps with technical advice from the
  IETF?

Yes.  The IETF should make the decision about ARIN's assignment
of the requested address block.

  Should the IESG identify any specific /10 for use as Shared CGN
  Space?  If no, do not approve the document.

Yes, identification of a specific /10 will avoid squatting or multiple
assignments of address blocks to individual service providers.

  Does this document describe the usage scenarios, constraints and
  caveats sufficiently well to allow the use of a /10 as Shared CGN
  Space?  If no, ask for a revision.

The text describing the usage of this /10 has evolved through the
various discussions and there appears to be consensus for the
current text.

  Should the IESG approve a request to IANA for a /10 as described
  in the document?  If yes, publish the document.

There appears to be rough consensus for approval at this point in time.

  Should the IESG request that IANA identify some other /10 (or
  similar address block), such as 172.16.0.0/12, 10.64.0.0/10 or
  240.0.0.0/10 for use as Shared CGN Space?

Yes.

One last point has been discussed: whether this address block
assignment is appropriate because it will be used only for
extending the lifetime of IPv4.  My opinion now is that this
consideration is a non-issue.  We need to do something to
keep the Internet running today.  IPv6 is the long-term
solution, regardless of what bandaids service providers choose
to spend money on today.
  5. Wesley Eddy: Comment [2011-11-30]:
    I agree with the comments and discuss positions from others that say there is
not IETF consensus on this document.
  6. Adrian Farrel: Comment [2011-11-30]:
    I concur with Stewart that there does not appear to be IETF consensus around
this I-D.

I am concerned that the alternative to this has been presented as "if you don't
allocate the address space, the ISPs will just squat on another space." However,
this also seems to be less worser than any other proposal on the table.
  7. Stephen Farrell: Comment [2012-02-14]:
    Based on more and more and more and more discussion I'm reluctantly 
ok with this. (Still)

In December I said: 

   I think additionally allocating part of 240/4 would be a fine thing to do at
   the same time within the same document. I would not be that keen on 
   punting on the 240/4 part allocation until later since that would engender
   most of the same discussion.

I still think that'd be good but it doesn't seem to have gotten traction
so I'm in the end also ok to go ahead without that.
  8. Pete Resnick: Comment [2012-01-27]:
    I am satisfied from the discussion on the IETF list that there is at least a
reasonable risk to use current 1918 address space for this purpose, and though I
do not believe that the proponents of making this new allocation have done
enough due diligence to determine whether that risk is serious, I also believe
that their fear of using 1918 space will cause them to either squat on a block,
or use a private allocation for these purposes that is not documented. I would
rather see a block set aside *and* documented rather than some other choice.

I also believe that the rewrite of this document in terms of Shared Address
Space that can be used like any other 1918 address space *with the caveat* that
it can be used in places that are normally reserved for public addresses
sufficiently answers my concerns that we are making a technology-specific
allocation for CGNs. This is general-use Shared Address Space, and I think the
expansion of 1918 for these specific purposes is reasonable.

I still agree with Stewart's DISCUSS that sufficient consensus has not been
established on the IETF list. I think this document (and the arguments I have
laid out above) may hopefully move toward some consensus, but that has yet to be
seen. However, I will allow Stewart to hold that DISCUSS. I would like to see
this document back on a telechat at some point after we have a better handle on
how rough the consensus on it is.

I have a few minor comments on the new revision, most of which I believe are
vestiges of the earlier drafts:

Section 4:

   Shared Address Space MUST NOT be used for any purpose other than
   those stated above.

I think that sentence is incorrect. What I think you mean is that Shared Address
Space MUST NOT be used unless the above conditions are met. I don't think you
have to repeat that with 2119 language since it is already said above, so I
suggest just dropping the sentence.

   Because CGN service requires non-overlapping address space on each
   side of the home NAT and CGN, entities using Shared Address Space for
   purposes other than for CGN service, as described in this document,
   are likely to experience problems implementing or connecting to CGN
   service at such time as they exhaust their supply of public IPv4
   addresses.

I also disagree with the above. Entities using Shared Address space *without
following the above guidance* may experience problems, but not just because
they're not CGNs. Again, I suggest you drop the above paragraph.

Section 5.2:

   As described in [RFC6269] and [I-D.donley-nat444-impacts], CGNs offer
   a reasonable quality of experience for many basic services including
   web, email, and Instant Messaging.  This is true regardless of
   whether the address range between the CGN and CPE is globally unique,
   Shared Address Space, or [RFC1918] space.  However, CGNs do adversely
   impact some advanced services, in particular:

I think the above is too much marketing for CGNs. A suggested reword:

   The primary motivation for the allocation of Shared Address Space is
   CGNs, and the use and impact of CGNs has been previously described in
   [RFC6269] and [I-D.donley-nat444-impacts]. Some of the services
   adversely impacted by CGNs are:

I think that sounds less defensive.
  9. Peter Saint-Andre: Comment [2011-12-08]:
    Based on list discussion, I have come to the conclusion that this is the least
worst workaround (not "solution") available to us at this time.
  10. Robert Sparks: Comment [2012-02-15]:
    
    
  11. Sean Turner: Comment [2011-12-01]:
    
    
    I agree with Ralph.
    
  




draft-ietf-mpls-tp-mib-management-overview


  
    
    
  1. Stephen Farrell: Comment [2012-02-14]:
    
    
    Is there no way to call something PAC-MAN and get that
onto page 12? :-)

    
    
  2. David Harrington: Comment [2012-02-13]:
    
    
    1) "The below modules only support the SNMP based MIB management" 
The MIB
modules can be used with any protocol that can read a MIB.
RFC1052 describes the
separation of MIB data models from protocols that carry MIB data.
Hence, it is
considered incorrect to say "SNMP based MIB".
Yes, SNMP is the most widely-used
protocol to access a MIB, but it is not the only one; CLIs often access MIB
information, and there is ongoing work to develop 
a) a MIB-to-YANG translation
for netconf; 
b) a MIB-to-syslog SDE translation for syslog;
c) a MIB-to-IE
translation for ipfix;
d) a MIB-to-XMLSchema translation for translating MIB
data to XML format.

I suggest the correct wording would be "The below MIB modules support MPLS
resiliency."

2) "can be achieved" might be better as "might be achieved", since the devil is
in the details for MIB design, and until it is done saying it can be don eight
be incorrect.

3) in 7, you might want to remove ", if SNMP is used in the management
interface", for the same reasons mentioned in #1.
    
    
  3. Dan Romascanu: Discuss [2012-02-12]:
    
    
        I like this document, but before I cast a 'Yes' vote I would like to clarify and
possibly fix one issue (more may come as the document was forwarded to the MIB
Doctors list).

I do not think we need to detail at this point where the OIDs for future work
need to be defined. For the mpls-tp stuff (section 6.1.1) it can be argued that
mpls-tp being a variant of mpls the OIDs may be grouped together for consistency
under mplsStdMIB. This is not the case with the other future MIB modules.
Allocation under the transmission branch is problematic, as this typically is
associated with an ifType and the MIB module describes ifType specific
augmentations. There is no ifType (as I understand) with PWE3, BFD or OAM for
MPLS-TP, so the location of these MIB modules should rather be under mib-2.

At least let us be mute about these, no need to describe under what branch will
be located future MIB modules at this point. 
    
    
  




draft-ietf-dnsext-ecdsa


  
    
    
  1. Wesley Eddy: Comment [2012-02-14]:
    
    
    I support Russ and PSA's DISCUSS points
    
    
  2. Adrian Farrel: Comment [2012-02-14]:
    
    
    I presume that Section 6 needs to be updated as this document goes
through the publication process. I think you should provide instructions
to the RFC Editor on what should be done to this section.

A way to do this would be to supply an RFC Editor note that fixes the
section consistent with the actual IANA allocations, but will not show
in the document until published as an RFC.
    
    
  3. Stephen Farrell: Comment [2012-02-13]:
    
    
    Section 4 says you MUST support signing "and/or" validation with
both lengths. I think that is not quite clear enough as the
requirement differs for different players in the DNSSEC game.
Aside from basic clarity, which is the most important thing, there
is also an IPR declaration here that distinguishes between things
that are needed and things that are optional so I think expressing
it in a way that makes clear that there are no
optional-to-implement bits for anyone would be an improvement.
I'd say that it'd be better to spell it out that implementations
that create DNSSEC values to put into the DNS MUST implement
signing and verification for both lengths, and that DNSSEC clients
MUST implement verification for both lengths. (Or whatever is
the right way to say thing.)

Will the examples be re-done after IANA have allocated codes?  Be
more than nice if that were to be the case.

An informational pointer to RFC 6090 might be no harm here (and
everywhere that uses ECC).

    
    
  4. Russ Housley: Discuss [2012-02-13]:
    
    
        
  The Gen-ART Review by Roni Even on 29-Jan-2012 raised a major concern.
  The IANA action in this document updates a registry that requires
  standard action for adding values:
  http://www.iana.org/assignments/ds-rr-types/ds-rr-types.txt 
    
    
    
  5. Peter Saint-Andre: Discuss [2012-02-14]:
    
    
        The AppsDir review by William Mills raised one major issue, about the formatting
and generation of the integers and octet strings described in Section 4. A
response would be appreciated. His review can be found here:

http://www.ietf.org/mail-archive/web/apps-discuss/current/msg04281.html
 
    
    
    
  6. Sean Turner: Comment [2012-02-13]:
    
    
    
  




draft-ietf-v6ops-v6-aaaa-whitelisting-implications


  
    
    
  1. Jari Arkko: Comment [2012-01-25]:
    
    
    I have cleared my Discuss. Thank for such a major edit of the document.

(FWIW I think the document should be re-reviewed in the IESG before approval and
I don't know if various last calls have been completed with the document, but
I'm happy with it.)
    
    
  2. Ralph Droms: Comment [2012-01-20]:
    
    
    I cleared my Discuss.

Updated on 2012/1/20.

1. (cleared)

2. Throughout section 5, "domains" are anthropomorphized to "choose to
use [whitelisting]," "view DNS Whitelisting [...]," "transition to
IPv6," etc.  At the risk of pedantic clunkiness of style, as an
example I suggest:

OLD:

   However, there is clear consensus that DNS Whitelisting can
   be a useful tactic a domain may choose to use as they transition to
   IPv6.

NEW:

   However, there is clear consensus that DNS Whitelisting can
   be a useful tactic an administrator can use during the transition
   of a domain to the use of IPv6 transport.

or NEW:

   However, there is clear consensus that DNS Whitelisting can be a
   useful tactic for use during the transition of a domain to IPv6
   transport.

    
    
  3. Wesley Eddy: Comment [2011-05-31]:
    
    
    
    
  4. Adrian Farrel: Comment [2011-04-24]:
    
    
    Thanks for a document that was both informative and easy to read.

One tiny nit:

Section 3

"someone slower than usual"

s/someone/somewhat/

    
    
  5. Stephen Farrell: Comment [2011-05-30]:
    
    
    - Spaces in references are odd and may break some tools. Be better
not do to that I think. Example: "[Evaluating IPv6 Adoption]"

- I'm not sure the reference to world IPv6 day should stay,
it'll be outdated just after an RFC issues so why bother?
(Describing what happens in June in retrospect will be very
interesting but this bit isn't.)

    
    
  6. Robert Sparks: Comment [2011-05-30]:
    
    
    
  




draft-ishikawa-yrpunl-ucode-urn


  
    
    
  1. Wesley Eddy: Comment [2012-02-14]:
    
    
    I agree with Stephen's DISCUSS that the language on IoT could be tightened up.
IoT is more of a concept than something concrete, and there are different
approaches to IoT, not all of which necessarily involve ucode.
    
    
  2. Adrian Farrel: Comment [2012-02-14]:
    
    
    I agree with the concern about the term "Internet of Things". I don't
think the use of that term is needed to justify this work, and I believe
the I-D would be easier to read and more compelling if the term was left
out. It is good enough to say "ucode exists and is use din many 
applications. This document provides a URN namespace for ucode to 
enable its use in Internet-related devices and software."

    
    
  3. Stephen Farrell: Discuss [2012-02-14]:
    
    
        
(updated discuss as per mail discussion)

- Is the the first occurrence of the "Internet of Things"
marketing/fund-raising buzzword in an RFC? If so, then maybe we
should discourage that? In any case, please add or reference 
a definition that makes technical sense or avoid the
(ill-defined) term.
 
    
    
    
  4. Stephen Farrell: Comment [2012-02-14]:
    
    
    - Can someone tell me if uidcenter.org is ok as an SDO for a
normative reference or not? I've never heard of 'em but this
may be outside my normal sphere of operation. 

- Even if uidcenter.org is ok, their normaive July 28 2009 document
(with a 2010 copyright?) or white paper or working draft doesn't
seem like a very stable document as a normative reference for an
RFC.

- Even if it were, then it appears that this I-D a) repeats the
text from the [UCODE] ref - if uidcenter.org are a bona-fide SDO
why is an RFC needed that says the same thing?) and b) has no
new substantive technical content, so I'm puzzled by that.

- If "Applications that use ucode take advantage of the Internet
extensively" is true, then what applications are those and why
are there no references to them?

- What is a "small user"? 

    
    
  5. Pete Resnick: Comment [2012-02-13]:
    
    
    Instead of creating a new hex-decimal, please use HEXDIG from RFC 5234.
    
  




draft-gerhards-syslog-plain-tcp


  
    
    
  1. Adrian Farrel: Comment [2011-12-11]:
    
    
    It would be good if the Introduction included a brief paragraph on the
purpose/content of this document. The first paragraph of Section 4
contains roughly the necessary material.

---

I am uncomfortable (but not quite to the point of a Discuss) by the way
that this I-D flies in the face of IETF consensus to recommend the use
of TLS. I believe this could be resolved by a slightly stronger 
statement on the intent of the document to facilitate interoperability
with legacy deployments whild continuing to recommend the use of TLS.
I.e. "this document does not recommend that new implementations or
deployments use syslog over TCP except for the explicit purpose of 
interoperating with existing deployments."

---

I am surprised that section 5 does not mention TCP/AO.
    
    
  2. Stephen Farrell: Comment [2011-12-14]:
    
    
    - I agree with Dave's discuss points 1,2 and 4 and sympathise with
his point 3.

- Be nice to add the hex values that go with %d32 and %d126 just to
be super-clear

- 3.1 mentions "relays" but those weren't mentioned in the intro -
be nice to say what those are in section 1.

- What does "not available" mean at the end of section 5?  I think
it would be better to say "This protocol SHOULD NOT be used unless
syslog/tls [RFC5425] has been tried and failed, e.g. because there
is no listener on port 6514."

- I think you could note that falling back to this if syslog/tls
fails could in principle indicate that an attack is happening. If
there's a sensible action to take there (e.g. some local logging of
the failure of the TLS handshake or whatever in addition to remote
logging using this) that'd maybe be worth saying.


    
    
  3. David Harrington: Comment [2012-02-11]:
    
    
    I cleared.
Thank you for addressing my concerns.

    
    
  4. Pete Resnick: Comment [2011-12-13]:
    
    
    I must agree with Robert's comment that the port allocation seems inappropriate.
However, it concerns me that the port that is chosen some of the time is the rsh
port. If there is an unregistered port that is widely used for this, it should
be registered.

I agree with Adrian's comment that some of the contents of section 4 would be
terribly helpful in the intro.

I think Peter's comment regarding character terminology is important, and I'm
happy to see you're addressing it.

I am ambivalent as to whether the document should be Informational or Historic.
I lean slightly toward Informational since it is describing widespread current
practice.

[Updated to add:]

Please re-use ABNF constructs defined in RFC 5234 instead of redefining them
here:

3.4.1 - DIGIT and SP are already defined in 5234.

3.4.2 - LF is already in 5234.

    
    
  5. Peter Saint-Andre: Comment [2011-12-08]:
    
    
    According to BCP 166 (RFC 6365):

   The terms "charset", or "character encoding scheme"
   and "coded character set", are strongly preferred over the term
   "character set" because "character set" has other definitions in
   other contexts, particularly outside the IETF.

Please consider changing the term used in Section 3.1 of this I-D to match BCP
166.
    
    
  6. Robert Sparks: Comment [2012-02-02]:
    
    
    
    
  7. Sean Turner: Comment [2011-12-14]:
    
    
    I tend to agree with Dave here.
    
  




draft-sarikaya-v6ops-prefix-delegation


  
    

  1.  (none)