IESG Narrative Minutes

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

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

Corrections from:

1 Administrivia

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

2 Protocol Actions

2.1 WG Submissions

2.1.1 New Item

  1. Asynchronous Layered Coding (ALC) Protocol Instantiation (Proposed Standard)
    draft-ietf-rmt-pi-alc-revised-09
    Token: Magnus Westerlund
    Note: WG Shepherd: Brian Adamson (adamson@itd.nrl.navy.mil)
    Discusses/comments (from ballot 2007):
    1. Pasi Eronen: Comment [2009-10-22]:
      The "Baseline Secure ALC Operation" (Section 5.1) seems very specific to some particular application (not clear what exactly), and probably wouldn't be very useful for most applications using ALC.
    2. Cullen Jennings: Discuss [2009-10-21]:
      My understanding is that there was IPR on 3450. Has this gone away somehow?
    3. Dan Romascanu: Discuss [2009-10-21]:
      1. This document updates RFC 3450 and moves it from Experimental to Proposed Standard. What is the rationale behind this move...
      2. How is this protocol deployed and managed?
    4. Dan Romascanu: Comment [2009-10-21]:
      The OPS-DIR review performed by Victor Fajardo raised a number of issues...

    Telechat:

  2. Certificate Management Service for The Session Initiation Protocol (SIP) (Proposed Standard)
    draft-ietf-sip-certs-09
    Token: Robert Sparks
    Discusses/comments (from ballot 2752):
    1. Lars Eggert: Discuss [2009-10-16]:
      Downref
    2. Lars Eggert: Comment [2009-10-16]:
      How many stacks are really going to support this "upconversion" to TCP? I was under the impression that TCP support wasn't really there?
    3. Pasi Eronen: Discuss [2009-10-22]:
      In Section 7.10, why is the credential service required to check that one of the SubjectAltNames matches the authorized user...
    4. Alexey Melnikov: Discuss [2009-10-17]:
      1. Is there any work on defining channel bindings for use in SIP?
      2. I think In Section 6.2 needs a normative reference to RFC 5234
      3. Question: does the Accept header field body contains "multipart/mixed" or "application/pkcs8"?
      4. are there any useful checks that can be performed to see if the application/pkix-cert body part matches information in the application/pkcs8 body part?
      5. Section 9.5: Credential services... I can't parse this sentence.
    5. Alexey Melnikov: Comment [2009-10-17]:
      "Certificates" definition strange
      Nice to state assumption that there is only one certificate per user at any given time earlier in the document
      I think an Informative reference to RFC 4086 would be appropriate
      which document defines the "state agent" term?
      ...
    6. Tim Polk: Discuss [2009-10-22]:
      the mechanisms for use with certificates from trusted third parties are under-specified so an implementer would not know how or where to integrate these tools into a product if they are available and the additional security is desired.
      I would like to see an additional section in the security considerations section that explains the incremental improvement in security provided by validating the chain of certificates associated with the user's third party certificate, pointing to RFC 5280.

    Telechat:

  3. Distribution of EAP based keys for handover and re-authentication (Proposed Standard)
    draft-ietf-hokey-key-mgm-09
    Token: Tim Polk
    Note: Glen Zorn (gwz@net-zen.net) is the document shepherd.
    IPR: Huawei Technologies Co., Ltd. 's Statement about IPR related to draft-ietf-hokey-key-mgm-00
    Discusses/comments (from ballot 3166):
    1. Jari Arkko: Discuss [2009-10-22]:
      if there are missing things, why is this a proposed standard?
    2. Pasi Eronen: Discuss [2009-10-22]:
      - After reading the abstract... I was expecting that this document would define a protocol... But the document never does that...
      - Since you cannot actually implement this document (and thus can't have two interoperable implementations), does it even belong on Standards Track?
      - Section 5 has a MUST-level requirement that's probably a leftover...
    3. Adrian Farrel: Comment [2009-10-20]:
      AAA is not an RFC Editor "well-known" abbrevation, and should be expanded...
    4. Russ Housley: Comment [2009-10-20]:
      In the Gen-ART Review by Francis Dupont on 2009-07-30, it was suggested...
    5. Alexey Melnikov: Comment [2009-10-17]:
      2 references don't look like Normative references
    6. Dan Romascanu: Comment [2009-10-21]:
      I actually am quite confortable with this document being approved as PS, because it does define a mechanism that involves interoperability on the wire. It would be good however for the IESG to consider again this issue before approval.

    Telechat:

  4. The SDP (Session Description Protocol) Grouping Framework (Proposed Standard)
    draft-ietf-mmusic-rfc3388bis-03
    Token: Cullen Jennings
    Note: Joerg Ott (jo@netlab.tkk.fi) is the document shepherd
    Discusses/comments (from ballot 3170):
    1. Adrian Farrel: Discuss [2009-10-21]:
      The Abstract and the Introduction should note "This document obsoletes RFC 3388
      I think that in this revision of 3388, you shouldn't define the attributes defined (sections 4 and 5) as "new"
      Need to add a normative reference for the definition of the BNF
      Since you are obsoleting RFC 3388, presubaly you would like the registry created by RFC 3388 to be updated
    2. Russ Housley: Discuss [2009-10-20]:
      In the Gen-ART Review by Elwyn Davies on 17 October 2009, there was a question. I think the question deserves an answer.
    3. Alexey Melnikov: Discuss [2009-10-19]:
      In Section 4... I suspect you are using ABNF defined in RFC 5234, but this is not explicitly stated. This reference needs to be Normative.
      Also, you should clarify where <token> is defined.
      I didn't find <space> in RFC 4566. Should you just use SP or WSP instead?
      In general, I think it is wrong to point to an IANA registry established by a RFC obsoleted by the document.
    4. Alexey Melnikov: Comment [2009-10-19]:
      is there any interaction with draft-ietf-mmusic-sdp-capability-negotiation-10.txt here?
      9.1.1... is this done because of use in SIP, or because of mid mismatch in the 200 OK response?
    5. Dan Romascanu: Discuss [2009-10-21]:
      The authors fail to make a crisp statement that no backwards compatibility problems would appear.
    6. Dan Romascanu: Comment [2009-10-21]:
      The OPS-DIR review by Mehmet Ersue raised a couple of issues
      I support Alexey's DISCUSS at #3.
    7. Robert Sparks: Discuss [2009-10-21]:
      The example SDP at the top of page 11 (in version -03) should be double-checked to make sure the final c and m lines are in the intended order.
    8. Robert Sparks: Comment [2009-10-21]:
      There are uses of 2119 words to constrain other documents here that should be edited out

    Telechat:

  5. Fast Handovers for Proxy Mobile IPv6 (Proposed Standard)
    draft-ietf-mipshop-pfmipv6-09
    Token: Jari Arkko
    Note: Vijay Devarapalli (vijay@wichorus.com) is the document shepherd.
    Discusses/comments (from ballot 3175):
    1. Ralph Droms: Discuss [2009-10-20]:
      I'm not at all aure I could implement an interoperable protocol from this document.
    2. Ralph Droms: Comment [2009-10-20]:
      The requirements for functions in the MN and the access network to support "predictive handover" should be stated.
      How is predictive handover better than reactive handover?
    3. Lars Eggert: Discuss [2009-10-19]:
      Section 4.1., paragraph 1: How large is this buffer and at what rate is it being drained after the tunnel is up?
      Section 4.1., paragraph 42: [IPv4PMIPv6] and [GREKEY] need to be normative references.
    4. Pasi Eronen: Discuss [2009-10-19]:
      1) In several places, the document talks of "the interface identifier of the MN". Does this refer to the lower 64 bits of some IPv6 address used by the MN (and if so, which?
      2) in PMIPv6, a MN can have several HNPs
      3) draft has a normative downward reference that wasn't called out
      4) The references IPv4PMIPv6 and GREKEY look normative to me.
      5) The document should probably say something about how EnableMAGLocalRouting and the PAR<->NAR tunnel interact.
    5. Russ Housley: Discuss [2009-10-20]:
      In the Gen-ART Review by Francis Dupont on 2009-09-22, Francis said: "incredible painful to read..." A revised draft was produced in response to this comment; however, it has not been posted yet. What is the plan?
    6. Alexey Melnikov: Discuss [2009-10-06]:
      4.3. IPv4 Support Considerations: seems to suggest that the document is registering a new option with IANA, but section 6.2.7 says:... So is this a new option, or is this a reuse of existing option?
    7. Alexey Melnikov: Comment [2009-10-06]:
      "A new flag 'P' is defined for the HI and HAck messages" Does this need registering with IANA? Do you mean that this flag needs to be set in any message specified in this document?
      6.2.7. IPv4 Address Option: Does this need a new allocation from IANA?
      6.1.2. Handover Acknowledge (HAck): It would have been better if this was an IANA registry.
      6.2.1. Context Request Option: Can you please elaborate on what exactly this means?
      6.2.8. Vendor-Specific Mobility Option: I think it would be more correct to say that Vendor IDs are values are as specified in [RFC5094].

    Telechat:

  6. vCard Extensions to WebDAV (CardDAV) (Proposed Standard)
    draft-ietf-vcarddav-carddav-09
    Token: Alexey Melnikov
    Note: Due to WG chairs being busy I didn't get the write-up in time. (Chairs were happy for the document to be sent to IESG review though.)
    So I've decided to do the shepherding write-up myself. Note that security related comments from Brian Carpenter's GenArt review are addressed using RFC Editor notes.

    Discusses/comments (from ballot 3184):
    1. Lisa Dusseault: Comment [2009-10-21]:
      statelessness is a tradeoff...
      section 8.6.2, Server Error status code (507): Does this conflate two different cases that really should be treated separately?
    2. Lars Eggert: Discuss [2009-10-19]:
      Section 11., paragraph 2: There currently isn't a way to register only a service name with IANA without at the same time also registering a port number.
    3. Lars Eggert: Comment [2009-10-19]:
      Section 8.7.2., paragraph 7: I believe one of these "<D:response>" tags is superfluous.
      Section 14., paragraph 0: The service name registrations from Section 11 are missing.

    Telechat:

  7. BGP Encodings and Procedures for Multicast in MPLS/BGP IP VPNs (Proposed Standard)
    draft-ietf-l3vpn-2547bis-mcast-bgp-08
    Token: Ross Callon
    IPR: Juniper's Statement of IPR related to draft-ietf-l3vpn-2547bis-mcast-bgp-06
    Discusses/comments (from ballot 3190):
    1. Ross Callon: Discuss [2009-09-30]:
      [interoperability] issue is being addressed by draft-ietf-l3vpn-mvpn-considerations. I believe that this latter document is necessary, and that it would be a mistake to approve either this document or its companion document until draft-ietf-l3vpn-mvpn-considerations is submitted for publication.

    Telechat:

  8. Salted Challenge Response (SCRAM) SASL and GSS-API Mechanism (Proposed Standard)
    draft-ietf-sasl-scram-10
    Token: Pasi Eronen
    Note: Simon Josefsson (simon@josefsson.org) is the document shepherd
    Discusses/comments (from ballot 3203):
    1. Ralph Droms: Comment [2009-10-22]:
      Trivial editorial nit

    Telechat:

  9. Preliminary Evaluation of RFC 1652 for Advancement to Full Standard (Standard)
    draft-ietf-yam-rfc1652bis-pre-evaluation-00
    Token: Alexey Melnikov
    Note: This draft contains the list of changes planned by the YAM WG to move RFC 1652 to Full Standard. There is no intention to publish this document as an RFC, so IESG should vote on this document as if RFC 1652 is advancing to Full Standard.
    S Moonesamy <sm+ietf@elandsys.com> has agreed to serve as the document shepherd, but note that there is no shepherding write-up for this document.
    Discusses/comments (from ballot 3211):
    1. Ron Bonica: Discuss [2009-10-06]:
      Agree with Adrian. This seems more like a communication with the IESG than something that needs to be store in the RFC series for perpetuity.
    2. Ralph Droms: Discuss [2009-10-20]:
      we should be clear in our response that other changes may be found to be required during the usual document processing including IETF last call and IESG voting.
    3. Ralph Droms: Comment [2009-10-20]:
      procedurally, how will we prepare an IESG response?
    4. Lisa Dusseault: Discuss [2009-10-05]:
      One of the big questions discussed about whether older email standards could go to Full Standard was whether the security provisions were sufficient... this pre-eval document doesn't address that or or make the IESG think about that.
    5. Pasi Eronen: Comment [2009-10-05]:
      My "No Objection" vote here is not a guarantee that I can't change my mind after considering the community input.
    6. Adrian Farrel: Discuss [2009-09-29]:
      This seems like a really weird way to communicate with the IESG...
    7. Adrian Farrel: Comment [2009-09-29]:
      Section 2... may be an exageration.
    8. Russ Housley: Discuss [2009-10-02]:
      an agenda entry that indicates the document is moving to standard is misleading and confusing.
    9. Cullen Jennings: Discuss [2009-10-21]:
      [answered three questions]
    10. Tim Polk: Discuss [2009-10-07]:
      I also want to discuss the implications of moving a document with known security limitations to full standard.
    11. Tim Polk: Comment [2009-10-07]:
      [answered three questions] Any of those answers could be changed during IETF Last Call for 1652bis.
    12. Robert Sparks: Comment [2009-10-07]:
      I find using a draft to drive discussions like this a very useful technique. However, using the balloting/evaluation process this way is a poor fit to the tool and I strongly discourage taking this path again.
    13. Magnus Westerlund: Discuss [2009-10-22]:
      I still think this should be handled another way. A management item would have been more suitable. There is a clear difference between this investigating question and the formal decision that balloting on the actual document is.

    Telechat:

  10. Internet X.509 Public Key Infrastructure: Additional Algorithms and Identifiers for DSA and ECDSA (Proposed Standard)
    draft-ietf-pkix-sha2-dsa-ecdsa-10
    Token: Pasi Eronen
    Note: Document shepherd is Stephen Kent (WG chair).
    Discusses/comments (from ballot 3215):
    1. Lars Eggert: Comment [2009-10-16]:
      Agree with Alexey; document needs an "Updates: 3279" header.
    2. Alexey Melnikov: Discuss [2009-10-14]:
      the draft itself doesn't contain "Updates: RFC 3279".
    3. Alexey Melnikov: Comment [2009-10-14]:
      It would have been better if the document were using names in OIDs consistently.

    Telechat:

  11. Virtual Subnet Selection Options for DHCPv4 and DHCPv6 (Proposed Standard)
    draft-ietf-dhc-vpn-option-11
    Token: Ralph Droms
    Note: John Jason Brzozowski (john_brzozowski@cable.comcast.com) is the document shepherd.
    Discusses/comments (from ballot 3218):
    1. Jari Arkko: Discuss [2009-10-22]:
      ...message to the reader... should be that the mechanism defined in this document is very brittle.
      I believe a key use case is that the network handles the VPN selection and the clients are blissfully unaware of what is going on. This seems inconsistent with the requirement that the VPN information MUST be included in every message that the client sends.
      Make it clear what its limitations are with respect relays or clients using this option with a server that does not support the option in v4.
    2. Lars Eggert: Discuss [2009-10-16]:
      If I have a client that has a VPN link up, and it broadcasts a DHCP message on that link, the only way a DHCP relay or a DHCP server will see that message if they themselves are part of that virtual network. So why is there a need for an option to identify the virtual network?
    3. Adrian Farrel: Comment [2009-10-21]:
      Section 1: What is meant by "VSS option or sub-option"?
      Please be careful to be consistent about naming.
    4. Russ Housley: Comment [2009-10-21]:
      The Gen-ART Review by Spencer Dawkins on 2009-10-21 raised two questions about 2119 language...
    5. Alexey Melnikov: Comment [2009-10-15]:
      5. Relay Agent Behavior: Does this need to be a MUST?
      9. IANA Considerations: This is an interesting way of saying that new IANA registry is not needed, but then putting requirements on future documents if this registry established in the future. Is this text needed?
    6. Tim Polk: Discuss [2009-10-22]:
      Dave Harrington's secdir/opsdir review has not received a response...
    7. Tim Polk: Comment [2009-10-22]:
      I support Jari's discuss with respect to differentiating between relay and client behavior.
    8. Dan Romascanu: Discuss [2009-10-21]:
      1) The OPS-DIR reviews performed by Juergen Quittek and David Harrington raised a number of issues
      2) The IANA section unclear on whether it can or cannot be expanded in the future.
      3) It is not clear how these solutions will be configured.
    9. Dan Romascanu: Comment [2009-10-21]:
      1. The Terminology section defines upstream and downstream using terms that have not been defined. It is unclear to me whether access concentrator and subscriber are similar to server and client.
      2. In section 3.4, might it be better to declare 2-254 as reserved...
      3. In section 4, it says DHCP can assign the same IP address to nodes in a VPN and in the global IP space, because the address is qualified by the VPN. Is this always true?
      4. I think section 4 would benefit from sub-sections to separate the scenarios...
      5. Will legacy DHCP entities ignore the VSS option by default? ...
      6. In section 5, it says the relay SHOULD insert VSS information into requests from a client. What happens if the client has inserted a VSS option?
      etc... 21 items in all
    10. Magnus Westerlund: Comment [2009-10-22]:
      Support for Dan's discuss on clarifying how to handle unknown VSS Information formats.

    Telechat:

  12. An Inband Data Communication Network For the MPLS Transport Profile (Proposed Standard)
    draft-ietf-mpls-tp-gach-dcn-06
    Token: Ross Callon
    Note: Loa Andersson (loa@pi.nu) is the document shepherd.
    Discusses/comments (from ballot 3220):
    1. Pasi Eronen: Discuss [2009-10-22]:
      Normally, such a document would say something about MTUs/fragmentation, and for IPv6, interface identifiers, link-local addresses, the overall link model (point-to-point, NBMA, etc.), multicast, and neighbor discovery/router advertisements/etc.

    Telechat:

  13. The DHCPv4 Relay Agent Identifier Suboption (Proposed Standard)
    draft-ietf-dhc-relay-id-suboption-07
    Token: Ralph Droms
    Note: John Jason Brzozowski (john_brzozowski@cable.comcast.com) is the document shepherd.
    Discusses/comments (from ballot 3221):
    1. Adrian Farrel: Discuss [2009-10-20]:
      I would like to see some discussion of what happens if the identifier carried in the Relay Agent Identifier suboption is not unique across the domain.
    2. Adrian Farrel: Comment [2009-10-20]:
      Please be careful to be consistent in the name of your new sub-option.
    3. Russ Housley: Discuss [2009-10-21]:
      In the Gen-ART Review Sean Turner on 2009-10-06, two issues were raised. I have not seen a response to these issues.
    4. Tim Polk: Discuss [2009-10-22]:
      To achieve interoperability, I believe that at least one relay identifier type should be MUST implement.

    Telechat:

