IESG Narrative Minutes

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

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

Corrections from: Adrian, Magnus

1 Administrivia

  1. Roll Call 1134? EST
    (some difficulty in getting call underway, scribe arrived just after his own name was called, earlier attendance copied from jabber posting)
    Amy:
  2. Bash the Agenda
  3. Approval of the Minutes of the past telechat
  4. Review of Action Items from last Telechat

2. Protocol Actions

2.1 WG Submissions

2.1.1 New Items

  1. Using GSS-API Mechanisms in SASL: The GS2 Mechanism Family (Proposed Standard)
    draft-ietf-sasl-gs2-18
    Token: Pasi Eronen
    Note: Alexey Melnikov (alexey.melnikov@isode.com) is the document shepherd
    Discusses/comments (from ballot 2573):
    1. Ralph Droms: Comment [2009-11-30]:
      Nits:
    2. Adrian Farrel: Comment [2009-11-27]:
      Section 10.1 - nit
    3. Russ Housley: Comment [2009-12-02]:
      editorial improvements suggested in the Gen-ART Review by Spencer Dawkins
    4. Alexey Melnikov: Comment [2009-12-02]:
      agreeing with Adrian's comment
      From SecDir review: ...
    5. Robert Sparks: Comment [2009-12-01]:
      Is [tls-unique] pointing to the IANA registry?

    Telechat:

  2. Support for RSVP in Layer 3 VPNs (Proposed Standard)
    draft-ietf-tsvwg-rsvp-l3vpn-05
    Token: Magnus Westerlund
    IPR: Cisco's Statement about IPR claimed in draft-ietf-tsvwg-rsvp-l3vpn-00
    Discusses/comments (from ballot 3011):
    1. Adrian Farrel: Discuss [2009-11-30]:
      some signigicant concerns about the reasoning for the protocol extensions proposed in this document...
    2. Adrian Farrel: Comment [2009-11-30]:
      Since the RSVP message is an IP encapsulated message, if there was no IP reachability, the message would not get there
    3. Alexey Melnikov: Comment [2009-11-18]:
      3.6. Other RSVP Messages... not using RFC 2119 keywords?

    Telechat:

  3. Authentication and Confidentiality in PIM-SM Link-local Messages (Proposed Standard)
    draft-ietf-pim-sm-linklocal-09
    Token: Adrian Farrel
    Note: Document shepherd is Stig Venaas <stig@venaas.com>
    Discusses/comments (from ballot 3095):
    1. Jari Arkko: Discuss [2009-12-02]:
      "PIM-SM packets that fail the confidentiality checks MUST be silently discarded"
      What is the "confidentiality check"?
    2. Alexey Melnikov: Comment [2009-11-28]:
      4. Authentication... reference please
      5. Confidentiality... as above
    3. Tim Polk: Discuss [2009-12-03]:
      I think it would be prudent to specify the "unique Security Association for each peer" method (method one in Section 8, as described in Figure 2 and paragraph 2 of section 8) as SHOULD implement.

    Telechat:

  4. Support of address families in OSPFv3 (Proposed Standard)
    draft-ietf-ospf-af-alt-09
    Token: Ross Callon
    Discusses/comments (from ballot 3174):
    1. Ralph Droms: Comment [2009-12-01]:
      A few nits
    2. Adrian Farrel: Discuss [2009-11-27]:
      I think this draft updates RFC 5340.
      this draft says we MUST use an Instance ID in the range 64-95 (instead of 0)
      Section 2.7: Including the whole packet format gives two normative definitions for the packet
      It would be good to identify the registries and the details of what you want included in the registries
    3. Adrian Farrel: Comment [2009-11-27]:
      A bit odd to have the Acknowledgements in an Appendix
    4. Russ Housley: Discuss [2009-12-02]:
      The Gen-ART Review by Christian Vogt raised one thing that could be changed to improve readability
    5. Russ Housley: Comment [2009-12-02]:
      The Gen-ART Review by Christian Vogt raised the following...
    6. Alexey Melnikov: Comment [2009-11-28]:
      Agreeing with Adrian about the missing Updates field
      2.2. OSPFv3 Options Changes: I don't see any bit called "MC" in the table below
      2.7. Database Description Maximum Transmissoin Unit (MTU): Is MTU in network byte order?
    7. Tim Polk: Discuss [2009-12-03]:
      I wanted to be sure the reference to the MC-bit in section 2.2 is deleted, as agreed to in Acee's email exchange with Alexey
    8. Dan Romascanu: Comment [2009-12-02]:
      support Adrian's DISCUSS about the need to mention 'update RFC 5340'
      it would be useful if some text would be added about the limitations of mixing routers compliant with this specification and 'non-capable' routers in the topology...

    Telechat:

  5. Advertising a Router's Local Addresses in OSPF TE Extensions (Proposed Standard)
    draft-ietf-ospf-te-node-addr-07
    Token: Ross Callon
    Note: Acee Lindem (acee@redback.com) is the document shepherd.
    Discusses/comments (from ballot 3185):
    1. Lars Eggert: Comment [2009-12-02]:
      Section 3., paragraph 0: This section would make a good appendix
      Section 4.1., paragraph 6: You mean: sum of the *lengths* ...
      Section 4.1., paragraph 10: The length calculation needs to be rounded up to be accurate
      Section 4.1., paragraph 11: "sum of *lengths*"
    2. Adrian Farrel: Comment [2009-11-27]:
      please consider fixing these nits...
    3. Alexey Melnikov: Comment [2009-11-27]:
      On page 6: I think a pointer to Appendix A.4.1.1 in RFC 5340 would be helpful here
      4.2. Operation: It looks like this section should be using "MUST"s instead of "must"s.
    4. Dan Romascanu: Comment [2009-12-02]:
      In the IANA considerations section: '... to create and maintain the resgistry ...' seems more appropriate

    Telechat:

  6. Label Switched Path (LSP) Dynamic Provisioning Performance Metrics in Generalized MPLS Networks (Proposed Standard)
    draft-ietf-ccamp-lsp-dppm-10
    Token: Adrian Farrel
    Note: Lou Berger (lberger@labn.net) is the document shepherd.
    Discusses/comments (from ballot 3240):
    1. Ralph Droms: Comment [2009-12-02]:
      What, exactly, does the term "real number" mean?
      Nits
    2. Lisa Dusseault: Comment [2009-12-01]:
      The document frequently contains phrasing like "The value of X is either a real number, or an undefined number of milliseconds."
      Anywhere the phrase "undefined number of milliseconds" occurs, I believe this could be clearer
    3. Russ Housley: Comment [2009-12-02]:
      Please expand "LSP" on first use.
      Several editorial improvements were suggested in the Gen-ART Review by Francis Dupont
    4. Tim Polk: Discuss [2009-12-03]:
      The security considerations section needs to be expanded.
    5. Tim Polk: Comment [2009-12-03]:
      ppm documents have addressed the following concerns in security considerations: "There are two types of security concerns: potential harm caused by the measurements, and potential harm to the measurements".
    6. Dan Romascanu: Discuss [2009-12-02]:
      it is odd that implementing the metrics in the two documents is a 'MAY' why performing the measurements based on the implementations is a 'SHOULD'...
      I think that the document should be more specific on what exact attacks on the control plane an implementer or operator should care about...

    Telechat:

  7. Transmission of IPv4 packets over IEEE 802.16's IP Convergence Sublayer (Proposed Standard)
    draft-ietf-16ng-ipv4-over-802-dot-16-ipcs-06
    Token: Ralph Droms
    Note: Gabriel Montenegro (g_e_montenegro@yahoo.com) is the document shepherd.
    Discusses/comments (from ballot 3242):
    1. Adrian Farrel: Comment [2009-11-28]:
      A few comments all at the level of nits
    2. Alexey Melnikov: Discuss [2009-11-28]:
      Appendix C. WiMAX IPCS MTU size: why have 2 similar but incompatible specs?
    3. Alexey Melnikov: Comment [2009-11-28]:
      4.2. Frame Format for IPv4 Packets: Nit: it would be nicer to readers to say that MSB means "Most Significant Byte" and LSB means "Less Significant Byte".
    4. Dan Romascanu: Discuss [2009-12-03]:
      David Black performed a quick OPS-DIR review and raised a number of issues which were not answered as far as I know, and should be clarified before approving this document.
    5. Magnus Westerlund: Comment [2009-12-01]:
      Section 4.2: It looks confusing that 0 = 1

    Telechat:

2.1.2 Returning Items

  1. (none)

2.2 Individual Submissions

