IESG Narrative Minutes

Narrative Minutes of the IESG Teleconference on 2009-04-23. These are not an official record of the meeting.

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

Corrections from:

1 Administrivia

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

2 Protocol Actions

2.1 WG submission

2.1.1 - New Items

  1. Exporting Type Information for IPFIX Information Elements (Proposed Standard)
    draft-ietf-ipfix-exporting-type-03
    Token: Dan Romascanu
    Extracted from Balloting:
    1. Lisa Dusseault: Discuss [2009-04-20]: I support Alexey's DISCUSS. Language information is needed to know how to display, search on and sort human-readable fields. However, there may be other ways to get language information in this case, besides tagging each description field, e.g. tagging a document or file or allowing the user to choose a "late binding" of a language (on viewing, rather than on saving the data), provided that all description fields within a file can be treated as the same language.
    2. Lars Eggert: Comment [2009-04-20]:
      Section 1., paragraph 3: "This document proposes a general mechanism to encode the full set of"
      s/proposes/defines/
      Section 3., paragraph 2: "privateEnterprseNumber Information Element"
      Nit: s/privateEnterprseNumber/privateEnterpriseNumber/
      Section 3.9., paragraph 7:" | informationElementID | The Information Element |"
      Nit: s/informationElementID/informationElementId/
    3. Russ Housley: Comment [2009-04-20]: The Gen-ART Review by Miguel Garcia on 20 April 2009 provides some editorial suggestions.
      Section 1.1, last paragraph. There is an unfinished sentence:
      "It draws data type definitions and data type semantics definitions from the Information Model; the encodings of these data types"
      Section 3, last paragraph. There is an unfinished sentence:
      "This Information Element supports references only to IANA-defined Information Elements; the privateEnterprseNumber Information Element"
      A nit revealed by idnits: RFC 2434 has been obsoleted by RFC 5226.
      The draft contains a number of tables. It would be nice to add a table number and a caption under each of them, so that the text (or text from other drafts and RFC) can safely refer to "Table nn in RFC xxxx". This is similar to what the draft does with Figures.
    4. Alexey Melnikov: Discuss [2009-04-19]:
      3.2. informationElementDescription
      "Description: A string containing a human-readable description of an Information Element."
      The document needs to say that the description is in Unicode, encoded as UTF-8 [RFC3629].
      A normative reference to RFC 3629 needs to be added.
      Moreover, BCP 18 (RFC 2277), section 4.2 says: "Protocols that transfer text MUST provide for carrying information about the language of that text. [...] Note that this does NOT mean that such information must always be present; the requirement is that if the sender of information wishes to send information about the language of a text, the protocol provides a well-defined way to carry this information."
      I think this clearly applies in this case.
      See last paragraph of Section 3.2 in RFC 5466 for an example text for addressing this issue.
      3.3. informationElementName
      "Description: A string containing the name of an Information Element."
      Character set and encoding should be specified here. Comments mentioned above for section 3.2 are likely to apply here as well.
      Comment [2009-04-19]:
      1.1. IPFIX Documents Overview
      "It draws data type definitions and data type semantics definitions from the Information Model; the encodings of these data types"
      Unfinished sentence.
      3. Type Information Export
      "This Information Element supports references only to IANA-defined Information Elements; the privateEnterprseNumber Information Element"
      Unfinished sentence.
      In Section 3.1:
      RFC 2434 was obsoleted by RFC 5226 (this can be fixed by RFC Editor).
      4. Security Considerations [...]
      A reference to UTF-8 (RFC 3629) would be nice here.
    5. Dan Romascanu: (blank)
    6. Robert Sparks: Comment [2009-04-20]: Each element's status in this draft is currently "Proposed" - a value rfc 5102 doesn't allow. I'm guessing the intent on approval is for this to become "current"? If so, an RFC/IANA note might be nice so they don't have to guess too.
    7. Magnus Westerlund: Discuss [2009-04-20]: This is formality discuss. Easily fixed:
      First of all the references to RFC 2434 are in the wrong category. The reference is a normative one, as you can't follow the process definition without understanding what the categories means.
      This results in a normative reference to RFC 2434, an obsoleted RFC, replaced by RFC 5226. Please update but watch out for the renaming of some categories for better clarity.

    Telechat:

  2. Specification of the IPFIX File Format (Proposed Standard)
    draft-ietf-ipfix-file-03
    Token: Dan Romascanu
    Extracted from Balloting:
    1. Lisa Dusseault: Comment [2009-04-20]: Is there any intent to register a MIME type? Is there any file extension already in use?
    2. Pasi Eronen: Discuss [2009-04-23]: I have reviewed draft-ietf-ipfix-file-03, and I have a couple of concerns that I'd like to discuss before recommending approval of the document:
      1) Relying on unspecified external mechanisms for authentication and confidentiality basically means there's no interoperability between File Writers and Readers.
      It seems some sort of authentication (probably of the File Writer, not necessarily Metering Process) would be very simple to do (using e.g. CMS), and could be implemented either as a "detached signature" (no modifications to the IPFIX File, signature is stored as a separate file), by wrapping the whole IPFIX File with CMS, or including the "detached signature" as additional information element at the end of the file.
      Encryption is probably a bit more complicated, and also something where relying on external mechanisms (for storage and transit) is a more reasonable assumption than for authentication. While wrapping the whole IPFIX File with CMS can provide encryption, too, this has implications for how the system is operated. If public-key based encryption is used, the signer (probably File Writer) needs the public keys of the recipients (and this might be quite difficult in many situations). Password-based encryption for CMS (RFC 3211) would be simpler to operate, but has its own limitations.
      I think the document should specify at least an authentication mechanism (based on public-key signatures and CMS). I'm not yet quite sure whether specifying an encryption mechanism would be equally important -- opinions from others would be welcome here.
      2) Even if the File Writer is not signing the data when writing a file, if the messages over TLS, it seems preserving this information (the fact that this messages were sent by node A over TLS to node B) would be important. I haven't worked out all the details yet, but this could be as simple as specifying "exporterCertificates" (and possibly "collectorCertificates" -- so we know who the exporter thought it was sending these records to) information elements in Section 8.1.
      3) Section 8.2.8 probably needs a sentence saying that MD5 is used as a simple checksum to detect random bit errors, not as a security mechanism or for detecting intentional modifications. (And therefore therefore collision-resistance or algorithm agility is not absolutely needed.)
      BTW -- The authors have indicated they're going to do some changes to address Sam Hartman's SecDir review; but updated version hasn't been submitted yet.
      Comment [2009-04-23]: A suggestion for editorial improvement: Section 9.2 seems to suggest that CBC mode has "infinite error propagation" (an error in ciphertext makes the rest of the file unreadable). That's not the case; a single bit error in ciphertext affects only two blocks in CBC (typically, 2*16=32 bytes), so a single error would usually damage just a single IPFIX Message.
    3. Cullen Jennings: Discuss [2009-04-22]: I think this draft should register a file extension. (And would be happy to hand this Discuss to an apps AD). I think this should be fairly easy to go register.
    4. Alexey Melnikov: Comment [2009-04-20]: Updated (one extra typo at the end).
      A well written document. Some minor editorial comments and questions.
      Question: Excuse my ignorance, but what is the difference between File Time Window Options Template defined in section 8.1.2 and Export Session Details Options Template defined in section 8.1.3? The former seems to provide subset of information defined in the latter.
      This document is asking for MIME type registration for the file format ;-).
      6.4. IPFIX Device Diagnostics
      Missing "to" before "store".
      8.2.4. maxFlowEndMicroseconds
      Typo: dateTimeMicroseconds
      8.2.8. messageMD5Checksum
      typo: calculate
    5. Tim Polk: Discuss [2009-04-22]: There are several issues that I would like to raise before publication of this document. [Note that several issues are derived from Sam Hartman's secdir review and Margaret Wasserman's Gen-Art review. My thanks to those reviewers!]
      Section 5.5 seems internally inconsistent. The second sentence states that an "ideal flow storage format will support the detection and correction of encoding-level errors in the data" but immediately follows by saying that these services are more appropriate at other layers.
      After a couple of passes, I gather that comprehensive data integrity services (including detection and correction of encoding-level errors) are needed when storing flow data but the flow storage format is only expected to provide for error detection and isolation. Other layers are expected to provide more advanced error correction if needed.
      If that is what is intended, some minor edits should suffice for 5.5, but the need for external data integrity services should be added to the security considerations.
      Section 5.6 has a couple of issues. First, encrypting bulk data directly using asymmetric cryptography is generally inappropriate. Data should be encrypted using an appropriate symmetric key algorithm, then that symmetric key can be encrypted using the public key(s) of the authorized reader(s). Paragraph 1 of 5.6 seems to specify direct encryption using asymmetric cryptography.
      Secondly, while I agree that authentication and confidentiality can be provisioned at a lower layer, I think a mandatory to implement security mechanism is needed for interoperability. (CMS would be one good choice here.)
      My third note on 5.6 could be satisfied here or in the security considerations. Use of TLS and DTLS for transient protection is mentioned in passing, but the applicability isn't clear. If the flow is sensitive enough to protect in storage, and the messages are being transmitted to other components prior to signing or encrypting for storage (e.g., using CMS) then the messages should have been protected on the wire using TLS or DTLS.
      Security Considerations:
      The first paragraph ends with "The file format must therefore provide appropriate procedures to guarantee the integrity and confidentiality of the stored information." However, much of section 5 was devoted to explaining why the file format could not included procedures to make that guarantee, and needed to be supplemented with other mechanisms.
      Since long term storage is envisioned by this specification, the strength of the cryptography employed has to factor in the expected lifetime of the data. For example, using SHA-1 and RSA 1024 to sign a flow today is okay if the data will be retained for a few months, but authenticating the creator in 2015 would demand SHA-256 and RSA 2048. Similar calculus must be performed with respect to the confidentiality requirements.
      Cryptographic algorithms become weaker with the passing of time and/or improvements in cryptographic attacks. To maintain security for a particular file, it may be necessary to re-apply cryptographic protection. In particular, to maintain the ability to verify the file creator, it may be necessary to re-sign a file with stronger keys, encapsulating the old signature and data, to extend the protection. A reference to RFC 4810 along with a brief explanation of the issue might be a good addition here.
      Sam Hartman's followup email (4/22/09) highlighted two limitations that seem to be inherent in the model:
      >The first is that the data is not integrity protected end-to-end. The exporter may transport to the collector over TLS. Let's assume that the collector is digitally signing the file. There's a break in the cryptographic protection at the collector: it could modify the data however it likes. When I read the file years later, I have to trust the collector and the exporter, not just the exporter.
      >If you considered that a problem and wanted to fix it, you'd need to add digital signatures at the exporter. Given my understanding of ipfix, that would seem both expensive and unnecessary. So, instead, you should document the issue and explain that the file reader needs to trust the file writer not to modify the contents.
      >The second issue is that the collector has no way to tell the file reader the identity of the exporter. If I have a TLS connection with badguy@evil.example.com, I might trust the data less than data from sensor-53@east.example.net. The identity of the collector could be captured in a CMS signature on the file. However nothing captures the identity of the exporter--not even as an assertion from the collector.
      These limitation need to be documented in the security considerations as well.
    6. Dan Romascanu: Comment [2009-04-22]: The following three issues were raised by OPS-DIR member Margaret Wassermann. They should be addressed before the publication of the document.
      ISSUE #1: Security Requirements
      This document does not seem to be consistent with its own stated security requirements, nor does it specify any interoperable security mechanisms. In particular, sections 5.6 of the document says: "5.6. Creator Authentication and Confidentiality "Archival storage of flow data may also require assurance that no unauthorized entity can read or modify the stored data. Asymmetric- key cryptography can be applied to this problem, by signing flow data with the private key of the creator, and encrypting it with the public keys of those authorized to read it. The ideal flow storage format will support the encryption and signing of flow data. As with error correction, this problem has been addressed well at a layer below that addressed by this document. Instead of specifying a particular choice of encryption technology, we can leverage the fact that existing cryptographic technologies work quite well on data stored in files to meet this requirement. Beyond support for the use of TLS for transport over TCP or DTLS for transport over SCTP or UDP, both of which provide transient authentication and confidentiality, the IPFIX protocol does not support this requirement directly. It is assumed that this requirement will be met externally."
      I agree with this section, but I cannot find any place in the document where it describes what type of file signing technology should be implemented in File Readers and Writers, what the certificates would look like and/or how they would be bound to the file data. It also doesn't indicate what encryption technologies should be used by a File Writer to encrypt the file, what elements should/shouldn't be encrypted or how a File Reader would determine what type of decryption to perform. Without including this information, the document is, essentially, suggesting (or nearly mandating) the implementation of non-interoperable security mechanisms.
      ISSUE #2: Option Scoping
      There are options defined that are meant to apply to "the the whole IPFIX Transport Session (i.e., the IPFIX File in the common case)", such as the Export Session Details Option. However, the document also indicates that the IPFIX file format is intended to support the free concatenation and splitting of IPFIX files at IPFIX Message boundaries. Is it expected that session-scoped options will appear in all of the messages to which they apply? If not, how would the session boundaries be determined? I see that there are min and max export times in the session scoped options, but I don't see anything that prohibits (or even warns against) concatenating IPFIX sessions with overlapping times. There is some discussion of this topic in section 7.1, where it is stated that File Readers may treat multiple files as a single Transport Session, but that they will not treat a single file as representing multiple Transport Sessions. However, that doesn't seem to be consistent with the "free manipulability of IPFIX Files through concatenation, appending, and splitting (on IPFIX Message boundaries)" described in section 3.
      ISSUE #3: Data Compression
      This issues issimilar to the security issue described in ISSUE #1 above. The document indicates that data compression is desirable. Section 9.1 talks in details about issues with data compression and suggests that block compression be used. However, the document does not mandate the implementation of any specific compression algorithm, nor does it indicate how a File Reader would determine that a file had been compressed and/or what type of compression was used. Without this information, the document is suggesting the implementation of a non-interoperable compression mechanism.
    7. Magnus Westerlund: Comment [2009-04-22]: I support Lisa's question about media type for this file format, please answer it.

    Telechat:

  3. Diameter Mobile IPv6: Support for Home Agent to Diameter Server Interaction (Proposed Standard)
    draft-ietf-dime-mip6-split-16.html
    IPR: Nortel Networks Statement about IPR claimed in draft-ietf-dime-mip6-split
    Token: Dan Romascanu
    Extracted from Balloting:
    1. Ralph Droms: Comment [2009-04-20]: Should RFC 4285, "Authentication Protocol for Mobile IPv6" be a normative reference?
    2. Lisa Dusseault: Comment [2009-04-23]: Figure 2 could be much better explained and referenced. It's clear there are conventions for such diagrams but the conventions are slightly mixed -- different for IKE and for EAP so different for left and right side of the same diagram!
      - On the left side, every message contains an HDR but that's just part of the list of what the message contains
      - on the right side, every message begins with its type (DER/DEA)
      - SK{xxx} indicates signing?
      - (xxx) indicates payload in DER and DEA messages
      - CP(xxx) indicates an IKE config payload?
      - is the order of messages required -- must the HA wait for a DEA before sending the next message to the MN
      An explicit reference that the abbreviations and conventions in the left side come from RFC4306 would be good. There is a reference to 4306 shortly after the diagram but it is worded as if it explains only a small point. Better would be "Conventions and abbreviations for the MN/HA interactions in this diagram are from RFC4306" (plus an explanation for SK(xxx) which is not there.)
      I'm not sure what the reference for the right side would be.
      Similar, for the tables in section 6, it's unclear that the conventions and meaning of the columns comes from, for example, RFC3588 (though the specifics differ -- in RFC3588, the last column is not considered an AVP Flag Rule)
    3. Lars Eggert: Comment [2009-04-20]: Section 6., paragraph 2: 
                           AVP  Defined             |    |    |SHLD| MUST|MAY |

      I'd prefer SHLD->SHOULD. (Here and elsewhere.)
    4. Pasi Eronen: Discuss [2009-04-22]: I have reviewed draft-ietf-dime-mip6-split-16, and have couple of questions/concerns that I'd like to discuss before recommending approval of the document:
      1. This document specifies only the MIP6_AUTH_MN_AAA authentication mode, but seems to have lot of text that doesn't make sense for this authentication mode -- but would make sense for the (somewhat controversial) MN-HA authentication mode (where HA just asks the AAA server for a key, without proving that the user is "live" -- violating various AAA design rules).
        The MN-HA parts include e.g. Section 4.2, 5th paragraph ("In some architectures..."), and many of the AVP definitions (such as including MIP-MN-HA-SPI in MIP6-Request message -- as far as I can tell, with MIP6_AUTH_MN_AAA mode, it's included only in MIP6-Answers).
        Could you clarify what is the situation here? Is there a second draft which defines the MN-HA authentication mode? Or is the intent to specify the final missing piece for MN-HA mode (the enumerated value) in some non-IETF spec (which is allowed by the "Specification Required" IANA rule)?
        (My preference would be to either omit the MN-HA authentication mode completely, or include it fully -- including 90% of it doesn't seem like a terribly good idea.)
      2. Section 4.1, paragraph beginning with "In some deployment scenarios.." seems to suggest using the MIP6I Diameter application for non-Mobile IPv6 purposes (IPsec VPNs). Could you clarify what is the intent here?
      3. Section 6.14, "The replay modes, defined in RFC 4004 [RFC4004], are supported". The replay modes in RFC 4004 are for Mobile IPv4, not Mobile IPv6. It seems not all of them are actually supported by MIPv6?
      4. Section 6.16: The MIP-Timestamp AVP is 32 bits, but the timestamp in the BU/BAck is 64 bits -- is the HA supposed to truncate/expand this?
      5. Section 6.15: What are the expected semantics of the MIP6_SPLIT bit? A NAS that sends a message with MIP6I/MIP6A application identifier already supports this specification -- so what additional information is communicated by setting or not setting this bit?
      6. The security considerations (or some place) should explicitly mention that this spec expects that the AAA Server derives the MN-HA security association (including MN-HA shared key) somehow (probably based on the MN-AAA shared key), but there is no IETF document specifying how that is done, and the security properties of the system depend on how this is done. (For example, the simplest possible way, just using MN-AAA key as the MN-HA key, would probably have implications on how you would want to deploy your AAA nodes.)
        (This is one big difference from RFC 4004 and related Mobile IPv4 specs -- in MIPv4 case, there is an RFC (3957) that specifies how to derive the MN-HA shared key from the MN-AAA key, in a way that's reasonably OK to transport over AAA.)
      7. To me both RFC 4285 and 5149 look like they should be normative. What was the reason for moving RFC 4285 from a Normative Reference (like it was in version -15) to Informative?

      Comment [2009-04-22]: Couple of editorial suggestions/nits:
      The abstract gives the impression that this document supports IKEv2 with certificates and pre-shared secrets. This is probably left over from older draft versions, which did support them?
      Section 4.3, 2nd paragraph: The text should be clearer that for IPsec, it means IKE SAs (not CHILD SAs/IPsec SAs).
      Section 6.7: what about an IPv4 care-of address? (with DSMIPv6)
      Sections 8: The symbol "*0" isn't defined -- does this mean "0+" or something else?
    5. Adrian Farrel: Comment [2009-04-20]: Page 20 "[ Multi-Round-Time"
      Is there a missing close square bracket?
    6. Tim Polk: Comment [2009-04-23]: Use of EAP methods that do not establish a shared key is discouraged but permitted (a SHOULD NOT in section 4.1).
      That seems to conflict with goal G4.3 from ietf-mext-aaa-ha-goals...

    Telechat:

  4. GRE Key Option for Proxy Mobile IPv6 (Proposed Standard)
    draft-ietf-netlmm-grekey-option-06
    Token: Jari Arkko
    Extracted from Balloting:
    1. Ralph Droms: Discuss [2009-04-20]: I found some of the text in the document less than clear. Although most (if not all) of this DISCUSS consists of editorial issues, I think the collection of issues and the degree to which the issues require some inference about the context for this document mean that interoperability of implementations is not assured.
      Section 3: It would help to mention explicitly in a sentence before section 3.1 which RFCs or I-Ds are referenced by the text in section 3. I think these docs are RFC 5213 and ID-PMIP6-IPv4.
      Also, for (perhaps foolish) consistency, it would help to use the acronyms for MAG, LMA, etc. thoruhgout, instead of sometimes using the acronym and sometimes using the full phrase like "mobile access gateway".
      Is "policy check" a term of art in the specifications to which this document refers? I'm not sure what policy is checked in which component when the term "policy check" appears and would like to see a clarification.
      Section 3.3.1: What are "the downlink GRE key" and "the uplink GRE key"; are they chosen dynamically by the MAG and LMA (respectively), or supplied through some other configuration or ??? Add text to explain where the keys come from?
      Section 3.3.2: I'm a little troubled by the claim that a mechanism for transferring the downlink GRE key from the old MAG to the new MAG is "out of scope for this specification"; seems like a key bit of the protocol function to leave undefined. Include an example of how the exchange might be accomplished?
      Section 6.2: I don't understand the diagram. Is it an update to part of the "Proxy Binding Update message"? Where is that message defined? Add text to explain the diagram and/or give a pointer to the original definition?
      Section 6.3: as with 6.2, it would clarify the text to give a pointer to the original message definition and explain what the figure specfies.
      And a final very small editorial note, while I'm at it: should section 7.5 be promoted to a first level section rather than appearing as a subsection of 7?
    2. Lisa Dusseault: Comment [2009-04-22]: The document could explain the need for having an encapsulation mode without keys. So far, it's not clear why two modes (and associated complexity) are needed if the mode with keys could handle all the encapsulation-only use cases.
    3. Pasi Eronen: Discuss [2009-04-21]: I have reviewed draft-ietf-netlmm-grekey-option-06, and have couple of questions/concerns that I'd like to discuss before recommending approval of the document:
      • Why does the TLV header need a "Length" field? The length is already known from the UDP header, and the document doesn't specify any special processing if the TLV header length field is smaller than calculated from UDP header.
      • Sections 4.1 and 5.1 should mention a flag indicating whether the TLV-header format is used.
      • The document is not very clear whether GRE-in-UDP tunneling (without TLV header) is an allowed combination or not. I guess it's not (because then demultiplexing PBUs/PBAs becomes a problem), but if that's true, then e.g. Sections 4.1 and 5.1 should say that the GRE flag implies either "no UDP" or "UDP+TLV".
      • How does the TLV-Header negotiation interact with normal UDP encapsulation negotation? If one wants to use the TLV-Header (with UDP, since TLV-without-UDP doesn't make sense), is setting the "T" bit enough, or is the NAT Detection option needed, too?
      • Figures 5 and 7: If the intent of brackets is to denote optional headers -- like they're used in DSMIPv6 spec -- they're not correct. I'd suggest removing the brackets completely to avoid confusion.

      [2009-04-22]: Updated part:
      - The document needs to either specify how these options work in Client MIP6, or explicitly say that they MUST NOT be used with Client MIP6 until some another RFC specifies the details.
    4. Adrian Farrel: Comment [2009-04-19]: Although the references to 3775 and 5213 for terminology are clear, it would still be nice if some of the acronyms were expanded on first use.
    5. Russ Housley: Comment [2009-04-21]: Please consider the comments in the Gen-ART Review by Spencer Dawkins posted on 21 April 2009. All of the comments are minor, although I'd like to see a wording change to address this one:
      Is "vanilla" a clearly-understood term of art? :-)
    6. Tim Polk: Comment [2009-04-23]: Section 3.3.2, paragraphs 2 and 3...
      It is unclear why the MAG is permitted to either pick a new downlink key or use the same downlink key after handoff, but the LMA is required to use the same uplink key. Does the protocol fail if the LMA selects a new uplink key?
    7. Robert Sparks: Comment [2009-04-22]: The 2nd bullet on page 10 last sentence could be misinterpreted such that this MAG NEVER sends that LMA a future message with a GRE Key Option. Consider clarifying the scope of the restriction?

    Telechat:

  5. Container Option for Server Configuration (Proposed Standard)
    draft-ietf-dhc-container-opt-05
    Token: Jari Arkko
    Extracted from Balloting:
    1. Ron Bonica: Discuss [2009-04-22]: This document probably deserves some discussion. To be honest, I am torn between voting YES and DISCUSS. Let's see how the discussion on the call goes.
      On the one hand, the DHCP container object is a good thing. It permits the host and the SP DHCP Server, even when the intervening RG client has no idea what those two parties are discussing.
      On the other hand, this conversation could be dangerous. If one were to think of the customer and SP domains as being separate, the RG client would be a reasonable place to put the security boundary. If the boundary were implemented at the RG client, it would be a bad thing for the client to pass on messages that it doesn't understand.
      If this option were to be used, each client host would have to protect itself from bad behavior on the part part of the SP (e.g., installing as route to 0.0.0.0/0 through your other provider, installing a static route to the SP's competitor through /dev/null).
    2. Lars Eggert: Comment [2009-04-20]: I'm abstaining. Basically, the addition of this option turns DHCP from a host configuration protocol into a DHCP server operations & management protocol. That's a pretty dramatic change in scope for DHCP, and even if I thought this was a good idea, I'm missing documents that describe how a DHCP that had been extended with this options would be used for this purpose.
    3. Adrian Farrel: Comment [2009-04-20]: The second sentence of the Abstract is particularly flimsy.
      "This DHCP option carries a set of DHCP options that can be used by another DHCP server."
      An option carries a set of options?
      "Used by"?
      "Another DHCP server" with respect to what?
      This optional use of the word "option" gets heavy again in the penultimate paragraph of section 1.
    4. Russ Housley: Discuss [2009-04-21]: The Gen-ART Review by Scott Brim posted on 7 April 2009 raises some concerns that have not been addressed. Responses to these concerns are needed, even if there are not any document changes. The review can be found at:
      http://www.softarmor.com/rai/temp-gen-art/draft-ietf-dhc-container-opt-05-brim.txt
    5. Cullen Jennings: Discuss [2009-04-22]: My apologies for getting to this draft so late. I did not realize what it was and did not even realize this work was in progress. It has lots of implication to VoIP and IpTV work in RAI. These are discus discuss and many of them simply reflect I am just getting up to speed on this now.
      I would like the geopriv and ecrit folks to get a chance to look at this. My understanding of their assumptions about DHCP will work is not at all consistent with this and this could have some fairly significant implications to plans for Emergency 911 type systems.
      Today, RG are almost always NATs and they are deployed in a nested fashion. So the DSL modem may have a RG, but very often another "RG" that is perhaps a wireless AP is plugged into that. This draft needs advice on how it works with multiple layers of RGs. My current read of it, it does not look like it would work in the layered case.
      This draft needs advice on how the RG deals with conflicts. For example, if normally it would take whatever DNS server was found by the RG client and advertise that in the RG server. But imagine the container also has the name of the DNS server. Which one does the RG Server use?
      I don't understand why the the SP needs to be able send different information to the equipment behind the RG than it sends to the RG. Can you clarify the reasoning behind this requirement?
      In section 3, the third req bullet point. I'm not clear on the requirement. Are you saying there much be a way for a SP to add new potion that gets sent to the user equipment without changing the software/config on the RG? This would make sense to me as a requirement but I'm not sure this draft meets that. When the RG Server gets an option it does not know about in he container, what does it do with it?
      How is expiry of the information in the container handled? If the SP wants to change some of the information in it, how is that done?
      These containers are going to get very large - does anything need to be said about size? With this work with a 10k container?
      In section 5.5, can you please explicitly list the things the RG Server needs to discard - as an implementer I would not know what to do.
      Can the SP send a container even if the RG client does not request it? This seems inconsistent with other DHCP stuff. Why is it like this?
      Can the RG server return a container to someone that requests it and what goes in it?
      The idea that DHCP authentication would be configure between two nested RG in grandma's house seems extremely unlikely. I am not aware of any deployments that use authenticated DHCP between SP and RG. The idea that I can get pushed a container with the RG client did not even send a request, seems very disturbing from a security point of view. This is going to contain things like my location for E911 calls. I realize that what is possible for the security is going to be pretty limited but I'd like to see it at least mitigate attackers that were not on the path between RG Client and SP DHCP server.
      The statement that the RG server MAY discard everything make a device that passes nothing useful down fully compliant with the spec. This seems a bit problematic for trying to deploy services that actually use this. I rather see something along lines of SHOULD pass it all unless explicitly configured to block something and default configuration needs to not block.
    6. Tim Polk: Discuss [2009-04-22]: Joe Salowey's secdir review (posted on 14 April 2009) proposed clarifying text for the security considerations and raised questions regarding the suitability of this protocol for interactions between the RG server and client hosts. I have not seen a response to this message, and am interested in hearing the author's position on the proposed text and the applicability question.
    7. Dan Romascanu: Discuss [2009-04-21]: I share the concerns expressed by othe ADs about the danger of this document being interpreted as defining an extension of DHCP that would allow usage as a more generic service configuration protocol. I believe that there is need for more strict language that clarifies the scope of the container option and restricts the deployment space to RGs.
      Specifically wherever it makes sense replace 'configuration information' by 'DHCP configuration information'.
      Also in the Intorduction section:
      "The DHCP Container option defined in this document provides a mechanism through which the RG DHCP client can pass DHCP options to the RG DHCP server without explicit knowledge of the semantics of those options. With this option, the SP DHCP server can pass both current and future DHCP options to the RG DHCP server."
      "The DHCP Container option does not carry IP addresses, IPv6 prefixes or other information about leases. It carries other configuration information."
      The last phrase should make clear that the DHCP container option carries configuration information expressed as DHCP options.
      Also, in the OPS-DIR review by Tina Tsou the observation was made that it is not clear from the text that the RG client and RG server are always considered as being physically colocated in the same device. It would be good to make this statement explicit, to avoid any other 'creative' deployments or interpretations in the future.
    8. Robert Sparks: Discuss [2009-04-20]: This document appears to target a very specific type of deployment, but doesn't explicitly restrict the applicability of the option to that deployment scenario.
      Given the very limited semantic definition it's very difficult to anticipate the potential consequences should some other type of deployment attempt to use the option, or if the option leaks into unintended places.
      There was some list discussion around multiple interfaces in an RG, but it focused on DHCP-clients on those interfaces. It's not clear what could happen that's sane if the RG element had more than one interface where it was acting as a server.
    9. Magnus Westerlund: Comment [2009-04-23]: I do support the discusses from Cullen on the need to clarify and explain multi-level deployments.
      I am also worried about the architectural change and lack of documentedanalysis on what the change means.

    Telechat:

  6. An Internet Attribute Certificate Profile for Authorization (Proposed Standard)
    draft-ietf-pkix-3281update-04
    Token: Tim Polk
    Extracted from Balloting:
    1. Jari Arkko: Discuss [2009-04-23]: I would like to talk about the document's normative reference to RFC 3281 (yes, the same one that the document is also deprecating).
    2. Adrian Farrel: Comment [2009-04-20]:
      s/IPSec/IPsec/ x2
    3. Alexey Melnikov: Discuss [2009-04-20]: (Updated the DISCUSS portion)
      • 4.2. Profile of Standard Fields
        "GeneralName offers great flexibility. To achieve interoperability, in spite of this flexibility, this profile imposes constraints on the use of GeneralName."
        "Conforming implementations MUST be able to support the dNSName, directoryName, uniformResourceIdentifier, and iPAddress options. This is compatible with the GeneralName requirements in [PKIXPROF] (mainly in section 4.2.1.6)."
        What about SRVName define in: [X509-SRV] "Internet X.509 Public Key Infrastructure Subject Alternative Name for Expression of Service Name", RFC 4985, August 2007.
        Many Apps protocols are starting to recommend use of SRVName, so having a MUST/SHOULD here about them would improve consistency across protocols.
      • In Appendix A Object Identifiers:
        RFC 4510 ([LDAP]) doesn't have section 4.1.2. I think you want to reference Section 1.4 in RFC 4512.
      • In Appendix B ASN.1 Module: 
           NOTE: The value for TBA will be included during AUTH48. 

   //** RFC Editor: Remove this note prior to publication **// 

   PKIXAttributeCertificate-2008 { iso(1) identified-organization(3) 
     dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) 
     id-mod-attribute-cert2(TBA) }

        But the IANA section says that no IANA action is required. Where is this TBA coming from?

      Comment [2009-04-20]: In general I think this is a well written document and I was planning to vote "Yes" originally. Here are some other comments that might be worth addressing:
      • 1.2. AC Path Delegation
        "[...] Since the administration and processing associated with such AC chains is complex and the use of ACs in the Internet today is quite limited, this specification does NOT RECOMMEND the use of AC chains."
        NOT RECOMMEND is not a RFC 2119 keyword ("NOT RECOMMENDED" is).
      • Figure 1: AC Exchanges
        Having arrows with direction of flows would be helpful here
      • 4.3.4. Authority Information Access
        ... Support for the id-ad-caIssuers accessMethod is NOT REQUIRED by this profile since AC chains are not expected.
        NOT REQUIRED make it look as if this is an RFC 2119 contstruct, but it isn't. I suggest rewording.
        Also, a reference to section 4.2.2.1 of RFC 5280 is going to be useful here, as a search for "authorityInformationAccess" in RFC 5280 yields no result.
      • 5. Attribute Certificate Validation 
           Support for an extension in this context means: 

   1. The AC verifier MUST be able to parse the extension value. 

   2. Where the extension value SHOULD cause the AC to be rejected, the

        Why use of SHOULD here? Suggest not using RFC 2119 in this case. I.e.
        "Where the extension value causes the AC ...".
        AC verifier MUST reject the AC.
      • 7.1. Attribute Encryption
        [...] Note that there may be more than one attribute of the same type (the same OBJECT IDENTIFIER) after decryption. That is, an AC MAY contain the same attribute type both in clear and in encrypted form (and indeed several times if the same recipient is associated with more than one EnvelopedData).
        I admit I might be confused here, but I have 2 questions:
        1). Is this MAY requirement only stated in this section? I can't think of a case when both an encrypted and an unencrypted attribute of the same type are present. Note that I can see a case when several encrypted attributes of the same type are present.
        2). Shouldn't the text in () talk about *different* recipients? One approach implementers may choose, would be to merge attribute values following decryption in order to re-establish the "once only" constraint.
      • In section 8: "...Implementers SHOULD be very careful in mappingthe authenticated identity to the AC holder."
        Can you elaborate on what problem the last sentence in Section 8 is trying to address? Is this referring to insecure mappings, or something else?
    4. Dan Romascanu: Discuss [2009-04-21]: If I understand well the current rules and the latest interpretation given by the Legal Counsel of the IETF, the code in Appendix B should include the (long version) copyright notice in "code" similarly to MIB modules and such.
    5. Robert Sparks: Discuss [2009-04-20]: I don't think the following normative reference is stable enough:
      [RFC3281-ERR] http://www.rfc-editor.org/errata_search.php?eid=302
      1) The content behind that link can change significantly over time
      2) The link, as expressed, puts a constraint (read burden for the maintainers) on how the errata_search tool works going forward.
      Could the single correction in that errata be captured as a note in this document instead?
      Comment [2009-04-20]: The diff between this and 3281 is pretty simple. The deletion of this sentence (near the end of page 32 of 3281 update) sticks out on casual inspection: "In this case, the digestedObjectType MUST be publicKey and the otherObjectTypeID field MUST NOT be present." I wanted to shine the light on it to make sure its deletion was intentional.
    6. Robert Sparks: Discuss [2009-04-20]: I don't think the following normative reference is stable enough:
      [RFC3281-ERR] http://www.rfc-editor.org/errata_search.php?eid=302
      1) The content behind that link can change significantly over time
      2) The link, as expressed, puts a constraint (read burden for the maintainers) on how the errata_search tool works going forward.
      Could the single correction in that errata be captured as a note in this document instead?
      Comment [2009-04-20]: The diff between this and 3281 is pretty simple. The deletion of this sentence (near the end of page 32 of 3281 update) sticks out on casual inspection: "In this case, the digestedObjectType MUST be publicKey and the otherObjectTypeID field MUST NOT be present." I wanted to shine the light on it to make sure its deletion was intentional.

    Telechat:

  7. Cryptographic Message Syntax (CMS) (advance to Draft Standard)
    rfc3852
    Token: Tim Polk
    Extracted from Balloting:
    1. Jari Arkko: Comment [2009-04-23]: Why on earth does the "Position list for N.N. for 2009-04-23 telechat " page in the tracker for this document point to some unrelated draft (https://datatracker.ietf.org/cgi-bin/idtracker.cgi#draft-schoenw-snmp-tc-ext) as opposed to the RFC?
    2. Lars Eggert: Comment [2009-04-20]: Agree with Alexey about rolling in the erratas. Also, RFC4853 should be rolled in and obsoleted.
    3. Pasi Eronen: Comment [2009-04-22]: I agree with Lars/Alexey that rolling in the erratas and RFC 4853 would improve the document.
    4. Cullen Jennings: Discuss [2009-04-22]:
      Real discuss - Seems like we need to clarify the license rules that apply to this. This could be resolved with note to RFC Editor that says this needs the note the it contains text from rules prior to Nov 2008.
      This is a discuss Discuss. I imagine I am missing something here but this seems like it brings in all 3280. Doesn't' this just bring 3280 to Draft as well? (and 3281 for that matter).
    5. Alexey Melnikov: Comment [2009-04-14]: I would prefer if Errata is folded into the document and a new RFC is created.
    6. Robert Sparks: Discuss [2009-04-23]: Discuss-Discuss: I would like to see this advance. I expected to find some discussion (in LC) of what I think are going to be downrefs this goes forward and am not finding it. Am I looking in the wrong places?

    Telechat:

2.1.2 Returning Items

  1. Carrying Location Objects in RADIUS and Diameter (Proposed Standard)
    draft-ietf-geopriv-radius-lo-23
    Token: Cullen Jennings Note: Did new LC because previous one did not mention DOWNREF
    Extracted from Balloting:
    1. Jari Arkko: Comment [2008-07-17]: I have reviewed the specification and the last call discussion, and I believe the document is ready to be approved. I think the authors have struck the right balance between keeping the location information opaque vs. allowing servers to make authorization decisions IF they need to do it.
      A few minor comments. Section 4.7:
      "The numerical value representing FUTURE_REQUESTS indicates that the RADIUS client MUST provide future Access-Requests with the same information as returned in the initial Access-Request message."
      To avoid confusion, please change s/future Access-Requests/future Access-Requests for the same session/
      Security Considerations say:
      "Confidentiality protection is not only a property required by this document, it is also required for the transport of keying material in the context of EAP authentication and authorization. Hence, this requirement is, in many environments, already fulfilled."
      Heh. Or at least the requirement is already present for other reasons in many environments. Fulfillment is another question...
      I'm not asking for any change here.
    2. Ralph Droms: Discuss [2009-04-22]:
      Section 4.5 (Page 27): The description of the "Integer" field in the Location-Capable Attribute does not make explicit that the contents of the field is a bit field representing capabilities. The description should be edited to match the description of the "Integer" field in the Requested-Loction-Info Attribute (section 4.7).
      Section 4.6 (Page 30): If I understand the description of the Location-Capable Attribute correctly, in figure 6 the RADIUS Client would indicate some set of location capabilities in the Location-Capable attribute in the Access-Request message, and the RADIUS Server selects a subset of those capabilities in the Requested-Location-Info Attribute in the Access-Challenge message. Figure 6 should include an example of the capabilities of the Radius Client in the Access-Request message, to be consistent with the indication of the capabilities in the Access-Challenge message.
      Comment [2009-04-22]: Section 4.4 (page 23): Text describing "String" in the Basic-Location-Policy_Rules Attribute is inconsistent: use "Flags" or "Flag" consistently; delete spurious "'" in "Flag'"; suggest (for consistency) replacing "The Flag' field" with "This field..."
      Section 6 (page 37): A pointer to the rules for interpreting the table of data types and flag rules would be helpful.
    3. Ralph Droms: Discuss [2009-04-22]:
      Section 4.5 (Page 27): The description of the "Integer" field in the Location-Capable Attribute does not make explicit that the contents of the field is a bit field representing capabilities. The description should be edited to match the description of the "Integer" field in the Requested-Loction-Info Attribute (section 4.7).
      Section 4.6 (Page 30): If I understand the description of the Location-Capable Attribute correctly, in figure 6 the RADIUS Client would indicate some set of location capabilities in the Location-Capable attribute in the Access-Request message, and the RADIUS Server selects a subset of those capabilities in the Requested-Location-Info Attribute in the Access-Challenge message. Figure 6 should include an example of the capabilities of the Radius Client in the Access-Request message, to be consistent with the indication of the capabilities in the Access-Challenge message.
      Comment [2009-04-22]: Section 4.4 (page 23): Text describing "String" in the Basic-Location-Policy_Rules Attribute is inconsistent: use "Flags" or "Flag" consistently; delete spurious "'" in "Flag'"; suggest (for consistency) replacing "The Flag' field" with "This field..."
      Section 6 (page 37): A pointer to the rules for interpreting the table of data types and flag rules would be helpful.
    4. Lars Eggert: Comment [2008-07-11]:
      • Section 4.1., paragraph 17: "Example: anyisp.example.com"
        Suggest to move this example down to the description of the REALM namespace, because it's specific to it. (It confused me on first reading to see the example and then read about namespaces where it isn't valis.) It might also be good to add one example to each of the other namespaces.
      • Section 4.2., paragraph 2:
        "The Location-Information Attribute provides meta-data about the location information, such as sighting time, time-to-live, location determination method, etc. Implementations SHOULD treat this attribute as undistinguished octets, like the Location-Data Attribute to which it refers."
        Why is this a SHOULD and not a MUST? Under what conditions may implementations interpret the attribute? (The same comment applies to other attributes below.)
      • Section 4.4., paragraph 19:
        "Note Well (variable): This field contains a URI that points to human readable privacy instructions. The data type of this field is string.
        The APP ADs should look at this. I'm not an i18n expert, but it seems pretty important to transport a URI here that points to something a user can understand.
      • Section 4.4., paragraph 21:
        "retransmission-allowed: When the value of this field is to zero (0), then the recipient of this Location Object is not permitted to share the enclosed location information, or the object as a whole, with other parties."
        Are there any protocol or encoding mechanisms in place to prevent this sharing, or do we simply trust the other end to conform to our wishes? (Same issue applies to "retention-expires".)
      • Section 4.6., paragraph 1:
        "A RADIUS server SHOULD NOT challenge for location information unless the Location-Capable Attribute has been sent to it."
        Why is this a SHOULD NOT? When is it permissible to challenge?
      • Section 6., paragraph 2: 
                                              |    |     |SHLD| MUST|    |

        s/SHLD/SHOULD/ (don't abbreviate RFC2119 terms)
      • Section 8.1., paragraph 3: 
           |   0x31   | REALM              | IETF O&M Area Directors            |
   |          |                    | (ops-chairs@ietf.org)              |

        The ADs are at ops-ads@ietf.org.
      • Section 8.2., paragraph 6:
        'No mechanism to mark entries as "deprecated" is envisioned. Based on expert approval it is possible to delete entries from the registry.'
        It's usually much safer to deprecate registry entries or to make them historic, compared to simply removing them. Is there a particular reason for this choice? (Same comment applies to other registries.)
      • Section 9., paragraph 1:
        "We would like to thank Bernhard Aboba for the numerous contributions to this document."
        It's a bit unusual to thank a co-author, but hey :-)
    5. Adrian Farrel: Discuss [2009-04-20]: I would have appreciated an overarching comment on the format of the TLVs you use so that it was clear whether the Length includes the Type and Length fields.
      I find that in 4.1 for the Operator-Name Attribute we have
      "Length: >= 5"
      Yet, Type is 1 byte, Length is 1 byte, and we see
      "Text: This field is at least two octets in length"
      (which looks like >= 4 to me with the Type and Length included)
      OTOH, in section 4.2 for the Location-Information Attribute we have a statement that
      "Length: >= 21"
      and I see that we have
      "Index (16 bits) Code (8 bits) Entity (8 bits) Sighting Time (64 bits) Time-to-Live (64 bits) Method (variable) [I think this is at least 8 bits]
      Total at least 168 bits = 21 bytes.
      So the Type and Length are not included.
      Then in 4.3 for Location-Data Attribute
      "Length: >= 21
      This is clearly wrong since
      "String: This field is at least two octets in length"
      And in 4.4 for Basic-Location-Policy-Rules Attribute
      "Length: >= 12"
      where
      "String:"This field is at least 8 octets in length"
      Neither 8 nor 10 is equal to 12
      But anyway, examining the contents of String yields
      "Flag (16 bits): Retention Expires (64 bits): Note Well (variable):"
      That is at least 80 bits or 10 octets.
      It is unclear whether the Note Well field may be empty.
      Sections 4.5 and 4.6 imply the Type and Length are included.
    6. Dan Romascanu: Comment [2008-11-07]: This COMMENT is based on the AAA-Doctor review by David Nelson.
      I have cleared a previous DISCUSS that was raising a number of concerns.
      1. One of them was mentioning that this document needs at the very least an IESG Note calling attention to the fact that certain of the RADIUS attributes fail to meet either the letter or spirit of the RADIUS Design Guidelines as to what may properly constitute an "opaque" attribute. Opaque attributes are those that are carried in RADIUS, but not parsed or directly acted upon by a RADIUS server.
      The revised text that addresses this issue is as follows:
      4. Attributes
      "It is important to note that the location specific parts of the attributes defined below are not meant to be processed by the RADIUS server. Instead, a location server specific component used in combination with the RADIUS server is responsible for receiving, processing and further distributing location information (in combination with proper access control and privacy protection). As such, from a RADIUS server point of view location information is treated as opaque data."
      This text does not reference the Design Guidelines, but rather simply declares that the attributes in question are to be considered opaque. I think this is a bit superficial, but probably suffices to address the issue.
      2. A second issue is whether RADIUS servers are expected to be able to parse and act upon these various defined "string" data sets. In the IETF Last Call discussion, these seemed to be some confusion as to whether this document required RADIUS servers (at least those implementing these attributes) to be "location aware" i.e. to be able to parse and act intelligently upon the content of the location information.
      The added text of Section 4 addresses this issue, too.
      While I have some lingering concerns that the attribute design style of this document may be viewed as a model for future work, as there is no explicit acknowledgement that it diverges from the Design Guidelines, I think that the added text is sufficient to close the DISCUSS.

    Telechat:

2.2 Individual Submissions

2.2.1 New Items

  1. Extending ICMP for Interface and Next-hop Identification (Proposed Standard)
    draft-atlas-icmp-unnumbered-06
    IPR: Juniper's Statement of IPR related to draft-atlas-icmp-unnumbered-06
    Token: Jari Arkko
    Extracted from Balloting:
    1. Lars Eggert: Discuss [2009-04-21]:
      First off, I do believe that the extensions in this document will provide useful testing & debugging information, and I have no issue with the specification per se.
      What I'm still not getting after reading the document (and I'm reading this while jetlagged, so excuse me if I'm missing something obvious) is exactly for which ICMP messages a box would include these extensions and under which conditions. Are these extensions only going into ICMP Unreachables or can they be included in other ICMP messages? Are they only included when the interface is unnumbered or can they be included in the other case?
      A related issue is that the document is clearly written with a focus on routers, but end systems also generate ICMP messages and specifically ICMP Unreachables. ICMP itself doesn't distinguish whether the box that emits an ICMP message is a host or a router in many cases. If this is to be a general extension to ICMP (which it sounds like) then it should be written as such, i.e., it should be more generally phrased such that the extension would apply to routers and hosts.
    2. Pasi Eronen: Discuss [2009-04-21]: I have reviewed draft-atlas-icmp-unnumbered-06, and have one concern that I'd like to discuss before recommending approval of the document:
      Since any valid US-ASCII string is also a valid UTF-8 string, why is charset type 0 needed at all? Or actually, why is the whole charset type field needed -- do you expect that someone will need something else than UTF-8? (If not, we should just delete the field; and if yes, probably using the existing IANA character set registry would be better than creating a new one?)
      Couple of minor comments/suggestions:
      - Section 4.2, "indicates the character set type used by the second field" should be "..used by the third field", right? (if the charset field is kept, that is)
      - Section 4.3, example 4: the C-Type value looks wrong -- Interface Role field contains 2 (sub-IP member), not 1? (Or is this just a consequence of weird bit numbering, already noted in Adrian's discuss?)
      - It looks like UTF-8 and US-ASCII should be normative references.
    3. Adrian Farrel: Discuss [2009-04-18]: In addition to my list of minor issues raised as Comments, I have a long list of relatively small Discuss issues. I believe they can be resolved with simple changes to the text.
      • a. c-type bit numbering (section 4.1)
        It is highly confusing that the c-type bit numbers are presented right-to-left. Could you arrange for the bits to be presented in the same order as they are in the other figures (e.g. figure 3). This will help to clear up my comment about how Interface Role is read from the c-type. You will also need to fix the bit numbering in the rest of the draft (page 8 para 2, and section 7).
      • b. Section 4.1: Next-hop "unless the Interface Role is 3"
        This value is not allowed!
      • c. Section 4.2
        You need to describe the padding rules for the Interface Name Sub-Object
      • d. Section 4.3
        In three cases you get the object length wrong.
        Eg.1 16*4 = 64, so you need L = 72 (4 + 4 + 64)
        Eg.2 Similarly: L = 76 (4 + 4 + 4 + 64)
        Eg.4 L = 8 (4 + 4)
      • e. Section 4.4 para 1
        It would be helpful if this paragraph explained/reminded how an unnumbered interface is identified as both an IP address and ifindex is required, but only the ifindex is allowed to be included.
        Recall that it is possible (although maybe not wise) to have numbered and unnumbered addresses on the same box, so the source address on the ICMP message might be the numbered interface out of which the message is sent, while we want to report about an unnumbered interface.
      • f. Section 4.4 para 2
        It is clear that more than one Interface Information Object with the same interface role MUST NOT be sent. But you need to describe what to do if it is received.
      • g. Section 5 para 2
        The reference to the "Description" is wrong. I assume you mean the "Interface Name". But is it still the case that the Interface Name can be rewritten with additional descriptive text?
      • h. Section 5 para 3
        This reference to I-D.ietf-behace-nat-icmp means that it should really be a normative reference.
      • i. Section 5 final para "MAY choose to pass the extention unaltered."
        Fine with that, but you need to give some reasoning.
      • j. Section 6 para 1
        This dependence on I-D.shen-udp-traceroute-ext means that it should be a normative reference.
      • k. Section 6
        There is no description of the security of the ICMP message (and in particular the security of the new extensions). Nor is there any mention of the use of the new extensions as part of an attack. I'm sure the Security ADs will comment further.
      • l. Section 7
        To be revised in line with point a.
      • m. Section 7
        s/on first come basis/as First Come First Served/

      Comment [2009-04-18]: A bunch of minor comments that would ideally be fixed before publication.
      1. Abstract mentions OSPF
        a. This reference to the IGP should probably also show up in the main text.
        b. You should give equal weight to IS-IS.
      2. Section 2 para 2 "nominal"
        I think you mean "normal"
      3. page 4 para 2 Two cases of "identify"
        I think you mean "indicate"
      4. page 4 para 3
        The text says "any or all" which implies that you can include an IPv4 and an IPv6 address for the incoming interface at the same time. But I don't think this is actually the case.
      5. page 4 paras 4 and 5 seem to say the same thing.
      6. Section 3.2
        Please expand ACL
      7. Section 4
        It would be nice to explain that the new object is formattedexactly as other ICMP objects and give a reference.
      8. Section 4.1 (see previous point)
        Up to this point we have no clue what a "c-type" is.
      9. Section 4.1
        It would be best if the fields described under Figure 1 used the same names as the fields in the figure (rather than close aproximations)
      10. Section 4.1
        Given the bit numbering in the figure, it is unclear from the text how the two-bit Interface Role field is read. The text says [6:7] which appears to imply that the value 2 is encoded as b01 in the figure. But please see my Discuss on bit numbering.
      11. Section 4.1 page 8 para 1 "With the exception of the Interface Name sub-object, the information included does not self-identify."
        Looking at the Interface Name sub-object, I don't believe it self-identifies either, although it does self-qualify.
      12. Section 4.1 page 8 para 2
        I note that the order of information elements is almost the same as the order of bits in the c-type, but not quite. While this certainly does not break the protocol, it is unnatural and may cause some implementations to stumble. Any reason not to reverse the the nexthop and name bits or elements?
      13. Figure 3
        Please align the bit numbers with the figure
      14. Figure 4 Example 1
        Please align the right-bars in the figure
      15. Section 5 para 1
        s/contain realm/contains realm/
        s/in presence/in the presence/
      16. Section 6
        I believe it would be wise to state that the policy controls SHOULD be configurable in an implementation (rather than simply referencing another I-D).
    4. Russ Housley: Discuss [2009-04-21]: The Gen-ART Review by Ben Campbell was originally posted on 2009-01-08, and it lead to some discussion where the authors agreed to make some changes. Then, other things lead to a repeat of the INTAREA Last Call. When the IETF Last Call was repeated, Ben reminded the authors of the previous discussion:
      "I previously reviewed this draft in it's first IETF LC. Further correspondences with the authors addressed all of my comments, however as far as I know the draft has not been updated.
      The document has still not been updated! Please make the agreed updates.
    5. Tim Polk: Discuss [2009-04-23]: Phil Hallam-Baker's secdir review (posted 9 February 2009) suggested the need for additional information in the security considerations section. There has been no response to date...
    6. Dan Romascanu: Discuss [2009-04-23]:
      In Section 4:
      "3. An Interface Name Sub-Object, containing a string of no more than 62 octets, MAY be included. That string, as specified in Section Section 4.2, is the interface name and SHOULD be the MIB-II ifName [RFC2863], but MAY be some other human-meaningful name of the interface."
      Then in 2.4:
      "The Interface Name Sub-Object MUST have a length that is a multiple of 4 octets and MUST NOT exceed 64 octets. A one octet "charset type" and a one octet "length" are required and the interface name can be at most 62 octets long. The interface name SHOULD be the full MIB-II ifName [RFC2863], if less than 63 octets, or the first 62 octets of the ifName, if the ifName is longer."
      RFC2863 defines ifName as a DisplayString with no other size limitation, which means it can exetend to as much as 255 characters. Two issues here:
      - what should the host or router that implements these extensions do when the ifName lenght is not a multiple of 4? Padding?
      - truncating to the first 62 bits if the lenght of ifName exceeds this value may result in non-unique names. It looks like it would be a better solution to recommend not to use ifName for the interface name sub-object in such cases.
      Comment [2009-04-23]:
      1. In the Abstract please replace 'MIBs' by 'MIB modules'
      2. I support Lars's DISCUSS about the need to be explicit about what ICMP messages will include these extensions.
    7. Robert Sparks: Discuss [2009-04-22]: Philip Matthews raised some questions during LC that should be answered before proceeding.
      See: http://www.ietf.org/mail-archive/web/ietf/current/msg56428.html
    8. Magnus Westerlund: Discuss [2009-04-23]:
      Section 4.1:
      2 :IP address : "When set, this indicates an IP address of the interface is included. When clear, no IP address is included. The version of the IP packet containing the ICMP message will indicate the type of IP address. An IPv4 packet will have an IPv4 address; an IPv6 packet will have an IPv6 address."
      Due to v4 to v6 translators that are currently under discussion and the recommendation considered is to pass ICMP extensions transparently. Thus I would strongly recommend explicit address family indication. I think the extension should be as self contained as possible from that perspective.
      Section 5. If this is going to stay the recommendation then this document should update RFC 5508 due to that the extension is of an class that didn't exist when the document was written. It also recommends a behavior that isn't the obvious one for a reader of RFC 5508, where transparent forwarding or dropping is the more logical choices.
      Section 5: Should include recommendations on what to do when doing address family translation, NAT-PT or the ongoing work in BEHAVE WG.

    Telechat:

2.2.2 Returning Items

  1. (none)

3 Document Actions

3.1 WG Submissions

3.1.1 New Items

  1. OSPFv2 Routing Protocols Extensions for ASON Routing (Experimental)
    draft-ietf-ccamp-gmpls-ason-routing-ospf-08
    Token: Adrian Farrel
    Extracted from Balloting:
    1. Jari Arkko: Discuss [2009-04-23]: The document says:
      "Length is set to the sum over all of the local prefixes included in the sub-TLV of (4 + (number of 32-bit words in the prefix)/4 ). The encoding of each prefix potentially using fewer than four 32-bit words is described below."
      "PrefixLength: length in bits of the prefix."
      "PrefixOptions: 8-bit field describing various capabilities associated with the prefix (see [RFC5340] Section A.4.2)."
      "IPv6 Address Prefix "i": encoding of the prefix "i" itself as an even multiple of 32-bit words, padding with zero bits as necessary."
      But I am having trouble understanding what exactly you are saying here, or at least there are multiple interpretations. Please clarify the following:
      * The formula for length, why do you divide (number of 32-bit words in the prefix)/4? So, if I have two 32-bit words, for instance, this becomes 2/4 = 0? Did you perhaps mean *4?
      * Related to this, the length field explanation does not say which units they are expressed in. I am guessing bytes, because you have the fixed term 4 in the formula.
      * I presume that there's a relationship between prefix length and how many 32 bit words you actually include, but you don't explicitly say this. Suggested reformulation: "... encoding of the prefix "i" itself as zero, two, or four 32-bit words, depending on whether prefix length is zero, less or equal to 64, or longer. Padding with zero bits is used as necessary.
      Comment [2009-04-23]: For some reason I had trouble getting a good overview of what the document is really doing and how ASON routing works in OSPF; my Discuss is about details, but I would also suggest an editorial pass to make the document more readable as a standalone document.
    2. Ralph Droms: Comment [2009-04-22]: Nit: in the 3rd para of the Abstract, this sentence is incomplete:
      "This document defines to the OSPFv2 Link State Routing Protocol [...]"
    3. Lisa Dusseault: Discuss [2009-04-23]: DISCUSS:
      Section 9.1.1 registers values 25 and 26 in a registry for which RFC 3630 says "Types in the range 3-32767 are to be assigned via Standards Action".
      Section 9.1.2 creates a new registry for which values 0-32767 are reserved for Standards Action, but this is not a Standards Action creating the registry or placing value 26 in it.
      I can't figure out which registry 9.1.3 is referring to.
      COMMENT:
      I don't really see an experiment to be run here. What outcome would lead to another version of the document to be published on the Standards Track instead of Experimental? Or conversely, what outcome would lead to us marking the document as Historic?
      That said, I don't really object to Experimental status - to me the implicit experiment if not otherwise stated is "to see if this works and is adopted".
      Comment [2009-04-23]: (blank)
    4. Robert Sparks: Comment [2009-04-22]: Please consider wordsmithing the sentence calling out [RFC2328] and [OSPF-CA] in the security considerations to make it more obvious that those are intended to be possible mechanisms. As it is, the sentence might be read to mean they are required mechanisms.

    Telechat:

  2. State Machines for Protocol for Carrying Authentication for Network Access (PANA) (Informational)
    draft-ietf-pana-statemachine-11
    Token: Jari Arkko
    Extracted from Balloting:
    1. Discuss [2009-04-23]: I didn't do a full review of the state machines, but I noticed one difference between the PANA-EAP interface and RFC 4137:
      The interface between the PANA state machine and EAP doesn't seem to support the case when when EAP silently discards a packet (eapNoResp and eapNoReq variables in the RFC 4137 state machines). Is this a limitation of the PANA protocol, or just a corner case that wasn't included in these state machines?
    2. Adrian Farrel: Comment [2009-04-20]: I'm clearing as Jari has pointed me at Section 4 that covers my most significant issue.
      There are two important points that are shown in the Abstract that I would like you to consider adding to the main body of the text.
      - "The statemachines and associated model are informative only."
      - "Implementations may achieve the same results using different methods."
    3. Tim Polk: Discuss [2009-04-23]: This is a discuss discuss. I will clear after the call unless the sponsoring AD asks me to hold. (Note this discuss is going to the iesg only...)
      Opening caveat: I am not really a state machine guy, so this may all be normal accepted practice. That is why it's a discuss discuss.
      I found the use of the eap_piggyback procedure in the exit conditions to be very confusing. I would expect exit conditions to be specified in terms of the rec'd messages and state variables, but not locally executed procedures.
      In a number of cases, there are two exit conditions that differ solely in the value returned by this procedure. It would make more sense to me if the exit condition was specified without eap_piggyback, and the call to eap_piggyback was the first step in the exit condition. This has an unfortunate side effect (multiple exit states, depending on the result), which may explain the methodology
      I will give one example to provide a basis for discussion. As dscribed above, note that collapsing the two states into one results in two different exit states:
      Current text, page 21: 
         - - - - - - - -(PAA-initiated Handshake, optimized) - - - - - -
   Rx:PAR[S] &&             EAP_Restart();             INITIAL
   PAR.exist_avp            TxEAP();
   ("EAP-Payload") &&       SessionTimerReStart
   eap_piggyback()            (FAILED_SESS_TIMEOUT);

   Rx:PAR[S] &&             EAP_Restart();             WAIT_EAP_MSG
   PAR.exist_avp            TxEAP();
   ("EAP-Payload") &&       SessionTimerReStart
   !eap_piggyback()           (FAILED_SESS_TIMEOUT);
                            if (generate_pana_sa())
                                Tx:PAN[S]("PRF-Algorithm",
                                  "Integrity-Algorithm");
                            else

      What I would have expected: 
         - - - - - - - -(PAA-initiated Handshake, optimized) - - - - - -
   Rx:PAR[S] &&             if eap_piggyback()              INITIAL
   PAR.exist_avp                 EAP_Restart();
   ("EAP-Payload")               TxEAP();
                                 SessionTimerReStart
                                   (FAILED_SESS_TIMEOUT);
                            else
                                 EAP_Restart();             WAIT_EAP_MSG
                                 TxEAP();
                                 SessionTimerReStart
                                    (FAILED_SESS_TIMEOUT);
                                 if (generate_pana_sa())
                                     Tx:PAN[S]("PRF-Algorithm",
                                        "Integrity-Algorithm");
                                 else
                                     Tx:PAN[S]();

    Telechat:

3.1.2 Returning Items

  1. (none)

3.2 Individual Submissions via AD

3.2.1 New Items

  1. (none)

3.2.2 Returning Items

  1. (none)

3.3 Independent Submissions via RFC Editor

3.3.1 New Items

  1. ECC Brainpool Standard Curves and Curve Generation (Informational)
    draft-lochter-pkix-brainpool-ecc-03
    Token: Tim Polk Note: Reviewing AD is satisfied that no IPR disclosure specific to this draft is needed. (Independent submission, not sponsored!)
    Extracted from Balloting:
    1. Jari Arkko: Discuss [2009-04-23]: I would like to talk about this on the call.
      I am trying to reconcile the facts that we are OK with the publication, the IANA considerations sections says there are no IANA actions, ecStdCurvesAndGeneration uses a value from the ISO tree, and defines a new subtree which presumably could have sub-allocations in it.
      At the very least, I'd like to know that
      (a) ISO is OK with this allocation (we should avoid stepping on IETF values *and* other people's values, too.
      (b) ISO or someone else has already a rule that tells what to do for suballocations under ecStdCurvesAndGeneration.

    Telechat:

  2. PPP Over Ethernet (PPPoE) Extensions for Credit Flow and Link Metrics (Informational)
    draft-bberry-rfc4938bis-00
    Token: Jari Arkko
    Extracted from Balloting:
    1. Alexey Melnikov: Comment [2009-04-19]: The document would be improved if it specifies byte order for 16bit and bigger fields.

    Telechat:

3.3.2 Returning Items

  1. (none)

1300 EDT break

1306 EDT back

4 Working Group Actions

4.1 WG Creation

4.1.1 Proposed for IETF Review

  1. Open Web authentication (oauth)
    Token: Lisa

    Telechat:

4.1.2 Proposed for Approval

  1. Multiple Interfaces (mif)
    Token: Jari

    Telechat:

  2. Locator/ID Separation Protocol (lisp)
    Token: Jari

    Telechat:

  3. Network-Based Mobility Extensions (netext)
    Token: Jari

    Telechat:

4.2 WG Rechartering

4.2.1 Under evaluation for IETF Review

  1. (none)

4.2.2 Proposed for Approval

  1. (none)

5. IAB News We can use

  1. Dave: IAB canceled meeting this week; retreat starts Sunday night (no formal agenda for retreat yet)

6. Management Issues

  1. 3932bis (Jari)

    Telechat:

  2. odd ipr-announce subject lines (Lars Eggert)

    Telechat:

  3. Liaison Response to ITU-T SG11 REVIEW DRAFT TEXT (Lars Eggert and Magnus Westerlund)

    Telechat:

7. Agenda Working Group News

1447 EDT Adjourned