2.1.2 Returning Item

  1. Post-Repair Loss RLE Report Block Type for RTCP XR (Proposed Standard)
    draft-ietf-avt-post-repair-rtcp-xr-06
    Token: Cullen Jennings
    Note: This draft still needs to be put on an IESG agenda
    Discusses/comments (from ballot 2961):
    1. Alexey Melnikov: Comment [2009-10-15]:
      Section 3 should say that network byte order is used for encoding 16bit values.
    2. Tim Polk: Comment [2009-01-27]:
      it would be helpful if this document noted any [security] considerations unique to this report block, as with the security considerations for the Loss RLE report block in RFC 3611.
    3. Dan Romascanu: Comment [2009-10-21]:
      1. It is not clear to me what item in the AVT WG charter this document is covering.
      2. It would be useful to clarify whether the applicability statements defined in RFC 3611 for packet-by-packet reporting blocks fully apply to the new block
    4. Robert Sparks: Comment [2009-10-21]:
      If an attacker can inject post-repair reports and also induce loss of the RTP, then the processing at the sending endpoint could be convinced that no remedial changes are necessary...
    5. Magnus Westerlund: Comment [2009-01-28]:
      During the fall we had a discussion about the issue of RTP sequence number wrap around... I think there still should be a warning about this issue, and the need for senders to take care of this issue.

    Telechat:

2.2 Individual Submissions

2.2.1 New Item

2.2.2 Returning Item

  1. URI Scheme for GSM Short Message Service (Proposed Standard)
    draft-wilde-sms-uri-19
    Token: Lisa Dusseault
    Discusses/comments (from ballot 1623):
    1. Jari Arkko: Comment [2008-09-25]:
      I share the issue in 2nd part of Russ's Discuss:
    2. Pasi Eronen: Comment [2009-08-06]:
      I think the document would benefit from including an example with a non-global number...
    3. Chris Newman: Discuss [2008-09-22]:
      1. The document needs a normative reference to the HTML 4.01 specification for...
      2. there are contexts where SMS is more expensive...
      3. The URI scheme doesn't have an extensibility model
      4. You need to discuss how use of comma as a delimiter between addresses interacts...
      5. While you've defined the charset of the body parameter, the semantics are not defined.
      6. Why is this "provisional" rather than "Permanent"?
    4. Dan Romascanu: Comment [2008-09-25]:
      I support the issue raised by Magnus in his DISCUSS.
    5. Robert Sparks: Discuss [2009-10-21]:
      As far as I can tell, the document doesn't discuss how to compare two sms: URIs for equality. Should it?

    Telechat:

3. Document Actions

3.1 WG Submissions

3.1.1 New Item

  1. Problem statement on the cross-realm operation of Kerberos (Informational)
    draft-ietf-krb-wg-cross-problem-statement-05
    Token: Tim Polk
    Discusses/comments (from ballot 2944):
    1. Russ Housley: Discuss [2009-10-21]:
      Brian Carpenter provided a Gen-ART review of -04. There where substantial changes to create -05. Brian was not able to review all of the changes, but he does report that hes concerns with sections 5.5 and 5.6 were not resolved.

    Telechat:

  2. Requirements for a Location-by-Reference Mechanism (Informational)
    draft-ietf-geopriv-lbyr-requirements-08
    Token: Cullen Jennings
    Note: The document shepherd for this document is Alissa Cooper.
    Discusses/comments (from ballot 3081):
    1. Alexey Melnikov: Comment [2009-10-22]:
      typo

    Telechat:

  3. POP3 Support for UTF-8 (Experimental)
    draft-ietf-eai-pop-07
    Token: Alexey Melnikov
    Note: Harald Alvestrand is the document shepherd.
    Discusses/comments (from ballot 3154):
    1. Ralph Droms: Discuss [2009-10-20]:
      Agreeing with Lars DISCUSS in the case of this doc...and we should discuss more generally how an Experimental doc can update a Standard.
    2. Lars Eggert: Discuss [2009-10-16]:
      In my reading, this document is not mandatory-to-implement for the POP3 standard. As such, it doesn't need to (and IMO shouldn't) update RFC1939.
    3. Adrian Farrel: Discuss [2009-10-22]:
      I think it would be valuable (and help with the discussions about an Experimental RFC updating a Standards Track one) to document the scope of the experiment.
    4. Adrian Farrel: Comment [2009-10-22]:
      The start of section 2 is a little cryptic! Could you arrange to begin with some English text that introduces the formal definitions?
    5. Russ Housley: Comment [2009-10-21]:
      as Experimental, this cannot update RFC 1939.
      The Gen-ART Review by Brian Carpenter on 2009-10-17 asks some good questions...
    6. Cullen Jennings: Comment [2009-10-21]:
      support Lars discuss on update

    Telechat:

  4. IPv6 Configuration in IKEv2 (Experimental)
    draft-ietf-ipsecme-ikev2-ipv6-config-02
    Token: Tim Polk
    Note: Paul Hoffman (paul.hoffman@vpnc.org) is the document shepherd.
    Discusses/comments (from ballot 3176):
    1. Russ Housley: Discuss [2009-10-21]:
      The Gen-ART Review by Avshalom Houri on 2009-09-24 raised a concern about authentication and re-authentication...
    2. Russ Housley: Comment [2009-10-21]:
      The Gen-ART Review by Avshalom Houri on 2009-09-24 suggested a section describing how the requirements in section 3 are being addressed by the solution.

    Telechat:

  5. Requirements for Federated File Systems (Informational)
    draft-ietf-nfsv4-federated-fs-reqts-05
    Token: Lars Eggert
    Note: Spencer Shepler (shepler@storspeed.com) is the document shepherd.
    Discusses/comments (from ballot 3206):
    1. Adrian Farrel: Comment [2009-10-22]:
      Nice document. Thank you.
    2. Alexey Melnikov: Comment [2009-10-19]:
      [several text clarity issues]

    Telechat:

3.1.2 Returning Item

3.2 Individual Submissions Via AD

3.2.1 New Item

3.2.2 Returning Item

3.3 Independent Submissions Via RFC Editor

3.3.1 New Item

  1. Procedures for Rights Handling in the RFC Independent Stream (Informational)
    draft-braden-independent-submission-01
    Token: Russ Housley
    Discusses/comments (from ballot 3244):
    1. Lars Eggert: Comment [2009-10-16]:
      April 1 RFCs are explicitly excluded from the requirement to be submitted as IDs first on http://www.rfc-editor.org/indsubs.html. How is rights transfer handled for them?
    2. Adrian Farrel: Discuss [2009-10-21]:
      Section 5 makes several requests to the IETF Trust for action. Is this I-D/RFC the most efficient way to make those requests?
    3. Russ Housley: Comment [2009-10-16]:
      Throughout the document, ISE is expanded as "Independent Stream Editor." However, RFC 5620 uses Independent Submission Editor.
      In Section 2, reword to ensure that "Trust" is interpreted as the IETF Trust.
    4. Cullen Jennings: Discuss [2009-10-21]:
      The draft says "Therefore, no separate licensing procedure is required for extracting and adapting code that is contained in an Independent Stream document submitted under the (preferred) unlimited derivative works terms."
      If this is a request to the Trustees, then it is inappropriate to publish at an RFC as it will be confused by people as what the rules are instead of what rules were requested. If it is statement of the rules, then I wonder if it would be better in the IAB stream.

    Telechat:

3.3.2 Returning Item

3.3.3 For Action

  1. 4over6 Transit Solution using IP Encapsulation and MP-BGP Extensions (Experimental)
    draft-wu-softwire-4over6-03
    Token: Russ Housley

    Telechat:

1349 EDT break skipped

4 Working Group Actions

4.1 WG Creation