2.2.1 New Items

  1. PATCH Method for HTTP (Proposed Standard)
    draft-dusseault-http-patch-16
    Token: Alexey Melnikov
    Note: Mark Nottingham <mnot@mnot.net> agreed to be the document shepherd.

    Discusses/comments (from ballot 3079):
    1. Adrian Farrel: Discuss [2009-12-01]:
      Can someone please confirm that the apropriate Expert Review was conducted
    2. Adrian Farrel: Comment [2009-12-01]:
      Section 1:... This is a bit strong. The new method seems to be desirable to increase the functionality and improve performance.
      Section 4.1: Would be nice to name the registry more precisely.
    3. Russ Housley: Discuss [2009-11-30]:
      The Last Call comment from Julian Reschke needs to be resolved.

    Telechat:

  2. FTP Command and Extension Registry (Proposed Standard)
    draft-klensin-ftp-registry-03
    Token: Alexey Melnikov
    Note: Barry Leiba <barryleiba@computer.org> is the document shepherd.

    Discusses/comments (from ballot 3200):
    1. Ralph Droms: Comment [2009-12-02]:
      section 2.2: what does "either new or modified" mean?
    2. Russ Housley: Discuss [2009-11-30]:
      Downref: Normative reference to Experimental RFC 2773
    3. Russ Housley: Comment [2009-11-30]:
      There has been discussion of the comments in the Gen-ART Review by Ben Campbell. I expected some changes to the document based on the discussion.
    4. Robert Sparks: Discuss [2009-12-02]:
      Given the changes to the strength of implementation requirements on some of the extensions, should this document Update 2389 and 2428 (should 3659 also be in this list)?

    Telechat:

2.2.2 Returning Items

  1. (none)

3. Document Actions

3.1 WG Submissions

3.1.1 New Items

  1. Securing Neighbor Discovery Proxy Problem Statement (Informational)
    draft-ietf-csi-sndp-prob-03
    Token: Ralph Droms
    Note: The document shepherd is Marcelo Bagnulo (marcelo@it.uc3m.es)
    Discusses/comments (from ballot 3247):
    1. Jari Arkko: Discuss [2009-12-03]:
      Section 2.3: Classic bridging does not require ND proxying at all...
    2. Pasi Eronen: Discuss [2009-12-01]:
      I think the text about IKEv2 (Section 2.2) is quite misleading.
      For Mobile IPv6... are there any SDOs that are even considering deployments where one MN would *ever* see ND queries from another MN, even if both are at home?
      two items from Stephen Farrell's SecDir review
    3. Adrian Farrel: Comment [2009-12-01]:
      Section 5: I read this a couple of times and it doesn't compute
    4. Russ Housley: Comment [2009-12-02]:
      Several editorial improvements were suggested in the Gen-ART Review by Vijay Gurbani.
    5. Tim Polk: Comment [2009-12-02]:
      my quick research on ring signature schemes came up with descriptions very different from those in section 4.1.3

    Telechat:

  2. Basic Socket Interface Extensions for Host Identity Protocol (HIP) (Experimental)
    draft-ietf-hip-native-api-09
    Token: Ralph Droms
    Note: Gonzalo Camarillo (Gonzalo.Camarillo@ericsson.com) is the document shepherd.
    Discusses/comments (from ballot 3250):
    1. Lars Eggert: Discuss [2009-12-02]:
      Since this extends a POSIX spec, are they aware of this effort?
    2. Pasi Eronen: Discuss [2009-12-03]:
      The draft has normative references to draft-ietf-btns-c-api, which is currently expired. It's not clear that the energy needed to finish it exists...
    3. Adrian Farrel: Comment [2009-12-01]:
      Acronyms used without expansion
    4. Russ Housley: Comment [2009-12-02]:
      Several editorial improvements were suggested in the Gen-ART Review by Ben Campbell.
    5. Alexey Melnikov: Comment [2009-11-28]:
      Some examples would be nice
      two Normative References look Informative to me.
    6. Robert Sparks: Discuss [2009-12-01]:
      two normative references to Informational documents that are in progress (one is long expired).
    7. Robert Sparks: Comment [2009-12-01]:
      ORCHIDs currently have a default sunset in 2014 (What will maintenance of the stream look like if something unexpected happens and this ORCHID assignment is not renewed?)

    Telechat:

3.1.2 Returning Items

  1. (none)

3.2 Individual Submissions Via AD

