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"


Valid HTML 4.01 Strict


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)