4.1.1 Proposed for IETF Review

  1. Internet Area Working Group (intareawg)
    Token: Jari

    Telechat:

4.1.2 Proposed for Approval

  1. (none)

4.2 WG Rechartering

4.2.1 Under evaluation for IETF Review

  1. Handover Keying (hokey)
    Token: Tim

    Telechat:

4.2.2 Proposed for Approval

  1. (none)

5. IAB News We can use

  1. Russ: pass, given time constraints

6. Management Issues

  1. Link Relations Request [IANA #259813] (Lisa Dusseault)

    Telechat:

  2. Planned boilerplate changes in xml2rfc (Alexey Melnikov)

    Telechat:

  3. Response to 3gpp on the liaison about a joint meeting (Jari Arkko)

    Telechat:

7. Agenda Working Group News

1410 EDT Adjourned



Appendix: Snapshot of discusses/comments

draft-ietf-rmt-pi-alc-revised

  1. Pasi Eronen: Comment [2009-10-22]:
    The "Baseline Secure ALC Operation" (Section 5.1) seems very specific
    to some particular application (not clear what exactly), and probably
    wouldn't be very useful for most applications using ALC. For example,
    using IP addresses in certificates (Section 5.1.2.5) is unlikely
    to be a good idea for most applications...
  2. Russ Housley: Comment [2009-10-20]:
    
        
  3. Cullen Jennings: Discuss [2009-10-21]:
        Can someone explain the IPR situation on this to me. My understanding is that
    there was IPR on 3450. Has this gone away somehow?
    
    It seems like this should be experimental. What changed? 
        
  4. Cullen Jennings: Comment [2009-10-21]:
    
        
  5. Dan Romascanu: Discuss [2009-10-21]:
        I think that the following two issues need to be discussed by the IESG before
    apprpving this document. I would be glad to clear the DISCUSS if there are
    appropriate answers to these questions.
    
    1. This document updates RFC 3450 and moves it from Experimental to Proposed
    Standard. What is the rationale behind this move - is the protocol implemented
    and succesfully deployed,  what is the operational experience that was gained in
    the 6-7 years since 3450 was published?
    
    2. How is this protocol deployed and managed? Are there any configuration
    operations that are required? How are sessions monitored? Are there performance
    metrics and parameters that need to be monitored? I understand that the answers
    may not be included in this document but some place else, but I could not find
    anything in the WG documents. 
        
  6. Dan Romascanu: Comment [2009-10-21]:
    The OPS-DIR review performed by Victor Fajardo raised a number of issues which
    are not blocking, but should be clarified and answered in order to improve the
    quality of the document:
    
    1. There is a strong recommendation regarding the placement of the RP
    (Rendezvous Points) as close to the source as possible. However the placement of
    RPs are typically not constrained by control protocols either in sparse or dense
    mode multicast deployments. Is not this a too strong of a deployment constraint
    when using ALC, and what can be the consequences of such a troplogy requirement
    not be met in depoyment? 
      
    2. In sec 2.2, is RFC3738 the default congestion
    control ? It is not clear how multiple congestion control schemes would inter-
    operate when they are present. i.e. how does it map a scheme to each possible
    length ?
     
    3. In paragraph 5 of sec 2.3, there seems to be several available
    mechanisms for communicating FEC OTI. Is the ALC responsible for mapping/sorting
    out which scheme is in use ?
     
    4. In 1st paragraph of sec 4.2, ALC MUST
    ‘recognize’ EXT_AUTH. In this context, what does ‘recognize’ mean ? Does
    it mean passing the responsibility to some auth module ? Its not clear in the
    document how this is supported.
     
    5. The last paragraph of sec 4.4 maybe more
    useful to be part of the security considerations section.

draft-ietf-sip-certs

  1. Ralph Droms: Comment [2009-10-20]:
    
        
  2. Lars Eggert: Discuss [2009-10-16]:
        Section 12.1., paragraph 4:
    >    [RFC2898]  Kaliski, B., "PKCS #5: Password-Based Cryptography
    >               Specification Version 2.0", RFC 2898, September 2000.
    
      DISCUSS: Downref. (The one to RFC5208 was handled in last-call but not
      this one?) 
        
  3. Lars Eggert: Comment [2009-10-16]:
    Section 6.5., paragraph 3:
    >    Implementations which generate large notifications are reminded to
    >    follow the message size restrictions for unreliable transports
    >    articulated in Section 18.1.1 of SIP.
    
      It's pretty much guaranteed that NOTIFYs that have S/MIME certs in
      them will be longer than 1300 bytes. It's also pretty much guaranteed
      that the clients will have no idea of the PMTU. According to Section
      18.1.1 of RFC3261 this means that these will need to be sent over TCP.
      How many stacks are really going to support this "upconversion" to
      TCP? I was under the impression that TCP support wasn't really there?
    
      (I may upgrade this to a discuss, but let's see.)
  4. Pasi Eronen: Discuss [2009-10-22]:
        I have reviewed draft-ietf-sip-certs-09, and have one question
    that I'd like to discuss before recommending approval of the document:
    
    In Section 7.10, why is the credential service required to check that
    one of the SubjectAltNames matches the authorized user (and the basic
    constraints)? The final recipient of the certificate will not usually
    use that SubjectAltName for anything (so it doesn't really matter what
    it contains)... and this check would complicate using CA-issued
    certificates (since it requires the credential service to know what
    kinds of names that particular CA uses).
    
    (I will probably clear this DISCUSS after the telechat, but would
    be interested in knowing the rationale behind this requirement.) 
        
  5. Pasi Eronen: Comment [2009-10-22]:
    
        
  6. Alexey Melnikov: Discuss [2009-10-17]:
        This is a good and useful document and I support its publication.
    However I have
    a small set of relatively minor issues I would like to discuss first.
    
    1) DISCUSS DISCUSS (I am likely to clear this part after the telechat)
    
    In Section 3:
    
       Bob's UA (Bob2) does a TLS [RFC5246] handshake with the credential
       server to authenticate that the UA is connected to the correct
       credential server.  Then Bob's UA publishes his newly created or
       updated credentials.  The credential server digest challenges the UA
       to authenticate that the UA knows Bob's shared secret.  Once the UA
       is authenticated, the credential server stores Bob's credentials.
    
    As TLS will only be authenticating the server end, it would be
    great to use some
    channel binding facility between TLS and Digest authentication. Is there any
    work on defining channel bindings for use in SIP?
    
    2) In Section 6.2:
                 etag-param = "etag" EQUAL token
    
    I think this needs a normative reference to RFC 5234 (ABNF).
    
    <<Check if "=/" needs to be used here>>
    
    3) DISCUSS DISCUSS
    
    In Section 7.5:
    
       The NOTIFY MUST contain a multipart/mixed (see [RFC2046]) body that
       contains both an application/pkix-cert body with the certificate and
       an application/pkcs8 body that has the associated private key
       information for the certificate.  The Content-Disposition MUST be set
       to "signal" as defined in [RFC3204].
    
       A future extension MAY define other NOTIFY bodies.  If no "Accept"
       header field is present in the SUBSCRIBE, the body type defined in
       this document MUST be assumed.
    
    Question: does the Accept header field body contains "multipart/mixed"
    or
    "application/pkcs8"? How would this work for future extensions if
    there is a
    need to return other media types inside a top level "multipart/mixed"?
    
    4) DISCUSS DISCUSS
    
    7.10.  Notifier Processing of PUBLISH Requests
    
    (Question to Security ADs):
    Excuse my ignorance, but are there any useful checks that can be
    performed to see if the application/pkix-cert body 
    part matches information in the application/pkcs8 body part?
    
    5) In Section 9.5:
    
       Credential services SHOULD implement the server name indication
       extensions in [RFC5246] and they MUST support a TLS profile of
       TLS_RSA_WITH_AES_128_CBC_SHA as described in [RFC5246] as a profile
       of TLS_RSA_WITH_3DES_EDE_CBC_SHA.
    
    I can't parse this sentence.
    
       The PKCS#8 in the clients MUST implement PBES2 with a key derivation
       algorithm of PBKDF2 using HMAC with SHA1
    
    (Comment) I think this needs references to HMAC and SHA1 documents.
    
       and an encryption algorithm
       of DES-EDE2-CBC-Pad as defined in [RFC2898].  It is RECOMMENDED that
       this profile be used when using PKCS#8.  A different passphrase
       SHOULD be used for the PKCS#8 encryption than is used for server
       authentication. 
        
  7. Alexey Melnikov: Comment [2009-10-17]:
    2.  Definitions
    
          Certificates
          that are signed by a certificate authority can also be used with
          all the mechanisms in this draft, but it is expected that they are
          used purely as a key carrier and that their validity is not
          checked.
    
    I find this statement to be strange, if not wrong.
    
    4.  UA Behavior with Certificates
    
       The Subscriber needs to decide how long it is willing to trust that
       the certificate it receives is still valid.  If the certificate is
       revoked before it expires, the Notifier will send a notification with
       an empty body to indicate that the certificate is no longer valid.
       If the certificate is renewed before it expires, the Notifier will
       send a notification with a body containing the new certificate.
    
    It would be nice to state the assumption that there is only one certificate per
    user at any given time earlier in the document.
    
    
    5.  UA Behavior with Credentials
    
       Credentials are created by creating a new key pair which will require
       appropriate randomness,
    
    I think an Informative reference to RFC 4086 would be appropriate here:
    
       [RFC4086]  Eastlake, D., Schiller, J., and S. Crocker, "Randomness
                  Requirements for Security", BCP 106, RFC 4086, June 2005.
    
    6.12.  State Agents and Lists
    
       The certificate server described in this section which serves
       certificates is a state agent and implementations of the certificate
       server MUST be implemented as a state agent.
    
    Question: which document defines the "state agent" term?
    
    7.6.  Subscriber Generation of SUBSCRIBE Requests
    
       The UA needs to authenticate with the credential service for these
       operations.  The UA MUST use TLS to directly connect to the server
       acting as the credential service or to a server that is authoritative
       for the domain of the credential service.  The UA MUST NOT connect
       through an intermediate proxy to the credential service.
    
    Last sentence: it would be helpful if the document pointed out
    how to achieve this.
    
    7.10.  Notifier Processing of PUBLISH Requests
    
       If the Subscriber submits a PUBLISH request with no body, this
       revokes the current credentials and causes all subscriptions to the
       credential package to be deactivated as described in the previous
       section.
    
    I think you need an explicit section reference number here, section 7.9 is
    talking
    about something else.
  8. Tim Polk: Discuss [2009-10-22]:
        This is a good document, and I will move to Yes once some issues have been
    addressed.
    
    As noted in section 2:
    
     Certificates
          that are signed by a certificate authority can also be used
    with
          all the mechanisms in this draft, but it is expected that they are
    used purely as a key carrier and that their validity is not
          checked.
    
    IMHO, the self-signed certificate and credential distribution mechanisms provide
    a significant incremental improvement in SIP security, and provide a reasonable
    transition strategy to promote use of certificates for SIP security.  If
    certificates signed by a trusted third party are used "purely as a key carrier"
    instead of self-signed certificates, the security achieved is the same in both
    cases.  However, using certificates issued by trusted third parties can provide
    a more robust level of security for SIP applications by leveraging the PKIX tool
    set.  However, the mechanisms for use with certificates from trusted third
    parties are under-specified so an implementer would not know how or where to
    integrate these tools into a product if they are available and the additional
    security is desired.
    
    I would like to see an additional section in the security considerations section
    that explains the incremental improvement in security provided by validating the
    chain of certificates associated with the user's third party certificate,
    pointing to RFC 5280. 
        
  9. Tim Polk: Comment [2009-10-22]:
    
      