3.2.1 New Items

  1. The SatLabs Group DVB-RCS MIB (Informational)
    draft-combes-ipdvb-mib-rcs-08
    Token: Jari Arkko
    Note: Document Shepherd is Gorry Fairhurst <gorry@erg.abdn.ac.uk>
    Discusses/comments (from ballot 2896):
    1. Ron Bonica: Discuss [2009-12-02]:
      it seems odd to use the RFC series to document a proprietary MIB.
    2. Russ Housley: Comment [2009-12-02]:
      Several minor editorial improvements were suggested in the Gen-ART Review by Avshalom Houri.

    Telechat:

  2. RFC 2731 ("Encoding Dublin Core Metadata in HTML") is Obsolete (Informational)
    draft-reschke-rfc2731bis-04
    Token: Alexey Melnikov
    Note: Bernard Desruisseaux <bernard.desruisseaux@oracle.com> is the document shepherd.
    RFC Editor seems to be fine with the idea of obsoleting an RFC submitted directly to RFC Editor (e.g. RFC 2731) with an AD sponsored document.
    Discusses/comments (from ballot 3198):
    1. Lars Eggert: Comment [2009-12-02]:
      Appendix C., paragraph 7: Whether the format is still in use doesn't really matter. It seems that RFC 2731 is no longer the definitive spec
    2. Cullen Jennings: Discuss [2009-12-02]:
      On the call I would like to talk about what happens next process wise (does this draft become an RFC or do we jut mark things obsolete?
      I'd like a stable normative reference to the document that obsoletes 2731.

    Telechat:

  3. The OAuth Core 1.0 Protocol (Informational)
    draft-hammer-oauth-07
    Token: Lisa Dusseault
    Discusses/comments (from ballot 3235):
    1. Lars Eggert: Comment [2009-12-02]:
      Is there a reason we're not publishing this as PS?
    2. Adrian Farrel: Comment [2009-12-01]:
      Thank you...
    3. Russ Housley: Discuss [2009-12-02]:
      Appendix A talks about "Differences from the Community Edition." Is there a stable reference that can be included in this Appendix?
    4. Russ Housley: Comment [2009-12-02]:
      I think it would be better to say in the introduction: 'The resulting OAuth protocol was stabilized at version 1.0 in October 2007 and published at the oauth.net website <http://oauth.net>."
    5. Cullen Jennings: Discuss [2009-12-02]:
      I don't think we have consensus to publish this. When the WG was formed, it was clear people did not want the IETF to rubber stamp the existing thing but that is exactly what is happen here.
      I also feel there are technical issues with this specification as an IETF RFC but theses do not seem to be worth discussing given my larger point.
    6. Tim Polk: Discuss [2009-12-02]:
      Section 4.13 should be revised to reference "RSA-SHA1" signatures, point to the current NIST statement, and clarify that NIST wants to phase out the use of SHA-1 *in digital signatures* by 2010.
    7. Tim Polk: Comment [2009-12-02]:
      (six editorial items)

    Telechat:

3.2.2 Returning Items

  1. (none)

3.3 Independent Submissions Via RFC Editor

3.3.1 New Items

  1. 4over6 Transit Solution using IP Encapsulation and MP-BGP Extensions (Experimental)
    draft-wu-softwire-4over6-03
    Token: Ralph Droms
    Discusses/comments (from ballot 3249):
    1. Ron Bonica: Comment [2009-12-02]:
      Since this document describes something that has already been done, its status should probably be INFORMATIONAL, not EXPERIMENTAL.
    2. Lars Eggert: Comment [2009-12-02]:
      Contains several unused references.
    3. Adrian Farrel: Discuss [2009-12-01]:
      If this is a record of your experiment that is now concluded, I think that you should class the I-D as Informational. If the experiment is intended to continue, I think you should add a seciton to describe the on-going experiment.
      Section 1: prefer "describes experimental extensions..."

    Telechat:

  2. Security Issues and Solutions in Peer-to-peer Systems for Realtime Communications (Informational)
    draft-irtf-p2prg-rtc-security-05
    Token: Robert Sparks
    Note: Stefano Previdi (sprevidi@cisco.com) is the document shepherd.
    Discusses/comments (from ballot 3261):
    1. (none)

    Telechat:

3.3.2 Returning Items

  1. Diversion Indication in SIP (Historic)
    draft-levy-sip-diversion-10
    Token: Robert Sparks
    Discusses/comments (from ballot 3213):
    1. Jari Arkko: Discuss [2009-11-18]:
      Could we get the RFC editor and authors to agree to put the IESG note to the body of the document, in which case no note would be needed?
    2. Jari Arkko: Comment [2009-11-18]:
      typo
    3. Adrian Farrel: Discuss [2009-12-02]:
      I agree with the point made by Robert in his initial email to the RFC Editor about the "voice" used in the draft. Starting from the first line of the Abstract, this document reads like a current proposal for a protocol solution.
    4. Russ Housley: Comment [2009-11-11]:
      some edits to IESG note
    5. Cullen Jennings: Discuss [2009-11-18]:
      Let me provide a bit of background...

    Telechat:

1314 EST break

1319 EST back

4 Working Group Actions

4.1 WG Creation

4.1.1 Proposed for IETF Review

  1. Multiple AoR reachabiliTy InformatioN Indication (martini)
    Token: Cullen

    Telechat:

4.1.2 Proposed for Approval

  1. HTTP State Management Mechanism (httpstate)
    Token: Lisa

    Telechat:

4.2 WG Rechartering

4.2.1 Under evaluation for IETF Review

  1. (none)

4.2.2 Proposed for Approval

  1. (none)

5. IAB News We can use

  1. DaveO: send summary to iesg email; spending a lot of cycles on IAB views of deployment on RPKI deployment, hope to wrap up in a week or two; anycast architecture progressing; description of IAB stream progressing; working on plenary plans for Anaheim and Maastricht; global internet traffic in Anaheim, economic issues for Maastricht

6. Management Issues

  1. RIM IPR disclosure and application/3gpp-ims+xml media type registration (Alexey Melnikov)

    Telechat:

  2. Document Authorship as IESG Statement (Dan Romascanu)

    Telechat:

  3. rfcxx99 documents (Sandy Ginoza)

    Telechat:

7. Agenda Working Group News

1413 EST Adjourned



Appendix: Snapshot of discusses/comments

draft-ietf-sasl-gs2

  1. Ralph Droms: Comment [2009-11-30]:
    Nits:
    
    The third para of the Introduction, s/The "Kerberos/the "Kerberos/
    
    Section 3.2, s/obliterate/eliminates/
    
    Section 5.1, s/takes a/take a/
  2. Adrian Farrel: Comment [2009-11-27]:
    Section 10.1 - nit
          OM_uint32 gss_inquire_saslname_for_mech(
            OM_uint32     *minor_status,
            const gss_OID  desired_mech,
            gss_buffer_t   sasl_mech_name,
            gss_buffer_t   mech_name,
            gss_buffer_t   mech_description,
          );
    Superfluous comma after mech_description.
  3. Russ Housley: Comment [2009-12-02]:
      Several editorial improvements were suggested in the Gen-ART Review
      by Spencer Dawkins.  Please consider them.
  4. Alexey Melnikov: Comment [2009-12-02]:
    I am agreeing with Adrian's comment.
    
    From SecDir review:
    
    OLD:
       GS2 does not use any GSS-API per-message tokens.  Therefore the
       setting of req_flags related to per-message tokens is irrelevant.
    
    NEW:
       GS2 does not use any GSS-API per-message tokens.  Therefore the
       per-message token ret_flags from GSS_Init_sec_context() and
       GSS_Accept_sec_context() are irrelevant; implementations SHOULD NOT
       set the per-message req_flags.
    
    Nico has suggested to add:
    
        FLAG	SERVER CB SUPPORT	DISPOSITION
        ----	-----------------	-----------
    
        n		Irrelevant		If server disallows non-channel-
                                            bound authentication, then fail
    
        y		CB not supported	Authentication may succeed
    
        y		CB supported		Authentication must fail
    
        p		CB supported		Authentication may succeed, with
                                            CB used
    
        p		CB not supported	Authentication will fail
    
        <none>	CB not supported	Client does not even try because
                                            it insists on CB
  5. Robert Sparks: Comment [2009-12-01]:
    Is [tls-unique] pointing to the IANA registry? If so, could it include a link?

draft-ietf-tsvwg-rsvp-l3vpn

  1. Ralph Droms: Comment [2009-11-30]:
    
        
  2. Adrian Farrel: Discuss [2009-11-30]:
        I have some signigicant concerns about the reasoning for the protocol
    extensions proposed in this document.
    
    I understand that this draft was last called in both the TSVWG and the
    L3VPN WG. That would mean that my Discuss points are going against the
    consensus of two working groups, however when I scan the archives I
    cannot see any comments of support made during the last call. In view
    of this, and examining the small number of emails about this work on the
    list, I don't feel that there is evidence of strong consensus, and so I
    am not worried about voicing my concerns. 
    
    In section 1, three key challenges are presented to be overcome in order
    to extend intra-VPN RSVP to operate over the PE-CE links. These are as
    follows:
    
    > o  RSVP Path message processing depends on routers recognizing the
    >    router alert option in the IP header.  However, packets traversing
    >    the backbone of a BGP/MPLS VPN are MPLS encapsulated and thus the
    >    router alert option is not normally visible to the egress PE.
    
    It is unclear why the router alert option would not be visible to the
    egress PE. The full IP header of all packets arriving on an LSP across
    is available for inspection. Indeed, the address fields are used for VRF
    lookup, and other header fields may be used for hashing if there are two
    parallel links between PE and CE.
    
    This doesn't seem to be a realistic motivation for the work. 
    
    It may be that some implementations have difficulty in inspecting the
    router alert option at the end of an LSP, but that it not something to
    solve through modifications to the protocol specifications.
    
    It may be that the use of the router alert option is no longer 
    considered a good idea for intercepting RSVP packets. This may be a 
    valid concer, but it has already been addressed in RSVP-TE and requires
    a change to the core RSVP specificaiton to allow IP packets to be 
    targeted at specific transit hops (not at the ultimate destination).
    
    > o  BGP/MPLS VPNs support non-unique addressing of customer networks.
    >    Thus a PE at the ingress or egress of the provider backbone may be
    >    called upon to process Path messages from different customer VPNs  
    >    with non-unique destination addresses.
     
    This is true, but it is exactly the case for normal data IP packets.
    In fact, the whole point about RSVP packets is that they are forwarded
    along the same path as the data packets, so it is no suprise that if
    data packets can be correctly delivered, so can RSVP packets.
    
    This issue does not appear to be a reason for this work.
    
    It may be that some implementations have an issue linking in correctly
    with the per-VPN router state, but that is not cause for changing the
    protocol specifications.
    
    > o  A PE at the ingress of the provider's backbone may receive Resv
    >    messages corresponding to different customer VPNs from other PEs,
    >    and needs to be able to associate those Resv messages with the
    >    appropriate customer VPNs.
    
    This is exactly the same issue as or handling Path messages. The Resv
    will arrive on an LSP that will identify the VPN to which the Resv 
    applies. This can be used to find the associated Path state, determine
    the next hop for the Resv, and identify the correct VRF for routing the
    Resv.
    
    Again, this is not a reason for these protocol extensions.
    
    Section 1 goes on to say that:
    
    > Additionally, it may be desirable to perform admission control over
    > the provider's backbone on behalf of one or more L3VPN customers.
    > Core (P) routers in a BGP/MPLS VPN do not have forwarding entries for
    > customer routes, and thus cannot natively process RSVP messages for
    > customer flows.  Also the core is a shared resource that carries
    > traffic for many customers, so issues of resource allocation among
    > customers and trust (or lack thereof) must also be addressed.  This
    > draft also specifies procedures for supporting such a scenario.
    
    If resources need to be reserved in the core network for LSPs then the
    RSVP messages must follow the same paths as the LSPs (and clearly not
    be encapsulated in the LSPs). This case does open up a variety of 
    addressing and resource sharing (policy) issues within the core of the
    network. Such issues are easily solved by using RSVP-TE to establish
    the LSPs across the core.
    
    I am left, therefore, with the feeling that, while this work might not
    be significantly harmful, it is also not very useful and may be a
    distraction.
    
    I have two supplementary issues
    
    1. Document Shepherd write-up template that can be found at
       http://www.ietf.org/IESG/content/Doc-Writeup.html asks...
    
       > Are there existing implementations of the protocol?  Have a
       > significant number of vendors indicated their plan to
       > implement the specification?
    
       Having such implementations or plans is not a requirement for
       publication. Answering the questions, however, would be a
       great help in understanding the value of this work. 
    
       For example, perhaps it should be Experimental since it describes
       changes for running RSVP in core networks. Or perhaps it should
       be Informaitonal because it describes one vendor's (IPR disclosed)
       implementation.
    
    2. The L3VPN working group is working on a draft on "Requirements for
       supporting Customer RSVP and RSVP-TE over a BGP/MPLS IP-VPN" (see
       draft=ietf-l3vpn-e2e-rsvp-te-reqts).
    
       Section 7.4 of this draft seems to acknowledge the existence of the
       L3VPN WG work, but discount it...
    
       > The requirements specified in that draft are similar
       > to those addressed by this document, in that both address the issue
       > of handling RSVP requests from customers in a VPN context.  It is
       > possible that the solution described here could be adapted to meet
       > the requirements of [I-D.ietf-l3vpn-e2e-rsvp-te-reqts].  To the
       > extent that this draft uses signalling extensions described in
       > [RFC3473] which have already been used for GMPLS/TE, we expect that
       > CE-CE RSVP/TE will be incremental work built on these extensions.
       > These extensions will be considered in a separate document.
    
       It does not seem right to me to push these protocol extensions in the
       knowledge that is is only "possible" that they could be adapted to 
       meet the requirements or the generic situation.
    
       It would be more reasonable to identify the full set of requirements
       for the problem space and then work on a solution that was either:
       - generally applicable
       or
       - applicable to a liited subset of the requirements with a clear 
         explanation of why a single solution was not developed. 
        
  3. Adrian Farrel: Comment [2009-11-30]:
    Section 3.1
    
    > Use of the VPN-IPv4
    > RSVP_HOP object enables RSVP control plane reachability between any
    > two adjacent RSVP hops in a MPLS VPN (e.g. a PE in AS 1 and a PE in
    > AS2), regardless of whether they have IP reachability to each other.
    
    This isn't the case. Since the RSVP message is an IP encapsulated
    message, if there was no IP reachability, the message would not get
    there!
    
    What you are doing is allowing a very narrow IP control plane channel
    in band with the payload data of the MPLS VPN. In other words, you
    are encapsulating IP/RSVP packets onto the LSP.
    
    That is the thing that enables control plane reachability.
    
    Your new object enables determination of VPN disambiguation at the PE
    and CE. But that is not what is described.
    
    ---
    
    It would be really nice if the desciptive text in Section 3 could make
    direct reference to the steps in Section 2.1.
  4. Alexey Melnikov: Comment [2009-11-18]:
    3.6.  Other RSVP Messages
    
     Comment: not using RFC 2119 keywords? The same comment probably applies to
     other sections, but this is where I've noticed.

