IESG Narrative Minutes

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

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

Corrections from: Barry, Pete, Robert, Adrian

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 Submissions

2.1.1 New Items

  1. Geolocation Policy: A Document Format for Expressing Privacy Preferences for Location Information (Proposed Standard)
    draft-ietf-geopriv-policy-25
    Token: Robert Sparks
    Note: The Document Shepherd for this document is Richard Barnes (rbarnes@bbn.com).
    Discusses/comments (from ballot draft-ietf-geopriv-policy):
    1. Stewart Bryant: Comment [2012-04-23]:
      Maybe "Internationalization" is an IETF keyword for character set, but I was surprised that the section did not include a discussion on the datums use in different countries. The text only supports WGS84, but I understand that there are other datums and that WGS84 is tied to GPS but that there are other Sat Nav systems.
    2. Ralph Droms: Comment [2012-04-25]:
      Minor editorial nits:
      (4 items)
    3. Adrian Farrel: Comment [2012-04-26]:
      I find the philosophical aspects of this work very hard to grapple with. Had the work been presented in a more abstract way (for example, as a policy language that could be used in a number of ways) I would have found it easier. But the text on motivation disturbs me and, while I can completely accept that many people are motivated in this way, the approach and ideas seem to me to be broken.
      I do not believe that I should enter a Discuss or stand in the way of this work because of my views, but I cannot offer a "No Objection" ballot position.
      Additionally, the authors might like to consider the following:
      It is not clear to me why algorithms need to be standardised in this case. While they do affect what is sent on the wire, and while they provide useful examples to show that the results can be reliably achieved, it seems to me that the results of the algorithms (i.e. the outputs based on the inputs) are all that need to be contained in a Technical Specification. In short, I do not believe that the specification of the algorithms is necessary for interoperability.
    4. Stephen Farrell: Discuss [2012-04-19]:
      Since the previous iesg discussions on this document pre-date me as an AD I might be commenting here on things that have already been discussed. If so, just send me a pointer if you can to the earlier discussion.
      - general: repeated queries are a threat here and are recognised as such in a number of places. I would like to have seen some guidance to implementers as to when such repeated queries might be considered to be an attack, and when not, and if there's something you can do about that. Can such guidance be offered? If so, why not include it in the document? If not, perhaps saying why that's the case would be worthwhile?
      - 13.4: The last sentence is too vague IMO. I think you mean that if location is only obscured e.g. around the home, then the lack of location implies that I'm at home. You should say that more clearly.
    5. Stephen Farrell: Comment [2012-04-19]:
      (12 items)
    6. Barry Leiba: Discuss [2012-04-23]:
      -- IANA Considerations --
      To ensure that IANA understands which registries you're putting things in, please specify very clearly which registry, using the exact name. It would be nice to include the URL as well, to be absolutely sure. I have no idea what registries you're registering into in 11.1, 11.2, 11.4, and 11.5. The registry for 11.6 appears to be "XCAP Application UNIQUE IDs", not "XCAP Application USAGE IDs"... is that correct?
      For the new registry in 11.3, I would like to see a rationale for the choice of registration policy. See draft-leiba-iana-policy-update, if you want to see where I'm coming from here. Standards Action is a very restrictive policy choice, and I'd like to see that it was seriously considered and discussed, and understand why it was chosen over a less restrictive option.
      I'm also generally concerned about the longevity of contact information for items registered for Standards Track use, and find it problematic to use an individual's email address. Discussion: should you be using the address of a WG or non-WG mailing list, which will survive, say, the job change of an individual?
    7. Barry Leiba: Comment [2012-04-23]:
      Substantive suggestions; please adopt or respond to these:
      (many items)
    8. Pete Resnick: Comment [2012-04-25]:
      This document needs a great deal of editing for simplification and clarity. That said, none of these (or the other changes I suggest below) are enough for me to hold up the document. But I do wish you would address these issues before publication.
      (many items)
    9. Sean Turner: Discuss [2012-04-25]:
      Just trying to make this actionable (I understand this parenthetical bit isn't so much: the rest of the section needs a good editorial pass to make sure it makes sense -see my comments):
      The last paragraph in s13.2 seems like it might be missing a discussion about one of the three things listed in the 1st sentence. There's a discussion about the 1st and 2nd issue but not the 3rd and the 1st and 2nd issue both "the following", which I assume has something to do with Jack Torrance/Nicholson. Maybe it's just editorial, but I'd like to make sure nothing got dropped.
    10. Sean Turner: Comment [2012-04-25]:
      (many items)

    Telechat:

  2. GSS-API Naming Extensions (Proposed Standard)
    draft-ietf-kitten-gssapi-naming-exts-14
    Token: Stephen Farrell
    Note: Shawn Emery (shawn.emery@oracle.com) is the document shepherd.
    Discusses/comments (from ballot draft-ietf-kitten-gssapi-naming-exts):
    1. Adrian Farrel: Comment [2012-04-25]:
      I have no objection to the publication of this document, and just three minor nits you may want to look at.
      (3 items)
    2. Russ Housley: Comment [2012-04-24]:
      Please consider the editorial comments from the Gen-ART Review by Pete McCann on 24-Apr-2012.
    3. Pete Resnick: Comment [2012-04-25]:
      In section 5:
      "Another aspect of context is encoding of the attribute information. An attribute containing an ASCII or UTF-8 version of an e-mail address could not be interpreted the same as a ASN.1 Distinguished Encoding Rules e-mail address in a certificate.
      "All of these contextual aspects of a name attribute affect whether two attributes can be treated the same by an application and thus whether they should be considered the same name attribute. In the GSS-API naming extensions, attributes that have different contexts MUST have different names so they can be distinguished by applications. As an unfortunate consequence of this requirement, multiple attribute names will exist for the same basic information. That is, there is no single attribute name for the e-mail address of an initiator."
      I don't have the expertise to evaluate this document thorougly, but something in the above seems weird, if not incorrect. It is certainly the case that an email address encoded in ASCII or UTF-8 cannot be byte-for-byte compared to the same email address encoded as an ASN.1 Distinguished Encoding Rules e-mail address. But the words "could not be interpreted the same as" strike me as incorrect. You *can* interpret the two e-mail address as the same if, after doing the decoding, you compare the addresses to each other. And it would, indeed, be very unfortunate for something that happens to use a different encoding to get a different name for each encoding and therefore have multiple non-comparable occurances of the item. It seems like you would want only one occurance of each item, marked with the encoding, and implementations would be responsible for the decoding.
      Maybe this is just a language issue. But something seems wrong about the above.
    4. Sean Turner: Comment [2012-04-23]:
      Only nits:

    Telechat:

  3. Raptor FEC Schemes for FECFRAME (Proposed Standard)
    draft-ietf-fecframe-raptor-10
    Token: Martin Stiemerling
    Note: Greg Shepherd (gjshep@gmail.com) is the document shepherd.
    IPR: QUALCOMM Incorporated's Statement about IPR related to draft-ietf-fecframe-raptor-01
    IPR: QUALCOMM Incorporated's Statement about IPR related to draft-ietf-fecframe-raptor-02
    IPR: QUALCOMM Incorporated's Statement about IPR related to draft-ietf-fecframe-raptor-04
    IPR: QUALCOMM Incorporated's Statement about IPR related to draft-ietf-fecframe-raptor-10
    Discusses/comments (from ballot draft-ietf-fecframe-raptor):
    1. Benoit Claise: Comment [2012-04-23]:
      4.1. Definitions: "This document uses definitions that apply to FEC Framework in general as defined in [RFC6363]. In addition, this document uses the following definitions:"
      Not sure what "that apply to FEC Framework in general" means. Don't you want to say something such as
      "The FEC-specific terminology used in this document is defined in [RFC6363]. In this document, as in [RFC6363], the first letter of each FEC-specific is capitalized along with the new terms defined here:"
    2. Stephen Farrell: Comment [2012-04-23]:
      - It's not clear to me whether the "device" mentioned in the IPR declaration's licensing section really only means h/w devices or not, or could badly impact e.g. an OSS implementation of this draft. I assume the WG have considered this and are happy with the idea of the license being specific to a "device" or at least don't seem to care (as implied by the write-up).
      - 6.2.1.2 - if the last octet is omitted then all the reserved bits aren't sent. Would it be worth noting that it'd not be safe to omit that octet if someone defines meanings for some of those reserved bits in future? Would "MAY be omitted" be better (i.e. use a 2119 keyword)? Finally, it'd have been nice if you had said that that octet SHOULD be sent or SHOULD be omitted - why not do that?
      - 7.1 - Would it be better to be explicit here about how the padding with zeros is done? I.e., rfc6330 says that symbols K through K'-1 are the padding symbols, the same is true here I think but good to say so, if so rather than forcing the reader to check in rfc6330.
      - 8.1.3 - Similar question about padding, though here the answer is obvious I guess, but still maybe no harm saying.
      - Section 9 defers to 6363 for security considerations, but 6330's and 5053's (identical?) security considerations seem more concrete, e.g. they RECOMMEND using something like TELSA, whereas 6363 eventually says "implement IPsec" but doesn't say much about what to use. It'd be good to be clearer about what, if anything, is mandatory-to-implement or SHOULD be used here. (This isn't a DISCUSS because all those RFCs are normative references so in theory implementing this means doing all of the above I guess.)
    3. Russ Housley: Comment [2012-04-24]:
      Please consider the editorial comments from the Gen-ART Review by Kathleen Moriarty on 18-Mar-2012.
    4. Robert Sparks: Comment [2012-04-24]:
      In section 7.2.1.2 did you mean to point to 6.2.1.2 instead of 6.2.2?
    5. Martin Stiemerling: Discuss [2012-04-20]:
      This document got a DISCUSS due to the transition of your responsible AD and the need to fix some parts of the documents before the DISCUSS is resolved into a YES.
      General:
      - There are a number of fields which do not say what type they are, e.g., integer or unsigned integer. On the other hand some fields are labelled as decimal number which is not applicable to the wire representation anyhow.
      - How are the bytes ordered on the wire. I guess in network byte order, but that should be noted somewhere.
      Here are those fields:
      - Section 6.2.1.2: "MSBL Value range: A decimal non-negative integer less than 8192 for FEC Scheme XXX1 and less than 56403 for FEC Scheme XXX2, in units of symbols"
      Remove decimal, as this is not applicable on the wire.
      "Encoding Symbol Size Name: "T", Value range: A decimal non-negative integer less than 65536, in units of octets"
      Remove decimal, as this is not applicable on the wire.
      Payload ID Format Name: "P", Value range: "A" or "B"
      The flag P can only take the binary values '0' or '1', but never "A" or "B". How is the symbolic value of 'A' reprented in P and how is the symbolic value of 'B' reprented in P?
      - Section 6.2.2., below "Figure 2: Source FEC Payload ID - Format A"
      "Source Block Number (SBN), (16 bits): An integer identifier for the source block that the source data within the packet relates to."
      "Encoding Symbol ID (ESI), (16 bits): The starting symbol index of the source packet in the source block."
      How is the index to be interpreted, e.g., as unsigned integer? Please specify this here!
      - Section 6.2.2., below "Figure 3: Source FEC Payload ID - Format B"
      "Source Block Number (SBN), (8 bits): An integer identifier for the source block that the source data within the packet relates to."
      "Encoding Symbol ID (ESI), (24 bits): The starting symbol index of the source packet in the source block."
      How is the index to be interpreted, e.g., as unsigned integer? Please specify this here!
      - Section 6.2.3., below " Figure 4: Repair FEC Payload ID - Format A"
      "Source Block Number (SBN), (16 bits) An integer identifier for the source block that the repair symbols within the packet relate to. For format A, it is of size 16 bits."
      "Encoding Symbol ID (ESI), (16 bits) Integer identifier for the encoding symbols within the packet."
      "Source Block Length (SBL), (16 bits) The number of source symbols in the source block."
      How is the number of source symbols to be interpreted, e.g., as unsigned integer? Please specify this here! The same for " Source Block Length (SBL)" for Format B.
      Section 8.1.3., below "Figure 6: Repair FEC Payload ID - Format A"
      "Initial Sequence Number (Flow i ISN) - 16 bits This field specifies the lowest 16 bits of the sequence number of the first packet to be included in this sub-block. If the sequence numbers are shorter than 16 bits then the received Sequence Number SHALL be logically padded with zero bits to become 16 bits in length respectively."
      How is the Flow i ISN to be interpreted, e.g., as unsigned integer?
      "Source Block Length (SBL) - 16 bits This field specifies the length of the source block in symbols."
      How is this to be interpreted, e.g., as unsigned integer?
      [con't from page 17]
      "Encoding Symbol ID (ESI) - 16 bits This field indicates which repair symbols are contained within this repair packet. The ESI provided is the ESI of the first repair symbol in the packet."
      How is this to be interpreted, e.g., as unsigned integer?
      Section 8.1.3., below "Figure 7: Repair FEC Payload ID - Format B"
      "Initial Sequence Number (Flow i ISN) - 16 bits This field specifies the lowest 16 bits of the sequence number of the first packet to be included in this sub-block. If the sequence numbers are shorter than 16 bits then the received Sequence Number SHALL be logically padded with zero bits to become 16 bits in length respectively."
      How is this to be interpreted, e.g., as unsigned integer?
      "Source Block Length (SBL) - 16 bits This field specifies the length of the source block in symbols."
      How is this to be interpreted, e.g., as unsigned integer?
      "Encoding Symbol ID (ESI) - 24 bits This field indicates which repair symbols are contained within this repair packet. The ESI provided is the ESI of the first repair symbol in the packet."
      How is this to be interpreted, e.g., as unsigned integer?
    6. Martin Stiemerling: Comment [2012-04-20]:
      Section 2:
      - replace "Section 6defines an FEC Scheme" with "Section 6 defines an FEC Scheme2
      - replace "Section 6but with optimisations for with "Section 6 but with optimisations for"
      - replace "over IP Based" Networks " with "over IP Based Networks" " (move ' " ')
      - Section 4.2: Add ADU to the list of abbreviations
      - Section 6.2.1.2, at the bottom of the page: replace "An encoding format for The MSBL and Encoding" with "An encoding format for the MSBL and Encoding S"
    7. Sean Turner: Comment [2012-04-25]:
      I guess I'm with Stephen on the security considerations it should really also point to RFCs 5053 or 6330.

    Telechat:

  4. Definitions of Managed Objects for Packet Sampling (Proposed Standard)
    draft-ietf-ipfix-psamp-mib-04
    Token: Ronald Bonica
    Note: Nevil Brownlee is the document shepherd
    Discusses/comments (from ballot draft-ietf-ipfix-psamp-mib):
    1. Adrian Farrel: Discuss [2012-04-25]:
      I don't think it makes sense to have DEFVAL clauses for read-only objects. They are really used for object creation and are not appropriate for describing the default beavior of protocol implementations.
      For example...
      psampSampCountBasedAvail
      psampSampTimeBasedAvail
      psampSampRandOutOfNAvail
      psampSampUniProbAvail
      psampFiltPropMatchAvail
      psampFiltHashAvail
    2. Adrian Farrel: Comment [2012-04-25]:
      Please remove the citations from the Abstract
      There are a couple of places where you should s/MIB/MIB module/ E.g. Section 5.1
      I would have expected to see some discussion of psampSampUniProbProbability and the non-support of NaN and Infinity in the compliance clauses.
      Should psampFiltHashFunction also include a reference to RFC 1141?

    Telechat:

  5. Creation and Use of Email Feedback Reports: An Applicability Statement for the Abuse Reporting Format (ARF) (Proposed Standard)
    draft-ietf-marf-as-16
    Token: Pete Resnick
    Note: Barry Leiba (barryleiba@computer.org) is the document shepherd.
    Discusses/comments (from ballot draft-ietf-marf-as):
    1. Benoit Claise: Comment [2012-04-25]:
      Thanks for addressing my points
    2. Adrian Farrel: Comment [2012-04-25]:
      Forgive me, but doesn't section 8.2 say that forged abuse reports constitute a real problem and the two mechanisms available to protect against them may result in genuine abuse reports being discarded?
      Is the message here "chosse which you think might be the least worse problem" or is it "you should use DKIM and SPF, but be aware that you may lose some genuine reports"?
      I would have liked some clarification as to which message is being sent.
    3. Stephen Farrell: Comment [2012-04-23]:
      Just a bunch of nitty comments. Feel free to take 'em or leave 'em.
      (10 items)
    4. Brian Haberman: Comment [2012-04-25]:
      Thanks for addressing my comments.
    5. Robert Sparks: Discuss [2012-04-24]:
      The MUST in section 4.5 item 1 may need clarification. Do you mean to say that the system MUST accept a report with a feedback type with any value that makes it into the (specification-required) registry? Or are you wanting to scope that to values that were registered with an RFC that Updates/Obsoletes 5965? Or something else? Is this effectively requiring implementations of automated report processing systems to be configurable with what feedback types it will accept? If so, would it make sense to say that explicitly? Also, consider more detail on what accept means here. Does it mean the system can't return a rejection response (what bad happens if it does?) or is the intent that it must _process_ the report.
    6. Robert Sparks: Comment [2012-04-24]:
      In section 5.1 item 1, is there a typical unstandardized out-of-band mechanism for telling unsolicited reporters to please stop that you can call out as an example (an existence proof)?
      In Section 6, item 1, the sentence "Automatic feedback generators MUST select recipients based on data provided by the report recipient." is really hard to understand (it's almost circular). Is it trying to say something like "Automatic feedback generators MUST only send to addresses explicitly provided by willing recipients."?

    Telechat:

  6. Channel Binding Support for EAP Methods (Proposed Standard)
    draft-ietf-emu-chbind-14
    Token: Sean Turner
    Note: Joe Salowey (jsalowey@cisco.com), EMU working group co-chair, is the Working Group Shepherd for this document.
    Discusses/comments (from ballot draft-ietf-emu-chbind):
    1. Benoit Claise: Comment [2012-04-26]:
      Just happy that there is an "Operations and Management Considerations" section. It makes sense in many documents, IMHO. Thanks for that.
      Regards, Benoit.
    2. Ralph Droms: Comment [2012-04-25]:
      Minor editroial nit: the affiliation for T. Clancy in the header should be fixed.
    3. Adrian Farrel: Discuss [2012-04-25]:
      I am escalating part of Barry's Comment to a Discuss
      Please give the valid ranges for new code point registries. Is the value zero reserved, out of scope, or unassigned?
    4. Adrian Farrel: Comment [2012-04-25]:
      idnits reveals...
      (3 items)
    5. Stephen Farrell: Discuss [2012-04-26]:
      (Sorry, I ran out of time to properly consider the secdir review so I'll just trust that that's being handled correctly.)
      1) cleared
      2) p22, 9.1 says "derivation of keying material including a key for integrity protection of channel binding messages" but that doesn't say that it must be that the authenticator can't know the relevant key. There also seems to be a missing MUST in the lead in to that list.
      3) cleared
    6. Stephen Farrell: Comment [2012-04-26]:
      (8 items plus nits)
    7. Russ Housley: Comment [2012-04-22]:
      The Gen-ART Review by Francis Dupont on 7-Apr-2012 raised quite a few editorial comments. The authors have indicated that many of them are very useful, and they want to update the document to address them, but this has not happened as yet.
    8. Barry Leiba: Comment [2012-04-24]:
      -- IANA Considerations --
      The definitions for the two new EAP Channel Binding Parameters sub-registries specify numbers in column one of the tables, but do not specify a range for those numbers. Is it 0-255 (one byte)? Something else? Please specify, so IANA (and the rest of us) knows. Similarly for the new sub-registry in 11.1.
      I would like to see a brief rationale for the choices of Standards Action and IETF Review for the registration policies for the two new parameters sub-registries. See draft-leiba-iana-policy-update if you want to see where I'm coming from on this. Just something brief that shows that it was considered and discussed, and that explains why these were chosen. Note: the definition for the new registry in 11.1 does give a rationale; thanks.

    Telechat:

  7. Email Greylisting: An Applicability Statement for SMTP (Proposed Standard)
    draft-ietf-appsawg-greylisting-08
    Token: Barry Leiba
    Discusses/comments (from ballot draft-ietf-appsawg-greylisting):
    1. Stewart Bryant: Comment [2012-04-24]:
      Thank you for the explanation.
    2. Benoit Claise: Comment [2012-04-25]:
      Please expand MTA. I know that you wrote: "Readers need to be familiar with the material and terminology discussed in [MAIL] and [EMAIL-ARCH]." We could help the reader a little bit, instead of searching into http://tools.ietf.org/html/rfc5598 to know what the acronym means
      Similarly, maybe it's obvious for people dealing with Email, but I had to lookup "MX record" ...
      OLD: Experience suggests that the, the vast majority of mail comes from
      NEW: Experience suggests that the vast majority of mail comes from
      Regards, Benoit.
    3. Ralph Droms: Comment [2012-04-26]:
      Thanks for addressing my comment.
    4. Adrian Farrel: Comment [2012-04-25]:
      I strongly support this effort which draws a line between blacklisting and more acceptable techniques. I hope this will serve as encouragement to service providers to move away from descriminatory and service-impacting blacklists.
      Section 1: s/for provider better service./for providing better service./
    5. Stephen Farrell: Comment [2012-04-24]:
      - intro: "a period of time" is usually measured in minutes here, might be worth saying that just in case
      - 2.3: Odd reference text: "refers to the [SMTP] command verb" I think it'd be better if the reference was handled differently and e.g. it said "refers to the 'SMTP' command verb in an SMTP [SMTP] session" (I prefer if the references are not part of the text but that's a different style issue). The "RFC5321.MailFrom" notation also shows as a reference on the tools page, not sure if that's desirable or not or if it can be avoided or not.
      - typo, section 3, s/the, the/the/
      - section 5: Are there any 4yz errors that SHOULD NOT or MUST NOT be used here? I've no idea and suspect not based on this text, but if there were then that'd be worth saying.
    6. Brian Haberman: Comment [2012-04-23]:
      This is a well-written document and describes a useful function. I do support Martin's DISCUSS about the status. It definitely reads like a BCP.
    7. Russ Housley: Comment [2012-04-24]:
      Please consider the editorial comments from the Gen-ART Review by Kathleen Moriarty on 23-Apr-2012.
    8. Pete Resnick: Comment [2012-04-22]:
      2.5: "Some implementations do filtering here"
      I think you meant, "Some implementations do greylisting here". There's no filtering described in this section.
      "o identifiers in the message, such as the contents of the RFC5322.From or RFC5322.To fields;"
      Change "message" to "message header" or "message content" or equivalent. I think there is the potential to confuse envelope here.
      2.6:
      I think you mean "spam", or maybe "spam senders", but not "spamware" in this paragraph. There is nothing about an IP address that identifies spamware, but it certainly might identify a sender of spam.
      4.2: "Some clients do not retry messages at all."
      and: "Some SMTP implementations make the error of treating all error codes as fatal;"
      I think it's worth adding "in violation of [SMTP]". It should be clear that you are only losing email from clients that are already not playing by the rules.
    9. Robert Sparks: Comment [2012-04-23]:
      This is a very clear and helpful document. Thank you for making the effort to assemble it.
      Greylisting has been widely deployed for several years, but a concise explanation of the concept and its consequences has been lacking - this will be a very good tool for administrators interacting with systems that are already greylisting as well as those that are just adopting the practice.
      I don't agree that this should be BCP - it seems a good candidate for re-review and progression on the standards ladder.
      (Updating the comment with this question/suggestion:)
      In the second paragraph of section 3, consider pointing to the sentence in section 2.1 of RFC5321 that says "SMTP clients that transfer all traffic regardless of the target domains associated with the individual messages, or that do not maintain queues for retrying message transmissions that initially cannot be completed, may otherwise conform to this specification but are not considered fully-capable."
      and say more strongly here that the agent receiving this retry response can't distinguish this condition from a disk full or other temporary condition making the receiver unable to accept where the sender really has no business knowing the reason why it's being told to re-try with a 400-level response
    10. Martin Stiemerling: Discuss [2012-04-24]:
      Section 5. point 2: The minimum default window is one minute. This seems to be rather short in respect of clock skew between different hosts and when messages are re-scheduled for delivery on hosts. Has this been tested/checked in real deployments.
      One example: This can be troublesome if the SMTP server which does the greylisting is +30 seconds off and the other end is off by -30 seconds. The other end will re-send the message just too late.
    11. Martin Stiemerling: Comment [2012-04-23]:
      - Section 1: "this can justify providing degraded service, until there is a basis for provider better service."
      I cannot parse the 'provider better service'.
      - Section 5: The text before the list of practices says those items are RECOMMENDED, but a number of items is about SHOULD and SHOULD NOT. Not a big issues, but logically not clean, i.e., are they RECOMMENDED or does SHOULD apply. Probably, it might be good to have two lists, one for RECOMMENDED and the other for the SHOULDs.

    Telechat:

  8. SIP-Specific Event Notification (Proposed Standard)
    draft-ietf-sipcore-rfc3265bis-08
    Token: Robert Sparks
    Note: Paul Kyzivat (pkyzivat@alum.mit.edu) is the document shepherd.
    Discusses/comments (from ballot draft-ietf-sipcore-rfc3265bis):
    1. Ralph Droms: Discuss [2012-04-26]:
      This DISCUSS position does not require any immediate action on the part of the authors.
      I have an issue with the state diagram in section 4.1.2 that I would like to discuss. In general, I've found it important to take care with state diagrams in protocol specifications to ensure that the state diagram is correct and, unless otherwise indicated, complete. I apologize for not having the time to work through the entire state diagram for correctness; I did notice that section 4.1.2.2 includes a message exchange - which, admittedly, does not result in a state change - that is not reflected in the state diagram.
      My suggestion would be to add a disclaimer to the effect that the state diagram is not normative and that there may be aspects of the protocol behavior that are not reflected in the statae diagram. I'm open to discussion of this suggestion.
    2. Adrian Farrel: Comment [2012-04-26]:
      Thanks for the detailed list of changes from 3265.
      Does this also update 3261?
    3. Stephen Farrell: Comment [2012-04-25]:
      Clarified my questions in a call with Robert. Be nice if we can document the reality sometime soon but this isn't the place to do it.
    4. Russ Housley: Discuss [2012-04-25]:
      The Gen-ART Review by Alexey Melnikov on 10-Apr-2012 started a discussion that has not yet reached closure. At least 3 issues need to be resolved:
      (1) Section 7.2 defines "reason" codes for use in the "Subscription-State" header field, and new reason codes require a Standards Action. This prevents registration of new Reason Codes in Experimental RFC. Please double check that that is intentional.
      (2) IANA reason code registrations require a reference to a published document which describes the event package. Insertion of such values takes place as part of the RFC publication process or as the result of "inter-SDO liaison activity." However, Standards Action is not appropriate since other SDOs do not publish Standard Track RFCs.
      (3) Ordering of template packages needs to be explained.
    5. Barry Leiba: Comment [2012-04-25]:
      Many thanks to Paul for an excellent and thorough PROTO writeup. A note here: the IPR and copyright stuff you note from the nits checklist is just the boilerplate that's automatically put in by xml2rfc (or manually put in otherwise; it's correct in this document). We should update the checklist to have current references, and to reflect the current position of that boilerplate in the documents.
      I also really like the "SHOULD" note in Section 1.2.
      On the IANA Considerations, thanks for retaining the context here, so the original document can be properly obsoleted. One suggestion:
      In the base section 7:
      OLD: (This section is not applicable until this document is published as an RFC.)
      NEW: The subsections here are for current reference, carried over from the original specification. The only IANA action requested here is to change all registry references that point to RFC 3265, and have them point to this RFC.
      ...or some such text, so that the registries now cite the new document.
    6. Pete Resnick: Comment [2012-04-25]:
      This is an incredibly well-written protocol document, and so clear that I'm fine with a Yes ballot.
      I can't convince myself any of these comments are DISCUSSion worthy, but I do think they all need addressing one way or the other.
      1.2: "It is inappropriate to fail to comply with "SHOULD"-strength requirements whimsically or for ease of implementation."
      I think that can be strengthened: "It is violation of a requirement of the specification to fail to comply with 'SHOULD' requirements whimsically or for ease of implementation."
      3.1.1
      Here and elsewhere, you say that something "MUST be defined by the event package". That's an odd use of MUST, since it's clearly not a protocol requirement for the implementer of the protocol, but rather a requirement for the protocol extension writer. I can see saying that "event packages will make such-and-so REQUIRED" to put implementers on notice that they will find the requirement in the event package, but I do wish you had a non-2119 way of expressing requirements for event package writers.
      "A natural consequence of this scheme is that a SUBSCRIBE request with an "Expires" of 0 constitutes a request to unsubscribe from an event."
      Maybe this is obvious and implicit for someone familiar with SIP, but you do mean "a SUBSCRIBE request *on the same dialog* with an 'Expires' of 0", right? You don't actually get to the fact that a SUBSCRIBE is dialog-creating until 4.1.2.1, but I think you can still make it clear here. Or you can just skip it, since it's covered in 4.1.2.3.
      4.1.2.1: "The "Expires" header field in a 200-class response to SUBSCRIBE request indicates the actual duration for which the subscription will remain active (unless refreshed)."
      This implies to me (though it's not stated explicitly here) that the response MAY have a different Expires value than provided in the request. Is that true? You say something about this in 4.2.14, but not here.
      4.1.3 For 'probation', you say "the client SHOULD retry at a later time". Is that really what you mean? What harm comes to me if I decide not to retry? Couldn't I decide to not retry? Do you mean "MAY retry at a later time", or perhaps "SHOULD NOT retry immediately". Some piece of information is missing here. I suspect this has some parallel to 'deactivitated' and migration, but I don't get it.
      4.2.1 Why the out clause for 3515? If it's causing problems, why not just say MUST NOT and update 3515 to deprecate the use?
      4.2.2 Seems to me that if a NOTIFY receives a failure response and the subscription is therefore removed, the notifier should *not* send an additional 'terminated' NOTIFY. But the state machine seems to indicate that it should. Was that the intention?
      4.5.2 Dialog sharing seems like a mess. Why is this not a SHOULD NOT?
      5 Generally: It seems like this entire section might work better as an appendix. It's not part of the protocol per se; it's extension documentation instructions. Also, the 2119 language in this section seems weird, especially in 5.4.1 and 5.4.12. Those seem like inappropriate uses of 2119. The only one I can make a case for is the one in 5.3.2, and even there I'm not convinced. (I notice that for some reason you *didn't* use 2119 language in 5.4.6 and 5.4.7, and *never* used MAY in this section.) Again, it would be nice if you could find a better way to express this. I'm not convinced 2119 is useful or appropriate here.
      7.1 2119 language in IANA Considerations sections always worry me. When you say, "Registrations with the IANA MUST include...", are you putting a requirement on IANA? On the Expert Reviewer? I would rather see these removed and instead indicate that it is "required information in the template" or something like that.
      7.1.1 s/initial IANA registration for event types will be empty/initial IANA registry for event types will be empty
      7.2 Why is "Standards Action" required for this?
      8.4: "token-nodot = 1*( alphanum / "-" / "!" / "%" / "*" / "_" / "+" / "`" / "'" / "~" )"
      Do you really want to allow "...---..."? Are you sure you don't want:
      "token-nodot = alphanum *( ( "-" / "!" / "%" / "*" / "_" / "+" / "`" / "'" / "~" ) alphanum )" instead?
    7. Martin Stiemerling: Comment [2012-04-23]:
      Section 4.1.2.4., paragraph 4: "Due to the potential for both out-of-order messages and forking, the subscriber MUST be prepared to receive NOTIFY requests before the SUBSCRIBE transaction has completed."
      + packet loss which can also lead to NOTIFY requests arriving before the SUBSCRIBE transaction to be completed.

    Telechat:

  9. Translation of SMIv2 MIB Modules to YANG Modules (Proposed Standard)
    draft-ietf-netmod-smi-yang-05
    Token: Benoit Claise
    Note: David Kessens is the Document Shepherd
    Discusses/comments (from ballot draft-ietf-netmod-smi-yang):
    1. Adrian Farrel: Comment [2012-04-25]:
      I found the text "config false" a bit out of context. Can you provide some explanation?
    2. Stephen Farrell: Comment [2012-04-24]:
      Just wanna check two things, they're probably ok already though...
      1. An ASN.1 INTEGER can be multi-precision (e.g. 2048 bits). Not sure if that's allowed in SMIv2 but if so, worth a mention? Section 2 implies 32 bits is enough.
      2. OID arcs can similarly be >32 bits long so if those were just mapped to 32 bit values that'd be bad.
    3. Sean Turner: Comment [2012-04-25]:
      s4.2: Is it worth having a default yang statement added to all converted MIBs that says this module was converted from SMIv2 to YANG using RFC X? Maybe it's called conversion?

    Telechat:

  10. Deprecate DES, RC4-HMAC-EXP, and other weak cryptographic algorithms in Kerberos (Best Current Practice)
    draft-ietf-krb-wg-des-die-die-die-04
    Token: Stephen Farrell
    Note: Sam Hartman (hartmans-ietf@mit.edu) is the document shepherd.
    Discusses/comments (from ballot draft-ietf-krb-wg-des-die-die-die):
    1. Adrian Farrel: Comment [2012-04-26]:
      I cleared my Discuss after a conversation with the AD and WG chair on the understanding that they will close the loop with the WG on whether the code points in any IANA registries should be deprecated.
    2. Brian Haberman: Comment [2012-04-17]:
      I am glad to see this draft and it is well-written.
      I am curious as to why the recommendation is limited to SHOULD NOTs and not MUSTs. Are there reasons to allow this wiggle room? If so, it would be good to give an example in the draft.
    3. Pete Resnick: Discuss [2012-04-25]:
      [Thanks for addressing my other DISCUSS comments]
      - I do want to make sure that we send the right announcement for both this document *and* the moving of 1510 to Historic. I'm just leaving this DISCUSS point as a placeholder until we figure out how to do that.
      - I am not entirely clear why this is a BCP and not part of the standards track specification of Kerberos. This is a change to a protocol and therefore part of a technical specification, not a policy or operational guideline.
    4. Pete Resnick: Comment [2012-04-25]:
      I am not entirely clear why this is a BCP and not part of the standards track specification of Kerberos. This is a change to a protocol and therefore part of a technical specification, not a policy or operational guideline.
    5. Robert Sparks: Comment [2012-04-24]:
      Like Pete, I don't understand why this should be published as a BCP (I support that portion of his DISCUSS).
    6. Martin Stiemerling: Comment [2012-04-22]:
      This draft does not update RFC 1510 but aims to obsolete it , i.e. the header of the draft is not correct: "Updates: 1510, 1964, 4120, 4121, 4757"
      However, Pete's discuss covers this already.
    7. Sean Turner: Comment [2012-04-17]:
      Finally!

    Telechat:

2.1.2 Returning Items

  1. Deprecating the X- Prefix and Similar Constructs in Application Protocols (Best Current Practice)
    draft-ietf-appsawg-xdash-05
    Token: Pete Resnick
    Discusses/comments (from ballot draft-ietf-appsawg-xdash):
    1. Ralph Droms: Comment [2012-03-12]:
      This text:
      2. Recommendations for Implementers of Application Protocols
      "Implementers of application protocols MUST NOT treat the general categories of "standard" and "non-standard" parameters in programatically different ways within their applications."
      while probably not harmful, is sufficiently vague and refers to undefined terms in a way as to contribute, perhaps, more confusion than value.

    Telechat:

2.2 Individual Submissions

2.2.1 New Items

  1. SHA-2 Data Integrity Verification for the Secure Shell (SSH) Transport Layer Protocol (Proposed Standard)
    draft-dbider-sha2-mac-for-ssh-05
    Token: Sean Turner
    Note: Jeffrey Hutzelman (jhutz@cmu.edu) is the document shepherd.
    Discusses/comments (from ballot draft-dbider-sha2-mac-for-ssh):
    1. Adrian Farrel: Comment [2012-04-25]:
      Congratulations! Shortest I-D on the telechat.
      I have no objection to the publiscation of this document and just two small nits.
      It doesn't really work to use RFC 2119 language in the Abstract.
      Section 2: "This memo adopts the style and conventions of [RFC4253] in defining new data integrity algorithms. The following new data integrity algorithms are defined:"
      I dare say I am overly pedantic, but I don't think the algorithms are actually defined here, just the identifiers for the algorithms.
    2. Stephen Farrell: Discuss [2012-04-23]:
      - I'd like to see the -96 bit truncated variants disappear as per previous comments. I believe the authors are ok with that so this is just so's we all remember to do that.

    Telechat:

2.2.2 Returning Items

  1. (none)

3. Document Actions

3.1 WG Submissions

3.1.1 New Items

  1. Synchronizing Location-to-Service Translation (LoST) Protocol based Service Boundaries and Mapping Elements (Experimental)
    draft-ietf-ecrit-lost-sync-17
    Token: Robert Sparks
    Note: Marc Linsner (mlinsner@cisco.com) is the document shepherd.
    IPR: Cisco's Statement of IPR relating to draft-ietf-ecrit-lost-sync-08
    Discusses/comments (from ballot draft-ietf-ecrit-lost-sync):
    1. Adrian Farrel: Comment [2012-04-25]:
      I see from the charter that this I-D was planned as Experimental. Although it is in no way a requirement for publication, I would really like this document to provide some explanation as to why it is targeted as Experimental. I would also like to see some parameters of the "experiment" - what is the scope? how does the experiment need to be contained? what feedback are the authors/WG looking for from experimenters? how will the experiment be judged a success?
    2. Stephen Farrell: Comment [2012-04-25]:
      - typo: singed mappings
      - what TLS authentication is required if any? Are anon ciphersuites ok or not? Is TLS mutual auth required or not? Be good to say either way.
      - Is there any requirement that the TLS server/client certs map to anything associated with the service (e.g. its DNS name) or with anything in the payload? Again be good to say either way.
      - Maybe this is my ignorance of LoST and Relax NG, but where do the <Signature> elements go in this protocol and what elements are required to be signed?
    3. Brian Haberman: Comment [2012-04-24]:
      I agree with Pete's feedback that there is a significant amount of fluff in this document that is not needed.
      Other comments:
      1. The second paragraph of section 4.2 states: "A newly received mapping MUST update an existing one having the same 'source' and 'sourceID' and a more recent time in 'lastUpdated'. That seems rather confusing sentence structure, so I would recommend something like: "If a newly received mapping has a more recent time in its 'lastUpdated' attribute, it MUST update an existing mapping that has matching 'source' and 'sourceID' attributes.".
      2. In section 4.1 (2nd paragraph) : s/SHOULD keep track to/SHOULD keep track of/.
      3. Second sentence of section 4.3 should start with "Imagine" rather than "Image".
    4. Russ Housley: Comment [2012-04-25]:
      Please consider the editorial comments from the Gen-ART Review by Wassim Haddad on 24-Apr-2012:
      - Perhaps I missed it somewhere in the document, but I could not find the meaning of "ESRPs" (page 5)
      - Suggest re-writing the last paragraph on page 8
      - Suggest re-writing the 3-line paragraph on page 9
    5. Barry Leiba: Comment [2012-04-25]:
      Some minor, non-blocking comments:
      -- Section 7 --
      Are there any ways to encounter or avoid synchronization loops other than what you say in the first two paragraphs here? What happens if a buggy node always modifies "last updated" to the current time before relaying a mapping? Would there be any way to stop a loop?
      It's more than a typo that singes things; this sentence is hard to read:
      OLD: With digitially singed mappings mappings cannot be modified by intermediate LoST servers.
      NEW: When mappings are digitially signed, they cannot be modified by intermediate LoST servers.
      -- Section 8 --
      Just noting that the second paragraph seems oddly familiar...... :-)
      -- Section 9.1 --
      The title and the first sentence each use different terms for what we now prefer to call "Media Type". It's not a big deal, but you might please switch to that term.
      -- Sections 9.2 and 9.3 --
      IANA probably knows where you're registering these, but I don't, and I'm always worried about registration errors. I suppose as long as it's clear to IANA, it's OK... but can you specify exactly what registries (using the exact names and perhaps URLs, from https://www.iana.org/protocols/ ) you mean?
    6. Pete Resnick: Discuss [2012-04-23]:
      Section 9.1:
      The ietf-types review pointed out specific language from RFC 3023 section 7.1 that should be used in the registration of application/lostsync+xml. Please fix:
      Optional parameters: charset: Indicates the character encoding of enclosed XML.
      Replace with "Same as charset parameter of application/xml as specified in RFC 3023."
    7. Pete Resnick: Comment [2012-04-23]:
      [Just a reminder: None of the following cause me as an AD to hold up publication of the document. They are just the (sometimes strongly held and expressed) beliefs of yet another bozo in the IETF community. Take them as such.]
      (many items)
    8. Sean Turner: Comment [2012-04-25]:
      I echo Stephen's comments.
      s5: Not sure if it's worth it but maybe mentioning that only offering HTTPS is different than RFC 5222 because it offers HTTP as well. Maybe saying because this is exchanging authoritative data it's inappropriate to use HTTP? Maybe you could do this in the 1st paragraph of the security considerations:
      "Hence, the protocol operations described in this document require authentication of neighboring nodes, which is why HTTPS is required."

    Telechat:

  2. S/MIME Capabilities for Public Key Definitions (Informational)
    draft-ietf-pkix-pubkey-caps-05
    Token: Sean Turner
    Note: Document Shepherd: Stephen Kent (kent@bbn.com)
    Discusses/comments (from ballot draft-ietf-pkix-pubkey-caps):
    1. Adrian Farrel: Comment [2012-04-25]:
      I am balloting No Objection on the assumption that the Security ADs are on top of this work.
      I do have a few nits I noticed along the way.
      Abstract: s/define/defined/
      Please expand acronyms not marked with an asterisk in http://www.rfc-editor.org/rfc-style-guide/abbrev.expansion.txt
      Section 1
      OLD: but we did not currently have any way of doing so at the current time.
      NEW: but we did not have any way of doing so.
      END
      Section 1: s/structure need/structure needs/
    2. Stephen Farrell: Comment [2012-04-24]:
      - I thought S/MIME capabilities were to allow a sender to know what a receiver wanted/could handle, this says it the other way around.
      - 1 s/need to be/needs to be/ in last para before 1.1
    3. Russ Housley: Discuss [2012-04-24]:
      The appendix includes TBD values that need to be assigned.
    4. Russ Housley: Comment [2012-04-24]:
      Please reword the last sentence of the Abstract. It says: "An example of where this is used is with the OCSP Agility draft."
      Can this be worded in a way that points to an RFC? If not, can it be worded in a way that does not use "draft"?
      Section 2.1 says: "RSAKeySize ::= INTEGER (1024 | 2048 | 3072 | 7680 | 15360 | 4096 | 8192, ...)"
      The integer values appear in a surprising order. While this will not impact code or interoperability, why not put them in ascending order?
      Should the capabilities in section 3.1 provide an optional way to specify sizes of P, Q, and G that are supported?
      Similarly, should the capabilities in section 3.2 provide an optional way to specify sizes of P and G that are supported?
      In Section 4.1 and 4.2 and 4.3, I suggest a list of named curves instead of the very rich structure that is currently specified. Several other documents have taken this approach. Any popular curve can be assigned an object identifier to name it.
      In addition to my comments above, please consider the comments from the Gen-ART Review by Mary Barnes on 23-Apr-2012.
    5. Barry Leiba: Comment [2012-04-24]:
      [Update: the -05 version addresses all my substantive comments.]

    Telechat:

3.1.2 Returning Items

  1. (none)

3.2 Individual Submissions Via AD