draft-ietf-hokey-key-mgm

  1. Jari Arkko: Discuss [2009-10-22]:
        This was a well written document, and I was about to vote Yes on it.
    However, before recommending the approval I would like you to help
    me understand this:
    
      The encoding of the key type is left to the discretion of
      the implementer.
    
    Yet, the document is scheduled to become a Proposed Standard, and later
    in the document you talk about the encoding of at least some fields
    in AAA protocols (PID = User-Name etc). To what extent does is this
    specification complete? What else is there missing than the KT field?
    Or, if there are missing things, why is this a proposed standard,
    wouldn't an informational specification that gives a general outline
    of an approach be more suitable? 
        
  2. Jari Arkko: Comment [2009-10-22]:
    
        
  3. Pasi Eronen: Discuss [2009-10-22]:
        I have reviewed draft-ietf-hokey-key-mgm-09, and have couple of
    concerns/questions that I'd like to discuss before recommending
    approval of the document:
    
    - After reading the abstract ("The document defines a key distribution
    exchange (KDE) protocol that can distribute these different types of
    root keys..."), I was expecting that this document would define a
    protocol (message formats and their processing).
    
    But the document never does that -- it's more like "high-level design
    for a protocol to be defined in the future".  Earlier versions of this
    draft actually included message formats, but it seems the were removed
    -- but the abstract and introduction were not updated to reflect
    this rather major change.
    
    - Since you cannot actually implement this document (and thus can't
    have two interoperable implementations), does it even belong on
    Standards Track?
    
    - Section 5 has a MUST-level requirement that's probably a leftover
    from times when this still defined a protocol: "the local ER server
    requesting the DSRK MUST include a KDE-Request message in the first
    EAP-Response message from the peer." 
        
  4. Pasi Eronen: Comment [2009-10-22]:
    
        
  5. Adrian Farrel: Comment [2009-10-20]:
    AAA is not an RFC Editor "well-known" abbrevation, and should be 
    expanded in the Abstract and on first use in the main text. You 
    might also add it to section 2.
  6. Russ Housley: Comment [2009-10-20]:
      In the Gen-ART Review by Francis Dupont on 2009-07-30, it was suggested:
    
        I understand this specification is very abstract about on wire
        entities (for instance there is nothing about encoding, etc) but
        this can become an issue about key labels, i.e., the reader has
        to read the (referenced) RFC 5295 if (s)he wants to know what are
        exactly these key labels (note the term "label" can denote many
        different things). I suggest to be slightly more reader friendly,
        for instance by writing the RFC 5295 establishes a IANA registry
        for "USRK Key Labels" too:
        
        for the specification of key labels -> ... and associated IANA registry.
  7. Alexey Melnikov: Comment [2009-10-17]:
    The following 2 references don't look like Normative references:
    
       [RFC2865]  Rigney, C., Willens, S., Rubens, A., and W. Simpson,
                  "Remote Authentication Dial In User Service (RADIUS)",
                  RFC 2865, June 2000.
    
       [RFC3588]  Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J.
                  Arkko, "Diameter Base Protocol", RFC 3588, September 2003.
  8. Dan Romascanu: Comment [2009-10-21]:
    I noticed that the PROTO write-up includes the following: 
    
    >My only concern is whether the document should be on the Standards track or
    >if BCP would be a better classification: the original document was less
    >abstract & more RADIUS-specific & so Standards Track made some sense; I'm
    >not so sure about this version.  
    
    I actually am quite confortable with this document being approved as PS, because
    it does define a mechanism that involves interoperability on the wire. It would
    be good however for the IESG to consider again this issue before approval.

draft-ietf-mmusic-rfc3388bis

  1. Adrian Farrel: Discuss [2009-10-21]:
        
    Some minor issues that should be easy to clean up.
    
    The Abstract and the Introduction should note "This document obsoletes
    RFC 3388."
    ---
    I find section 10 a little short of information. It *does* capture the
    main functional difference between this I-D and RFC 3388, but if I run
    a diff between the documents I see far more changes. These should be
    explained in section 10; possibly just add "Rewrite the following 
    secitons for clarity...", "Add the following sections for additional
    explanation...", and "update IP address in the example"
    ---
    I think that in this revision of 3388, you shouldn't define the
    attributes defined (sections 4 and 5) as "new". Please replace
    OLD
       A new "media stream identification" media attribute is defined.
    NEW
       This document defines the "media stream identification" media 
       attribute.
    
    etc. Which has the added benefit of removing a gratuitous passive voice.
    ---
    Need to add a normative reference for the definition of the BNF you are
    using. Then add citations in sections 5 and 6.
    ---
    Section 12 needs some work.
    Since you are obsoleting RFC 3388, presubaly you would like the registry
    created by RFC 3388 to be updated to have a reference to this document.
    Esepcially since section 5 says that this document defines the things in
    the registry. 
        
  2. Adrian Farrel: Comment [2009-10-21]:
    
        
  3. Russ Housley: Discuss [2009-10-20]:
        
      In the Gen-ART Review by Elwyn Davies on 17 October 2009, there was
      a question.  I think the question deserves an answer.
    
      s9.4.2, last para:  How does the offerer know that the grouping is the
      cause of the error message? (This comment may be due to my lack of
      understanding of the minutiae of SDP). 
        
  4. Russ Housley: Comment [2009-10-20]:
    
        
  5. Alexey Melnikov: Discuss [2009-10-19]:
        I have several relatively minor points that should be addressed before I can
    recommend approval of this document:
    
    1). This is a minor point that can be addressed with an RFC Editor note:
    
    In Section 4:
    
       A new "media stream identification" media attribute is defined.  It
       is used for identifying media streams within a session description.
       Its formatting in SDP [RFC4566] is described by the following BNF
       (Backus-Naur Form):
    
               mid-attribute      = "a=mid:" identification-tag
               identification-tag = token
    
    I suspect you are using ABNF defined in RFC 5234, but this is not explicitly
    stated. This reference needs to be Normative.
    
    Also, you should clarify where <token> is defined. I suspect it is defined in
    RFC 4566, but you need to be explicit.
    
    2). In Section 5:
    
       A new "group" session-level attribute is defined.  It is used for
       grouping together different media streams.  Its formatting in SDP is
       described by the following BNF:
    
    
               group-attribute     = "a=group:" semantics
                                     *(space identification-tag)
    
    I didn't find <space> in RFC 4566. Should you just use SP or WSP instead?
    
               semantics           = "LS" / "FID" / semantics-extension
               semantics-extension = token
    
    3). DISCUSS DISCUSS
    
    In general, I think it is wrong to point to an IANA registry established by a
    RFC obsoleted by the document. I think it would be much better to copy the
    original IANA considerations section to this document. 
        
  6. Alexey Melnikov: Comment [2009-10-19]:
    6.  Use of "group" and "mid"
    
       All the "m" lines of a session description that uses "group" MUST be
       identified with a "mid" attribute whether they appear in the group
       line(s) or not.  If a session description contains at least one "m"
       line that has no "mid" identification the application MUST NOT
       perform any grouping of media lines.
    
    The last sentence: is there any interaction with draft-ietf-mmusic-sdp-
    capability-negotiation-10.txt here?
    
    
    9.1.1.  Example
    
     [Example omitted]
    
       Since alignment of "m" lines is performed based on matching of nth
       lines, the first stream had "mid:1" in the INVITE and "mid:2" in the
       200 OK.  Therefore, the application MUST ignore every "mid" and
       "group" lines contained in the SDP.
    
    Last sentence: is this done because of use in SIP, or because of
    mid mismatch in the 200 OK response?
    
       [RFC4346]  Dierks, T. and E. Rescorla, "The Transport Layer Security
                  (TLS) Protocol Version 1.1", RFC 4346, April 2006.
    
    This should probably be updated to point to TLS 1.2.
  7. Dan Romascanu: Discuss [2009-10-21]:
        I am unconfortable with the following statement in the section that describes
    changes relative to RFC 3388.
    
       Given a semantics value, [RFC3388] used to restrict "m" line
       identifiers to only appear in a single group using that semantics.
       That restriction has been lifted.  From conversations with
       implementers, it seems that the lifting of this restriction is
       unlikely to cause backwards compatibility problems.
    
    The authors fail to make a crisp statement that no backwards compatibility
    problems would appear. This seems to be not an implementation but a deployment
    issue, and it is not clear what is the recommendation here for an operator. If
    compatibility problems do show up what are the symptoms or the impact? 
        
  8. Dan Romascanu: Comment [2009-10-21]:
    The OPS-DIR review by Mehmet Ersue raised a couple of issues which are non-
    blocking but still may be considered:
    
    1.  Chapter 5.  Group Attribute
     
    It is unclear to me what the following
    statement actually means: 
    "Further semantics MUST be defined in a standards-
    track document."
    The document in review _is_  a standards-track document and if
    necessary the further semantics can be defined in this document.
     
     
    2. I
    support Alexey's DISCUSS at #3. I also think that it is not appropriate to point
    to an IANA registry established by a RFC obsoleted by this document. The
    document should include the original IANA considerations from RFC3388 and a note
    that this has already been done.
  9. Robert Sparks: Discuss [2009-10-21]:
        The example SDP at the top of page 11 (in version -03) should be
    double-checked to make sure the final c and m lines are in the
    intended order. 
        
  10. Robert Sparks: Comment [2009-10-21]:
    There are uses of 2119 words to constrain other documents here that should
    be edited out (The MUST in section 5, leading to Dan's question, is a good
    example). I _think_ the MUST in the example section 9.1.1 (which let to 
    Alexey's comment) is another example, but I'm not sure if this is attempting
    to note a consequence of some other requirement or to actually state a new
    requirement. If it's the former, where is the actual requirement? If the 
    latter, it's in the wrong place.

draft-ietf-mipshop-pfmipv6

  1. Ralph Droms: Discuss [2009-10-20]:
        I'm not at all aure I could implement an interoperable protocol from this
    document.  The only description of message transmission and processing is in
    Section 4.  There appear to be only general descriptions of message flows and
    operations in section 4.  Is this document defining extensions to RFC 5568?  If
    so, there should be an explicit description of what is the same and what is
    updated.
    
    This document introduces a formal definition for "access network", spec., P-AN
    and N-AN, that doesn't seem to appear in RFC 5213.  There are references to an
    "access network" in RFC 5213, but those references seem to imply a passive link;
    in this document, the P-AN and N-AN include L2 devices that apparently can send
    and receive messages as shown, e.g., in figure 2.
    
    Is there some other document in which the access nodes are given this more
    active definition?  Access nodes don't appear in RFC 5568, either.
    
    Related: this sentence seems like a handwave:
    
       (b)  The previous access network (P-AN), to which the MN is currently
            attached, indicates the handover of the MN to the PAR (PMAG).
            Detailed definition and specification of this message are
            outside the scope of this document.
    
    Why is the AN involved at all?  RFC 5213 assigns all of this detection
    responsibility directly to the MAG.
    
    =====
    How does the PAR know the NAR in predictive handover? (4.1)
    
       (c)  The PAR sends the HI to the NAR.  The HI message MUST have the P
    flag set and include the MN ID, the HNP, the MN IID and the
            address of
    the LMA that is currently serving the MN.
    =====
    In reactive handover, if the MN
    does nor provide the old AP-ID to the NAR, how does the NAR determine the PAR?
    
       (a)  The MN undergoes handover from the P-AN to the N-AN.  The AP-ID
            on the old link may be provided by the MN to help identify the
            PMAG on the new link.
    
    BTW, even though PAR/PMAG and NAR/NMAG are interchangeable throughout the doc,
    it would be good to choose one and stick with.
    
    There seems to be an unstated assumption that AP-IDs can be mapped to access
    routers. 
        
  2. Ralph Droms: Comment [2009-10-20]:
    The requirements for functions in the MN and the access network to support
    "predictive handover" should be stated.
    
    How is predictive handover better than reactive handover?  It seems both require
    traffic buffering, either at the NAR (predictive) or the PAR (reactive).
  3. Lars Eggert: Discuss [2009-10-19]:
        
    Section 4.1., paragraph 1:
    >    It is hence required that all MAGs have the capability
    >    and enough resources to buffer packets for the MNs accommodated by
    >    them.
    
      DISCUSS: How large is this buffer and at what rate is it being drained
      after the tunnel is up? Sending large amounts of data at line-rate
      between the PMAG and NMAG may overload the NMAG.
    
    
    Section 4.1., paragraph 42:
    >    The encapsulation type for these user packets SHOULD follow that used
    >    in the tunnel between the LMA and MAG (IPv6-in-IPv6 as specified in
    >    [RFC2473], IPv6-in-IPv4, IPv6-in-IPv4-UDP as specified in
    >    [IPv4PMIPv6], TLV-header UDP tunneling as specified in [GREKEY] or
    >    any new method defined in the future).
    
      DISCUSS: [IPv4PMIPv6] and [GREKEY] need to be normative references. I
      also don't think that we can simply allow any possible future
      tunneling mechanism here. IMO this should become a "MUST follow either
      X, Y or Z". Finally, since there are multiple options here, how does
      one MAG know which scheme the other one is expecting/using?
      Configuration? 
        
  4. Lars Eggert: Comment [2009-10-19]:
    
        
  5. Pasi Eronen: Discuss [2009-10-19]:
        I have reviewed draft-ietf-mipshop-pfmipv6-09, and have couple of
    questions/concerns that I'd like to discuss before recommending
    approval of the document:
    
    1) In several places, the document talks of "the interface identifier
    of the MN".  Does this refer to the lower 64 bits of some IPv6 address
    used by the MN (and if so, which? the MN could be using any number of
    addresses from its HNP), or perhaps to the MAG's identifier for the
    MN-MAG point-to-point link (if-id; Section 6.1 of RFC 5213)?  (But as
    far as I can tell, the latter isn't necessarily 64 bits, and isn't
    required to be unique between MAGs; it could be e.g. MIB ifIndex).
    
    2) The document talks about "the HNP" -- but in PMIPv6, a MN can have
    several HNPs?
    
    3) The draft has a normative downward reference that wasn't called out
    in IETF Last Call. However, to me it looks like RFC4988 could be
    moved to an informative reference.
    
    4) The references IPv4PMIPv6 and GREKEY look normative to me.
    
    5) The document should probably say something about how
    EnableMAGLocalRouting and the PAR<->NAR tunnel interact.  In
    particular, when local routing is not used, does the PAR use the
    PAR<->NAR tunnel only for packets received from the LMA? (but
    packets received from directly connected CNs are not sent via
    this tunnel) 
        
  6. Pasi Eronen: Comment [2009-10-19]:
    
        
  7. Russ Housley: Discuss [2009-10-20]:
        
      In the Gen-ART Review by Francis Dupont on 2009-09-22, Francis said:
    
      "incredible painful to read (obviously a candidate for "how an RFC
       should not be" :-)."
    
      A revised draft was produced in response to this comment; however, it
      has not been posted yet.  What is the plan? 
        
  8. Russ Housley: Comment [2009-10-20]:
    
        
  9. Alexey Melnikov: Discuss [2009-10-06]:
        1). 4.3.  IPv4 Support Considerations
    
       As for IPv4 Home Address Mobility Support, the MN acquires IPv4 Home
       Address (IPv4-MN-HoA) and in the case of handover, the PMAG needs to
       transfer IPv4-MN-HoA to the NMAG, which is the inner destination
       address of the packets forwarded on the downlink.  For this purpose,
       a new option called IPv4 Address Option is defined in this document.
    
    This seems to suggest that the document is registering a new option with IANA,
    but section 6.2.7 says:
    
       As described in Section 4.3, if the MN runs in IPv4-only mode or
       dual-stack mode, it requires IPv4 home address (IPv4-MN-HoA).  This
       option is used to transfer the IPv4 home address if assigned on the
       previous link.  The format of this option follows the IPv4 Home
       Address Request Option defined in [IPv4PMIPv6].
    
    So is this a new option, or is this a reuse of existing option? 
        
  10. Alexey Melnikov: Comment [2009-10-06]:
    4.  Proxy-based FMIPv6 Protocol Overview
    
       A new flag 'P' is defined for the HI and
       HAck messages to distinguish from those in [RFC5568].
    
    Does this need registering with IANA?
    
       This flag MUST be set in the entire document.
    
    Do you mean that this flag needs to be set in any message specified in this
    document?
    
    
    6.2.7.  IPv4 Address Option
    
       As described in Section 4.3, if the MN runs in IPv4-only mode or
       dual-stack mode, it requires IPv4 home address (IPv4-MN-HoA).  This
       option is used to transfer the IPv4 home address if assigned on the
       previous link.  The format of this option follows the IPv4 Home
       Address Request Option defined in [IPv4PMIPv6].
    
    Does this need a new allocation from IANA?
    
    6.1.2.  Handover Acknowledge (HAck)
    
       Code
                   Code values 0 through 4 and 128 through 130 are defined
                   in [RFC5568].  In this specification, the meaning of Code
                   value 0 is modified, 128 through 130 are reused, and 5,
                   6, 131 and 132 are newly defined.
    
                           0: Handover Accepted or Successful
    
                           5: Context Transfer Accepted or Successful
    
                           6: All available Context Transferred
    
                           128: Handover Not Accepted, reason unspecified
    
                           129: Administratively prohibited
    
                           130: Insufficient resources
    
                           131: Requested Context Not Available
    
                           132: Forwarding Not Available
    
    It would have been better if this was an IANA registry.
    
    
    6.2.1.  Context Request Option
    
       This option is sent in the HI message to request context information
       on the MN.  If a default set of context information is defined and
       always sufficient, this option is not mandatory.
    
    Can you please elaborate on what exactly this means?
    
       This option is more
       useful to retrieve additional or dynamically selected context
       information.
    
    6.2.1.  Context Request Option
    
          0                   1                   2                   3
          0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
         +---------------+---------------+---------------+---------------+
         |  Option-Type  | Option-Length |           Reserved            |
         +---------------+---------------+-------------------------------+
         |  Req-type-1   | Req-length-1  |  Req-type-2   | Req-length-2  |
         +---------------------------------------------------------------+
    
    This doesn't show any optional data following any Req-length-i.
    This caused me some confusion during my review.
    
    6.2.8.  Vendor-Specific Mobility Option
    
       This option is used to transfer any other information defined in this
       document.  The format of this option follows the Vendor-Specific
       Mobility Option defined in [RFC5094].  The exact values in the Vendor
       ID, Sub-Type and Data fields are outside the scope of this document.
    
    I think it would be more correct to say that Vendor IDs are values are as
    specified in [RFC5094].