draft-ietf-pim-sm-linklocal

  1. Jari Arkko: Discuss [2009-12-02]:
        The document says:
    
    o  PIM-SM packets that fail the confidentiality checks MUST be
       silently discarded, although an implementation is RECOMMENDED to
       maintain a counter of such packets.  Note: this is an auditable
       event as described in RFC 4302 [RFC4302] and RFC 4303 [RFC4303].
    
    What is the "confidentiality check"? Is this a copy-paste-error from
    the authentication text few lines above, or do you have some specific
    requirement on what kind of an ESP SA needs to be used? But the SPD
    and SAD already define the requirements on those, so its not clear
    to me why you have to say anything additional. 
        
  2. Jari Arkko: Comment [2009-12-02]:
    
        
  3. Alexey Melnikov: Comment [2009-11-28]:
    4.  Authentication
    
       Implementations conforming to this specification MUST support
       authentication for PIM-SM link-local messages.  Implementations
       conforming to this specification MUST support HMAC-SHA1.
    
    A reference to the document that defines authentication using HMAC-SHA1
    would be very helpful here.
    And BTW, did you mean HMAC-SHA1-96 mentioned in RFC 4835?
    
    5.  Confidentiality
    
       Implementations conforming to this specification SHOULD support
       confidentiality for PIM-SM.  Implementations supporting
       confidentiality MUST support AES-CBC with a 128-bit key.
    
    As above.
  4. Tim Polk: Discuss [2009-12-03]:
        Given the known limitations of manual keying, and the limitations of current
    automated keying
    methods for routing protocols, I am comfortable with manual
    keying being the mandatory to
    implement method.  However, we are about to form a
    wg with the goal of developing practical
    automated key management for routing
    protocols.
    
    I think it would be prudent to specify the "unique Security Association for each
    peer" method
    (method one in Section 8, as described in Figure 2 and paragraph 2
    of section 8) as
    SHOULD implement.  Implementations that support this method
    will be more amenable to
    migrating from manual keying to automated keying. 
        
  5. Tim Polk: Comment [2009-12-03]:
    
      

draft-ietf-ospf-af-alt

  1. Ralph Droms: Comment [2009-12-01]:
    A few nites...
    
    From section 1:
    
       There are requirements to advertise other AFs
       in OSPFv3 including multicast IPv6, unicast IPv4, and multicast IPv4.
    
    Can details about the source and nature of these requirements be provided?
    
    In section 3:
    
       Currently the entire Instance ID number space is used for IPv6
       unicast. 
    
    Can a reference to this usage specification be cited here?
    
    Expand "LSAs" on first use?
    
    In section 2.2:
    
      s/When a router supports AF/When a router supports AF Instance IDs/
    
    for clarity?
  2. Adrian Farrel: Discuss [2009-11-27]:
        
    A good piece of work and a reasonable solution to the problem. I will vote
    "Yes" when we have resolved my relatively small Discuss issues.
    
    ---
    
    I think this draft updates RFC 5340.
    My reasoning is that RFC 5340 imposes no restrictions on the use of
    the Instance ID, but this document places semantics on the value of
    that field.
    
    ---
    
    RFC 5340 says
       Instance ID
          Every interface is assigned an Instance ID.  This should default
          to 0.  It is only necessary to assign a value other than 0 on
          those links that will contain multiple separate communities of
          OSPF routers.  For example, suppose that there are two communities
          of routers on a given ethernet segment that you wish to keep
          separate.
          The first community is assigned an Instance ID of 0 and all the
          routers in the first community will be assigned 0 as the Instance
          ID for interfaces connected to the ethernet segment.  An Instance
          ID of 1 is assigned to the other routers' interfaces connected to
          the ethernet segment.  The OSPF transmit and receive processing
          (see Section 4.2) will then keep the two communities separate.
    Now, suppose we have a link that only supports IPv4 unicast. According
    to the text in RFC 5340, we have to use (should use / can use) Instance
    ID 0 on this link.
    But this draft says we MUST use an Instance ID in the range 64-95.      
    At the very least this is cause for "updates RFC5340", but I think you 
    need to call out this change more clearly to avoid interop problems.
    
    ---
    
    Furthermore, in section 2.3 you have
       Prefixes which don't match the AF of the OSPFv3 instance, MUST be
       discarded in any route computation.
    This is an interoperability change from RFC 5340 since legacy 
    implementations are allowed to send all addresses with (e.g.) Instance
    ID 0.
    
    ---
    
    Section 2.7
    I am not comfortable with the reinclusion of the figure for the OSPFv3
    database description packet. It seems to me that you are just
    reinterpretting one field slightly and defining a new bit. Including the
    whole packet format gives two normative definitions for the packet.
    
    ---
    
    Section 5
    The IANA section could use some tidying up, although IANA has resolved
    some issues during IETF last call.
    Perhaps the right thing to do is to update the document in line with 
    the discussions with IANA.
    Points that I notice...
    
       The following IANA assignments are to be made from existing
       registries:
    
    ...but the second piece of work listed is a new registry.
    
    It would be good to identify the registries and the details of what
    you want included in the registries. 
        
  3. Adrian Farrel: Comment [2009-11-27]:
    A bit odd to have the Acknowledgements in an Appendix
  4. Russ Housley: Discuss [2009-12-02]:
        
      The Gen-ART Review by Christian Vogt raised one thing that could be
      changed to improve readability:
      > 
      > The document uses the acronym "AF" both to denote the term address
      > family, as well as to refer to the OSPF extensions being specified in
      > the document (e.g., in the definition of the AF bit in section 2.2).
      > This is confusing, in particular because "AF" is explicitly defined only
      > to mean the former, not the latter.  I suggest using a different name,
      > e.g., "AF support", to denote the OSPF extensions being specified, and
      > adding a definition for this to the introduction of the document.
      > 
      Is there any reason that this change should not be made? 
        
  5. Russ Housley: Comment [2009-12-02]:
      The Gen-ART Review by Christian Vogt raised the following:
      >
      > In section 3, "Backwards Compatibility", it may furthermore be worth
      > mentioning that all modifications to OSPFv3, as specified in this
      > document, exclusively affect the use of OSPFv3 for new address families.
      > Since this is a prerequisite for backwards compatibility, it will
      > further support the backwards compatibility claim of this section.
  6. Alexey Melnikov: Comment [2009-11-28]:
    Agreeing with Adrian about the missing Updates field.
    
    2.2.  OSPFv3 Options Changes
    
       A new AF-bit is added to the OSPFv3 options field.  V6-bit and MC-bit
       are only applicable to the IPv6 unicast AF.
    
    I don't see any bit called "MC" in the table below:
    
                                   1                     2
               0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8  9  0  1  2  3
              +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+-+--+-+-+--+--+--+
              | | | | | | | | | | | | | | | |AF|*|*|DC|R|N|x | E|V6|
              +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+-+--+-+-+--+--+--+
    
    2.7.  Database Description Maximum Transmissoin Unit (MTU)
          Specification for Non-IPv6 AFs
    
            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
           +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
           |              6 (TBD)          |               4               |
           +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
           |                           IPv6 MTU                            |
           +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    
    Is MTU in network byte order?
  7. Tim Polk: Discuss [2009-12-03]:
        This is a very minor discuss, but I wanted to be sure the reference to the MC-
    bit in section
    2.2 is deleted, as agreed to in Acee's email exchange with
    Alexey.  Suggested RFC Editor's
    Note:
    
    OLD
       A new AF-bit is added to the OSPFv3 options field.  V6-bit and MC-bit
       are only applicable to the IPv6 unicast AF.
    NEW
       A new AF-bit is added to the OSPFv3 options field.  The V6-bit
       is only applicable to the IPv6 unicast AF. 
        
  8. Tim Polk: Comment [2009-12-03]:
    
        
  9. Dan Romascanu: Comment [2009-12-02]:
    I support Adrian's DISCUSS about the need to mention 'update RFC 5340' in the
    header of the document because of the changing of semantics in the Instance ID.
    This being said I think that the backwards compatibility section demonstrates
    that there are no backward compatibility issues, although it would be useful if
    some text would be added about the limitations of mixing routers compliant with
    this specification and 'non-capable' routers in the topology, and maybe
    operational recommendations about the transition of the network to a fully
    compliant configuration.