3.2.1 New Items

  1. Asymmetric Extended Route Optimization (AERO) (Experimental)
    draft-templin-aero-10
    Token: Stewart Bryant
    Discusses/comments (from ballot draft-templin-aero):
    1. Ronald Bonica: Discuss [2012-04-25]:
      - It is impossible to evaluate this draft without more detail regarding the operational scenario in which it is to be deployed. If the reference scenario described in Section 4.3 were deployed by devices and links contained within a single campus, one might ask why the problem could not be solved by running an IGP on Routers A, B and D and by putting Host F behind a router.
      - This draft appears to use ICMP as a routing protocol. However, ICMP does not have all of the capabilities required by a routing protocol. You might want to explore the this issue in the next version of this draft.
      - The approach used in this draft seems to contradict the following statement from RFC 1812:
      "A router using a routing protocol (other than static routes) MUST NOT consider paths learned from ICMP Redirects when forwarding a packet. If a router is not using a routing protocol, a router MAY have a configuration that, if set, allows the router to consider routes learned through ICMP Redirects when forwarding packets."
      - Beyond these, there are many other comments. For example, Stephen's question regarding authentication is telling. However, it may not be worth discussing these until we understand the problem that you are really trying to solve.
    2. Benoit Claise: Comment [2012-04-26]:
      Looking at the number of DISCUSS already, I would prefer to wait for the next version of the draft before reviewing the document in details. By spending 15 minutes on the draft, I have some questions already. Therefore, I reserve the option to come back and potential add a DISCUSS on the next document version.
    3. Ralph Droms: Discuss [2012-04-24]:
      1. In this text from the Introduction: "For example, when an ingress link neighbor accepts an ordinary redirect message, it has no way of knowing whether the egress link neighbor is ready and willing to accept packets directly without involving an intermediate router."
      I don't think I see any description of a way for the egress node to explicitly notify the ingress node, either directly or through the intermediate node, that the egress node is unwilling "to accept packets directly", nor do I see how the intermediate node reacts to a NAK from the egress node.
      2. Also in the text cited in point 1, I don't see any support for the assertion that an intermediate router is required. Isn't that what routing protocols do?
      On re-reading that text, I realize I may be confused: does "without involving an intermediate router" mean:
      a) the ingress node needs an intermediate router to learn whether the egress nodes will accept traffic from the ingress node or
      b) the egress node will not accept traffic directly from the ingress node but it will accept traffic forwarded from the ingress node forwarded through the intermediate node?
      3. Do I have it right in section 4.4.7 that the Redirect response from D is sent to L3(B) (i.e., unicast to the ingress node), but the intermediate node A snoops that Redirect message and verifies the contents in various ways before forwarding it to B? And then it doesn't decrement the hopcount? Why are these exceptional forwarding rules necessary? Can't D send the Redirect to A, and then A send a corresponding Redirect to B?
      4. Section 4.4.5 specifies that the AERO Predirect/Redirect message will use type 100, while Figure 4 shows the use of type 137. I include this as a DISCUSS point because Figure 4 needs to be fixed to show type 100 before the document is published to avoid problems with the existing ICMP Redirect message.
    4. Ralph Droms: Comment [2012-04-24]:
      1. The document has many details about the operations of the various AERO nodes that are not germane to the specification of AERO. I would suggest editing out all of the provisioning and initialization details in, e.g., section 4.3, and simply describe the state of the various AERO nodes at the time of AERO operation.
      2. In section 4.4.11, what prevents A from invoking the Predirect/Redirect mechanism for each datagram received from B destined for D, even if B has determined that B cannot send directly to D?
      3. In the Security Considerations section, how does an Aero edge node know to trust an AERO intermediate router that advertises itself? I think the digital signature mechanism needs to be explored in more detail or data authentication more generally needs to be left for future work.
    5. Adrian Farrel: Discuss [2012-04-25]:
      It is entirely unclear to me what real problem this work is designed to solve.
      It is clear that it is possible to construct a network where "triangular paths" could exist and where redirection can help resolve the issues.
      Only one brief paragraph is given to explain why "ordinary redirection may lead to operational issues on certain link types and/or in certain deployment scenarios" and it is unclear to me whether this represents a real problem. It would appear that the issue can arrise when the multi-access link has very large numbers of hosts and very large numbers of routers on the same link. Is this realistic? Do we not find this type of deployment in the wild because of these problems or because that is simply not how networks are usually built?
      So I would like to see several things called out more explicitly:
      - What are the deployments that motivate this work?
      - Is the model here that the Aero Edge Routers are acting as "PEs" in a sort of VPN like model?
      - What sort of scaling numbers are to be considered?
      - What are the operational problems with existing solutions and why can they not be solved using pre-existing protocol solutions?
      - Would the problem not exist if all nodes on the link were routers or if nearly all (i.e. except for a default and alternate router) were hosts?
      - How come spoofing of redirects is given as a motivation for this work yet called out as a security issue for Aero with a remediation offered that could be applied today?
      Other than that, I feel that there are so many significant changes needed to address the many Discusses already raised that I am cautious about drawing a line under my review and reserve the option to come back and add to my Discuss when a future version has been published. I hope the sponsoring AD will put the document back on a future telechat after it has been updated.
    6. Adrian Farrel: Comment [2012-04-25]:
      In Figure 5, I assume that nodes B and F are actually routers (i.e. AERO edge routers) since they provide acceess to hosts through IP clouds.
    7. Stephen Farrell: Discuss [2012-04-25]:
      (1) 4.4.4 - I don't get the origin authentication check, you say that the source address is correct if a list of 4 things are ok, but then later that only one of them needs to be ok. Which is it? The latter case (any of the 4) seems broken since the 3rd bullet is just the easily spoofed MAC address. The last paragraph here is also odd, the two sentences seem to contradict one another.
      (2) the signature scheme in 4.4.4 is undefined, you need to either define it, or else fess up and say that there's no current scheme and AERO just depends on things that are easily forged and strong data origin authentication is for future work. (I'd be ok with the latter for an experimental draft like this I think.)
      section 3: no security requirements for strong authentication?
    8. Stephen Farrell: Comment [2012-04-25]:
      FWIW, I agree with a bunch of the the other discusses on this.
    9. Brian Haberman: Discuss [2012-04-24]:
      I am editing my DISCUSS points in order focus on the issues that still need resolving. Since a new document is not available, I have marked each point with the state I think they are in...
      This document is going to require some true DISCUSSion in order to resolve some obvious issues.
      1. If this draft goes forward as Experimental, it needs more justification. What issues with AERO make it unsuitable for use on the Internet as a whole? What network characteristics are required to assess AERO's behavior? What issues will arise if non-AERO and AERO-capable nodes attempt to interact? Is AERO truly suitable for any multi-access network?
      2. From the author, my understanding is that an AERO edge router will have a set of ACLs that only allow traffic to be forwarded to it that comes from its default router (router D only forwards traffic from router A by default). That implies that router D must trust the MAC-level information (e.g., src MAC address) contained in a forwarded frame. How is that accomplished? In general, multi-access networks require specific MAC-level functions to do that. Discussion of these issues and how they relate to the AERO messages is needed.
      3. [Resolved pending a new version] Section 4.2.2 specifies AERO host behavior. Since that behavior does not differ from standard IPv6 host behavior defined in RFC 4861 and RFC 4862, what is the purpose? *IF* you need to say anything about host behavior, state that it acts as an IPv6 host (as defined in RFCs 4861, 4862, and 6434).
      4.[Resolved pending a new version] Do AERO edge routers (Section 4.2.3) differ from the CPE routers defined in RFC 6204 (other than the added AERO functionality)? It appears that they should, but it is not specifically called out.
      5.[Modified] I find the claim (section 4.4.1) that "...the ingress node has no way of knowing whether the egress is willing to accept its packets, ..." dubious at best. These packets are being transmitted as IP datagrams, which are best effort. It is not the job of layer-3 to build reliability into the packet forwarding paradigm.
      6. [Resolved] Section 4.4.5 re-defines the structure of the ICMPv6 Redirect message by adding new bit fields. Given that, why does the document not list itself as updating RFC 4861? If that is the case, this change needs to be reviewed by the 6MAN working group.
      7. [Modified] Sections 4.4.10-12 have convinced me that this specification is really a dynamic routing protocol using ICMPv6 Redirect (and the variant Predirect) messages. The incorporation of mobility concepts and periodic reachability logic makes this no different than existing MANET and scaled-down IGPs. In this light, the document does not clearly explain key functional behaviors or why those behaviors are not needed. In order to address these concerns, more detail is needed (per Russ' DISCUSS) on exactly what link types AERO is expected to work under. Single-link behavior for something like Ethernet does not make sense in the context of AERO.
    10. Brian Haberman: Comment [2012-04-24]:
      1. [Resolved pending a new version] Section 4.2.2 states that the egress AERO router sends a Redirect message to the intermediate AERO router who then proxies that Redirect to the ingress AERO router. It would be good to include a forward pointer to sections 4.4.7 and 4.4.8 since that is where the sending and redirect rules are defined.
      2. [Resolved pending a new version] The Acknowledgments section seems to have been truncated.
    11. Russ Housley: Discuss [2012-04-24]:
      I understand that the AERO mechanisms were initially designed for NBMA tunnel virtual interfaces, but these mechanisms can also be applied to any multiple access link types that support redirection. That said, I think we need to better characterize the environments where AERO is appropriate, and maybe even more importantly the environments where AERO is not appropriate.
      This position seems to be supported by the Gen-ART Review by Pete McCann on 24-Apr-2012. Please consider the other comments that are included in this review.
    12. Barry Leiba: Comment [2012-04-25]:
      Lots of DISCUSS positions already, and I don't have anything new to add. I'll just say that I support some of the other AD's DISCUSS positions, particularly Brian's and Ron's.
    13. Pete Resnick: Comment [2012-04-22]:
      I agree with Brian's DISCUSS regarding status. In fact, even Experimental seems a bit odd. The document doesn't describe the circumstances under which you would want to experiment and why you wouldn't want to let this out on the Internet as a proposed standard. I think some more explanation, and perhaps an adjustment to status, is needed.
    14. Martin Stiemerling: Comment [2012-04-25]:
      I'm supporting the other DISCUSSes which cover the issues of the draft.
    15. Sean Turner: Discuss [2012-04-25]:
      Hate to pile on but there were a number of agreed changes as a result of the secdir review. This is just a placeholder discuss until fixes to those changes are agreed and incorporated.
    16. Sean Turner: Comment [2012-04-25]:
      I support the discusses from the other ADs.

    Telechat:

3.2.2 Returning Items

  1. (none)

3.3 IRTF and Independent Submission Stream Documents

3.3.1 New Items

  1. (none)

3.3.2 Returning Items

  1. (none)

1246 EDT break

1253 EDT back

4 Working Group Actions

4.1 WG Creation

4.1.1 Proposed for IETF Review

  1. Worthwhile Extensible Internet Registration Data Service (weirds)
    Token: Pete

    Telechat:

4.1.2 Proposed for Approval

  1. sunset4 (sunset4)
    Token: Ralph

    Telechat:

  2. Network Virtualization Overlays (nvo3)
    Token: Stewart

    Telechat:

4.2 WG Rechartering

4.2.1 Under evaluation for IETF Review

  1. (none)

4.2.2 Proposed for Approval

  1. (none)

5. IAB News We can use

6. Management Issues

  1. Designated expert for Link Relations registries (Barry Leiba)

    Telechat:

  2. Approval of IESG Statement on the Conclusion of Experiments (Adrian Farrel)

    Telechat:

  3. RFC 1510 to Historic (Stephen Farrell)

    Telechat:

  4. Executive Session: ISOC BoT Candidate Confirmation (Russ Housley)

    Telechat:

7. Agenda Working Group News

1430 EDT Adjourned


Valid HTML 4.01 Strict


Appendix: Snapshot of discusses/comments

(at 2012-04-26 07:30:04 PDT)

draft-ietf-geopriv-policy

  1. Stewart Bryant: Comment [2012-04-23]:
    Maybe "Internationalization" is an IETF keyword for character set, but I was
    surprised that the section did not include a discussion on the datums use in
    different countries. The text only supports WGS84, but I understand that there
    are other datums and that WGS84 is tied to GPS but that there are other Sat Nav
    systems.
  2. Ralph Droms: Comment [2012-04-25]:
    Minor editorial nits:
    
    section 4:
    
       The 'profile' attribute allows to indicate the
       location profile that is included as child elements in the <location>
       element and each profile needs to describe under what conditions each
       <location> element evaluates to TRUE.
    
    missing word in "allows to"? (also section 6.4)
    
    section 6.5.2
    
       5.  Let P = 0.2887 (=sqrt(3)/6) and q = 0.7113 (=1-p),
    
    lower case or upper case P?
    
    section 7.5
    
       Suppose you want a to obscure
    
    s/a// ?
    
    section 7.5
    
       In his way
    
    "In this way"?
    
    THe document lists 6 authors; you may get pushback as the guideline is 5.
  3. Adrian Farrel: Comment [2012-04-26]:
    I find the philosophical aspects of this work very hard to grapple
    with. Had the work been presented in a more abstract way (for example,
    as a policy language that could be used in a number of ways) I would
    have found it easier. But the text on motivation disturbs me and,
    while I can completely accept that many people are motivated in this
    way, the approach and ideas seem to me to be broken.
    
    I do not believe that I should enter a Discuss or stand in the way 
    of this work because of my views, but I cannot offer a "No Objection"
    ballot position.
    
    ===
    
    Additionally, the authors might like to consider the following:
    
    It is not clear to me why algorithms need to be standardised in this
    case. While they do affect what is sent on the wire, and while they
    provide useful examples to show that the results can be reliably
    achieved, it seems to me that the results of the algorithms (i.e. the
    outputs based on the inputs) are all that need to be contained in a
    Technical Specification. In short, I do not believe that the
    specification of the algorithms is necessary for interoperability.
  4. Stephen Farrell: Discuss [2012-04-19]:
    Since the previous iesg discussions on this document pre-date me as an AD
    I might be commenting here on things that have already been discussed.
    If so, just send me a pointer if you can to the earlier discussion.
    
    - general: repeated queries are a threat here and are recognised as such
    in a number of places. I would like to have seen some guidanace to
    implementers as to when such repeated queries might be considered to be
    an attack, and when not, and if there's something you can do about that.
    Can such guidance be offered?  If so, why not include it in the document?
    If not, perhaps saying why that's the case would be worthwhile? 
    
    - 13.4: The last sentence is too vague IMO. I think you mean that if
    location is only obscured e.g. around the home, then the lack of location
    implies that I'm at home. You should say that more clearly.
    
  5. Stephen Farrell: Comment [2012-04-19]:
    abstract: "restrict access" in the abstract is ambiguous - it could mean
    "restrict access to a target's actual location" or it could mean
    "restrict access to something based on a target's location information."
    Not sure if that needs fixing or not but this is only addressing the
    former I think.
    
    4.1: what does "within" mean here - does overlapping count or not?
    Seems like that could be made more precise, but maybe its defined
    elsewhere in which case a reference to the relevant section of the
    relevant RFC would be good. I think that's clarified later, but 
    be good to be clear here too.
    
    6.2: It'd maybe be good to explicitly state the meaning of setting this
    to the current date. I assume it means "don't retain."
    
    6.4: CID URIs are mentioned here but not explained nor is the acronym
    expanded. Be nice to do that.
    
    - 13.2: says that "The quotient of the sizes A1/A should be, even in the
    worst case, larger than a fixed known number, in order that the user
    knows what is the maximal information leakage he has." Should that should
    be a 2119 SHOULD? In other words, is the "maximum leakage" referred to
    here really a parameter of the 6.5.2 algorithm? If so, then ought that
    not be called out with 2119 terms?  
    
    - 13.2: I don't follow how the A1/A quotient is >0.13, can you explain
    that some more? (That may or may not need to be reflected in the
    document, not sure.)
    
    - 13.3: 1st para - What is an implementer supposed to do with or based on
    this paragraph?
    
    - 13.4: This seems to imply "uncertainty" is a parameter of the
    algorithm, but that's not explained. This is a similar point to that made
    for 13.2
    
    13: the term "privacy region" is used but not defined 
    
    10.4: typo s/to defined/to define/
    
    13.2: a few typos at the end of 1st para, and more elsewhere, could do
    with an editorial pass really
    
    13.3: "further checks are performed" seems wrong if you don't say what
    those are, maybe s/are/can be/?
  6. Barry Leiba: Discuss [2012-04-23]:
    -- IANA Considerations --
    To ensure that IANA understands which registries
    you're putting things in, please specify very clearly which registry, using the
    exact name.  It would be nice to include the URL as well, to be absolutely sure.
     I have no idea what registries you're registering into in 11.1, 11.2, 11.4, and
    11.5.  The registry for 11.6 appears to be "XCAP Application UNIQUE IDs", not
    "XCAP Application USAGE IDs"... is that correct?
    
    For the new registry in 11.3, I would like to see a rationale for the choice of
    registration policy.  See draft-leiba-iana-policy-update, if you want to see
    where I'm coming from here.  Standards Action is a very restrictive policy
    choice, and I'd like to see that it was seriously considered and discussed, and
    understand why it was chosen over a less restrictive option.
    
    I'm also generally concerned about the longevity of contact information for
    items registered for Standards Track use, and find it problematic to use an
    individual's email address.  Discussion: should you be using the address of a WG
    or non-WG mailing list, which will survive, say, the job change of an
    individual?
    
  7. Barry Leiba: Comment [2012-04-23]:
    Substantive suggestions; please adopt or respond to these:
    
    -- Introduction --
    
       This document does not describe the protocol used to convey location
       information from the Location Server to the Location Recipient.
    
    What document does?  Should it be noted here, with a citation?
    ----
    OLD (unclear what part is "for example")
       Transformations regulate in a location information
       context how a Location Server modifies the information elements that
       are returned to the requestor, for example, by reducing the
       granularity of returned location information.
    NEW (I think you mean...)
       Transformations regulate in a location information
       context how a Location Server modifies the information elements that
       are returned to the requestor by, for example, reducing the
       granularity of returned location information.
    ----
       Both algorithms come with limitations, i.e. they
       provide location obfuscation under certain conditions and may
       therefore not be appropriate for all application domains.
    
    It's not clear exactly what this means.  Is the only limitation the one related
    to the obfuscation?  If there are other limitations, then it should be "e.g.",
    not "i.e."  If that's the only limitation, I suggest replacing "limitations,
    i.e." with "limitations:".  Also, it doesn't make sense that providing location
    obfuscation would be a limitation; perhaps you mean *only* under certain
    conditions?  So maybe this is what you mean?:
    NEW
       Both algorithms come with
    limitations: they
       provide location obfuscation only under certain conditions,
       and may  therefore not be appropriate for all application domains.
    
    -- Section 3.1 --
    
    The preferred term now is "media type", not "MIME type"; please change it. Also
    in Section 10.4.
    
    -- Section 3.2 --
    
    URL, not URI ?
    
    -- Section 6.2 --
    
       The value provided with the <set-retention-expiry> element indicates
       seconds and these seconds are added to the current date.
    
       If the <set-retention-expiry> element is absent then the value of the
       <retention-expiry> element in the PIDF-LO is kept unchanged or, if
       the PIDF-LO is created for the first time, then the value MUST be set
       to the current date.
    
    It looks like "current date" means "current date and time"; should you not say
    that?  Also, I guess absence then means that the retention expiry is
    immediate... and I presume that's OK.
    
    -- Section 6.4 --
    
       If the <keep-rule-reference> element is absent, then the value of the
       <external-ruleset> element in the PIDF-LO is kept unchanged when
       available or, if the PIDF-LO is created for the first time then the
       <external-ruleset> element MUST NOT be included.
    
    This creates an interesting situation, in which the absence of a value has a
    meaning that cannot be conveyed by any value that might be present.  That's odd,
    and possible troublesome, so I want to be sure you've thought about that.
    
    -- Internationaliztion Considerations --
    
       The content of the <label>
       element is meant to be provided by a human (the Rule Maker) and also
       displayed to a human.
    
    Does this also mean that the information might need to be language-tagged and/or
    translated (in addition to perhaps being in non-ASCII characters?
    
    -- Section 13.3 --
    
    The first paragraph is confusing,  and doesn't seem to reach a reasonable
    conclusion.  It purports to talk about usability, but then seems to get into
    information leakage, and never makes a point that seems to me to be clear and
    useful.  Please try to re-work that paragraph.
    
    -- Section 13.4 --
    
       Location obscuring attempts to remove information about the location
       of a Target.  The effectiveness of location obscuring is determined
       by how much uncertainty a Location Recipient has about the location
       of the Target.
    
    As you note earlier (and later, two paragraphs down), this is oversimplified:
    the effectiveness is not determined just by that, but is also strongly
    influenced by what can be revealed by repeated queries over time -- how
    aggregating responses can reveal more than a single response will.
    
       Obscured locations can still serve a purpose where a Location
       Recipient is willing to respect privacy.
    
    It's not clear what value that paragraph has.  It seems to say, basically, "If
    the LR doesn't want to attack you, then whatever you've done will be fine."
     It's true, but not very useful as a security consideration.  You might just
    want to remove this paragraph, and take the word "more" out of the subsequent
    one.
    
    This is an old document; please double-check the references to make sure they're
    accurate, current, and correctly classified.  The reference to RFC 2434 is
    obsolete, replaced by 5226, for example.
    
    ========
    Editorial suggestions.  No need to respond to these; take them, leave
    them, or modify them as you please.  There are also numerous errors in
    punctuation, number agreement, and the like; it would be good for one of the
    native English speaking editors to go through the document source code and fix
    those... or I guess we can let the RFC Editor deal with them.
    
    -- Introduction --
    
    (clarity)
    Not all terminology is in one place, and Target isn't specifically
    defined.  I suggest the following structure for the introduction (and if you do
    this, you can remove the second paragraph from section 2):
       -----
       1.
    Introduction
           First sentence as written.  Second sentence.
    
       1.1 Terminology for the model, as in RFC 3693
           Location Generator (LG), [explain].
           Location Server (LS), ...
           Location Recipient (LR), ...
           Rule Maker (RM), ...
           Authorization Policy, ...
           Location Object (LO), ...
           Target, ...
    
       1.2 Overview
           The basic rule set defined [...]
       -----
    
    OLD (sounds awkward)
       The basic rule set,
       however, does not allow to control access to location information
       based on specific Location Recipients.
    NEW
       The basic rule set,
       however, does not allow access control for location information
       based on specific Location Recipients.
    
    OLD (clarity)
       The rule set allows the entity that uses the rules defined in this
       document to restrict the retention
    NEW
       The enhanced rule set allows the entity that uses the rules
       defined in this document to restrict the retention
    
    OLD (sounds awkward)
       or that the resolution of parts of the Location Object is
       reduced.
    NEW
       or that the resolution is reduced for parts of the Location
       Object.
    
    OLD (to read more smoothly)
       The typical sequence of operations is as follows.  A Location Server
       receives a query
    NEW
       In the typical sequence of operations, a Location Server
       receives a query
    
    OLD (awkward usage)
       determine under which circumstances the entity executing the rules,
       for example a Location Server,
    NEW
       determine under which circumstances the entity executing the rules,
       such as a Location Server,
    
    -- Section 2 --
    OLD (setting off defined terms)
          The term permission refers to the action and transformation
          components of a rule.
    NEW
          The term "permission" refers to the action and transformation
          components of a rule.
    OR
          The term Permission refers to the action and transformation
          components of a rule.
    
    In general, please be consistent with how you set off defined terms, and avoid
    using a term in a definition while making it look like it's just part of the
    sentence.
    
    OLD (bad usage)
          as motivated in RFC 4079
    
    This usage of "motivated" is made-up business jargon and will be difficult for
    many non-native speakers (and quite some native speakers) to understand.
    NEW
      
      as explained in RFC 4079
    [or "described in", or something like that]
    
    -- Section 4.1 --
    
    OLD (repetition)
       reference system based on WGS 84 [NIMA.TR8350.2-3e] based on the
       European Petroleum Survey Group
    NEW
    Can you re-word this to avoid the "based on... based on" repetition?
    
    -- Section 7.5 --
    
    OLD
          We will set up a grid not only for the continental US, but for the
          whole earth between latitudes 25 and 50 degrees
    
    You're not including Alaska.  This is a total nit, but in order to avoid
    arguments about whether "continental" U.S. includes Alaska, you might switch to
    "contiguous US".
    
    -- Section 13.1 --
    
    First paragraph has a spurious ")" at the end.
    
    OLD (unclear antecedent)
       This algorithm for
       geodetic location information obfuscation makes use of these
       techniques.
    NEW
       The algorithm defined in this document for
       geodetic location information obfuscation makes use of these
       techniques.
    
    -- Section 13.2 --
    
    OLD
       For example, when a transformation indicates that civic location is
       provided at a 'building' level of granularity.  Consequently, floor
       levels, room numbers, etc. would be hidden.
    
    The first sentence is not a complete sentence, and the second is not a very good
    one.  Merge these, and make a proper sentence.  Maybe (assuming I understand
    what you mean to say) something like this?:
    
    NEW
       For example, when a transformation indicates that civic location is
       provided at a 'building' level of granularity, floor levels, room
       numbers, and other detailed information would be hidden.
    
    The paragraph that begins thus:
       The algorithm presented in Section 6.5.2 has
    some measures against
       leaking information when moving, switching from one
    privacy region to
       another one
    ...is very long, and has quite a number of
    grammatical errors.  I suggest getting one of the native-English-speaking
    editors to fix this and to split it into at least three paragraphs.
  8. Pete Resnick: Comment [2012-04-25]:
    This document needs a great deal of editing for simplification and clarity. That
    said, none of these (or the other changes I suggest below) are enough for me to
    hold up the document. But I do wish you would address these issues before
    publication.
    
    First, the strictly editorial. There's a great deal of use of the passive voice
    that is making the text very complicated. Here are two paragraphs from section 4
    that could be greatly clarified by editing, with some suggested replacements:
    
       This section describes the location-specific conditions of a rule.
       The <conditions> element contains zero, one or an unbounded number of
       <location-condition> child element(s).  Providing more than one
       <location-condition> element may not be useful since all child
       elements of the <conditions> element must evaluate to TRUE in order
       for the <conditions> element to be TRUE.  The <location-condition>
       element MUST contain at least one <location> child element.  The
       <location-condition> element evaluates to TRUE if any of its child
       elements is TRUE, i.e., a logical OR.
    
    "The <conditions> element contains zero or more <location-condition> child
    element(s). The <conditions> element evaluates to TRUE if all of its child
    elements evaluate to TRUE (and therefore multiple <location-condition> elements
    are not normally useful). The <location-condition> element MUST contain at least
    one <location> child element.  The <location-condition> element evaluates to
    TRUE if any of its child elements evaluates to TRUE."
    
       The <location> element has three attributes, namely 'profile', 'xml:
       lang'
    and 'label'.  The 'profile' attribute allows to indicate the
       location profile
    that is included as child elements in the <location>
       element and each profile
    needs to describe under what conditions each
       <location> element evaluates to
    TRUE.  This document defines two
       location profiles, one civic and one
    geodetic location profile, see
       Section 4.1 and Section 4.2.  The 'label'
    attribute allows a human
       readable description to be added to each <location>
    element.  The
       'xml:lang' attribute contains a language tag providing further
    information for rendering of the content of the 'label' attribute.
       
    "The
    three attributes of <location> element are 'profile', 'xml:lang', and 'label'.
    The 'profile' attribute contains the type oflocation data in the <location>
    element. Two location profiles, one geodentic and one civic, are defined in
    Sections 4.1 and 4.2. The 'label' attribute contains a human readable
    description of the location. The 'xml:lang' attribute contains a language tag
    indicating the language of the 'label' attribute."
    
    I'm not going to go through and edit this entire document, but you get the idea;
    I hope the editors can have a proper edit of this document done, if not have the
    RFC Editor assist with this. These are just two examples. The entire document
    could use a good rewrite.
    
    From here on, I will point only out places where I think the language obfuscates
    meaning.
    
    4:
    
       The <location-condition> and the <location> elements provide
       extension points.  If an extension is not understood by the entity
       evaluating the rules then this rule evaluates to FALSE.
    
    Are you saying that if an unknown extension is used in a child of <location>,
    that <location> should evaluate FALSE if if another known child of <location>
    evaluates TRUE? That violates the logical OR of the <location> element.
    
    4.2 "bit-by-bit comparison": No normalization of comparison is allowed? That
    doesn't seem necessary. If you do need this, at least make it "octet-by-octet"
    or "byte-by-byte" if you must.
    
    "If the civic location of the Target is unknown": Do you mean "If the
    <civicAddress> element is missing"? This reads as if the <location> should
    evaluate to FALSE if the civic location is not understood, and I don't think
    that's what you mean.
    
    6 (generally) Why does this section talk about when the PIDF-LO is first
    created? That has nothing to do with the transformations. That info belongs
    somewhere else.
    
    6.1 (and forward) "This element asks...". The element does not "ask" anything.
    Please rewrite.
    
    6.2 "<set-retention-expiry> element is an integer." I assume unsigned, yes?
    Probably best to say.
    
    6.5.1 I can't get any more granular than the 6 choices? Why not?
  9. Sean Turner: Discuss [2012-04-25]:
    Just trying to make this actionable (I understand this parenthetical bit isn't
    so much: the rest of the section needs a good editorial pass to make sure it
    makes sense -see my comments):
    
    The last paragraph in s13.2 seems like it might be missing a discussion about
    one of the three things listed in the 1st sentence.  There's a discussion about
    the 1st and 2nd issue but not the 3rd and the 1st and 2nd issue both "the
    following", which I assume has something to do with Jack Torrance/Nicholson.
    Maybe it's just editorial, but I'd like to make sure nothing got dropped.
    
  10. Sean Turner: Comment [2012-04-25]:
    s3.1: so maybe I'm nit picking but maybe r/privacy safe/privacy enabling ? It's
    not really safe it's enabling.
    
    s3.2: r/There are two ways how the/There are two ways the 
    
    s4: r/allows to indicate/indicates
    
    s6.5.2: r/steps.The/steps. The
    
    s6.5.2: I found this a little hard to parse:
    
     The maximal distortion of the map may
           not be too much (see notes below).
    
    r/much/large?
    
    s6.5.2, step 5: r/P/p 
    
    s6.5.2: Okay I'll bite what's the basis for picking those values for p and q?
    
    s8/s9: I'm going with the thought that somebody verified the XML schema.
    
    I agreed with many of the initial IESG reviews of early versions of this draft,
    but I think the security considerations is great big step in the right
    direction.  But, I had a bunch of edits on the security considerations to make
    it more understandable.  Not sure that all my suggestions are correct though.
    
    s13.1, 1st para:
    
    r/This is accomplished through the usage of
      authorization policies./This is accomplished
      using authorization policies.
    
    r/treated in [RFC4745])./addressed in [RFC4745].
    
    s13.1, 2nd para:
    
    r/In addition to the authorization policies mechanisms/
      In addition to the authorization policies, mechanisms 
    
    r/makes use of these/uses these
    
    s13.1, 3rd para:
    
    what does this mean:
    
      The requirements of location information with respect to privacy
      protection vary.
    
    requirements on the information or requirements on giving out the information?
    
    r/While the two obfuscation algorithm/While the two obfuscation algorithms
    
    I think you mean to protection against unauthorized disclosure of location
    information:
    
    r/protection/protecting against unauthorized disclosure of location information
    
    This sounds odd:
    
     There
     are certainly applications that require a different level of
     protection and for this purpose the ability to define and use
     additional algorithms has been envisioned. New algorithms can be
     specified via the available extension mechanism.
    
    Maybe:
    
     Applications requirements vary widely; therefore, an extension mechanism is
     supported to allow for the definition of new algorithms.
    
    s13.2, 1st para:
    
    r/then it contains/it contains 
    
    r/is danger to reveal information over time/is a danger than information will be
    revealed over time.
    
    r/real/reveal ?
    
    13.2, 3rd para: ?
    
    OLD:
    
       For this purpose the algorithm described in Section 6.5.2 uses a grid
       that ensures to report the same location information whenever the
       target remains in the same geographical area.
    
    NEW:
    
       For this purpose the algorithm described in Section 6.5.2 uses a grid
       that ensures the same location information is reported whenever the
       target remains in the same geographical area.
    
    s13.2, 5th para:
    
    r/measures/protections ?
    
     r/is visiting regularly/is regularly visiting
    
    r/The first issue is the following:/The first concern is the ability to be
    followed:
    
    The second issue is also the following?  Isn't the 3rd concern listed in the 1st
    sentence visiting places regularly?
    
    r/If the reported obfuscated locations are all
       randomly different, an analysis will probably soon reveal the home
       location with high precision/
       If the reported obfuscated locations are all
       randomly chosen, an analysis can reveal the home
       location with high precision.
    
    all randomly different/all randomly chosen (it'd be funny if they were all
    randomly the same) and will probably is wishy-washy - the point is you can do an
    analysis.
    
    r/may render a much precise location
       information than desired./
      may render a much more precise location
       information than is desired.
    
    once or in a regular repetitive way   can non-regular samples help leak samples?
    maybe r/once or in a regular repetitive way/once or multiple times
    
    also is it or or and at the end of that sentence?
    
    r/An opponent,/A stalker,  ;) but probably better to say attacker
    
    Oh and I support Stephen's discuss position.