draft-ietf-vcarddav-carddav

  1. Lisa Dusseault: Comment [2009-10-21]:
    I have balloted "yes" on this document although I hope my comments may be useful
    anyway.
    
    Disadvantage #2 in section 1. drove me crazy: 
    
       2.  Stateless nature of protocol can result in more data being sent
           with each transaction to maintain per-user session across
           requests.
    
    First, statelessness is a tradeoff, not a pure disadvantage: scaling and easy
    server-form usage vs. volume of bits.
    
    Second, the idea that VCARDDAV requires servers to "maintain per-user session"
    across requests is misleading.  There are only two pieces of information that
    should be maintained across requests. The first might be possibly cookies,
    although I don't yet know if cookie support is required.  The other thing is
    Digest nonces.  Both of these support user authentication or identity, so
    "session" is going too far.
    
    Third, when TLS is used, VCARDDAV does have a session that is maintained over a
    connection and TLS client authentication could even maintain the context.  In
    this deployment scenario, session maintenance is done at a different layer and
    thus not "required by VCARDDAV".
    
    My first suggestion is just to remove this.  The lack of change notification
    drawback can stand on its own rather than being a list.
    
    If the "stateless" drawback has to be there for some reasons, I'd rephrase it.  
    
            2.  Although stateless design does allow scalability (e.g. using HTTP
    server farms), it has a cost in transmission volume.  Some context-establishing
    information, typically user authorization, must be resent in each request unless
    an underlying and authorizing connection is maintained.
    
    Second issue: 
    
    In section 8.6.2, a Server Error status code (507) is indicated for use in cases
    when the server has no errors but is honouring the client's result limit
    request.  Does this conflate two different cases that really should be treated
    separately? For example, what if the client asks for their results to be limited
    to 500 responses but the server decides to further limit the response to 50?
    The client can't tell until counting up the number of resources whether the
    server successfully applied the client's requested limit, or applied a cutoff of
    its own.
    
    Also in this section, I believe it's ambiguous what should be returned if the
    client requested a REPORT response limited to X items but there were fewer than
    X items matching the filter.  One could imagine an implementor putting 507 in
    the status response to indicate "The client's limit was applied because no more
    than X resources were returned".  One could also imagine an implementor
    returning 200 OK because no results were truncated.
    
    My suggestion here if it's not too late, would be to consider dropping in a
    <VCARDDAV:results-truncated> element that is only used when there really were
    results truncated at either the client or the server's choice.  When this
    happens because of a server choice, the 507 status code is also used to alert
    the client.  Otherwise, a 200 OK is fine.
    
    I'm quite open to arguments that this is unnecessary or too late but I wanted to
    see if it had been considered.
  2. Lars Eggert: Discuss [2009-10-19]:
        
    Section 11., paragraph 2:
    >    This specification adds two service types for use with SRV records:
    
      DISCUSS: There currently isn't a way to register only a service name
      with IANA without at the same time also registering a port number. (It
      will be once draft-ietf-tsvwg-iana-ports is IESG-approved.) We should
      discuss during the telechat how to handle this case. 
        
  3. Lars Eggert: Comment [2009-10-19]:
    Section 8.7.2., paragraph 7:
    >    <?xml version="1.0" encoding="utf-8" ?>
    >    <D:multistatus xmlns:D="DAV:"
    >                   xmlns:C="urn:ietf:params:xml:ns:carddav">
    >      <D:response>
    >      <D:response>
    
      I believe one of these "<D:response>" tags is superfluous.
    
    
    Section 10.4., paragraph 7:
    >       specification if the CARDAV:address-data XML element part of the
    
      Nit: s/CARDAV/CARDDAV/ (also elsewhere in the document)
    
    
    Section 14., paragraph 0:
    > 14.  IANA Consideration
    
      The service name registrations from Section 11 are missing.

draft-ietf-l3vpn-2547bis-mcast-bgp

  1. Ross Callon: Discuss [2009-09-30]:
        I understand that the many options available in this draft and the closely
    related draft-ietf-l3vpn-2547bis-mcast are necessary for a variety of reasons
    including technical issues and differences between various network environments.
    However, these many options place interoperability at risk. This issue is being
    addressed (in my opinion quite well) by "Mandatory Features in a Layer 3
    Multicast BGP/MPLS VPN Solution", draft-ietf-l3vpn-mvpn-considerations. I am
    placing this discuss because I believe that this latter document is necessary,
    and that it would be a mistake to approve either this document or its companion
    document until draft-ietf-l3vpn-mvpn-considerations is submitted for
    publication.
    
    I will move to a YES vote as soon as draft-ietf-l3vpn-mvpn-considerations is
    submitted. 
        
  2. Ross Callon: Comment [2009-09-30]:
    
      

draft-ietf-sasl-scram

  1. Ralph Droms: Comment [2009-10-22]:
    Trivial editorial nit...
    
    Section 3, 4th para:
    
       Informative Note: Implementors are encouraged to create test cases
       that use both username passwords with non-ASCII codepoints.
    
    change to "username and passwords"

draft-ietf-yam-rfc1652bis-pre-evaluation

  1. Ron Bonica: Discuss [2009-10-06]:
        Agree with Adrian. This seems more like a communication with the IESG than
    something that needs to be store in the RFC series for perpetuity. 
        
  2. Ron Bonica: Comment [2009-10-06]:
    
        
  3. Ralph Droms: Discuss [2009-10-20]:
           o  Does the IESG believe the proposed changes are suitable during a
          move from Draft to Full Standard?
    
    I do.
    
       o  Does the IESG believe any other proposed changes are necessary to
          satisfy IESG requirements to advance to Full Standard?
    
    I don't know of any other changes.
    
    However, we should be clear in our response that other changes may be found to
    be required during the usual document processing including IETF last call and
    IESG voting.
    
       o  Does the IESG consider the downward references acceptable for a
          Full Standard?
    
    I do. 
        
  4. Ralph Droms: Comment [2009-10-20]:
    One additional item for our discussion of this doc - procedurally, how will we
    prepare an IESG response?
  5. Lisa Dusseault: Discuss [2009-10-05]:
        One of the big questions discussed about whether older email standards could go
    to Full Standard was whether the security provisions were sufficient -- whether
    authentication and privacy met our modern requirements, or if not, whether Full
    Standard was acceptable anyway because of historical considerations.
    
    If that is in fact going to be an issue, then this pre-eval document doesn't
    address that or or make the IESG think about that.  Future pre-eval documents,
    if we stick with this WG model, could reasonably compare the standard's security
    to modern requirements.  This DISCUSS position is so that we can talk about
    these issues on the call. 
        
  6. Lisa Dusseault: Comment [2009-10-05]:
    
        
  7. Pasi Eronen: Comment [2009-10-05]:
    My "No Objection" vote means the following answers to the questions in
    Section 3: Yes, I think the proposed changes are suitable. No, I don't
    think any other changes are necessary. Yes, I consider the downward
    references acceptable.
    
    However, the eventual advancement of RFC 1652 to Full Standard will
    naturally go through IETF Last Call (this draft did not go through
    IETF Last Call), where the community has an opportunity to provide 
    more input. My "No Objection" vote here is not a guarantee that 
    I can't change my mind after considering the community input.
  8. Adrian Farrel: Discuss [2009-09-29]:
        
    This seems like a really weird way to communicate with the IESG, and
    I assume we are not supposed to evaluate the draft for publication
    as an RFC as I see...
    
    
    Abstract
       THIS INTERNET DRAFT IS WRITTEN TO FACILITATE PROCESSING WITHIN THE
       IESG.  IT IS NOT MEANT TO BE PUBLISHED AS AN RFC.
    
    1.1.  Note to RFC Editor
    
       This Internet-Draft is not meant to be published as an RFC.  It is
       written to facilitate processing within the IESG.
    
    I think it a shame that community resource has been burnt (e.g. SecDir
    review) evaluating this document as a potential RFC.
    
    ---
    
    In answer to the questions in Section 3
    
       o  Does the IESG believe the proposed changes are suitable during a
          move from Draft to Full Standard?
    
    Yes
    
       o  Does the IESG believe any other proposed changes are necessary to
          satisfy IESG requirements to advance to Full Standard?
    
    I believe that the it is necessary to satisfy any requirements that
    arise from community evaluation of the protocol and from the
    implementation reports.
    
       o  Does the IESG consider the downward references acceptable for a
          Full Standard?
    
    I would prefer that we moved the entire collection forward together,
    but would tolerate the downrefs if the community approves them.
    
    ----
    
    What about draft-dusseault-impl-reports? Not an RFC yet, but good guidance. 
        
  9. Adrian Farrel: Comment [2009-09-29]:
    Section 2
          The universal deployment of this feature is well-known
    
    I suspect this may be an exageration.
  10. Russ Housley: Discuss [2009-10-02]:
        
      This document is not a candidate for standard, which is what one would
      expect from the this agenda item entry.  The document is a reasonable
      way to capture the questions at hand, but an agenda entry that indicates
      the document is moving to standard is misleading and confusing.
    
      This document should be moved to the 'Dead' state in the tracker. 
        
  11. Russ Housley: Comment [2009-10-02]:
    
        
  12. Cullen Jennings: Discuss [2009-10-21]:
          o  Does the IESG believe the proposed changes are suitable during a
          move
    from Draft to Full Standard?
    Yes at this point in time but that does not
    guarantee what opinion will be in future
    
       o  Does the IESG believe any other proposed changes are necessary to
          satisfy IESG requirements to advance to Full Standard?
    Yes
    
       o  Does the IESG consider the downward references acceptable for a
          Full Standard?
    No. 
        
  13. Cullen Jennings: Comment [2009-10-21]:
    
        
  14. Tim Polk: Discuss [2009-10-07]:
        I also want to discuss the implications of moving a document with known security
    limitations
    to full standard. 
        
  15. Tim Polk: Comment [2009-10-07]:
    My personal responses wrt to the questions in section 3:
    (1) I have no issues with the changes proposed.
    (2) I have not made my mind up whether other changes are needed.
    (3) I have no issues with the downrefs.
    
    Any of those answers could be changed during IETF Last Call for 1652bis.
  16. Robert Sparks: Comment [2009-10-07]:
    I find using a draft to drive discussions like this a very useful technique.
    However, using the balloting/evaluation process this way is a poor fit to the
    tool and I strongly discourage taking this path again.
    
    I currently think the changes proposed are suitable.
    I don't have a problem with the downward references.
  17. Magnus Westerlund: Discuss [2009-10-22]:
        I still think this should be handled another way. A management item would have
    been more suitable.
    
    I also note that any views of the current IESG will become mote in 6 months time
    when many of the current ADs has been changed.
    
    Also, I wouldn't commit to a position now. There is a clear difference between
    this investigating question and the formal decision that balloting on the actual
    document is.
    
    On the questions my answer is:
    1. Yes
    2. Maybe, I would note that the security
    consideration for example is bloody useless. Are there issues with describing
    correctly what the existing issues are even if not fixed?
    3. If you anyway are
    moving the other documents to full standard, are there issues with bringing the
    documents together so that there would be no downward references at all? 
        
  18. Magnus Westerlund: Comment [2009-10-22]:
    
      