draft-ietf-ospf-te-node-addr

  1. Lars Eggert: Comment [2009-12-02]:
    Section 3., paragraph 0:
    > 3. Rejected Potential Solution
    
      This section would make a good appendix.
    
    Section 4.1., paragraph 6:
    >    The Node IPv4 Local Address sub-TLV length is in octets. It is the
    >    sum of all n IPv4 Address encodings in the sub-TLV where n is the
    >    number of local addresses included in the sub-TLV.
    
      You mean: sum of the *lengths* of all n IPv4 encodings (each of which
      is 5 octets.)
    
    Section 4.1., paragraph 10:
    >    This encoding consumes (PrefixLength +
    >    31) / 32) 32-bit words.
    
      The length calculation needs to be rounded up to be accurate.
    
    Section 4.1., paragraph 11:
    >    The Node IPv6 Local Address sub-TLV length is in octets. It is the
    >    sum of all n IPv6 Address encodings in the sub-TLV where n is the
    >    number of local addresses included in the sub-TLV.
    
      "sum of *lengths*" (see above)
  2. Adrian Farrel: Comment [2009-11-27]:
    Voting "Yes" but please consider fixing these nits...
    
    Section 2.1
       For the above reasons this document proposes an enhancement to
    OSPF
       TE extensions to advertise the local addresses of a node.
    s/proposes/defines/
    ---
    Section 4.1
       The Node IPv4 Local Address sub-TLV
    length is in octets. It is the
       sum of all n IPv4 Address encodings in the
    sub-TLV where n is the
       number of local addresses included in the sub-TLV.
    The
    use of "sum" is confusing. Perhaps "sum of the lengths"?
    ---
    Section 4.1
       The
    Node IPv6 Local Address sub-TLV length is in octets. It is the
       sum of all n
    IPv6 Address encodings in the sub-TLV where n is the
       number of local
    addresses included in the sub-TLV.
    Ditto
    ---
    Section 4.2
       The node attribute
    TLV must appear in exactly one TE LSA originated
       by a router. Furthermore,
    only one node attribute TLV must be
       advertised in such a LSA. A node
    attribute TLV must carry at most one
       Node IPv4 Local Address sub-TLV and at
    most one Node IPv6 Local
       Address sub-TLV.
    I thought that the node attribute
    TLV was optional, so this looks off. I also wonder if this can be reworded in
    2119 langauge.
       The node attribute TLV MUST NOT appear in more than one TE LSA
    originated by a router. Furthermore, such an LSA MUST NOT include
       more than
    one node attribute TLV. A node attribute TLV MUST NOT carry
       more than one of
    each of the Node IPv4 Local Address sub-TLV and the
       Node IPv6 Local Address
    sub-TLV.
    ---
  3. Alexey Melnikov: Comment [2009-11-27]:
    On page 6:
       PrefixOptions is an 8-bit field describing various capabilities
       associated with the prefix [RFC5340].
    
    I think a pointer to Appendix A.4.1.1 in RFC 5340 would be helpful here.
    
    4.2. Operation
    
       The node attribute TLV must appear in exactly one TE LSA originated
       by a router. Furthermore, only one node attribute TLV must be
       advertised in such a LSA. A node attribute TLV must carry at most one
       Node IPv4 Local Address sub-TLV and at most one Node IPv6 Local
       Address sub-TLV.
    
    It looks like this section should be using "MUST"s instead of "must"s.
  4. Dan Romascanu: Comment [2009-12-02]:
    In the IANA considerations section: 
    
    >   IANA is requested to maintain the registry for the sub-TLVs of the
       node attribute TLV and reserve value 1 for Node IPv4 Local Address
       sub-TLV and value 2 for Node IPv6 Local Address sub-TLV.
    
    '... to create and maintain the resgistry ...' seems more appropriate.

draft-ietf-ccamp-lsp-dppm

  1. Ralph Droms: Comment [2009-12-02]:
    What, exactly, does the term "real number" mean?  Is the term used in the
    mathematical sense of "rational or irrational number", or in the sense of "in
    contrast to the 'undefined' value"?
    
    Nits:
    This phrase seems awkward (and the comma may be syntactically incorrect):
    
       The [metric] is undefined, means [...]
    
    The phrasing often used in the following paragraph:
    
       The undefined value of this metric indicates [...]
    
    seems less awkward; could it be used in both situations?
    
    Use either "set up" or "setup" uniformly throughout (I think "set up" would be
    preferable)?
    
    In section 6.6, s/Thus, In practice/Thus, in practice/
    
    I can't make sense of this sentence in section 9 (same sentence appears in
    sections 10, 11 and 12):
    
       Sampling
       is to select a particular potion of singleton values of the given
       parameters.
    
    In sections 10.5 and 12.5, s/bacth/batch/
  2. Lisa Dusseault: Comment [2009-12-01]:
    The document frequently contains phrasing like 
       "The value of X is either a real
       number, or an undefined number of milliseconds."
    
    This did not compute for me.  I believe this would mean the same thing and hope
    it makes more sense:
       "The value of X is either a real number of milliseconds,
    or undefined."
    
    Anywhere the phrase "undefined number of milliseconds" occurs, I believe this
    could be clearer.
  3. Russ Housley: Comment [2009-12-02]:
      Please expand "LSP" on first use.
    
      Several editorial improvements were suggested in the Gen-ART Review
      by Francis Dupont.  Please consider them.
  4. Tim Polk: Discuss [2009-12-03]:
        The security considerations section needs to be expanded.  As noted in Dan's
    discuss, further
    information about the types of control plane attacks is needed.
    
    As noted in Tom Yu's secdir review, the security requirements for the collected
    data are not
    clear.  Do the metrics require security protection in transit?
    when stored on a host?  If security
    is required, should we be concerned with
    integrity, authentication, or confidentiality?
    
    Note also that Tom's review merits a response... 
        
  5. Tim Polk: Comment [2009-12-03]:
    Traditionally (e.g., in RFCs 2330, 2679, and 2681), ppm documents have addressed
    the
    following concerns in security considerations:
    
       There are two types of security concerns: potential harm caused by
       the measurements, and potential harm to the measurements. 
    
    The authors may find organizing the security considerations for this document in
    this
    fashion helpful... although I think those documents are missing the concept
    of harm from
    disclosure to or modification by an attacker.  (Should be part of
    the discussion of type 1)
  6. Dan Romascanu: Discuss [2009-12-02]:
        I like this document and I will support its approval but I would like two minor
    aspects to be answered first:
    
    1. In section 3 I find the following recommendations for implementation and
    deployment:
    
    >  Note that data path related metrics, for example, the time between
       the reception of Resv message by ingress node and forward data path
       becomes operational, are defined in another document
       [I-D.sun-ccamp-dpm].  An implementation MAY choose whether to
       implement metrics in the two documents together.  However, it is
       RECOMMENDED that both measurements are performed to complement each
       other.
    
    First I find questionable whether RFC 2119 capitalization is appropriate when
    refering to the content of another document which is complementary in nature.
    This being said, it is odd that implementing the metrics in the two documents is
    a 'MAY' why performing the measurements based on the implementations is a
    'SHOULD'. I would expect that implementating the metrics be at least at the same
    level of requirements as measuring based on the implementation.
    
    2. I find the following part of the security considerations section rather
    vague:
    
    >   When samples of the metrics are collected in a passive manner, e.g.,
       by monitoring the operations on real-life LSPs, the implementation of
       the monitoring and reporting mechanism must be careful so that they
       will not be used to attack the control plane.
    
    I think that the document should be more specific on what exact attacks on the
    control plane an implementer or operator should care about. For instance is
    privacy of any concern? Should traffic that carries monitoring or reporting
    information have lower priority in order to avoid disturbing other control
    traffic? Should authentication mechanisms be put in place so that only
    authenticated entites have access to the information? 
        
  7. Dan Romascanu: Comment [2009-12-02]:
    
      