draft-ietf-kitten-gssapi-naming-exts

  1. Adrian Farrel: Comment [2012-04-25]:
    I have no objection to the publication of this document, and just
    three minor nits you may want to look at.
    
    Section 2
    
       This document proposes concrete GSS-API
       extensions.
    
    Should feel free to be more positive! s/proposes/defines/
    
    ---
    
    Section 3
    
    I suspect the RFC editor will ask you to expand "iff"
                  
    ---
    
    Please consider replacing the reference text used here for 
    [OASIS.saml-core-2.0-os] with the text used in RFC 6595 to include the
    stable URL.
  2. Russ Housley: Comment [2012-04-24]:
      Please consider the editorial comments from the Gen-ART Review by
      Pete McCann on 24-Apr-2012.  The review can be found at:
      http://www.ietf.org/mail-archive/web/gen-art/current/msg07387.html
  3. Pete Resnick: Comment [2012-04-25]:
    In section 5:
    
       Another aspect of context is encoding of the attribute information.
       An attribute containing an ASCII or UTF-8 version of an e-mail
       address could not be interpreted the same as a ASN.1 Distinguished
       Encoding Rules e-mail address in a certificate.
    
       All of these contextual aspects of a name attribute affect whether
       two attributes can be treated the same by an application and thus
       whether they should be considered the same name attribute.  In the
       GSS-API naming extensions, attributes that have different contexts
       MUST have different names so they can be distinguished by
       applications.  As an unfortunate consequence of this requirement,
       multiple attribute names will exist for the same basic information.
       That is, there is no single attribute name for the e-mail address of
       an initiator.
    
    I don't have the expertise to evaluate this document thorougly, but something in
    the above seems weird, if not incorrect. It is certainly the case that an email
    address encoded in ASCII or UTF-8 cannot be byte-for-byte compared to the same
    email address encoded as an ASN.1 Distinguished Encoding Rules e-mail address.
    But the words "could not be interpreted the same as" strike me as incorrect. You
    *can* interpret the two e-mail address as the same if, after doing the decoding,
    you compare the addresses to eachother. And it would, indeed, be very
    unfortunate for something that happens to use a different encoding to get a
    different name for each encoding and therefore have multiple non-comparable
    occurances of the item. It seems like you would want only one occurance of each
    item, marked with the encoding, and implementations would be responsible for the
    decoding.
    
    Maybe this is just a language issue. But something seems wrong about the above.
  4. Sean Turner: Comment [2012-04-23]:
    Only nits:
    
    s2: r/(eg an X509/(e.g., an X.509 
    s3/s5/s7.5/s7.6: r/iff/if  X3
    s5: Consider
    Kerberos PKINIT (RFC 4556).  Isn't this an informative reference? so: Consider
    Kerberos PKINIT [RFC4556].
    s5: r/certificate authority/certification authority
    X2
    s5: references for ASCII/UTF-8/ASN.1?

draft-ietf-fecframe-raptor

  1. Benoit Claise: Comment [2012-04-23]:
    4.1.  Definitions
    
       This document uses definitions that apply to FEC Framework in general
       as defined in [RFC6363].  In addition, this document uses the
       following definitions:
    
    Not sure what "that apply to FEC Framework in general" means.
    Don't you want to say something such as
    
       The FEC-specific terminology used in this document is defined in [RFC6363].
       In this document, as in [RFC6363], the first letter of
       each FEC-specific is capitalized along with the new terms defined here:
  2. Stephen Farrell: Comment [2012-04-23]:
    - Its not clear to me whether the "device" mentioned in the IPR
    declaration's licensing section really only means h/w devices or not,
    or could badly impact e.g. an OSS implementation of this draft. I
    assume the WG have considered this and are happy with the idea of the
    license being specific to a "device" or at least don't seem to care (as
    implied by the write-up).
    
    - 6.2.1.2 - if the last octet is omitted then all the reserved bits
    aren't sent. Would it be worth noting that it'd not be safe to omit
    that octet if someone defines meanings for some of those reserved bits
    in future? Would "MAY be omitted" be better (i.e. use a 2119 keyword)?
    Finally, it'd have been nice if you had said that that octet SHOULD be
    sent or SHOULD be omitted - why not do that?
    
    - 7.1 - Would it be better to be explicit here about how the padding
    with zeros is done? I.e., rfc6330 says that symbols K through K'-1 are
    the padding symbols, the same is true here I think but good to say so,
    if so rather than forcing the reader to check in rfc6330.
    
    - 8.1.3 - Similar question about padding, though here the answer is
    obvious I guess, but still maybe no harm saying.
    
    - Section 9 defers to 6363 for security considerations, but 6330's and
    5053's (identical?) security considerations seem more concrete, e.g.
    they RECOMMEND using something like TELSA, whereas 6363 eventually says
    "implement IPsec" but doesn't say much about what to use. It'd be good
    to be clearer about what, if anything, is mandatory-to-implement or
    SHOULD be used here. (This isn't a DISCUSS because all those RFCs
    are normative references so in theory implementing this means doing
    all of the above I guess.)
  3. Russ Housley: Comment [2012-04-24]:
      Please consider the editorial comments from the Gen-ART Review by
      Kathleen Moriarty on 18-Mar-2012.  The review can be found at:
      http://www.ietf.org/mail-archive/web/gen-art/current/msg07284.html
  4. Robert Sparks: Comment [2012-04-24]:
    In section 7.2.1.2 did you mean to point to 6.2.1.2 instead of 6.2.2?
  5. Martin Stiemerling: Discuss [2012-04-20]:
    This document got a DISCUSS due to the transition of your responsible AD and the
    need to fix some parts of the documents before the DISCUSS is resolved into a
    YES.
    
    General:
    - There are a number of fields which do not say what type they are,
    e.g., integer or unsigned integer. On the other hand some fields are labelled as
    decimal number which is not applicable to the wire representation anyhow. 
    - How
    are the bytes ordered on the wire. I guess in network byte order, but that
    should be noted somewhere.
    
    Here are those fields:
    - Section 6.2.1.2:
       MSBL  Value range:  A decimal non-negative integer less than 8192 for
          FEC Scheme XXX1 and less than 56403 for FEC Scheme XXX2, in units
          of symbols
    
    Remove decimal, as this is not applicable on the wire. 
    
       Encoding Symbol Size  Name:  "T", Value range:  A decimal non-
          negative integer less than 65536, in units of octets
    
    Remove decimal, as this is not applicable on the wire. 
    
       Payload ID Format  Name:  "P", Value range:  "A" or "B"
    
    The flag P can only take the binary values '0' or '1', but never "A" or "B". How
    is the symbolic value of 'A' reprented in P and how  is the symbolic value of
    'B' reprented in P?
    
    - Section 6.2.2., below "Figure 2: Source FEC Payload ID - Format A"
    
       Source Block Number (SBN), (16 bits):  An integer identifier for the
          source block that the source data within the packet relates to.
    
       Encoding Symbol ID (ESI), (16 bits):  The starting symbol index of
          the source packet in the source block.
    
    How is the index to be interpreted, e.g., as unsigned integer? Please specifiy
    this here!
    
    - Section 6.2.2., below "Figure 3: Source FEC Payload ID - Format B"
    
       Source Block Number (SBN), (8 bits):  An integer identifier for the
          source block that the source data within the packet relates to.
    
       Encoding Symbol ID (ESI), (24 bits):  The starting symbol index of
          the source packet in the source block.
    
    How is the index to be interpreted, e.g., as unsigned integer? Please specifiy
    this here!
    
    - Section 6.2.3., below " Figure 4: Repair FEC Payload ID - Format A"
    
       Source Block Number (SBN), (16 bits)  An integer identifier for the
          source block that the repair symbols within the packet relate to.
          For format A, it is of size 16 bits.
    
       Encoding Symbol ID (ESI), (16 bits)  Integer identifier for the
          encoding symbols within the packet.
    
       Source Block Length (SBL), (16 bits)  The number of source symbols in
          the source block.
    
    How is the number of source symbols to be interpreted, e.g., as unsigned
    integer? Please specifiy this here!
    The same for " Source Block Length (SBL)"
    for Format B.
    
    Section 8.1.3., below "Figure 6: Repair FEC Payload ID - Format A"
    
       Initial Sequence Number (Flow i ISN) - 16 bits  This field specifies
          the lowest 16 bits of the sequence number of the first packet to
          be included in this sub-block.  If the sequence numbers are
          shorter than 16 bits then the received Sequence Number SHALL be
          logically padded with zero bits to become 16 bits in length
          respectively.
    
    How is the Flow i ISN to be interpreted, e.g., as unsigned integer?
    
       Source Block Length (SBL) - 16 bits  This field specifies the length
          of the source block in symbols.
    
    How is this to be interpreted, e.g., as unsigned integer?
    
    [con't from page 17]
       Encoding Symbol ID (ESI) - 16 bits  This field indicates which repair
          symbols are contained within this repair packet.  The ESI provided
          is the ESI of the first repair symbol in the packet.
    
    How is this to be interpreted, e.g., as unsigned integer?
    
    Section 8.1.3., below "Figure 7: Repair FEC Payload ID - Format B"
    
       Initial Sequence Number (Flow i ISN) - 16 bits  This field specifies
          the lowest 16 bits of the sequence number of the first packet to
          be included in this sub-block.  If the sequence numbers are
          shorter than 16 bits then the received Sequence Number SHALL be
          logically padded with zero bits to become 16 bits in length
          respectively.
    
    How is this to be interpreted, e.g., as unsigned integer?
    
       Source Block Length (SBL) - 16 bits  This field specifies the length
          of the source block in symbols.
    
    How is this to be interpreted, e.g., as unsigned integer?
    
       Encoding Symbol ID (ESI) - 24 bits  This field indicates which repair
          symbols are contained within this repair packet.  The ESI provided
          is the ESI of the first repair symbol in the packet.
    
    How is this to be interpreted, e.g., as unsigned integer?
    
  6. Martin Stiemerling: Comment [2012-04-20]:
    Section 2:
    - replace "Section 6defines an FEC Scheme" with "Section 6 defines an
    FEC Scheme2
    - replace "Section 6but with optimisations for with "Section 6 but
    with optimisations for"
    - replace  "over IP Based" Networks  "  with "over IP
    Based Networks"   " (move ' " ')
    - Section 4.2: Add ADU to the list of
    abbreviations
    - Section 6.2.1.2, at the bottom of the page:
      replace "An
    encoding format for The MSBL and Encoding" with "An encoding format for the MSBL
    and Encoding S"
  7. Sean Turner: Comment [2012-04-25]:
    I guess I'm with Stephen on the security considerations it should really also
    point to RFCs 5053 or 6330.

draft-ietf-ipfix-psamp-mib

  1. Adrian Farrel: Discuss [2012-04-25]:
    I don't think it makes sense to have DEFVAL clauses for read-only 
    objects. They are really used for object creation and are not
    appropriate for describing the default beavior of protocol 
    implementations.
    
    For example...
    
    psampSampCountBasedAvail
    psampSampTimeBasedAvail
    psampSampRandOutOfNAvail
    psampSampUniProbAvail
    psampFiltPropMatchAvail
    psampFiltHashAvail
    
  2. Adrian Farrel: Comment [2012-04-25]:
    Please remove the citations from the Abstract
    
    ---
    
    There are a couple of places where you should s/MIB/MIB module/
    E.g. Section 5.1
    
    ---
    
    I would have expected to see some discussion of 
    psampSampUniProbProbability and the non-support of NaN and Infinity
    in the compliance clauses.
    
    ---
    
    Should psampFiltHashFunction also include a reference to RFC 1141?

draft-ietf-marf-as

  1. Benoit Claise: Comment [2012-04-25]:
    Thanks for addressing my points
  2. Adrian Farrel: Comment [2012-04-25]:
    Forgive me, but doesn't section 8.2 say that forged abuse reports
    constitue a real problem and the two mechanisms available to protect
    against them may result in genuine abuse reports being discarded?
    
    Is the message here "chosse which you think might be the least worse
    problem" or is it "you should use DKIM and SPF, but be aware that you
    may lose some genuine reports"?
    
    I would have liked some clarification as to which message is being sent.
  3. Stephen Farrell: Comment [2012-04-23]:
    Just a bunch of nitty comments. Feel free to take 'em or leave
    'em.
    
    5.1 (1) - this has a MUST but there's no well-defined/standard way to
    satisfy the MUST, maybe make that an "ought"? 
    
    5.1 (2) - I think you mean that "they think will" pass SPF/DKIM checks,
    since they can't be sure
    
    5.2 (1) - "the receiver" is a bit ambiguous in the 1st sentence, maybe
    s/the receiver/the report receiver/? (Or if handling is expensive for
    both, then maybe say that.)
    
    5.3 (1) - what does "SHOULD make" mean? Same comment as above for use
    of SHOULD when there's no standard way to do it, i.e. maybe
    s/SHOULD/ought/
    
    5.5 (1) - is "bulk senders" at the end here ambiguous? I read it as
    referring to the sender of the message(s) that triggered the report.
    
    6 - what is a "smaller" AS or use-case? Do you mean fewer people will
    do this or that its simpler?
    
    6 - point (3), is the "MUST be constructed" there right? If everything
    needed to satisfy this MUST is later in point 3, then you could say
    "MUST be done as stated below" - as is, this looks like there's
    something else needed to satisfy the MUST but you don't say what.
    
    8.3 - this is a little terse, maybe point back at those recommendations
    or say a bit more?
    
    8.4 - might be better to say "larger volumes or higher frequency"
    
    8.5 - I guess this means that report receivers ought not react to
    missing reports as if something was wrong. Not sure if that's worth
    noting explicitly or not.
  4. Brian Haberman: Comment [2012-04-25]:
    Thanks for addressing my comments.
  5. Robert Sparks: Discuss [2012-04-24]:
    The MUST in section 4.5 item 1 may need clarification. Do you mean to say that
    the system MUST accept a report with a feedback type with any value that makes
    it into the (specification-required) registry? Or are you wanting to scope that
    to values that were registered with an RFC that Updates/Obsoletes 5965? Or
    something else? Is this effectively requiring implementations of automated
    report processing systems to be configurable with what feedback types it will
    accept? If so, would it make sense to say that explicitly? Also, consider more
    detail on what accept means here. Does it mean the system can't return a
    rejection response (what bad happens if it does?) or is the intent that it must
    _process_ the report.
    
  6. Robert Sparks: Comment [2012-04-24]:
    In section 5.1 item 1, is there a typical unstandardized out-of-band mechanism
    for telling unsolicited reporters to please stop that you can call out as an
    example (an existence proof)?
    
    In Section 6, item 1, the sentence "Automatic feedback generators MUST select
    recipients based on data provided by the report recipient." is really hard to
    understand (it's almost circular). Is it trying to say something like "Automatic
    feedback generators MUST only send to addresses explicitly provided by willing
    recipients."?

draft-ietf-emu-chbind

  1. Benoit Claise: Comment [2012-04-26]:
    Just happy that there is an "Operations and Management Considerations" section. 
    It makes sense in many documents, IMHO.
    Thanks for that.
    
    Regards, Benoit.
  2. Ralph Droms: Comment [2012-04-25]:
    Minor editroial nit: the affiliation for
    T. Clancy in the header should be fixed.
  3. Adrian Farrel: Discuss [2012-04-25]:
    I am escalating part of Barry's Comment to a Discuss
    
    Please give the valid ranges for new code point registries.
    Is the value zero reserved, out of scope, or unassigned?
    
  4. Adrian Farrel: Comment [2012-04-25]:
    idnits reveals...
    
      -- The document has a disclaimer for pre-RFC5378 work, but was first
         submitted on or after 10 November 2008.  Does it really need the
         disclaimer?
    
    I would prefer you to fix this (if it needs fixing) with a respin so 
    there is a copy of the document on file with the correct disclaimer.
    
    ---
    
    Please expand acronyms on first use if they don't appear in
    http://www.rfc-editor.org/rfc-style-guide/abbrev.expansion.txt with an
    asterisk.
    
    I found...                                    
    
    NAS (In the Abstract and a bit too late in the Introduction)
    SSID (seciton 1)
    
    ---
    
    Section 3
    
       o  Enterprise Network: A corporate network may have multiple virtual
          Lads (VLANs) running throughout their campus network
    
    This is the most beautiful text I have read for a long time. Thank you!
    
    BTW s/Lads/LANs/ is only part of the problem.
    Does a LAN run through a network?
  5. Stephen Farrell: Discuss [2012-04-26]:
    (Sorry, I ran out of time to properly consider the secdir review
    so I'll just trust that that's being handled correctly.)
    
    1) cleared
    
    2) p22, 9.1 says "derivation of keying material including a key for
    integrity protection of channel binding messages" but that doesn't say
    that it must be that the authenticator can't know the relevant key.
    There also seems to be a missing MUST in the lead in to that list.
    
    3) cleared
    
  6. Stephen Farrell: Comment [2012-04-26]:
    1) The secdir review [1] has resulted in some changes that are already
    agreed and some that are being chatted about between reviewer and wg
    chair. This is just a discuss to hold things while that happens. (Not
    all the review comments are DISCUSS level, but a few are. We can
    figure out which if we get stuck on some if that's ok.)
    
       [1]
    http://www.ietf.org/mail-archive/web/secdir/current/msg03271.html
    
    2) Does this really work with ERP? Seems like it'd add more
    roundtrips, e.g. making ERP-AAK pointless. 
    
    3) Why can't the authenticator cheat on CB if the EAP method is based
    on symmetric crypto with a KDC like thing? In fig 1 the lying NAS
    could mess with i1 as sent from peer to server.  Why not?
    
    4) Does including attributes that were validated in the CB failure
    message not expose the server to someone probing the server's policy?
    E.g. the lying NAS could play about until it knows what cheating is
    possible?
    
    5) What does "MAY be defined" mean in 7.1? By whom? Where?  Does that
    need to be here?
    
    6) What does "as thorough of a validation as possible" mean in section
    8? That doesn't seem to be testable.
    
    7) Is "typically contains" enough for User-Name protection if EAP
    method identity protection is employed? I expected to see a MUST
    there.
    
    8) Is A.3 correct? If the selected method is breakable (if not why
    bid down to it?) then the bad NAS can probably change the i1 message
    so I'm not convinced by this argument.
    
    nits:
    
    - p10 - rfc5296bis is in IESG Evaluation, and obsoletes 5296 so you
    should update the reference
    
    - p11 - knowing that the client is using layer 2 crypto doesn't seem
    very compelling if concerned about a bad NAS, since its the often the
    case that the putative bad NAS that can see the plaintext, it could
    leak that back over the air in clear if it wanted. (Liable to be
    detected, but then so might lack of layer2 crypto in the client UI.)
    
    - p22 - the NAS identifier can expose the user's location, depending
    on how those are named and whether confid. is available for the
    peer/server i1 or i2 message. That might be worth a mention.
  7. Russ Housley: Comment [2012-04-22]:
      The Gen-ART Review by Francis Dupont on 7-Apr-2012 raised quite a few
      editorial comments.  The authors have indicated that many of them are
      very useful, and they want to update the document to address them, but
      this has not happened as yet.
  8. Barry Leiba: Comment [2012-04-24]:
    -- IANA Considerations --
    
    The definitions for the two new EAP Channel Binding Parameters sub-registries
    specify numbers in column one of the tables, but do not specify a range for
    those numbers.  Is it 0-255 (one byte)?  Something else?  Please specify, so
    IANA (and the rest of us) knows.  Similarly for the new sub-registry in 11.1.
    
    I would like to see a brief rationale for the choices of Standards Action and
    IETF Review for the registration policies for the two new parameters sub-
    registries.  See draft-leiba-iana-policy-update if you want to see where I'm
    coming from on this.  Just something brief that shows that it was considered and
    discussed, and that explains why these were chosen.  Note: the definition for
    the new registry in 11.1 does give a rationale; thanks.

draft-ietf-appsawg-greylisting

  1. Stewart Bryant: Comment [2012-04-24]:
    Thank you for the explanation.
  2. Benoit Claise: Comment [2012-04-25]:
    Please expand MTA.
    I know that you wrote: "Readers need to be familiar with the
    material and terminology discussed in [MAIL] and [EMAIL-ARCH]." We could help
    the reader a little bit, instead of searching into
    http://tools.ietf.org/html/rfc5598 to know what the acronym means
    
    Similarly, maybe it's obvious for people dealing with Email, but I had to lookup
    "MX record" ...
     
    OLD:
    Experience suggests that the, the vast majority of mail
    comes from
    
    NEW
    Experience suggests that the vast majority of mail comes from 
    
    Regards, Benoit.
  3. Ralph Droms: Comment [2012-04-26]:
    Thanks for addressing my comment.
  4. Adrian Farrel: Comment [2012-04-25]:
    I strongly support this effort which draws a line between blacklisting and more
    acceptable techniques. I hope this will serve as encouragement to service
    providers to move away from descriminatory and service-impacting blacklists.
    
    ---
    
    Section 1
    
    s/for provider better service./for providing better service./
  5. Stephen Farrell: Comment [2012-04-24]:
    - intro: "a period of time" is usually measured in minutes here, might
    be worth saying that just in case
    
    - 2.3: Odd reference text: "refers to the [SMTP] command verb" I think
    it'd be better if the reference was handled differently and e.g. it
    said "refers to the 'SMTP' command verb in an SMTP [SMTP] session" (I
    prefer if the references are not part of the text but that's a
    different style issue). The "RFC5321.MailFrom" notation also shows as
    a reference on the tools page, not sure if that's desirable or not or
    if it can be avoided or not.
    
    - typo, section 3, s/the, the/the/
    
    - section 5: Are there any 4yz errors that SHOULD NOT or MUST NOT be
    used here?  I've no idea and suspect not based on this text, but if
    there were then that'd be worth saying.
  6. Brian Haberman: Comment [2012-04-23]:
    This is a well-written document and describes a useful function.  I do support
    Martin's DISCUSS about the status.  It definitely reads like a BCP.
  7. Russ Housley: Comment [2012-04-24]:
      Please consider the editorial comments from the Gen-ART Review by
      Kathleen Moriarty on 23-Apr-2012.  The review can be found at:
      http://www.ietf.org/mail-archive/web/gen-art/current/msg07382.html
  8. Pete Resnick: Comment [2012-04-22]:
    2.5
    
       Some implementations do filtering here
    
    I think you meant, "Some implementations do greylisting here". There's no
    filtering described in this section.
    
       o  identifiers in the message, such as the contents of the
          RFC5322.From or RFC5322.To fields;
    
    Change "message" to "message header" or "message content" or equivalent. I think
    there is the potential to confuse envelope here.
    
    2.6
    
    I think you mean "spam", or maybe "spam senders", but not "spamware" in this
    paragraph. There is nothing about an IP address that identifies spamware, but it
    certainly might identify a sender of spam.
    
    4.2
    
       Some clients do not retry messages at all.
     
    and
    
       Some SMTP implementations make the error of treating all error codes
       as fatal;
    
    I think it's worth adding "in violation of [SMTP]". It should be clear that you
    are only losing email from clients that are already not playing by the rules.
  9. Robert Sparks: Comment [2012-04-23]:
    This is a very clear and helpful document. Thank you for making the effort to
    assemble it.
    
    Greylisting has been widely deployed for several years, but a concise
    explanation of the concept and its consequences has been lacking - this will be
    a very good tool for administrators interacting with systems that are already
    greylisting as well as those that are just adopting the practice.
    
    I don't agree that this should be BCP - it seems a good candidate for re-review
    and progression on the standards ladder.
    
    (Updating the comment with this question/suggestion:)
    
    In the second paragraph of section 3, consider pointing to the sentence in
    section 2.1 of RFC5321 that says
    "SMTP clients that transfer all traffic
    regardless of the
       target domains associated with the individual messages, or
    that do
       not maintain queues for retrying message transmissions that initially
    cannot be completed, may otherwise conform to this specification but
       are not
    considered fully-capable." 
    and say more strongly here that the agent receiving
    this retry response can't distinguish this condition from a disk full or other
    temporary condition making the receiver unable to accept where the sender really
    has no business knowing the reason why it's being told to re-try with a
    400-level response
  10. Martin Stiemerling: Discuss [2012-04-24]:
    Section 5. point 2: The minimum default window is one minute. This seems to be
    rather short in respect of clock skew between different hosts and when messages
    are re-scheduled for delivery on hosts. Has this been tested/checked in real
    deployments.
    
    One example:
    This can be troublesome if the SMTP server which does the
    greylisting is +30 seconds off and the other end is off by -30 seconds. The
    other end will re-send the message just too late.
    
  11. Martin Stiemerling: Comment [2012-04-23]:
    - Section 1:
    "this can justify providing degraded service, until there is a
    basis 
       for provider better service."
    I cannot parse the 'provider better
    service'.
    - Section 5:
    The text before the list of practices says those items
    are RECOMMENDED, but a number of items is about SHOULD and SHOULD NOT. Not a big
    issues, but logically not clean, i.e., are they RECOMMENDED or does SHOULD
    apply. Probably, it might be good to have two lists, one for  RECOMMENDED and
    the other for the SHOULDs.

draft-ietf-sipcore-rfc3265bis

  1. Ralph Droms: Discuss [2012-04-26]:
    This DISCUSS position does not require any immediate action on the
    part of the authors. 
    
    I have an issue with the state diagram in section 4.1.2 that I would
    like to
    discuss.  In general, I/ve found it important to take care with state diagrams
    in protocol specifications to ensure that the state diagram is
    correct and,
    unless otherwise indicated, complete.  I apologize for
    not having the time to
    work through the entire state diagram for
    correctness; I did notice that section
    4.1.2.2 includes a message
    exchange - which, admittedly, does not result in a
    state change - that
    is not reflected in the state diagram.
    
    My suggestion would be to add a disclaimer to the effect that the
    state diagram is not normative and that there may be aspects of the
    protocol behavior that are not reflected in the statae diagram.  I'm
    open to discussion of this suggestion.
    
  2. Adrian Farrel: Comment [2012-04-26]:
    Thanks for the detailed list of changes from 3265.
    
    ---
    
    Does this also update 3261?
  3. Stephen Farrell: Comment [2012-04-25]:
    Clarified my questions in a call with Robert. Be nice if we can document
    the reality sometime soon but this isn't the place to do it.
  4. Russ Housley: Discuss [2012-04-25]:
    
      The Gen-ART Review by Alexey Melnikov on 10-Apr-2012 started a
      discussion that has not yet reached closure.  At least 3 issues
      need to be resolved:
    
      (1)  Section 7.2 defines "reason" codes for use in the "Subscription-
      State" header field, and new reason codes require a Standards Action.
      This prevents registration of new Reason Codes in Experimental RFC.
      Please double check that that is intentional.
    
      (2) IANA reason code registrations require a reference to a published
      document which describes the event package.  Insertion of such values
      takes place as part of the RFC publication process or as the result of
      "inter-SDO liaison activity."  However, Standards Action is not
      appropriate since other SDOs do not publish Standard Track RFCs.
    
      (3) Ordering of template packages needs to be explained.
    
  5. Barry Leiba: Comment [2012-04-25]:
    Many thanks to Paul for an excellent and thorough PROTO writeup.  A note here:
    the IPR and copyright stuff you note from the nits checklist is just the
    boilerplate that's automatically put in by xml2rfc (or manually put in
    otherwise; it's correct in this document).  We should update the checklist to
    have current references, and to reflect the current position of that boilerplate
    in the documents.
    
    I also really like the "SHOULD" note in Section 1.2.
    
    On the IANA Considerations, thanks for retaining the context here, so the
    original document can be properly obsoleted.  One suggestion:
    
    In the base section 7:
    OLD
       (This section is not applicable until this document is published as
       an RFC.)
    NEW
       The subsections here are for current reference, carried over from
       the original specification.  The only IANA action requested here is
       to change all registry references that point to RFC 3265, and have
       them point to this RFC.
    
    ...or some such text, so that the registries now cite the new document.
  6. Pete Resnick: Comment [2012-04-25]:
    This is an incredibly well-written protocol document, and so clear that I'm fine
    with a Yes ballot.
    
    I can't convince myself any of these comments are DISCUSSion worthy, but I do
    think they all need addressing one way or the other.
    
    1.2
    
       It is inappropriate to fail to comply with
       "SHOULD"-strength requirements whimsically or for ease of
       implementation.
    
    I think that can be strengthened: "It is violation of a requirement of the
    specification to fail to comply with 'SHOULD' requirements whimsically or for
    ease of implementation."
    
    3.1.1
    
    Here and elsewhere, you say that something "MUST be defined by the event
    package". That's an odd use of MUST, since it's clearly not a protocol
    requirement for the implementer of the protocol, but rather a requirement for
    the protocol extension writer. I can see saying that "event packages will make
    such-and-so REQUIRED" to put implementers on notice that they will find the
    requirement in the event package, but I do wish you had a non-2119 way of
    expressing requirements for event package writers.
    
       A natural consequence of this scheme is that a SUBSCRIBE request with
       an "Expires" of 0 constitutes a request to unsubscribe from an event.
    
    Maybe this is obvious and implicit for someone familiar with SIP, but you do
    mean "a SUBSCRIBE request *on the same dialog* with an 'Expires' of 0", right?
    You don't actually get to the fact that a SUBSCRIBE is dialog-creating until
    4.1.2.1, but I think you can still make it clear here. Or you can just skip it,
    since it's covered in 4.1.2.3.
    
    4.1.2.1
    
       The "Expires" header field in a 200-class response to SUBSCRIBE
       request indicates the actual duration for which the subscription will
       remain active (unless refreshed).
    
    This implies to me (though it's not stated explicitly here) that the response
    MAY have a different Expires value than provided in the request. Is that true?
    You say something about this in 4.2.14, but not here.
    
    4.1.3 For 'probation', you say "the client SHOULD retry at a later time". Is
    that really what you mean? What harm comes to me if I decide not to retry?
    Couldn't I decide to not retry? Do you mean "MAY retry at a later time", or
    perhaps "SHOULD NOT retry immediately". Some piece of information is missing
    here. I suspect this has some parallel to 'deactivitated' and migration, but I
    don't get it.
    
    4.2.1 Why the out clause for 3515? If it's causing problems, why not just say
    MUST NOT and update 3515 to deprecate the use?
    
    4.2.2 Seems to me that if a NOTIFY receives a failure response and the
    subscription is therefore removed, the notifier should *not* send an additional
    'terminated' NOTIFY. But the state machine seems to indicate that it should. Was
    that the intention?
    
    4.5.2 Dialog sharing seems like a mess. Why is this not a SHOULD NOT?
    
    5 Generally: It seems like this entire section might work better as an appendix.
    It's not part of the protocol per se; it's extension documentation instructions.
    Also, the 2119 language in this section seems weird, especially in 5.4.1 and
    5.4.12. Those seem like inappropriate uses of 2119. The only one I can make a
    case for is the one in 5.3.2, and even there I'm not convinced. (I notice that
    for some reason you *didn't* use 2119 language in 5.4.6 and 5.4.7, and *never*
    used MAY in this section.) Again, it would be nice if you could find a better
    way to express this. I'm not convinced 2119 is useful or appropriate here.
    
    7.1 2119 language in IANA Considerations sections always worry me. When you say,
    "Registrations with the IANA MUST include...", are you putting a requirement on
    IANA? On the Expert Reviewer? I would rather see these removed and instead
    indicate that it is "required information in the template" or something like
    that.
    
    7.1.1 s/initial IANA registration for event types will be empty/initial IANA
    registry for event types will be empty
    
    7.2 Why is "Standards Action" required for this?
    
    8.4
    
       token-nodot       =  1*( alphanum / "-"  / "!" / "%" / "*"
                                / "_" / "+" / "`" / "'" / "~" )
    
    Do you really want to allow "...---..."? Are you sure you don't want:
    
       token-nodot       =  alphanum *( ( "-"  / "!" / "%" / "*"
                                / "_" / "+" / "`" / "'" / "~" ) alphanum )
    
    instead?
  7. Martin Stiemerling: Comment [2012-04-23]:
    Section 4.1.2.4., paragraph 4:
    
    >    Due to the potential for both out-of-order messages and forking, the
    >    subscriber MUST be prepared to receive NOTIFY requests before the
    >    SUBSCRIBE transaction has completed.
    
    + packet loss which can also lead to NOTIFY requests arriving before the
    SUBSCRIBE transaction to be completed.

draft-ietf-netmod-smi-yang

  1. Adrian Farrel: Comment [2012-04-25]:
    I found the text "config false" a bit out of context. Can you provide 
    some explanation?
  2. Stephen Farrell: Comment [2012-04-24]:
    Just wanna check two things, they're probably ok already
    though...
    
    1. An ASN.1 INTEGER can be multi-precision (e.g. 2048 bits). Not sure
    if that's allowed in SMIv2 but if so, worth a mention? Section 2
    implies 32 bits is enough.  
    
    2. OID arcs can similarly be >32 bits long so if those were just
    mapped to 32 bit values that'd be bad.
  3. Sean Turner: Comment [2012-04-25]:
    s4.2: Is it worth having a default yang statement added to all converted MIBs
    that says this module was converted from SMIv2 to YANG using RFC X?  Maybe it's
    called conversion?

draft-ietf-krb-wg-des-die-die-die

  1. Adrian Farrel: Comment [2012-04-26]:
    I cleared my Discuss after a conversation with the AD and WG chair on the
    understanding that they will close the loop with the WG on whether the code
    points in any IANA registries should be deprecated.
  2. Brian Haberman: Comment [2012-04-17]:
    I am glad to see this draft and it is well-written.
    
    I am curious as to why the recommendation is limited to SHOULD NOTs and not
    MUSTs.  Are there reasons to allow this wiggle room?  If so, it would be good to
    give an example in the draft.
  3. Pete Resnick: Discuss [2012-04-25]:
    [Thanks for addressing my other DISCUSS comments]
    
    I do want to make sure that we send the right announcement for both this
    document *and* the moving of 1510 to Historic. I'm just leaving this DISCUSS
    point as a placeholder until we figure out how to do that.
    
  4. Pete Resnick: Comment [2012-04-25]:
    I am not entirely clear why this is a BCP and not part of the standards track
    specification of Kerberos. This is a change to a protocol and therefore part of
    a technical specification, not a policy or operational guideline.
  5. Robert Sparks: Comment [2012-04-24]:
    Like Pete, I don't understand why this should be published as a BCP (I support
    that portion of his DISCUSS).
  6. Martin Stiemerling: Comment [2012-04-22]:
    This draft does not update RFC 1510 but aims to obsolete it , i.e. the header of
    the draft is not correct:
    "Updates: 1510, 1964, 4120, 4121, 4757"
    
    However, Pete's discuss covers this already.
  7. Sean Turner: Comment [2012-04-17]:
    Finally!

draft-ietf-appsawg-xdash

  1. Ralph Droms: Comment [2012-03-12]:
    This text:
    
    2.  Recommendations for Implementers of Application Protocols
    
       Implementers of application protocols MUST NOT treat the general
       categories of "standard" and "non-standard" parameters in
       programatically different ways within their applications.
    
    while probably not harmful, is sufficiently vague and refers to
    undefined terms in a way as to contribute, perhaps, more confusion
    than value.

draft-dbider-sha2-mac-for-ssh

  1. Adrian Farrel: Comment [2012-04-25]:
    Congratulations! Shortest I-D on the telechat.
    
    I have no objection to the publiscation of this document and just two
    small nits.
    
    ---
    
    It doesn't really work to use RFC 2119 language in the Abstract.
    
    ---
    
    Section 2
    
       This memo adopts the style and conventions of [RFC4253] in defining
       new data integrity algorithms.
    
       The following new data integrity algorithms are defined:
    
    I dare say I am overly pedantic, but I don't think the algorithms are
    actually defined here, just the identifiers for the algorithms.
  2. Stephen Farrell: Discuss [2012-04-23]:
    - I'd like to see the -96 bit truncated variants
      disappear as per previous comments. I believe the
      authors are ok with that so this is just so's we all
      remember to do that.
    

draft-ietf-ecrit-lost-sync

  1. Adrian Farrel: Comment [2012-04-25]:
    I see from the charter that this I-D was planned as Experimental.
    Although it is in no way a requirement for publication, I would really
    like this document to provide some explanation as to why it is targeted
    as Experimental. I would also like to see some parameters of the 
    "experiment" - what is the scope? how does the experiment need to be
    contained? what feedback are the authors/WG looking for from 
    experimenters? how will the experiment be judged a success?
  2. Stephen Farrell: Comment [2012-04-25]:
    - typo: singed mappings
    
    - what TLS authentication is required if any? Are anon 
    ciphersuites ok or not? Is TLS mutual auth required or
    not? Be good to say either way.
    
    - Is there any requirement that the TLS server/client 
    certs map to anything associated with the service (e.g.
    its DNS name) or with anything in the payload? Again
    be good to say either way.
    
    - Maybe this is my ignorance of LoST and Relax NG, but
    where do the <Signature> elements go in this protocol
    and what elements are required to be signed?
  3. Brian Haberman: Comment [2012-04-24]:
    I agree with Pete's feedback that there is a significant amount of fluff in this
    document that is not needed.
    
    Other comments:
    
    1. The second paragraph of section 4.2 states: "A newly received mapping MUST
    update an existing one having the same 'source' and 'sourceID' and a more recent
    time in 'lastUpdated'.  That seems rather confusing sentence structure, so I
    would recommend something like: "If a newly received mapping has a more recent
    time in its 'lastUpdated' attribute, it MUST update an existing mapping that has
    matching 'source' and 'sourceID' attributes.".
    
    2. In section 4.1 (2nd paragraph) : s/SHOULD keep track to/SHOULD keep track
    of/.
    
    3. Second sentence of section 4.3 should start with "Imagine" rather than
    "Image".
  4. Russ Housley: Comment [2012-04-25]:
      Please consider the editorial comments from the Gen-ART Review by
      Wassim Haddad on 24-Apr-2012:
      - Perhaps I missed it somewhere in the document, but I could not find
        the meaning of "ESRPs" (page 5)
      - Suggest re-writing the last paragraph on page 8 
      - Suggest re-writing the 3-line paragraph on page 9
  5. Barry Leiba: Comment [2012-04-25]:
    Some minor, non-blocking comments:
    
    -- Section 7 --
    
    Are there any ways to encounter or avoid synchronization loops other than what
    you say in the first two paragraphs here?  What happens if a buggy node always
    modifies "last updated" to the current time before relaying a mapping?  Would
    there be any way to stop a loop?
    
    It's more than a typo that singes things; this sentence is hard to read:
    OLD
       With
       digitially singed mappings mappings cannot be modified by
       intermediate LoST servers.
    NEW
       When
       mappings are digitially signed, they cannot be modified by
       intermediate LoST servers.
    
    -- Section 8 --
    
    Just noting that the second paragraph seems oddly familiar......
    :-)
    
    -- Section 9.1 --
    
    The title and the first sentence each use different terms for what we now prefer
    to call "Media Type".  It's not a big deal, but you might please switch to that
    term.
    
    -- Sections 9.2 and 9.3 --
    
    IANA probably knows where you're registering these, but I don't, and I'm always
    worried about registration errors.  I suppose as long as it's clear to IANA,
    it's OK... but can you specify exactly what registries (using the exact names
    and perhaps URLs, from https://www.iana.org/protocols/ ) you mean?
  6. Pete Resnick: Discuss [2012-04-23]:
    Section 9.1:
    
    The ietf-types review pointed out specific language from RFC 3023 section 7.1
    that should be used in the registration of application/lostsync+xml. Please fix:
    
       Optional parameters:  charset
    
          Indicates the character encoding of enclosed XML.
    
    Replace with "Same as charset parameter of application/xml as specified in RFC
    3023."
    
  7. Pete Resnick: Comment [2012-04-23]:
    [Just a reminder: None of the following cause me as an AD to hold up publication
    of the document. They are just the (sometimes strongly held and expressed)
    beliefs of yet another bozo in the IETF community. Take them as such.]
    
    Section 1:
    
    This is supposed to be a technical specification, not an academic paper. I find
    the 6 pages of fluff in the introduction to be useless and distracting to the
    reader. It is poorly written and never actually describes the purpose of the
    document. I have to wait until the first full paragraph of page 8 to see:
    
       This document defines two types of exchanges and those are best
       described by the exchange between two nodes as shown in Figure 5 and
       Figure 6.
    
    Don't explain by pointing me to diagrams and examples. Explain in words. I think
    this section should be completely rewritten and reduced to 2 paragraphs. The
    current introduction diminishes the document.
    
    Section 4.1:
    
       The LoST Sync source SHOULD keep track to which LoST Sync destination
       it has pushed mapping elements.  If it does not keep state
       information then it always has to push the complete data set.
    
    In the first two sentences, do you really mean:
    
       The LoST Sync source SHOULD only push new mapping elements which it
       has not previously pushed to the LoST Sync destination.
    
    Your current text is making a requirement about internal state of the
    implementation. What I have above is a protocol requirement. I think that's what
    you meant. You continue:
    
       As discussed in Section 5.1 of [RFC5222], mapping elements are
       identified by the 'source', 'sourceID' and 'lastUpdated' attributes.
       A mapping is considered the same if these three attributes match.  It
       is RECOMMENDED not to push the same information to the same peer more
       than once.
    
    So, I must ask why is RECOMMENDED not to push the same information to the same
    peer? Is it simply bandwidth considerations? Or processing on the peer? Why the
    2119 imperative?
    
       A <pushMappings> request sent by a LoST Sync source MUST containing
       one or more <mapping> elements.
    
    Do you mean, "A <pushMappings> request sent by a LoST Sync source MUST contain
    at least one or more <mapping> elements" or "MUST NOT be empty" or something
    like that? What is the requirement here? What are you trying to prevent?
    
    Section 4.2:
    
       A newly received mapping MUST update an existing one having the same
       'source' and 'sourceId' and a more recent time in 'lastUpdated'.
    
    Again, what's the protocol requirement here that requires the 2119 imperatives?
    Don't you really mean, "A newly received mapping that has the same 'source' and
    'sourceID' as a previous mapping with a more recent 'lastUpdated' time is an
    update to the existing mapping."?
    
    Similarly:
    
       If the received mapping does not match with any existing mapping
       based on the 'source' and 'sourceId' then it MUST be added to the
       local cache as an independent mapping.
    
    "Otherwise, it is a new independent mapping." Again, what bad behavior are you
    trying to prevent with the "MUST"?
    
    Section 5:
    
       This document uses HTTPS as a transport to exchange XML documents.
    
    No it doesn't. There is nothing in this document concerning the use of HTTPS or
    any other transport protocol. I don't even think the document "assumes" the use
    of HTTPS. I think this section can be struck from the document without any harm.
    
    Section 9.1:
    
    The ietf-types review pointed out specific language from RFC 3023 section 7.1
    that should be used in the registration of application/lostsync+xml.
    
       Encoding considerations:  Identical to those of "application/xml" as
          described in [RFC3023], Section 3.2.
    
    Not that it makes a real difference, but you might as well replace with "Same as
    encoding considerations of application/xml as specified in RFC 3023" to keep it
    consistent with the precise language of 3023.
  8. Sean Turner: Comment [2012-04-25]:
    I echo Stephen's comments.
    
    s5: Not sure if it's worth it but maybe mentioning that only offering HTTPS is
    different than RFC 5222 because it offers HTTP as well.  Maybe saying because
    this is exchanging authoritative data it's inappropriate to use HTTP?  Maybe you
    could do this in the 1st paragraph of the security considerations:
    
      Hence, the protocol operations described in
      this document require authentication of neighboring nodes,
      which is why HTTPS is required.

draft-ietf-pkix-pubkey-caps

  1. Adrian Farrel: Comment [2012-04-25]:
    I am balloting No Objection on the assumption that the Security ADs
    are on top of this work.
    
    I do have a few nits I noticed along the way.
    
    ---
    
    Abstract
    
    s/define/defined/
    
    ---
    
    Please expand acronyms not marked with an asterisk in 
    http://www.rfc-editor.org/rfc-style-guide/abbrev.expansion.txt
    
    ---
    
    Section 1
    
    OLD
       but we did not currently have any way of
       doing so at the current time.
    NEW
       but we did not have any way of doing so.
    END
    
    ---
    
    Section 1
    
    s/structure need/structure needs/
  2. Stephen Farrell: Comment [2012-04-24]:
    - I thought S/MIME capabilities were to allow a sender to
    know what a receiver wanted/could handle, this says it the
    other way around.
    
    - 1 s/need to be/needs to be/ in last para before 1.1
  3. Russ Housley: Discuss [2012-04-24]:
    
      The appendix includes TBD values that need to be assigned.
    
  4. Russ Housley: Comment [2012-04-24]:
      Please reword the last sentence of the Abstract.  It says:
      >
      > An example of where this is used is with the OCSP Agility draft.
      >
      Can this be worded in a way that points to an RFC?  If not, can it be
      worded in a way that does not use "draft"?
    
      Section 2.1 says:
      >
      >       RSAKeySize ::= INTEGER (1024 | 2048 | 3072 | 7680 | 15360 |
      >                            4096 | 8192, ...)
      >
      The integer values appear in a surprising order.  While this will not
      impact code or interoperability, why not put them in ascending order?
    
      Should the capabilities in section 3.1 provide an optional way to
      specify sizes of P, Q, and G that are supported?
    
      Similarly, should the capabilities in section 3.2 provide an optional
      way to specify sizes of P and G that are supported?
    
      In Section 4.1 and 4.2 and 4.3, I suggest a list of named curves
      instead of the very rich structure that is currently specified.
      Several other documents have taken this approach.  Any popular curve
      can be assigned an object identifier to name it.
    
      In addition to my comments above, please consider the comments from
      the Gen-ART Review by Mary Barnes on 23-Apr-2012.  The review can be
      found here:
      http://www.ietf.org/mail-archive/web/gen-art/current/msg07383.html
  5. Barry Leiba: Comment [2012-04-24]:
    [Update: the -05 version addresses all my substantive comments.]

draft-templin-aero

  1. Ronald Bonica: Discuss [2012-04-25]:
    - It is impossible to evaluate this draft without more detail regarding the
    operational scenario in which it is to be deployed. If the reference scenario
    described in Section 4.3 were deployed by devices and links contained within a
    single campus, one might ask why the problem could not be solved by running an
    IGP on Routers A, B and D and by putting Host F behind a router.
    
    - This draft appears to use ICMP as a routing protocol. However, ICMP does not
    have all of the capabilities required by a routing protocol. You might want to
    explore the this issue in the next version of this draft.
    
    - The approach used in this draft seems to contradict the following statement
    from RFC 1812:
    
    "A router using a routing protocol (other than static routes) MUST NOT consider
    paths learned from ICMP Redirects when forwarding a packet. If a router is not
    using a routing protocol, a router MAY have a configuration that, if set, allows
    the router to consider routes learned through ICMP Redirects when forwarding
    packets."
    
    - Beyond these, there are many other comments. For example, Stephen's question
    regarding authentication is telling. However, it may not be worth discussing
    these until we understand the problem that you are really trying to solve.
    
  2. Benoit Claise: Comment [2012-04-26]:
    Looking at the number of DISCUSS already, I would prefer to wait for the next
    version of the draft before reviewing the document in details. By spending 15
    minutes on the draft, I have some questions already. Therefore, I reserve the
    option to come back and potential add a DISCUSS on the next document version.
  3. Ralph Droms: Discuss [2012-04-24]:
    1. In this text from the Introduction:
    
       For example, when an ingress link neighbor accepts an ordinary
       redirect message, it has no way of knowing whether the egress link
       neighbor is ready and willing to accept packets directly without
       involving an intermediate router.
    
    I don't think I see any description of a way for the egress node to
    explicitly notify the ingress node, either directly or through the
    intermediate node, that the egress node is unwilling "to accept
    packets directly", nor do I see how the intermediate node reacts to a
    NAK from the egress node.
    
    2. Also in the text cited in point 1, I don't see any support for the
    assertion that an intermediate router is required.  Isn't that what
    routing protocols do?
    
    On re-reading that text, I realize I may be confused: does "without
    involving an intermediate router" mean:
    
    a) the ingress node needs an intermediate router to learn whether the
    egress nodes will accept traffic from the ingress node or
    b) the egress node will not accept traffic directly from the ingress
    node but it will accept traffic forwarded from the ingress node
    forwarded through the intermediate node?
    
    3. Do I have it right in section 4.4.7 that the Redirect response from
    D is sent to L3(B) (i.e., unicast to the ingress node), but the
    intermediate node A snoops that Redirect message and verifies the
    contents in various ways before forwarding it to B?  And then it
    doesn't decrement the hopcount?  Why are these exceptional forwarding
    rules necessary?  Can't D send the Redirect to A, and then A send a
    corresponding Redirect to B?
    
    4. Section 4.4.5 specifies that the AERO Predirect/Redirect message
    will use type 100, while Figure 4 shows the use of type 137. I include
    this as a DISCUSS point because Figure 4 needs to be fixed to show
    type 100 before the document is published to avoid problems with the
    existing ICMP Redirect message.
    
  4. Ralph Droms: Comment [2012-04-24]:
    1. The document has many details about the operations of the various
    AERO nodes that are not germane to the specification of AERO.  I would
    suggest editing out all of the provisioning and initialization details
    in, e.g., section 4.3, and simply describe the state of the various
    AERO nodes at the time of AERO operation.
    
    2. In section 4.4.11, what prevents A from invoking the
    Predirect/Redirect mechanism for each datagram received from B
    destined for D, even if B has determined that B cannot send directly
    to D?
    
    3. In the Security Considerations section, how does an Aero edge node
    know to trust an AERO intermediate router that advertises itself?  I
    think the digital signature mechanism needs to be explored in more
    detail or data authentication more generally needs to be left for
    future work.
  5. Adrian Farrel: Discuss [2012-04-25]:
    It is entirely unclear to me what real problem this work is designed to 
    solve.
    
    It is clear that it is possible to construct a network where "triangular
    paths" could exist and where redirection can help resolve the issues.
    
    Only one brief paragraph is given to explain why "ordinary redirection
    may lead to operational issues on certain link types and/or in certain
    deployment scenarios" and it is unclear to me whether this represents a
    real problem. It would appear that the issue can arrise when the multi-
    access link has very large numbers of hosts and very large numbers of 
    routers on the same link. Is this realistic? Do we not find this type
    of deployment in the wild because of these problems or because that is
    simply not how networks are usually built? 
    
    So I would like to see several things called out more explicitly:
    
    - What are the deployments that motivate this work?
    
    - Is the model here that the Aero Edge Routers are acting as "PEs" in
      a sort of VPN like model?
    
    - What sort of scaling numbers are to be considered?
    
    - What are the operational problems with existing solutions and why
      can they not be solved using pre-existing protocol solutions?
    
    - Would the problem not exist if all nodes on the link were routers
      or if nearly all (i.e. except for a default and alternate router)
      were hosts?
    
    - How come spoofing of redirects is given as a motivation for this
      work yet called out as a security issue for Aero with a remediation   
      offered that could be applied today? 
    
    Other than that, I feel that there are so many significant changes 
    needed to address the many Discusses already raised that I am cautious
    about drawing a line under my review and reserve the option to come back
    and add to my Discuss when a future version has been published. I hope
    the sponsoring AD will put the document back on a future telechat after
    it has been updated.
    
  6. Adrian Farrel: Comment [2012-04-25]:
    In Figure 5, I assume that nodes B and F are actually routers (i.e. AERO
    edge routers) since they provide acceess to hosts through IP clouds.
  7. Stephen Farrell: Discuss [2012-04-25]:
    (1) 4.4.4 - I don't get the origin authentication check, you
    say that the source address is correct if a list of 4 things are ok,
    but then later that only one of them needs to be ok. Which is it?  The
    latter case (any of the 4) seems broken since the 3rd bullet is just
    the easily spoofed MAC address. The last paragraph here is also
    odd, the two sentences seem to contradict one another.
    
    (2) the signature scheme in 4.4.4 is undefined, you need to either
    define it, or else fess up and say that there's no current scheme
    and AERO just depends on things that are easily forged and strong
    data origin authentication is for future work. (I'd be ok with
    the latter for an experimental draft like this I think.)
    section 3: no security requirements for strong authentication?
    
  8. Stephen Farrell: Comment [2012-04-25]:
    FWIW, I agree with a bunch of the the other discusses on this.
  9. Brian Haberman: Discuss [2012-04-24]:
    I am editing my DISCUSS points in order focus on the issues that still need
    resolving.  Since a new document is not available, I have marked each point with
    the state I think they are in...
    
    This document is going to require some true DISCUSSion in order to resolve some
    obvious issues.
    
    1. If this draft goes forward as Experimental, it needs more justification.
    What issues with AERO make it unsuitable for use on the Internet as a whole?
    What network characteristics are required to assess AERO's behavior?  What
    issues will arise if non-AERO and AERO-capable nodes attempt to interact?  Is
    AERO truly suitable for any multi-access network?
    
    2. From the author, my understanding is that an AERO edge router will have a set
    of ACLs that only allow traffic to be forwarded to it that comes from its
    default router (router D only forwards traffic from router A by default). That
    implies that router D must trust the MAC-level information (e.g., src MAC
    address) contained in a forwarded frame.  How is that accomplished?  In general,
    multi-access networks require specific MAC-level functions to do that.
    Discussion of these issues and how they relate to the AERO messages is needed.
    
    3. [Resolved pending a new version] Section 4.2.2 specifies AERO host behavior.
    Since that behavior does not differ from standard IPv6 host behavior defined in
    RFC 4861 and RFC 4862, what is the purpose?  *IF* you need to say anything about
    host behavior, state that it acts as an IPv6 host (as defined in RFCs 4861,
    4862, and 6434).
    
    4.[Resolved pending a new version] Do AERO edge routers (Section 4.2.3) differ
    from the CPE routers defined in RFC 6204 (other than the added AERO
    functionality)?  It appears that they should, but it is not specifically called
    out.
    
    5.[Modified] I find the claim (section 4.4.1) that "...the ingress node has no
    way of knowing whether the egress is willing to accept its packets, ..." dubious
    at best. These packets are being transmitted as IP datagrams, which are best
    effort.  It is not the job of layer-3 to build reliability into the packet
    forwarding paradigm.
    
    6. [Resolved] Section 4.4.5 re-defines the structure of the ICMPv6 Redirect
    message by adding new bit fields.  Given that, why does the document not list
    itself as updating RFC 4861?  If that is the case, this change needs to be
    reviewed by the 6MAN working group.
    
    7. [Modified] Sections 4.4.10-12 have convinced me that this specification is
    really a dynamic routing protocol using ICMPv6 Redirect (and the variant
    Predirect) messages. The incorporation of mobility concepts and periodic
    reachability logic makes this no different than existing MANET and scaled-down
    IGPs.  In this light, the document does not clearly explain key functional
    behaviors or why those behaviors are not needed. In order to address these
    concerns, more detail is needed (per Russ' DISCUSS) on exactly what link types
    AERO is expected to work under.  Single-link behavior for something like
    Ethernet does not make sense in the context of AERO.
    
  10. Brian Haberman: Comment [2012-04-24]:
    1. [Resolved pending a new version] Section 4.2.2 states that the egress AERO
    router sends a Redirect message to the intermediate AERO router who then proxies
    that Redirect to the ingress AERO router. It would be good to include a forward
    pointer to sections 4.4.7 and 4.4.8 since that is where the sending and redirect
    rules are defined.
    
    2. [Resolved pending a new version] The Acknowledgments section seems to have
    been truncated.
  11. Russ Housley: Discuss [2012-04-24]:
    
      I understand that the AERO mechanisms were initially designed for NBMA
      tunnel virtual interfaces, but these mechanisms can also be applied to
      any multiple access link types that support redirection.  That said, I
      think we need to better characterize the environments where AERO is
      appropriate, and maybe even more importantly the environments where
      AERO is not appropriate.
    
      This position seems to be supported by the Gen-ART Review by
      Pete McCann on 24-Apr-2012.  Please consider the other comments that
      are include in this review.  The review can be found at:
      http://www.ietf.org/mail-archive/web/gen-art/current/msg07385.html
    
  12. Barry Leiba: Comment [2012-04-25]:
    Lots of DISCUSS positions already, and I don't have anything new to add.  I'll
    just say that I support some of the other AD's DISCUSS positions, particularly
    Brian's and Ron's.
  13. Pete Resnick: Comment [2012-04-22]:
    I agree with Brian's DISCUSS regarding status. In fact, even Experimental seems
    a bit odd. The document doesn't describe the circumstances under which you would
    want to experiment and why you wouldn't want to let this out on the Internet as
    a proposed standard. I think some more explanation, and perhaps an adjustment to
    status, is needed.
  14. Martin Stiemerling: Comment [2012-04-25]:
    I'm supporting the other DISCUSSes which cover the issues of the draft.
  15. Sean Turner: Discuss [2012-04-25]:
    Hate to pile on but there were a number of agreed changes as a result of the
    secdir review.  This is just a placeholder discuss until fixes to those changes
    are agreed and incorporated.
    
  16. Sean Turner: Comment [2012-04-25]:
    I support the discusses from the other ADs.