draft-ietf-pkix-sha2-dsa-ecdsa

  1. Lars Eggert: Comment [2009-10-16]:
    INTRODUCTION, paragraph 13:
    >   Abstract
    >      This document updates RFC 3279
    
      Agree with Alexey; document needs an "Updates: 3279" header.
    
    
    Section 6.1, paragraph 8:
    >      [SEC1]         Standards for Efficient Cryptography SEC 1:
    >                      Elliptic Curve Cryptography, Version 2.0, 2009.
    
      Published by whom?
  2. Alexey Melnikov: Discuss [2009-10-14]:
        This is almost nitpicking, but the Abstract says:
    
      Abstract 
    
         This document updates RFC 3279 to specify algorithm 
         identifiers and ASN.1 encoding rules for the Digital Signature 
         Algorithm (DSA) and Elliptic Curve Digital Signature Algorithm 
         (ECDSA) digital signatures when using SHA-224, SHA-256, SHA-384 
         or SHA-512 as hashing algorithm.
    
    But the draft itself doesn't contain "Updates: RFC 3279".
    Otherwise, I have no objections to publishing this document. 
        
  3. Alexey Melnikov: Comment [2009-10-14]:
    It would have been better if the document were using names in OIDs consistently.
    For example, section 2 uses:
    
         id-sha224  OBJECT IDENTIFIER  ::=  { joint-iso-itu-t(2) 
              country(16) us(840) organization(1) gov(101) csor(3) 
              nistalgorithm(4) hashalgs(2) 4 } 
    
    And Section 3.1  uses:
         id-dsa-with-sha224 OBJECT IDENTIFIER  ::=  { joint-iso-ccitt(2)  
             country(16) us(840) organization(1) gov(101) csor(3) 
             algorithms(4) id-dsa-with-sha2(3) 1 }. 
    
    I.e. joint-iso-itu-t versa joint-iso-ccitt, and nistalgorithm versa algorithms

draft-ietf-dhc-vpn-option

  1. Jari Arkko: Discuss [2009-10-22]:
        I support this document and it was generally well written. However,
    there are a few issues that need to be looked at before the specification
    is complete. The document says:
    
    > Thus, if a DHCPv4 relay agent has a requirement to determine if the
    > address allocated by a DHCPv4 server is on a particular VPN, it must
    > use some other approach than the appearance of the VSS sub-option in
    > the reply packet to make this determination.
    
    But there is no other mechanism.
    
    I would have understood if you simply said that the document assumes
    the relay and server must be configured properly and be capable of
    using VSS options. And that nothing works if this assumption is broken.
    But the document has many words about the situation and strong 
    requirements like the one quoted above. In my view, these are
    confusing the message to the reader, which should be that the
    mechanism defined in this document is very brittle. If that is
    really the case, please say so and add sufficient warning labels
    for users. But maybe that's not the case and I have misunderstood
    something?
    
    The document says:
    
       The typical use of the VSS option or sub-option is for the relay
       agent to know the VPN on which the DHCP client is operating.  The
       DHCP client itself does not, in this scenario, know the VPN on which
       it resides.
       ...
       In this second scenario, the DHCP client is again unaware of any VPN
       activity.
       ...
       A DHCPv4 or DHCPv6 client will employ the VSS option to communicate
       VSS information to their respective servers.  This information MUST
       be included in every message concerning any IP address on a different
       VPN than the global or default VPN. 
    
    These excerpts give an inconsistent view about what the client needs to
    do. I believe a key use case is that the network handles the VPN
    selection and the clients are blissfully unaware of what is going on.
    This seems inconsistent with the requirement that the VPN information
    MUST be included in every message that the client sends. Furthermore,
    an existing client does not understand this specification, and hence
    its fundamentally incapable of respecting the rules.
    
    I would suggest that the document be corrected with respect to the
    following:
    
    1. Make it clear what its limitations are with respect relays or clients
    using this option with a server that does not support the option in v4.
    (Alternatively, develop an additional option that you can actually use
    to verify that the server did indeed understand the VSS option.)
    
    2. Clients need to be able to work with this, without being aware of
    this specification. 
        
  2. Jari Arkko: Comment [2009-10-22]:
    
        
  3. Lars Eggert: Discuss [2009-10-16]:
        I feel like I'm missing something here: If I have a client that has a VPN link
    up, and it broadcasts a DHCP message on that link, the only way a DHCP relay or
    a DHCP server will see that message if they themselves are part of that virtual
    network. So why is there a need for an option to identify the virtual network? 
        
  4. Lars Eggert: Comment [2009-10-16]:
    
        
  5. Adrian Farrel: Comment [2009-10-21]:
    Section 1
       This memo defines a Virtual Subnet Selection (VSS) option for DHCPv4
       and DHCPv6, and a DHCPv4 relay-agent-information sub-option.  These
       are intended for use by DHCP clients, relay agents, and proxy clients
       in situations where VSS information needs to be passed to the DHCP
       server for proper address or prefix allocation to take place.  If the
       receiving DHCP server understands the VSS option or sub-option, this
       information may be used in conjunction with other information in
       determining the subnet on which to select an address as well as other
       information such as DNS server, default router, etc.
    What is meant by "VSS option or sub-option"? You have only mentioned a 
    "VSS option" and a "relay-agent-information sub-option".
    I think this is just a bit of sloppy language and can be cleaned up to
    match section 3 where you define two VSS options and one VSS sub-option.
    You could probably say
    OLD
       This memo defines a Virtual Subnet Selection (VSS) option for DHCPv4
       and DHCPv6, and a DHCPv4 relay-agent-information sub-option.
    NEW
       This memo defines a Virtual Subnet Selection (VSS) option for each of
       DHCPv4 and DHCPv6, and a VSS sub-option carried in the DHCPv4 relay-
       agent-information option.
    
    ---
    
    Please be careful to be consistent about naming. For example...
    Section 1
       This memo defines a Virtual Subnet Selection (VSS) option for DHCPv4
       and DHCPv6, and a DHCPv4 relay-agent-information sub-option.
    and
       If the allocation is being done through a DHCPv4 relay, then the
       relay sub-option defined here should be included.
  6. Russ Housley: Comment [2009-10-21]:
      The Gen-ART Review by Spencer Dawkins on 2009-10-21 (later than usual)
      raised two questions about 2119 language in Section 5.
    
      > A DHCPv4 relay agent SHOULD include a DHCPv4 VSS sub-option in a
      > relay-agent-information option [RFC3046], while a DHCPv6 relay agent
      > SHOULD include a DHCPv6 VSS option in the Relay-forward message.
      >
      Is this functionality supposed to work if either SHOULD is violated?
      I'm wondering why these are not MUSTs.
    
      > The value placed in the Virtual Subnet Selection sub-option or option
      > SHOULD be sufficient for the relay agent to properly route any DHCP
      >
      I don't think this is a 2119 SHOULD. I'm thinking "more like a statement
      of fact" - perhaps "will be sufficient"? If it's really 2119, why 
      isn't it a MUST?
  7. Alexey Melnikov: Comment [2009-10-15]:
    5.  Relay Agent Behavior
    
       Anytime a relay agent places a VSS option or sub-option in a DHCP
       request, it MUST send it only to a DHCP server which supports the VSS
       option or sub-option.
    
    Does this need to be a MUST? This seems like configuration/policy.
    
    
    7.1.  Returning the DHCPv4 or DHCPv6 Option
    
       The appearance of the DHCPv6 VSS option in the OPTION_ORO [RFC3315]
       or the OPTION_ERO [RFC4994] should not change the processing or
    
    "SHOULD NOT"?
    
       decision to return (or not to return) the VSS option as specified in
       this document.
    
    
    9.  IANA Considerations
    
       While the type byte defined in Section 3.4 defines a number space
       that could be managed by IANA, expansion of this number space is not
       anticipated and so creation of a registry of these numbers is not
       required by this document.  In the event that additional values for
       the type byte are defined in subsequent documents, IANA should at
       that time create a registry for these type bytes.  New values for the
       type byte may only be defined by IETF Consensus, as described in
       [RFC5226].  Basically, this means that they are defined by RFCs
       approved by the IESG.
    
    This is an interesting way of saying that new IANA registry is not needed, but
    then putting requirements on future documents if this registry established in
    the future. Is this text needed?
  8. Tim Polk: Discuss [2009-10-22]:
        Dave Harrington's secdir/opsdir review has not received a response (to my
    knowledge, anyway.)
    I am particularly interested in the authors' feelings on
    identifying known mitigation
    strategies, as suggested in the secdir portion of
    the review. 
        
  9. Tim Polk: Comment [2009-10-22]:
    I support Jari's discuss with respect to differentiating between relay and
    client behavior.
    
    To my reading, the only scenarios that are known to be useful involve VSS-aware
    relays
    and clients that are not VSS-aware.  However, the document indicates
    clients can make use
    of this option.
  10. Dan Romascanu: Discuss [2009-10-21]:
        The OPS-DIR reviews performed by Juergen Quittek and David Harrington raised a
    number of issues which I believe need to be addressed before this documment can
    be approved:
    
    1. It looks like in several cases there is an explicit concern of the
    operational impact of deploying agents that use the VSS sub-options with servers
    that do not use it.
    
       Section 4 says "Deploying relay
       agents which support and emit VSS sub-options in concert with DHCPv4
       servers which do not support the VSS option or sub-option as defined
       in this document SHOULD NOT be done, as such an ensemble will not
       operate correctly together because all of the IP addresses will be
       allocated from the global or default VPN regardless of the VPN on
       which the client's reside."
    
    and also: 
    
       "There are many other scenarios which can be created with multiple
       relay agents each inserting VSS information into different Relay-
       forward messages, relay agent VSS information conflicting with client
       VSS information, or DHCP server VSS information conflicting with
       relay agent and client VSS information.  Since these scenarios do not
       describe situations that are useful today, specifying precisely how
       to resolve all of these conflicts is unlikely to be valuable in the
       event that these scenarios actually become practical in the future.
    
       The current use of the VSS option and sub-option require that each
       entity knows the part that it plays in dealing with VPN data.  Each
       entity -- client, relay agent or agents, and server -- SHOULD know
       through some policy or configuration beyond the scope of this
       document whether it is responsible for specifying VPN information
       using the VSS option or sub-option or responsible for responding to
       VSS information specified by another entity, or simply ignoring any
       VSS information which it might see.
    
       Some simple conflict resolution approaches are discussed below, in
       the hopes that they will cover simple cases that may arise from
       scenarios beyond those envisioned today.  However, for more complex
       scenarios, or simple scenarios where appropriate conflict resolution
       strategies differ from those discussed in this document, a document
       detailing the usage scenarios and appropriate conflict resolution
       strategies SHOULD be created and submitted for discussion and
       approval."
    	
    or: 
    
       section 7 says "   In either case above, care should be taken to   
       ensure that a client or
       relay agent receiving a reply containing a VSS option will correctly
       understand the VSS option.  Otherwise, the client or relay agent will
       end up using the address as though it were a global address."
    
    I would like to understand better this negative impact and also what kind of
    care should be taken - especially by an operator - other then deploying full and
    correct VSS option aware agents and servers.
    
    2.      VPN types 2-254 are declared to be invalid "as of this memo", but there
    is no discussion if and how they could become valid in the future. The IANA
    section unclear on whether it can or cannot be expanded in the future.
    
    3. It is not clear how these solutions will be configured. There is quite a bit
    of text that says the entity "has been configured in some way"
            
    In some
    cases, the configuration MUST be done correctly for the system to work, but the
    configuration requirements are not detailed. For example, Section 4 says "It is
    important to ensure that each entity ... is configured correctly." and "There is
    no conflict between different entities trying to specify different VSS
    information -- each entity knows its role through policy or configuration
    external to this document." and "In the event that there were more than one
    relay agent involved in this transaction, some external configuration or policy
    would be needed to inform the DHCPv6 server into which Relay-reply message the
    VSS option should go." 
        
  11. Dan Romascanu: Comment [2009-10-21]:
    1. The Terminology section defines upstream and downstream using terms that have
    not been defined.
    It is unclear to me whether access concentrator and subscriber
    are similar to server and client.
    
    2. In section 3.4, might it be better to declare 2-254 as reserved rather than
    invalid?
    The text says "invalid as of this memo".
    Should there be a mechanism to
    support enterprise-specific VSS?
    
    3. In section 4, it says DHCP can assign the same IP address to nodes in a VPN
    and in the global IP space, because the address is qualified by the VPN. Is this
    always true? Is there any potential for conflict, such as in forwarding loops,
    if the two addresses spaces are handled by the same device?
    
    4. I think section 4 would benefit from sub-sections to separate the scenarios,
    and all the "in this scenario" phrases could be eliminated.
    Diagrams of the
    scenarios would be helpful.
    
    5. Will legacy DHCP entities ignore the VSS option by default? or will the
    presence of the option somehow impact entity behaviors (e.g., by dropping
    packets)?
    
    6. In section 5, it says the relay SHOULD insert VSS information into requests
    from a client. What happens if the client has inserted a VSS option? That isn't
    discussed.
    
    7. Section 5 says
       "Anytime a relay agent places a VSS option or sub-option in
    a DHCP
       request, it MUST send it only to a DHCP server which supports the VSS
    option or sub-option." How does it know? is there an option discovery mechanism?
    
    8. In section 5, if a relays requests a specific VPN, but the server returns an
    address not within that VPN, then the relay should drop the packet. Should the
    relay let the server know that it dropped the packet and why? Won't the server
    assume the address has actually been assigned to the client, thus reducing the
    pool of available addresses?
    
    9. In section 5,  "If an IP address that is on the requested VPN is not
    required, then the relay agent is free to accept the IP address that is not on
    the VPN that was requested." Then why request it? Under what conditions would it
    not be required? how does the relay know whether it is or is not required?
    
    10. In section 5, it says "There are only two pieces of information which can be
    determined ..." but the speciied behaviors could also result from mis-
    configuration, right? And the relay cannot tell whether it is a deliberate
    behavior or a mis-configuration.
    
    11. section 5:   " Thus, if a DHCPv4 relay agent has a requirement to
    determine
    if the address allocated by a DHCPv4 server is on a particular VPN, it must use
    some other approach than the appearance of the VSS sub-option inthe reply packet
    to make this determination." What other approach works?
    
    12. section 5: "   Note that in some environments a relay agent may
    choose to
    always place a VSS option or sub-option into packets and messages that it
    forwards in order to forestall any attempt by a downstream relay agent or client
    to specify VSS information.  In this case, a type field of 255 is used to denote
    the global, default VPN.  When the type field of 255 is used, there MUST NOT be
    any additional VSS
    Information in the VSS option."  This section does not say
    that the relay must check to make sure there is no existing VSS option. Section
    5 talks about relays inserting VSS options, but does not specify that the relay
    must check that no VSS=255 is present in the message already.
    But section 7.3
    talks about resolving conflicting VSS options. I am not sure the potential
    conflicts abd resolutions are covered adequately.
    
    13. section 5.1 what does "if the relay agent is unable to honor the server
    requirement" mean? This could be made less ambiguous.
    
    14. section 5.1 "   The DHCP server MUST NOT place VSS information in
    an
    outgoing packet if the relay agent or DHCP client is unprepared to properly
    interpret the VSS information." This seems ambiguous. How will the server know
    if the other entities can properly interpret the VSS information?
    
    s/send in/insert/
    
    15. Section 4 says "The DHCP client, in this scenario, does not know the VPN on
    which it resides. Section 6 says "A DHCPv4 or DHCPv6 client will employ the VSS
    option to communicate VSS information to their respective servers.  This
    information MUST be included in every message concerning any IP address on a
    different VPN than the global or default VPN."
    These statements seem to conflict
    regarding the client's knowledge.
    
    16. section 6: "   Clients should be aware that some DHCP servers will
    return a
    VSS option with different values than that which was sent in.  In addition, a
    client may receive a response from a DHCP server with a VSS option when none was
    sent in by the Client."
    
    So should subsequent messages from the client use the original VSS information
    or the server-returned or relay-returned VSS info?
    
    Can a return message contain multiple VSS options? If I read the document
    correctly, multiple relays can add their own VSS options, and a server typically
    copies all the options. If a client is expected to include the VSS option
    information in subsequent messages, does it include multiple VSS options? The
    second paragraph of 6 says that is not allowed.
    
    17. The terminology issue concerns the use of the word "global"
    for non-VPN
    addresses. According to the use of this term, also a "private" IP address, such
    as 10.X.X.X, is called "global".
    Is it appropriate calling it so even if this
    address is usually called "private" and is not globally routable?
    
    The draft says in line 6 of the second paragraph of section 4:
    " ... the IP
    address space is in the global or default VPN used throughout the Internet". Are
    private IP addresses used throughout the Internet? Maybe ...
     
    For me this
    terminology choice is confusing. I would rather rename it or at least add an
    entry to the terminology section that "global"
    does not cover public IP
    addresses only but includes also private ones.
    
    ----
    
    18. In lines 3-5 of the 3rd paragraph of section 4 the draft says:
    "There is no
    conflict in this allocation, since the clients have essentially different IP
    addresses. Shouldn't it be different "IP address spaces" instead of "IP
    addresses"? Earlier in this paragraph you say the the IP addresses may be the
    same. Only the address spaces are different.
    
    ----
    
    19. page 4, 4th paragraph:
    "It is important to ensure that each entity in this
    scenario ..."
    As far as I understand this applies only to the DHCP relay and
    server and not to the client. The client would be an antity in the scenario to
    which it is not important to ensure this.
    If I'm correct, please change the text
    accordingly.
    
    ----
    
    20. section 6, last paragraph:
    Here "should" and "should not" are used.
    Shouldn't they get replaced by "SHOULD" and "SCHOULD NOT"?
    
    21. section 1, lines 6-7:
    "The configured rates are below the rate of the link ..."
    would "the rate of the link" be "the maximum rate of the link"?
  12. Magnus Westerlund: Comment [2009-10-22]:
    Support for Dan's discuss on clarifying how to handle unknown VSS Information
    formats. This can be a MUST ignore if that works properly. Or if you are going
    to stay with SHOULD you need to define what the alternative is and that it makes
    sense. Or maybe you do need to define a error or response procedure.

draft-ietf-mpls-tp-gach-dcn

  1. Pasi Eronen: Discuss [2009-10-22]:
        
    I have reviewed draft-ietf-mpls-tp-gach-dcn-06, and have one question
    that I'd like to discuss before recommending approval of the document:
    
    This looks a lot like IPv4/v6-over-FOO document (for link layer or
    tunneling technology FOO). Normally, such a document would say
    something about MTUs/fragmentation, and for IPv6, interface
    identifiers, link-local addresses, the overall link model (point-to-
    point, NBMA, etc.), multicast, and neighbor discovery/router 
    advertisements/etc.
    
    Is something about this topics needed in this document? (And if not,
    why not -- where would those details be?) 
        
  2. Pasi Eronen: Comment [2009-10-22]:
    
        
  3. Magnus Westerlund: Comment [2009-10-22]:
    I am looking forward to hearing the answers to Pasi's Discuss.

draft-ietf-dhc-relay-id-suboption

  1. Adrian Farrel: Discuss [2009-10-20]:
        
    I would like to see some discussion of what happens if the identifier
    carried in the Relay Agent Identifier suboption is not unique across
    the domain. This is most likely to arise from misconfiguration of ASCII
    strings (but might also happen in a security attack).
    
    What is the impact on the network? Can one relay agent detect that there
    is another operating with an identical identifier? Can other network
    nodes spot the duplication? Do you expect anything more than an alert 
    raised by the node that spots the issue? 
        
  2. Adrian Farrel: Comment [2009-10-20]:
    |Please be careful to be consistent in the name of your new sub-option.
    For example, in Section 1 para 2.
       This specification introduces a Relay Agent Identifier suboption for
       the Relay Information option.  The Relay-Id suboption carries a
       sequence of octets that is intended to identify the relay agent
       uniquely within the administrative domain.
    
    ---
    Notwithstanding the reference to RFC 3315, "DUID" should be expanded on
    first use.
  3. Russ Housley: Discuss [2009-10-21]:
        
      In the Gen-ART Review Sean Turner on 2009-10-06, two issues were raised.
      I
    have not seen a response to these issues.  The review can be found at:
    http://www.softarmor.com/rai/temp-gen-art/draft-ietf-dhc-relay-id-
    suboption-07-turner.txt 
        
  4. Russ Housley: Comment [2009-10-21]:
    
        
  5. Tim Polk: Discuss [2009-10-22]:
        To achieve interoperability, I believe that at least one relay identifier type
    should be MUST implement. 
        
  6. Tim Polk: Comment [2009-10-22]:
    
      

draft-ietf-avt-post-repair-rtcp-xr

  1. Alexey Melnikov: Comment [2009-10-15]:
    Section 3 should say that network byte order is used for encoding 16bit values.
  2. Tim Polk: Comment [2009-01-27]:
    The security considerations are a one sentence pointer to RFC 3611.  While the
    RFC 3611
    considerations do apply, it would be helpful if this document noted any
    considerations
    unique to this report block, as with the security considerations
    for the Loss RLE report block
    in RFC 3611.  Without this information, the reader
    might infer that the security considerations
    are the same as for Loss RLE, which
    I don't think is true...
    
    It seems that this extension is intended for use in addition to the Loss RLE
    Report Block.  I also
    assume that the Loss RLE and Post Repair Loss RLE report
    blocks are protected by the same
    security mechanisms.  In this case, the only
    additional information that is revealed is the
    overall effectiveness of the loss
    repair mechanisms.  That is, unlike the Loss RLE report
    block, this extension
    does not facilitate multicast inference of network characteristics (MINC) 
    since
    any useful information has already been revealed.
    
    The open question is whether knowledge of the effectiveness of repair mechanisms
    on a
    particular system is helpful to an attacker.  (I would guess that it could
    be useful, but I will
    leave that up to the RTCP experts.)
  3. Dan Romascanu: Comment [2009-10-21]:
    1. It is not clear to me what item in the AVT WG charter this document is
    covering. I see that two new metric blocks are to be defined, one for  high
    resolution measurements of audio and speech quality and the second for quality
    of video, but it is not clear where does this document and a number of other of
    this WG I-Ds fit.
    
    2. It would be useful to clarify whether the applicability statements defined in
    RFC 3611 for packet-by-packet reporting blocks fully apply to the new block
    defined in this document and what are the differences if there are such
    differences. What is the applicability for network monitoring purposes?
  4. Robert Sparks: Comment [2009-10-21]:
    One thought to explore if it hasn't been already: If an attacker can inject
    post-repair reports and also induce loss of the RTP, then the processing at the
    sending endpoint could be convinced that no remedial changes are necessary (due
    to loss) when, in fact, they should be made. This would only be effective if no
    other feedback exposed the problem.
  5. Magnus Westerlund: Comment [2009-01-28]:
    During the fall we had a discussion about the issue of RTP sequence number wrap
    around. I did accept the decision to not expand the numberspace. However, I
    think there still should be a warning about this issue, and the need for senders
    to take care of this issue. Can you please add a paragraph or so about it?