draft-ietf-16ng-ipv4-over-802-dot-16-ipcs

  1. Adrian Farrel: Comment [2009-11-28]:
    A few comments all at the level of nits...
    
    ---
    
    Sections 1 and 5.2
    
    In section 1
       This document also discusses ARP (Address Resolution Protocol) and
       Multicast Address Mapping.
    Well, section 5.2 contains precisely 2 lnes and two words to say that 
    ARP is not used.
    
    ---
    
    Section 2
    As far as I can see, the terms "Subscriber station (SS)" and "Mobile
    Node (MN)" are not used in the document at all.
    
    ---
    
    Section 3 para 1
    You have shown "(AR)" twice
    
    ---
    
    Section 4.3
    s/if an MS/If an MS/
    
    ---
    
    Appendix D
    s/advertisemnet/advertisement/
  2. Alexey Melnikov: Discuss [2009-11-28]:
        This is a DISCUSS DISCUSS and I will clear it during/after the telechat.
    
    Appendix C.  WiMAX IPCS MTU size
    
       WiMAX (Worldwide Interoperability for Microwave Access) forum has
       defined a network architecture[WMF].  Furthermore, WiMAX has
       specified IPv4 CS support for transmission of IPv4 packets between MS
       and BS over the IEEE 802.16 link.  The WiMAX IPv4 CS and this
       specification are similar.  One significant difference, however, is
       that the WiMAX Forum [WMF] has specified the IP MTU as 1400 octets
       [WMF] as opposed to 1500 in this specification.
    
    This begs the question: why have 2 similar but incompatible specs? 
        
  3. Alexey Melnikov: Comment [2009-11-28]:
    4.2.  Frame Format for IPv4 Packets
    
                            0                   1
                            0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
                           +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                           |H|E|   TYPE    |R|C|EKS|R|LEN  |
                           +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                           |    LEN LSB    |    CID MSB    |
                           +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                           |    CID LSB    |    HCS        |
                           +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    
    Nit: it would be nicer to readers to say that MSB means "Most Significant Byte"
    and LSB means "Less Significant Byte".
  4. Dan Romascanu: Discuss [2009-12-03]:
        David Black performed a quick OPS-DIR review and raised a number of issues which
    were not answered as far as I know, and should be clarified before approving
    this document.
    
    (1) MTU size seems problematic.  This document strongly recommends
    (SHOULD) a
    1500 byte MTU, but Appendix C observes that a lot of actual equipment uses a
    1400 byte MTU.  The latter's likely to cause more problems with the former as
    it's visibly smaller than a typical Ethernet MTU, but it's apparently in
    "running code".
    
    [DR - I would like to understand better the operational implications of the
    limitations because of the fact that mechanisms defined in Section 4 would not
    work, and because an IPv4 CS client is not capable of doing ARP probing to find
    out the link MTU in such cases]
     
    (2) It's not at all clear whether link-level
    broadcast or multicast can be relied upon to work.  Section 5.3 and Appendix D
    are not promising - it looks like the baseline is that IPv4 multicast is point
    to point up to at least the Access Router and possibly beyond.
    I'm not sure that
    this is an actual problem, but the document probably ought to be more explicitly
    about saying that one ought to have low expectations for useful multicast
    behavior from a point-to-point link layer technology.
     
    (3) Section 5.1 seems to
    assume that ICMP Router Discovery is in use.  Either that needs to be stated as
    a requirement of this specification, or some other spec needs to be cited as
    imposing this requirement.  The discussion of multicast in router discovery is
    actually clearer than other parts of the document. 
        
  5. Dan Romascanu: Comment [2009-12-03]:
    
        
  6. Magnus Westerlund: Comment [2009-12-01]:
    Section 4.2:
    
    C: CRC Indicator. 1 = CRC is included, 0 = 1 No CRC is included
    
    It looks confusing that 0 = 1, I guess the 1 can be removed.

draft-dusseault-http-patch

  1. Adrian Farrel: Discuss [2009-12-01]:
        
    Can someone please confirm that the apropriate Expert Review was
    conducted (by Graham Klyne). 
    
    (Is this something we should add to the write-up as standard?) 
        
  2. Adrian Farrel: Comment [2009-12-01]:
    Section 1
       A new method is necessary to improve interoperability and prevent
       errors.
    
    This is a bit strong. The new method seems to be desirable to increase
    the functionality and improve performance.
    
    ---
    
    Section 4.1
    
       The 'Accept-Patch' response header should be added to the permanent
       registry (see [RFC3864]).
    
    Would be nice to name the registry more precisely. IANA has this as the
    'Permanent Message Header Field Names' registry.
  3. Russ Housley: Discuss [2009-11-30]:
        
      The Last Call comment from Julian Reschke needs to be resolved.
    
      > In the meantime, a new draft was published, see
      > <http://tools.ietf.org/html/draft-dusseault-http-patch-16>.
      > 
      > The new text is:
      > 
      >    A PATCH request can be issued in such a way as to be idempotent,
      >    which also helps prevent bad outcomes from collisions between two
      >    PATCH requests on the same resource in a similar timeframe.
      >    Collisions from multiple PATCH requests may be more dangerous than
      >    PUT collisions, because some patch formats need to operate from a
      >    known base point or else corrupt the resource.  Clients using this
      >    kind of patch application SHOULD acquire a strong ETag [RFC2616] for
      >    the resource to be modified, and use that ETag in the If-Match header
      >    on the PATCH request to verify that the resource is still unchanged.
      >    If a strong ETag is not available for a given resource, the client
      >    can use If-Unmodified-Since as a less-reliable safeguard.
      > 
      > This text is still problematic, in that
      > 
      > 1) It suggests that the client is in control of the etag ("...acquire a
      > strong etag..."); however, the client has no control over this at all;
      > it's the server who decides, and also it's the server who's in charge in
      > deciding what type of etags it accepts in which operations.
      > 
      > 2) It doesn't mention that WebDAV defines another conditional header
      > which doesn't have the limitations of If-Match (per RFC2616, not
      > HTTPbis). 
        
  4. Russ Housley: Comment [2009-11-30]:
    
      

draft-klensin-ftp-registry

  1. Ralph Droms: Comment [2009-12-02]:
    In this test from section 2.2:
    
       Command Name -  The FTP command, either new or modified, used in the
          extension or with which the extension is used. 
    
    what does "either new or modified" mean?
    
    In section 3, s/marke/marked/
  2. Pasi Eronen: Comment [2009-12-03]:
    
        
  3. Adrian Farrel: Comment [2009-11-30]:
    
        
  4. Russ Housley: Discuss [2009-11-30]:
        
      Downref: Normative reference to Experimental RFC 2773. 
        
  5. Russ Housley: Comment [2009-11-30]:
      There has been discussion of the comments in the Gen-ART Review by
      Ben Campbell.  I expected some changes to the document based on the
      discussion.
  6. Alexey Melnikov: Comment [2009-12-03]:
    
        
  7. Robert Sparks: Discuss [2009-12-02]:
        Given the changes to the strength of implementation requirements on some of the
    extensions, should this document Update 2389 and 2428 (should 3659 also be in
    this list)? 
        
  8. Robert Sparks: Comment [2009-12-02]:
    
      

draft-ietf-csi-sndp-prob

  1. Jari Arkko: Discuss [2009-12-03]:
        Section 2.3 states:
    
       The Neighbor Discovery (ND) Proxy specification [RFC4389] provides a
       method by which multiple link layer segments are bridged into a
       single segment and specifies the IP-layer support that enables
       bridging under these circumstances.  The proxy in this case forwards
       messages while modifying their source and destination MAC addresses,
       and rewrites their Link-Layer Address Options, solicited, and
       override flags.
    
    This is a bit misleading. Classic bridging does not require ND proxying
    at all. However, there are circumstances outlined in RFC 4389 where
    its desirable to implement ND proxying / ARP proxying instead of
    classic bridging. I would suggest a small rewrite:
    
       The Neighbor Discovery (ND) Proxy specification [RFC4389] defines an
       alternative method to classic bridging. Just as with classic bridging,
       multiple link layer segments are bridged into a single segment, but
       with the help of proxying at IP layer rather than link layer bridging.
       The proxy in this case forwards
       messages while modifying their source and destination MAC addresses,
       and rewrites their Link-Layer Address Options, solicited, and
       override flags. 
        
  2. Jari Arkko: Comment [2009-12-03]:
    
        
  3. Pasi Eronen: Discuss [2009-12-01]:
        I have reviewed draft-ietf-csi-sndp-prob-03, and have a couple of
    questions/concerns that I'd like to discuss before recommending
    approval of the document:
    
    - I think the text about IKEv2 (Section 2.2) is quite misleading. As
    far as I know, in most security gateway deployments the gateway has a
    block of addresses, and "intercepting" packets sent to this block is
    handled by routing (static routes or intra-AS routing protocol), not
    by ND/ARP messages.
    
    It's not totally impossible that the approach described in Section 2.2
    could be used, but IMHO it would be rare.
    
    - For Mobile IPv6, I guess we don't really have deployments, but are
    there any SDOs that are even considering deployments where one MN
    would *ever* see ND queries from another MN, even if both are at home?
    (AFAIK in most other SDO specs, every MN gets a full IPv6 prefix, so
    securing NS/NA is not really an issue -- and RS/RA is handled by
    security the point-to-point link to the router.)
    
    From Stephen Farrell's SecDir review:
    
    - Section 4.2.6: I think current best practices usually avoid
    increasing certificate serial numbers (and use random-looking serial
    numbers instead).  I'd suggest either deleting that if its felt to be
    unlikely used, or else, if its actually likely to be used, then
    documenting how it could actually work
    
    - In Section 7.2, I would strongly recommend deleting the word
    "non-repudiable" (or alternatively, explaining what is meant by 
    the term in this context -- it's very overloaded term.) 
        
  4. Pasi Eronen: Comment [2009-12-01]:
    
        
  5. Adrian Farrel: Comment [2009-12-01]:
    Section 5
    
       The previous part of this document focused on the case where two
       nodes defend the same address (i.e. the node and the proxy).  But,
       there are scenarios where two or more nodes are defending the same
       address.
    
    I read this a couple of times and it doesn't compute :-)
    Firstly I suggest you insert a reference in place of "the previous part
    of this document".
    Secondly: can you resolve the "But"? The second sentence seems to say,
    "but the first sentence is true"!
    
    ---
    
    A petty nit...
    
    Would you consider changing the title to...
    Problem Statement for Securing Neighbor Discovery Proxy
    ...or...
    Securing Neighbor Discovery Proxy : Problem Statement
    ...to add a little clarity.
  6. Russ Housley: Comment [2009-12-02]:
      Several editorial improvements were suggested in the Gen-ART Review
      by Vijay Gurbani.  Please consider them.
     
      > 1) You may want to expand SEND before first use in Section 2;
      > you do so later on (below Figure 1), but should move that up.
      >
      > 2) S2.3, below Figure 3: The text says that "An alternative
      > (alluded to in an appendix of ND Proxy)..."   You may want to
      > provide a reference to the document containing this appendix.
      >
      > 3) S3.3: s/options) [RFC4389]/options) [RFC4389]./
  7. Tim Polk: Comment [2009-12-02]:
    I am not repeat NOT a cryptographer, and am not familiar with ring signature
    schemes, but
    my quick research on ring signature schemes came up with
    descriptions very different from those in section 4.1.3:
    
       This is the case, for example, with ring signature algorithms.  These
       algorithms generate a signature using the private key of any member
       from the same group, but to verify the signature the public keys of
       all group members are required.  
    
    The abstract of "Cryptanalysis of a Generalized Ring Signature Scheme"
    (published in
    vol. 6 no. 2 of IEEE Transactions on Dependable and Secure
    Computing) states:
    
          In a ring signature, instead of revealing the actual identity of the
    message signer, it
          specifies a set of possible signers. The verifier can
    be convinced that the signature 
          was indeed generated by one of the ring
    members; however, the verifier is unable to 
          tell which member actually
    produced the signature. A convertible ring signature 
          scheme allows the
    real signer to convert a ring signature into an ordinary signature 
          by
    revealing secret information about the ring signature.
    
    These definitions seem in conflict.  One of the cryptographers here at NIST
    noted that
    both descriptions seem to fall into the "group signature" class of
    algorithms, but she
    was not immediately familiar with the term "ring signature"
    so she couldn't tell me which
    was the accepted definition.
    
    I would strongly encourage you to include a reference for the class of
    algorithms identified 
    in 4.1.3, since there is some confusion even within the
    cryptographic community.
    
    I would also suggest adding a new section to the security considerations
    describing the
    risks of being on the bleeding edge with cryptography.  Where
    classes of algorithms have 
    had limited scrutiny, there are risks that new
    attacks will be developed in the future.

draft-ietf-hip-native-api

  1. Ralph Droms: Comment [2009-12-02]:
    
        
  2. Lars Eggert: Discuss [2009-12-02]:
          DISCUSS-DISCUSS: Since this extends a POSIX spec, are they aware of
      this effort? (Do they need to be?) 
        
  3. Lars Eggert: Comment [2009-12-02]:
    
        
  4. Pasi Eronen: Discuss [2009-12-03]:
        The draft has normative references to draft-ietf-btns-c-api, which is
    currently expired. It's not clear that the energy needed to finish
    it exists -- but that would leave this draft forever stuck in the
    RFC editor queue.
    
    Is it fine to wait until btns-c-api is done? Or is this reference
    really normative? 
        
  5. Pasi Eronen: Comment [2009-12-03]:
    
        
  6. Adrian Farrel: Comment [2009-12-01]:
    Acronyms used ahead of section 2.
    LSI
    HIP (Expanded in second paragraph of section 1; used in first paragraph)
    
    ---
    
    Acronyms used without expansion
    FQDN
    RR
    HI
    
    ---
    
    Might be nice to describe the "experiment" in a little more detail. In 
    particular, how will you judge the success of the experiment?
    
    ---
    
    Figure 2
    Stray character at the start of the ship_hit line.
  7. Russ Housley: Comment [2009-12-02]:
      Several editorial improvements were suggested in the Gen-ART Review
      by Ben Campbell.  Please consider them.
  8. Alexey Melnikov: Comment [2009-11-28]:
    A good document. Some examples would be nice though.
    
    Also:
    
    10.  Normative References
    
       [I-D.ietf-btns-c-api]
                  Richardson, M., Williams, N., Komu, M., and S. Tarkoma,
                  "C-Bindings for IPsec Application Programming Interfaces",
                  draft-ietf-btns-c-api-04 (work in progress), March 2009.
    
       [I-D.ietf-shim6-proto]
                  Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming
                  Shim Protocol for IPv6", draft-ietf-shim6-proto-12 (work
                  in progress), February 2009.
    
    The above references look Informative to me.
  9. Robert Sparks: Discuss [2009-12-01]:
        This experimental document has two normative references to Informational
    documents that are in progress (one is long expired). 
        
  10. Robert Sparks: Comment [2009-12-01]:
    Per 
    http://www.iana.org/assignments/iana-ipv6-special-registry/
    ORCHIDs currently have a default sunset in 2014:
    
    2001:10::/28    ORCHID      21 Mar 07        21 Mar 14         Overlay       See
    RFC             Not Routed     [RFC4843]
    
    Should this document ask an implementor to check to see if that's been
    updated?
    (What will maintenance of the stream look like if something unexpected happens
    and this ORCHID assignment is not renewed?)

draft-combes-ipdvb-mib-rcs

  1. Ron Bonica: Discuss [2009-12-02]:
        I may remove this discuss at the telechat. Somehow, it seems odd to use the RFC
    series to document a proprietary MIB. Do we have any precedent for doing this? 
        
  2. Ron Bonica: Comment [2009-12-02]:
    
        
  3. Russ Housley: Comment [2009-12-02]:
      Several minor editorial improvements were suggested in the Gen-ART
      Review by Avshalom Houri.  Please consider them.