draft-wilde-sms-uri

  1. Jari Arkko: Comment [2008-09-25]:
    I share the issue in 2nd part of Russ's Discuss: I also felt that the document
    brought in a bit too many details about the processing, formatting, and delivery
    of SMSes. This RFC does not define how SMSes are sent, it just defines URIs.
    Some overview is useful, of course.
  2. Pasi Eronen: Comment [2009-08-06]:
    I think the document would benefit from including an example with a
    non-global number (not starting with "+"), since the exact syntax used
    for them changed very recently (when going from version -15 to -16),
    and the change might not be obvious to someone who read the old
    versions.
  3. Russ Housley: Comment [2009-08-06]:
    
        
  4. Cullen Jennings: Comment [2009-10-21]:
    
        
  5. Alexey Melnikov: Comment [2009-08-24]:
    
        
  6. Chris Newman: Discuss [2008-09-22]:
        I consider this an important specification, am glad it is being
    produced, and believe the specification could be improved with an
    additional revision considering some or all of the issues mentioned
    in other discuss positions and mentioned here:
    
    1. The document needs a normative reference to the HTML 4.01 specification which
    defines the format for the media type
    application/x-www-form-urlencoded.
    
    2. The following text is factually incorrect:
    
       ... As SMS transport is
       "out-of-band" as far as normal HTTP over TCP/IP is concerned, this
       provides a way to fill in forms offline, and send the data without
       making a TCP connection to the server, as the set-up time, cost, and
       overhead for a TCP connection are large compared to an SMS message.
    
    With my iPhone, there are contexts where SMS is more expensive that
    HTTP/TCP (e.g. local use if I'm over my prepaid SMS limit).  In
    addition, SMS can be more expensive on the server infrastructure side;
    a two-way email-to-SMS gateway has to track a large amount of state
    because SMS has no extension fields for reply gateways.  That's special
    SMS-only state that's unnecessary with simple stateless HTTP/TCP
    connections.  Finally, I observe this contradicts the previous point
    that SMS "is a major source of revenue" (which implies it's expensive
    for end-users).
    
    3. The URI scheme doesn't have an extensibility model as far as I can
    tell.  In the case of the mailto URI we needed to add extensions to
    the original proposal over time.  Whether or not the same will be true
    for SMS, it would be helpful to clearly state: is more than one
    key-value after the "?" permitted.  If so, are unknown keys "must
    understand" or silently ignored?
    
    4. You need to discuss how use of comma as a delimiter between addresses
    interacts with use of comma within a telephone-subscriber (e.g., as
    the RFC 3966 ABNF permits in the isub= parameter).
     [This is addressed by erratum 203 on RFC 3966 as mentioned in the
      appendix, but I missed that on first reading.  It's perhaps worth
      mentioning that erratum in the text as well the appendix since it's
      important.]
    
    5. While you've defined the charset of the body parameter, the semantics
    are not defined.  Is a newline permitted?  If so, how is a newline
    encoded?  Perhaps a reference to 5198 would be helpful?
    
    6. Why is this "provisional" rather than "Permanent"? 
        
  7. Dan Romascanu: Comment [2008-09-25]:
    I support the issue raised by Magnus in his DISCUSS.
  8. Robert Sparks: Discuss [2009-10-21]:
        As far as I can tell, the document doesn't discuss how to compare two sms: URIs
    for equality. Should it? (Would these ever go into address books? Is it
    important to know when two of these containing the same list, but with the
    elements in different order, are the same list?) 
        
  9. Robert Sparks: Comment [2009-10-21]:
    
      

draft-ietf-krb-wg-cross-problem-statement

  1. Russ Housley: Discuss [2009-10-21]:
        
      Brian Carpenter provided a Gen-ART review of -04.  There where substantial
      changes to create -05.  Brian was not able to review all of the changes,
      but he does report that hes concerns with sections 5.5 and 5.6 were not
      resolved.  Brian's summary of his concerns is below.  These concerns
      deserve discussion.
    
      Section 5.5 makes a general assumption that a TGS exchange taking ~200ms
      is okay, but several times this is not. That may be true for the particular
      type of control system the authors consider, but may be wildly wrong (in
      either direction) for other controls applications. Also, the associated
      recommendations R-6 and R-7 are written as generalisations that I don't
      think offer any useful engineering guidance for protocol design.
    
      Section 5.6 describes a chicken-and-egg problem in authentication for
      roaming users but all it really does is transfer that chicken-and-egg
      problem into requirements R-3 and R-4. It's very circular, and the
      correct conclusion might be quite different: don't even try to solve
      this using Kerberos; use an IPsec (or TLS or SSH) session to connect
      into the home Kerberos domain. 
        
  2. Russ Housley: Comment [2009-10-21]:
    
      

draft-ietf-geopriv-lbyr-requirements

  1. Alexey Melnikov: Comment [2009-10-22]:
    I like the document.
    
    1.  Introduction
    
       As justification for a LbyR model, consider the circumstance that in
       some mobile networks it is not efficient for the end host to
       periodically query the Location Information Server (LIS) for up-to-
       date location information.  This is especially the case when ower
    
    Did you mean "owner"?
    
       availability is a constraint or when a location update is not
       immediately needed.

draft-ietf-eai-pop

  1. Ralph Droms: Discuss [2009-10-20]:
        Agreeing with Lars DISCUSS in the case of this doc...and we should discuss more
    generally how an Experimental doc can update a Standard. 
        
  2. Ralph Droms: Comment [2009-10-20]:
    
        
  3. Lars Eggert: Discuss [2009-10-16]:
        This document is going for Experimental and updates RFC1939, which is a Full
    Standard.
    
    In my reading, this document is not mandatory-to-implement for the POP3
    standard. As such, it doesn't need to (and IMO shouldn't) update RFC1939.
    
    If it indeed is mandatory-to-implement, I believe we have an issue. When
    protocols progress up the standards track, we drop pieces what we don't believe
    have sufficient interoperability testing or that are otherwise thought to be
    less stable. It's hence problematic to later glue such pieces (i.e., this
    Experimental spec) onto the original Full Standard protocol.
    
    I'd like to discuss on the call what folks think should be done here. 
        
  4. Lars Eggert: Comment [2009-10-16]:
    
        
  5. Adrian Farrel: Discuss [2009-10-22]:
        
    I think it would be valuable (and help with the discussions about an
    Experimental RFC updating a Standards Track one) to document the scope
    of the experiment. That is:
    - why is this an experiment?
    - how is the experiment confined?
    - what are the risks if the experiment escapes?
    - how will you judge the success (or otherwise) of the experiment?
    
    I think I agree that while an Experimental RFC can build on Standards
    Track work, it cannot "update" it. The meaning of "update" is often not
    fully understood, but in my understanding it means "to be conformant
    with the base RFC it is now necessary to be conformant with both RFCs."
    And that is why "updates" is not appropriate in this case. 
        
  6. Adrian Farrel: Comment [2009-10-22]:
    The start of section 2 is a little cryptic! Could you arrange to begin
    with some English text that introduces the formal definitions?
    
    Ditto section 3.
    
    ---
    
    Agree with Russ that the French needs to be checked, although I disagree
    with his interpretation of correct French :-)
  7. Russ Housley: Comment [2009-10-21]:
      Lars Eggert's DISCUSS; as Experimental, this cannot update RFC 1939.
    
      The Gen-ART Review by Brian Carpenter on 2009-10-17 asks some good
      questions:
    
      I would have expected a reference to RFC 5198 (PS for UTF-8 in
      protocols) as well as RFC 3629.
    
      I wonder whether any French person has checked the examples such as
      >
      > La Language commande a ete execute avec success
      >
      "Language" is not a French word. The French word for a specific
      language such as French is "langue".  Also, "success" is not a French
      word. It should be "succès" (that's a grave accent on the e, if UTF-8
      didn't quite get through). There are four other accents missing in the
      sentence.  I know we can't yet use UTF-8 in drafts but in that case, I
      suggest either using the usual U+HHHH notation for the accented
      characters, or choosing an example language that doesn't need accents.
      In any case the examples should be checked by a native speaker.
      (Actually the sentence makes very little sense anyway: "The language
      ordered has been executed with success.")
    
      The examples as presented would make the IETF look a bit silly in France.
  8. Cullen Jennings: Comment [2009-10-21]:
    support Lars discuss on update

draft-ietf-ipsecme-ikev2-ipv6-config

  1. Russ Housley: Discuss [2009-10-21]:
        
      The Gen-ART Review by Avshalom Houri on 2009-09-24 raised a concern
      about authentication and re-authentication.  In particular, I think
      that a bit more discussion of this paragraph is needed:
    
       The gateway uses the Link ID to look up relevant local state,
       verifies that the authenticated peer identity associated with
       the link is correct, and continues the handshake as usual.
    
      Based on the discussion following the posting of the Gen-ART Review,
      I expected an updated Internet-Draft. 
        
  2. Russ Housley: Comment [2009-10-21]:
      The Gen-ART Review by Avshalom Houri on 2009-09-24 suggested a
      section describing how the requirements in section 3 are being 
      addressed by the solution.

draft-ietf-nfsv4-federated-fs-reqts

  1. Adrian Farrel: Comment [2009-10-22]:
    Nice document. Thank you.
  2. Alexey Melnikov: Comment [2009-10-19]:
       A6:  In a federated system, we assume that an FSN MUST express, or
            can be used to discover, the following two pieces of
            information:
    
     [...]
    
            As an example, an FSN could be represented by a URL of the form
            nsdb.example.com/UUID
    
    Pedantic: this is actually not a proper URL.
    
            where nsdb.example.com is the FQDN of the
            server hosting the NSDB node and UUID is the string
            representation of the identifier.
    
    
       R9:   The projected namespace (and the objects named by the
             namespace) MUST be accessible to clients via at least one
             standard filesystem access protocol.
    
    What do you call a "standard filesystem access protocol"?
    
             a.  The namespace SHOULD be accessible to clients via versions
                 of the CIFS (SMB) protocol.
    
    Is there a reference for CIFS that can be used?
    (There was actually one earlier reference to CIFS in the document.)
    
             b.  The namespace SHOULD be accessible to clients via the NFSv4
                 protocol as described in [RFC3530].
    
             c.  The namespace SHOULD be accessible to clients via the NFSv3
                 protocol as described in [RFC1813].
    
             d.  The namespace SHOULD be accessible to clients via the NFSv2
                 protocol as described in [RFC1094].
    
    7.  Security Considerations
    
       A federation could contain multiple Public Key Infrastructure (PKI)
       trust anchors [RFC5280].  The federation protocols SHOULD define a
       mechanism for managing a fileserver's NSDB trust anchors
       [TA-MGMT-REQS].  A general purpose trust anchor management protocol
       [TAMP] would be appropriate, though it might be desirable for the
       federation protocols to facilitate trust anchor management by, for
       example, using trust anchor interchange formats [TA-FORMAT].
    
    It would be more logical to have these requirements elsewhere in the document,
    if they are indeed requirements.
    
    
    I think the following references are Informative:
    
       [RFC2203]  Eisler, M., Chiu, A., and L. Ling, "RPCSEC_GSS Protocol
                  Specification", RFC 2203, September 1997.
    
       [RFC2743]  Linn, J., "Generic Security Service Application Program
                  Interface Version 2, Update 1", RFC 2743, January 2000.
    
       [RFC4513]  Harrison, R., "Lightweight Directory Access Protocol
                  (LDAP): Authentication Methods and Security Mechanisms",
                  RFC 4513, June 2006.
    
       [RFC5246]  Dierks, T. and E. Rescorla, "The Transport Layer Security
                  (TLS) Protocol Version 1.2", RFC 5246, August 2008.

draft-braden-independent-submission

  1. Lars Eggert: Comment [2009-10-16]:
    Section 4., paragraph 1:
    >    Independent Stream authors will submit their material as Internet-
    >    Drafts.  These drafts will be submitted to, and stored in, the IETF
    >    Internet-Drafts repository in the same fashion as IETF Internet-
    >    Drafts.
    
      Minor comment: FWIW, April 1 RFCs are explicitly excluded from the
      requirement to be submitted as IDs first on
      http://www.rfc-editor.org/indsubs.html. How is rights transfer handled
      for them?
  2. Adrian Farrel: Discuss [2009-10-21]:
        I may have been watching this insufficiently, but...
    
    Section 5 makes several requests to the IETF Trust for action. Is this I-D/RFC
    the most efficient way to make those requests? Will the Trust even notice that
    we have made the request? How do we expect the Trust's public statements and
    commitments to be recorded?
    
    Hopefully, this can be addressed simply by you telling me what the current state
    of affairs is.
    
    ---
    
    Section 7 (the IANA section) also includes...
    
       This document does make specific request of the IASA, as described in
       preceding sections.
    
    Firstly, does this actually refer to section 5 rather than section 6? I can't
    see any specific requests for aciton in seciton 6 although there is an implicit
    request for the IPR collation service to apply (be extended?) to the Independent
    Stream.
    
    Second, I'm not sure that "hiding" this note about IASA in the IANA section is
    the best idea.
    
    I think this can be addressed by some simple edits. 
        
  3. Adrian Farrel: Comment [2009-10-21]:
    Comment removed after email discussions with Joel Halpern.
  4. Russ Housley: Comment [2009-10-16]:
      Throughout the document, ISE is expanded as "Independent Stream Editor."
      However, RFC 5620 uses  Independent Submission Editor.  Please use the
      term from RFC 5620.
    
      The Abstract says:
    
        This document specifies the procedures by which authors of RFC
        Independent Stream documents grant the community "incoming" rights
        for copying and using the text.  It also specifies the "outgoing"
        rights the community grants to readers and users of those documents,
        and it requests that the IETF Trust manage the outgoing rights to
        effect this result.
    
      s/effect/affect/
    
      Section 2 says:
    
        Section 8 of RFC 4846 presented the copyright rules for the
        Independent Submission stream.  The present document is intended to
        be fully consistent with that section, and to update it by clarifying
        the Trust-based formal procedures to effect those rules.
    
      The last sentence should be reworded to ensure that "Trust" is
      interpreted as the IETF Trust.
    
      Documents that become April 1st RFCs are not posted an I-Ds.  Should this
      document say anything about them?
  5. Cullen Jennings: Discuss [2009-10-21]:
        The draft says 
    
       Note also that this unlimited derivative works policy applies to all
       parts of an Independent Stream document, including any code.
       Therefore, no separate licensing procedure is required for extracting
       and adapting code that is contained in an Independent Stream document
       submitted under the (preferred) unlimited derivative works terms. 
    
    If this is a request to the Trustees, then it is inappropriate to publish at an
    RFC as it will be confused by people as what the rules are instead of what rules
    were requested. If it is statement of the rules, then I wonder if it would be
    better in the IAB stream. 
        
  6. Cullen Jennings: Comment [2009-10-21]:
    
      

draft-wu-softwire-4over6