draft-reschke-rfc2731bis

  1. Lars Eggert: Comment [2009-12-02]:
    Appendix C., paragraph 7:
    
    >    julian.reschke@greenbytes.de (2009-10-08): It's not clear whether
    >    this case is really a candidate for reclassification as "historic".
    >    After all, the format that was described in RFC 2731 is still in use
    >    in Dublin Core's DC-HTML; it just got revised.
    
      Whether the format is still in use doesn't really matter. It seems
      that RFC 2731 is no longer the definitive spec (it is obsoleted by
      later DC work) and so IMO it should be made historic.
  2. Cullen Jennings: Discuss [2009-12-02]:
        On the call I would like to talk about what happens next process wise (does this
    draft become an RFC or do we jut mark things obsolete?
    
    I'd like a stable normative reference to the document that obsoletes 2731. It
    seems to me that it should be http://dublincore.org/documents/2008/08/04/dc-
    html/ not http://dublincore.org/documents/dc-html/ but I really don't know. 
        
  3. Cullen Jennings: Comment [2009-12-02]:
    
      

draft-hammer-oauth

  1. Lars Eggert: Comment [2009-12-02]:
      Is there a reason we're not publishing this as PS?
  2. Adrian Farrel: Comment [2009-12-01]:
    Thank you for bringing this work for publication as an Informational
    RFC, and for including the clear statement of origin and intent at the
    end of Section 1.
  3. Russ Housley: Discuss [2009-12-02]:
        
      Appendix A talks about "Differences from the Community Edition."
      Is there a stable reference that can be included in this Appendix?
      If not, it might be good to repeat a few sentences from the
      Introduction about the origins of the "Community Edition."
    
      RFC 5208 has a similar history in that an original specification was
      developed outside the IETF, and then change control was given to the
      IETF for future versions.  I think the document should indicate that
      change control has been given to the IETF.  In RFC 5208, that was done
      with an IESG note.  I'm fine with other approaches too. 
        
  4. Russ Housley: Comment [2009-12-02]:
      I think it would be better to remove the URI reference [1], and say
      in the introduction:
    
        The resulting OAuth protocol was stabilized at version 1.0 in
        October 2007 and published at the oauth.net website <http://oauth.net>.
  5. Cullen Jennings: Discuss [2009-12-02]:
        
    I don't think we have consensus to publish this. When the WG was formed, it was
    clear people did not want the IETF to rubber stamp the existing thing but that
    is exactly what is happen here. I would have no object to this being published
    as historic with a normative reference to the standards track RFC is done and
    marked this as obsolete by the standards track work.  Publishing this now will
    harm interoperability with the eventual specification the WG is working on and
    cause future fragmentation in the implementations and deployments. As seen in
    the WG, there are changes that are needed to this for the IETF to have consensus
    to publish it.
    
    I also feel there are technical issues with this specification as an IETF RFC
    but theses do not seem to be worth discussing given my larger point. 
        
  6. Cullen Jennings: Comment [2009-12-02]:
    
        
  7. Tim Polk: Discuss [2009-12-02]:
        Section 4.13 references NIST's initial response to the Wang attack on SHA-1
    (specified as
    [SHA-COMMENTS], which dates to August 2004), which noted that
    SHA-1 and algorithms of
    similar strength would be phased out at the end of 2010.
    This statement was a little rushed,
    and should have noted that SHA-1 would be
    phased out for use in digital signatures only. A 
    more recent statement from
    NIST can be found at
    
        http://csrc.nist.gov/groups/ST/hash/statement.html
    
    This statement clarifies that the attacks on SHA-1 only impact the strength of
    functions 
    requiring collision resistance, such as the digital signatures
    generated with SHA1, and has
    no impact on HMACs.  NIST expects the "HMAC-SHA1"
    signature method to remain secure 
    for another fifteen to twenty years.
    
    Section 4.13 should be revised to reference "RSA-SHA1" signatures, point to the
    current
    NIST statement, and clarify that NIST wants to phase out the use of
    SHA-1 *in digital
    signatures* by 2010. Adding a sentence that notes the "HMAC-
    SHA1" signature method
    are not at risk would also be helpful. 
        
  8. Tim Polk: Comment [2009-12-02]:
    Section 1, paragraph 5
    s/substitute the need/make it unnecessary/
    
    Section 1.1
    suggest adding a definition for "credentials" and noting that three
    classes (client, temporary, 
    and token) are defined for OAuth
    
    Sections 2.1 and 2.3
    
    In sections 2.1 and 2.3, the attribute definitions do not specify REQUIRED or
    OPTIONAL.  (In
    Section 2.2 the definition of oauth_token explicitly notes
    REQUIRED, and the list of attributes 
    given in 3.1 are all REQUIRED excepting
    oauth_version which is OPTIONAL.)
    
    Explicitly noting REQUIRED or OPTIONAL for oauth_callback (in the request in
    2.1),
    oauth_token, oauth_token_secret, and oauth_callback_confirmed (in the
    response in 2.1) and
    oauth_verifier (in 2.3) would improve the clarity.
    
    Section 2.3 states "The token credentials issued by the server MUST reflect the
    exact scope,
    diration, and other attributes approved by the resource owner."
    
    I find "reflect" ambiguous.  Are you suggesting that this information should be
    embedded
    into the credentials, or simply maintained at the server?
    
    Section 3.3, last sentence:  "Servers applying
       such a restriction SHOULD provide a way for the client to sync its
       clock with the server's clock, which is beyond the scope of this
       specification."
    
    What if a client is associated with multiple servers?  Given the
    level of synchronization required, isn't it a sufficient for both
    clients and servers to synchronize with a trusted time source
    of their own choice?
    
    Section 4.3 states:
    
       When used with the "PLAINTEXT" method, the protocol makes no attempt
       to protect credentials from eavesdroppers or man-in-the-middle
       attacks.  The "PLAINTEXT" method is only intended to be used in
       conjunction with a transport-layer security mechanism such as TLS or
       SSL which does provide such protection.
    
    This one is splitting hairs, I know, but please change "does" to "can" in the
    second
    sentence.  In the context of machine-to-machine communication, TLS/SSL
    *will* provide
    this protection.  However, it is quite possible to implement a
    man-in-the-middle attack
    even with TLS with the involvement of users.

draft-wu-softwire-4over6

  1. Ron Bonica: Comment [2009-12-02]:
    Since this document describes something that has already been done, its status
    should probably be INFORMATIONAL, not EXPERIMENTAL.
  2. Lars Eggert: Comment [2009-12-02]:
      Contains several unused references.
  3. Adrian Farrel: Discuss [2009-12-01]:
        
    I welcome the fact that this document has been brought forward.
    
    Normally an Experimental I-D would describe an experiment that is to be
    run. In
    that case, it would include a description of the scope of the
    experiment, how
    the experiment will be measured, the way that the 
    success of the experiment
    will be judged, and the proposed next steps                    
    depending on the
    success or failure of the experiment.
    
    In this case, however, it looks like you have already run the 
    experiment. If this is a record of your experiment that is now 
    concluded, I think that you should class the I-D as Informational. If
    the experiment is intended to continue, I think you should add a 
    seciton to describe the on-going experiment.
    
    ---
    
    Section 1 says...
    
       This document defines
       extensions to MP-BGP employed to communicate tunnel end-point
       information and establish 4over6 tunnels between dual-stack Provider
       Edge (PE) routers positioned at the edge of the IPv6 backbone
       network.
    
    This is not consistent with the Experimental status. The wording used
    in the Abstract is subtly different, and better. Would it work to 
    replace this text with:
    
       This document describes experimental
       extensions to MP-BGP employed to communicate tunnel end-point
       information and establish 4over6 tunnels between dual-stack Provider
       Edge (PE) routers positioned at the edge of the IPv6 backbone
       network. 
        
  4. Adrian Farrel: Comment [2009-12-01]:
    
      

draft-irtf-p2prg-rtc-security

  1. (none)

draft-levy-sip-diversion

  1. Jari Arkko: Discuss [2009-11-18]:
        Could we get the RFC editor and authors to agree to put the IESG note
    to the body of the document, in which case no note would be needed? 
        
  2. Jari Arkko: Comment [2009-11-18]:
    The file header says:
    
       Inended status: Historic
    
    and you meant "Intended status", of course.
  3. Adrian Farrel: Discuss [2009-12-02]:
        
    I don't object to the publication of this material as a Historic RFC, but I
    agree with the point made by Robert in his initial email to the RFC Editor about
    the "voice" used in the draft. Starting from the first line of the Abstract,
    this document reads like a current proposal for a protocol solution.
    
    Although the Historic classificaiton should make it clear that there is no
    intention for implementation or standardisation, I regret that some people might
    not notice this "subtlty".
    
    If considerable updates to the text are not feasible (effort, time, etc.) I
    would suggest:
    - a minor rework of the Abstract
      - include the note that is
    present at the start of
        the Introduction
    - consider Jari's suggestion to
    move the substance of the IESG note
      into the Introduction 
        
  4. Adrian Farrel: Comment [2009-12-02]:
    
        
  5. Russ Housley: Comment [2009-11-11]:
    Current IESG note says:
    
       This RFC contains an early alternate proposal that was not chosen
       by the SIP working group when creating the solution specified
       in RFC 4244 "An Extension to the Session Initiation Protocol (SIP)
       for Request History Information".
    
    I suggest some edits:
    
       This document contains an early proposal to the IETF SIP Working
       Group that was not chosen; the solution that was chosen can be
       found in RFC 4244 "An Extension to the Session Initiation Protocol
       (SIP) for Request History Information".
  6. Cullen Jennings: Discuss [2009-11-18]:
        I think we need to talk about this one a bunch. The IESG note about 4244 does
    not seem right quite right - 3325 was the primary work that came out of this
    thought I agree that later 4244 also covers this.
    
    Let me provide a bit of background. Cisco was doing work with cable labs and
    came up with something close to this draft. Cisco then submitted it to the IETF
    and in the mean time Cisco implemented it their gateways. The draft was very
    controversial at IETF for a variety of reasons largely technical. In the
    meantime, if you wanted call-id to work (which everyone did want) and you were
    using cisco gateways (which had the bulk of the market share at that time) you
    pretty much needed to do this to work. So lots of vendors implemented. As the
    discussion continued at IETF, effectively 3325 was formed by taking the parts of
    this draft that people could agree on and adding a security section that we
    could sneak past the IESG on some sort of bogus private used in walled gardens
    pretext. As you can imagine that pretext turned out to be a disaster in the long
    run. After 3325 was published, many people felt folks that had done the pre
    standard implementation of this draft should migrate to 33245 and we would have
    interoperability - many did migrate and some did not. Later 4244 added in more
    functionality that 3325 did not have and had been in this draft. The IETF also
    defined 4474 for call-id which is the only solutions of these that is usable on
    the internet. (as a side note I am author of some of the text in this draft,
    3325, 4244, and 4474). At this point in time, the sheer number of different
    solutions to the caller-id problem is a significant interoperability problem.
    The IETF is working on a 4244bis draft as a WG item and discussing work on
    calling and called part id in WG meetings. My understanding of Cisco position on
    this topic is that thought Cisco is still the primary user of this approach,
    Cisco does not believe it would be helpful to the internet, or even Cisco, to
    publish this even as an historic RFC. It has generated much discussion for many
    years inside Cisco.  People from multiple other vendors, such as Microsoft, have
    strongly suggested that this draft should be updated with a version of this
    draft roughly says whatever you do don't use this - go do what the IETF
    standards track recommends.  I'd like to note that the reason the author sent
    this is to the RFC Ed is that Joel Halpern asked him to submit it and somehow
    between Steve and Joel, Steve was under the impression that Joel was the Chair
    of the IETF so did it.
    
    I also note this draft has changed the syntax from earlier version that were
    widely implemented so I'm not sure how much it does reflect the historic code
    base. The draft is in pretty sad state and I wonder at things like two of the
    original authors being removed and the spelling mistakes that are hard to
    imagine anyone other than me making - my favorite being "Inended status".
    
    In summary, I believe publishing an RFC that is an alternative to the standards
    track RFCs for the caller-id problem is harmful to interoperability and this
    should not be published. 
        
  7. Cullen Jennings: Comment [2009-11-18]: