ITU Update (Adrian and Stewart)
Telechat:
- Adrian: SG15, playing with what they do with MPLS-TP rec and RFCs. We went to the meeting with many contributions from many companies. Some say you better use RFCs, other say you have to base OAM MPLS-TP on OAM. Some nations came with position that if you o either of these, we will strongly object. ITU is in a bind. Bottom line is that they can't reach conclusion. An attempt will be made to push through ethernet-based OAM. Then be left up to nations how to handle that, we'll see whether it happens at this meeting. Fallback is that they may have a draft recommendation that everyone can point at. Does this appear to be in violation of their agreement with us. I think so, but they claim it isn't. We want to come up with some middle road that saves Chinese face, keeps MPLS pure, etc. We put forward two options today. One is that you bring your ideas to the IETF and have info RFCs that have IETF consensus, you can point to them from your docs. The other option is that they do their work on a different ethertype. That doesn't depend upon IETF completing standards, but would go in a different direction. We've been discussing with ITU, and they're relatively OK with option 2, but with modification. They would like to send all data on MPLS ethertype. When it comes to OAM, they want to send that on different ethertype. Stewart and I think it preserves integrity of MPLS, but it's an awful engineering solution. The questions are: to what level do we need to push or back off, and how should we verify the integrity of MPLS for the second proposal?
- Russ: This is not what I expected.
- Adrian: We have not committed to anything.
- Stewart: If you tell us to take the hard-line approach, we'll do that.
- Russ: Based on you guys being there, what do you think the outcome to hard or soft line will be?
- Stewart: We have no idea what happens when we push it to the next stage. All kinds of country positions that would support us. It could go to TAP. We have no idea.
- Russ: Then only national bodies have a say.
- Jari: Clarify what the process is. If the current set of voting entities don't agree, can the ITU make a decision?
- Adrian: My reading of how it's set up is that this SG can exit this meeting with a consented document, punting the decision into the approval process.
- Russ: I told Malcolm two weeks ago that consenting the G.tpoam document would be considered a breach of the JWT agreement. But you seem to be saying something else now. You seem to be saying that using a different EtherType makes it okay.
- Adrian: If we don't do anything, they will consent it with the same ethertype, they will say they don't think it's a breach of the agreement.
- Russ: If they consent the doc with the same ethertype, we have to consider it a breach.
- Adrian: Our hard-line position is to say that nothing is on the table, and we will consider this a breach of the agreement.
- Tim: Suppose the IETF completes work on MPLS-TP including OAM work. Nothing would prevent ITU-T from putting together an OAM protocol on another ethertype, and say we're going to use MPLS as IETF defined it, and for OAM we'll use this other ethertype. If they should do that, would we find that objectionable? Would we claim that was inappropriate change to IETF specs? We might say it doesn't look so good, but we wouldn't consider that a violation of our process. Right?
- Adrian: You're asking the right question.
- Tim: If we could live with this if we hadn't been fuzzy with them, it should still be OK and let the Chinese save face. We will provide a solution that works well. If they use one that won't work well, but do it on a different ethertype, that should be OK.
- Stewart: Suppose they invented a different routing protocol that ran on a different ethertype, or another DNS lookup on a different ethertype, would that be OK?
- Ron: I think it would not be OK, and that's part of the question.
- Adrian: If we do something on a different ethertype, then bifurcates above IP, that seems bad because ones you're in IP you don't know the ethertype.
- Ralph: The subtlety in bifurcating on the ethertype and coming together... in theory, once you split based on the ethertype, you can have a separate protocol through the rest of the protocol stack. If it looks like the same bits on the wire, you can still call it a separate protocol. Using IPv4 and v6 as an example, it's not always the case that both sides will keep everything separate. As a practical matter, Adrian is right: even if you bifurcate at ethertype, they will both come together in the same implementation code and can't differentiate how they originated.
- Adrian: From specification, anything written with a new ethertype is redocumented, but not done by reference.
- Ralph: If you have a registry of protocols, you could go up the stack and have a chain of documentation that says these are truly separate protocols all the way up the stack, even though the bits look familiar. I haven't resolved for myself where you get to a separate protocol stack.
- Adrian: Sounds to me that this floated idea doesn't meet with instant approval, and Pete has made a point in jabber about the involvement of IAB. I should put the points in email and collect opinions about whether we should back off or follow through.
- Stewart: We really need the feedback by Monday at the latest.
- Adrian: We need a feeling by tomorrow. Don't have to say yes or not, but it's important to know where we lean.
- Russ: The point about the stacks coming back together is one I hadn't thought of before, and it's significant.
2. Protocol Actions
2.1 WG Submissions
2.1.1 New Items
- Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry (BCP)
draft-ietf-tsvwg-iana-ports-10
Token: Alexey Melnikov
Note: Gorry Fairhurst (gorry@erg.abdn.ac.uk) is the document shepherd.
Discusses/comments (from ballot 3225):
- Stewart Bryant: Comment [2011-02-15]:
I have one question which is almost a discuss discuss. Should IANA reserve/have a special request process for services that contain IETF key words that imply critical IETF services (IETF, BGP, MPLS...) so no one can pass of a proprietary design as one approved by the IETF.
- Adrian Farrel: Comment [2011-02-15]:
I am worried that this document should discuss deprecation. I don't think it is important enough for a Discuss, but would appreciate the authors considering this. IMHO, it is subtly different from de-assignment.
- Alexey Melnikov: Comment [2011-02-15]:
I need to check if IETF LC comments regarding anonymous reviewers should be addressed
- as per document authors this is out of scope for this document and will be described in another document.
(Currently internal processes of the IANA ports and services design team are not documented by any RFC. This document doesn't change that.)
- Tim Polk: Comment [2011-02-16]:
(1) In section 7.2, the word "strives" and phrase "strive to" are used repeatedly in an effort to give IANA some wiggle room. While wiggle room is probably a necessity, it would be helpful to explain when the wiggle room may reasonably be required. It would probably be good to require additional information in the request whenever the submitter asks IANA to violate these principles.
This *might* help avoid some appeals.
(2) In 8.2, the process for de-assignment can only be initiated by the Assignee: "The Assignee of a granted port number assignment can return the port number to IANA at any time if they no longer have a need for it."
Section 8.4, revocation, would presumably cover the case where the process was initiated by someone other than the Assignee. However, there doesn't seem to be a mechanism for a 3rd party to indicate they believed specific ports could safely be de-assigned/revoked. Should this section provide instructions (e.g., email destination, preferred subject line, required contents) for such submissions?
[Note: the remainder of 8.4 seems entirely satisfactory to process such a
request...]
(3) Waiting to see what Alexey determines about anonymous reviewers :)
- Peter Saint-Andre: Discuss [2011-02-15]:
I am strongly in favor of this document and will probably change my ballot to "Yes" once we have a chance to discuss the following two issues.
1. [addressed by existing text, clarified through discussion]
2. Regarding port numbers, Section 8.1.1 states:
"Note that the applicant MUST NOT use the requested port prior to the completion of the assignment."
This seems quite unrealistic, because developers (and developer communities) use ports all the time when designing and testing application protocols Prohibiting such experimentation strikes me as detrimental to innovation and opposed to the IETF's principles of "rough consensus and running code".
- Robert Sparks: Comment [2011-02-17]:
1) I can't see how "IANA strives to" is functionally in any way different from "IANA SHOULD". What do you expect either IANA or the expert reviewers to do differently given those different phrases as guidance?
2) This document should acknowledge that the conversation around non-anonymous expert review happened, call out the conclusion (I believe we saw community consensus that it was important), and recommend the work that would need to happen to put that in place.
- Sean Turner: Comment [2011-02-17]:
(I didn't think of this but it might be a good idea)
It would be nice to have something that would allow a 3rd party to indicate that a service name/port number can be de-assigned. For example, the assignee is unreachable and their company have gone belly up. Their protocol was never widely deployed and ten years later it's completely gone. A good netizen could inform IANA about this and then IANA could determine whether it's true and de-assign the name/number.
Telechat:
- Alexey: Let's quickly talk about this. Peter, do we need to discuss the second point of your discuss?
- Peter: No.
- Alexey: I'll try to convince Joe to change the wording.
- Robert: I suppose Peter's sentiment on that; he's not alone.
- Alexey: I get his point. OK, let's do this by email.
- Lars: Maybe we can rephrase this [proposes wording].
- Alexey: Experimenting with a port is OK as long as it doesn't leak. I think I can add some RFC-ed notes on this, but let's go to email. Other point worth mentioning is that Cullen's LC comments raise the question about scope of the doc. Among the authors, and I agree, the scope of the doc is basically to restructure and unify IANA registries. It's not talking about the specific process of the review team. It also doesn't talk about specific details about why one port is preferred to multiple. There is apparently no consensus on this point. I think a paragraph near the beginning of the doc clarifying scope would be good.
- Lars: That sounds OK.
- Peter: That would help, because people think it's saying more than it is.
- Lars: There's a disconnect here, so if we can clarify it in the intro, that's good. This is meant to describe procedures for IANA with the registry. It's not meant to be a guide for the public. That's not clear to many people. This could be a never-ending doc, and I think it's good enough now.
- Alexey: That's the major concern: if we start describing review team process, it's controversial, and it will drag on. Restructuring the registries is the important par.
- Robert: Restructuring the registries is copping out, not talking about how IANA works with the review teams.
- Lars: No other expert review teams have their procedures described in much detail. The reason they're called experts is that we trust their technical opinions.
- Robert: You're talking about not putting in vast sections. I'm just talking about not even touching the anonymous review thing because it's out of scope. That particular detail should be in scope. We do, with a lot of documents, give guidance to the experts. it would be reasonable to have that in here.
- Lars: This doc has some of that. I also want to mention about public reviewers, this is something we have to discuss in the scope of RFC 5226, in general.
- Michelle: For all registries, the name of the reviewer is public. We had a talk about this, to say in the response "your application was reviewed by X". We're doing that for all registries. I don't think this is an issue any more.
- Jari: I'm basically siding with Lars. There's a set of things you could say about the guidance, and I think this is saying enough, or close to it. It wouldn't help to make it too detailed. I'm in favour of letting this doc move forward.
- Robert: I balloted "no obj", ad made comments. I think we actually lose some benefit of the energy by pretending this discussion didn't happen.
- Lars: There were issues with insufficient information in requests, and there was some bad interaction with the reviwers as a result. That's why the reviewers want some sort of anonymity. The reviewers need to be able to be candid and not have to defend their positions in public. Opening up the information about who the reviwers are can be problematic. It's not easy to find reviewers, and we don't want to lose them because of things like this.
- Robert: Open process is open. Discussions should happen on the lists. There are ways to mitigate the pain if we want to make this review process more open, and I think we should. But I think we don't hold up this doc to make that happen.
- Peter: I agree that we should make this as transparent as we can.
- Alexey: I was pushing editors to work on another doc in this area. But this will take time.
- Peter: I don't want to hold this up, but let's note somewhere that this conversation happened, and further work is required.
- Alexey: I can add a comment in the tracker.
- Ralph: I thought you were talking about deleting sec 7 entirely. Is that true?
- Alexey: We're still discussing. I don't think it will happen.
- Robert: I would object.
- Alexey: If a better argument is made to delete it, I'll bring it to the IESG.
- Lars: There's been no discussion of that among the authors.
- Alexey: We still have some discussion among editors. We have some time to get closure here in the next couple of weeks. I'll take the discussion with Peter to email, and I'll enter more RFC-ed notes based on our discussions.
- Amy: Will this require revised ID?
- Alexey: Not sure. I think I can do it with RFC-ed notes.
- Amy: I'll put it in AD followup.
- IS-IS Extensions Supporting IEEE 802.1aq Shortest Path Bridging (Proposed Standard)
draft-ietf-isis-ieee-aq-04
Token: Stewart Bryant
Note: David Ward (dward@juniper.net) is the document shepherd.
Discusses/comments (from ballot 3660):
- Tim Polk: Discuss [2011-02-16]:
The security considerations state: "If zero configuration methods are used to auto configure NNIs or UNIs there are intrinsic security concerns that should be mitigated with authentication procedures for the above cases. Such procedures are beyond the scope of this document."
draft-ietf-isis-ieee-aqWhile these procedures are beyond the scope of this document, it would be helpful to identify which procedures the authors have in mind (or note that such procedure have yet to be developed).
- Dan Romascanu: Discuss [2011-02-14]:
1. The following convention is defined for the document in Section
"The lower case forms "must", "must not", "shall", "shall not", "should", "should not" and "may" in this document are to be interpreted in the sense defined in [RFC2119], but are used where the normative behavior is defined in documents published by SDOs other than the IETF."
There are two problems here that attracted my attention:
- should really any form of "must" or "should", etc. that appears in this document be interpreted in the sense defined in [RFC2119]? This does not seem to be the intention, and I would prefer to make clear that this interpretation applies only in the sections that deal with the IEEE 802.1 documents.
- The keywords "recommended" and "optional" are missing from the list. Is this intentional? While I could not find any instances of "recommended" I did find a few instances of "optional" which I would think should be interpreted in the sense defined in [RFC2119] - for example in section 4.1
2. In the IANA considerations section:
"The MT-Capability TLV is the only TLV requiring a new sub-registry. Type value 144 (TBD) is requested, with a starting sub-TLV value of 1, and managed by Standards Action."
Is really Standards Action necessary? Why would not Expert Review be sufficient?
- Peter Saint-Andre: Comment [2011-02-16]:
I agree with Dan Romascanu's DISCUSS regarding lower-case conformance keywords -- they are confusing
- Sean Turner: Comment [2011-02-17]:
I support Tim's discuss.
Also, is this draft going to be held by the RFC editor while the 802.1aq draft goes final? The normative reference is to a DRAFT of the IEEE spec.
Telechat:
- Stewart: I'd like advice about one item. Dan, the authors will sort your discuss out. This is essentially an enabling doc, the twin of the trill specs. The question is how much I need to push them on a sec consid section. The second question has to do with what we do about normative dependency on the IEEE spec. I'm keen to make IEEE not get the impression that IETF is sitting on this to delay them.
- Tim: On sec consid, I don't think there's much more for them to do. They made significant improvements based on the secdir and opsdir reviews. One issue is talking about authentication problem, where they do hand-waving. Need to be clear whether there's new engineering that needs to be done. I think we need that. But that's the only question that's raised.
- Stewart: I'd like to get your help on that. What do we do about the normative ref to the IEEE spec?
- Dan: What is the spec that's referenced?
- Stewart: The rest of the AQ design itself. We only do a piece of it.
- Tim: Is that doc not stable yet? A draft?
- Stewart: I don't know how close to gelling it is. I don't know how the IEEE process works, I think they need an RFC number.
- Dan: Do they need an RFC number from us?
- Russ: Do they need IANA numbers, or RFC numbers?
- Dan: IEEE specs have two types of ref, equivalent to ours.
- Stewart: They need our IANA stuff before they finish.
- Russ: We can give them that before RFC if that's sufficient.
- Stewart: I'll talk to the authors and find out what they need. I want the IETF to be whiter than white in dealing with this.
- Michelle: Is this doc approved already?
- Stewart: It has discusses, but we think we can resolve quickly.
- Michelle: IANA will assign the numbers as soon as it's approved.
- Stewart: They can probably be OK with it in the editor queue. I'll find out when they need the RFC number. And it's "revised ID".
- Using 127-bit IPv6 Prefixes on Inter-Router Links (Proposed Standard)
draft-ietf-6man-prefixlen-p2p-01
Token: Jari Arkko
Note: Bob Hinden (bob.hinden@gmail.com) is the document shepherd.
Discusses/comments (from ballot 3676):
- Ralph Droms: Comment [2011-02-14]:
Pedantic, editorial nits...
- Lars Eggert: Comment [2011-02-15]:
Section 6., paragraph 3:
a) Addresses with all zeros in the rightmost 64 bits SHOULD NOT be assigned as unicast addresses, to avoid colliding with the Subnet-Router anycast address [RFC4291].
b) Addresses in which the rightmost 64 bits are assigned the highest 128 values, (i.e., ffff:ffff:ffff:ff7f to ffff:ffff:ffff:ffff), SHOULD NOT be used as unicast addresses to avoid colliding with Reserved Subnet Anycast Addresses [RFC2526].
Any reason these are not MUST NOTs?
- Adrian Farrel: Comment [2011-02-17]:
I have reduced my position from a Discuss after useful discussion with two of the authors about whether an "updates" clause would be useful/relevant.
It would be good to find a way to dilute the language that appears to say the I-D is fixing some specific issues in a specific RFC. Maybe a way forward would be to be more positive about this document "This document provides a definitive statement on..." "This document clarifies issues in a number of previous RFCs that have led to misunderstandings..." "This document offers latest guidance / best common practice on the use of..."
I'll leave this with the authors/shepherd/AD to think about, and if you think it is silly or wrong or impossible, then it's your document and this is only a Comment.
- Sean Turner: Comment [2011-02-16]:
#1) Sec 3: s/does not apply/do not apply
#2) Sec 5.1: s/which uses medium/which use a medium
Telechat:
- Amy: No issues on this. No objections: approved.
- IS-IS Registry Extension for Purges (Proposed Standard)
draft-ietf-isis-reg-purge-00
Token: Stewart Bryant
Note: David Ward (dward@juniper.net) is the document shepherd.
Discusses/comments (from ballot 3678):
- Ralph Droms: Discuss [2011-02-16]:
Following up to get a bit of history filled in, section 3.3.1 of RFC 3563 indicates that, as of the time of publication of RFC 3563, ISO/IEC JTC1 would take over the IS-IS registry:
"Until JTC1 provides the registry service for IS-IS, IANA is requested to temporarily maintain such a registry as described below. Upon notification from JTC1, the registry management authority (i.e., value allocation) will be transferred to JTC1. [...]"
Has this transfer of registry service to JTC1 taken place or (as I assume) is the IANA registry still authoritative? Is there still a need to notify JTC1 of the change to the registry proposed in this document?
- Lars Eggert: Comment [2011-02-15]:
Agree with Dan that this document should be on a telechat AFTER it passes IETF last call (unless this is urgent in some way?)
Section 4., paragraph 1: "This document requests that IANA modify the IS-IS 'TLV Codepoints Registry' by adding a column in the registry for 'Purge'. A 'y' in this column indicates that the TLV for this row MAY be found in a purge. A 'n' in this column indicates that the TLV for this row MUST NOT be found in a purge."
It would be slightly more self-explanatory if the registry column was titled "Allowed in Purge".
- Tim Polk: Discuss [2011-02-16]:
This is a fine document, and I support its publication, but...
I was surprised to find an extensive update to the purge processing and generation rules in this document. The title, abstract, and introduction gave me no clue that there would be new processing rules. Perhaps that merits a mention somewhere before section 3?
- Dan Romascanu: Comment [2011-02-14]:
I have no objection with approving the document as it stands right now but I observe that there is an IETF Last Call running for it and lasting six days after the IESG telechat date. I suggest that any approval be conditional, and in case substantial comments are submitted as Last Call comments after the IESG telechat they are brought to the attention of the IESG.
Telechat:
- Stewart: Good dialogue between authors and ADs. I thought we were close to resolution. In the case of Ralph's, it seems that everyone knows the history and what's happening.
- Ralph: If everyone knows the history, that might be in the category of the IPv6 document cleanup. Maybe we need a doc that says this registry belongs to IANA. I'll clear.
- Stewart: Did authors get back to Tim on your discuss?
- Tim: He proposed text for the abstract, which I'd like to see in the body too. I'll clear if you do that as a note.
- Stewart: It needs to go to point raised.
- Amy: AD follow-up.
- Purge Originator Identification TLV for IS-IS (Proposed Standard)
draft-ietf-isis-purge-tlv-05
Token: Stewart Bryant
Note: David Ward (dward@juniper.net) is the document shepherd.
Discusses/comments (from ballot 3679):
- Ralph Droms: Comment [2011-02-16]:
Balloting no objection assuming there is an easy answer to my question (posted to draft-ietf-isis-reg-purge-00) about the IANA ISIS-TLV registry and notifying ISO JTC1.
- Tim Polk: Comment [2011-02-16]:
In the Intro, this document states: "Field experience has observed several circumstances where an IS can improperly generate a purge. These are all due to implementation deficiencies or implementations that predate [ISO TC1] and generate a purge when they receive a corrupted LSP."
In the security considerations, it is noted that: "Therefore, all implementations in a domain implementing authentication MUST be upgraded to receive the POI TLV before any IS is allowed to generate a purge with the POI TLV."
Since you need to touch every ISIS implementation in the domain anyway, is it worth stating that implementations SHOULD be updated for consistency with [ISO TC1] (i.e., and not generate a purge when they receive a corrupted LSP) at the same time?
- Dan Romascanu: Comment [2011-02-14]:
"This document requests that IANA assign code point 13 for the 'Purge Originator Identification' TLV from the IS-IS 'TLV Codepoints Registry'. The additional values for this TLV should be: IIH:n, LSP:y, SNP:n, Purge:y."
I assume that this is OK with this document but usually an Internet-Draft cannot / should not make a request for a specific value, but just require a code point value and recommend that this value be 13.
- Sean Turner: Comment [2011-02-16]:
Please add a pointer for where I can find the definition of system ID.
Telechat:
- Stewart: I need to go through the comments on this to make sure they're addressed properly.
- Amy: Aproved, point raised, writeup needed.
- A Registry for PIM Message Types (Proposed Standard)
draft-ietf-pim-registry-04
Token: Adrian Farrel
Note: Mike McBride (mmcbride@cisco.com) is the document shepherd.
Discusses/comments (from ballot 3686):
- Lars Eggert: Comment [2011-02-15]:
Section 3.2., paragraph 1: "Assignment of new message types is done according to the "IETF Review" model, see [RFC5226]."
It'd be good to add "or IESG Approval" here - there are sometimes cases where that shortcut is needed.
- Tim Polk: Comment [2011-02-16]:
I can't remember if there is a precedent for registry documents achieving PS. The decision to reserve the value 15 to support extensibility might be justification, but that seems relatively weak. So, I support discussing Robert's issue, but do not have a particularly strong position either way. If anyone can point out precedent justifying going PS that would be enough for me...
- Dan Romascanu: Discuss [2011-02-17]:
3.2. Assignment of new message types: "Assignment of new message types is done according to the "IETF Review" model, see [RFC5226]."
Adding new message types would update this document whose intended status is PS. It looks like "IETF Review" policy is not enough, as IETF Review does not mandate a standards track document, but just WG or AD-sponsored documents that go through IETF Lasc Call (but still could be Informational or Experimental). ":Standards Action" policy seems to be needed in order to update this document.
Note that if Robert's DISCUSS is resolved by donwngrading the intended status of this document to Informational, than "IETF Review" would be sufficient.
- Robert Sparks: Discuss [2011-02-15]:
Why is the intended status PS? This isn't a candidate for progression on the standards ladder (an interop report will never make sense).
Telechat:
- Amy: We can't discuss this with Adrian, because he's had to leave.
- Robert: At least one is something we can start discussing, and continue on next call. I'll take the token to find the next time we can discuss it. It had to do with the intended status of docs that are just creating a registry. Things that don't have protocol don't make sense on standards track. 2026 talks about this, and this was one reason BCP was created. This particular doc would be fine as informational. Having these kinds of docs go out as PS wouldn't be terrible, but it confuses what standards track is. Dan has a discuss that refers to mine. I was planning to clear. Should I not?
- Dan: No, hold discuss. If the status changes it will handle mine as well.
- Robert: It looks like you're worried that if something registers a code point in this registry, it will have to update this doc.
- Dan: Yes. This .... document that creates a new message type. An information can't update a standards track doc. If intended status stays as PS, then the policy needs to be changed to "standards action".
- Robert: Or some text could be added to make this explicit.
- Stewart: It does give the procedure for new entries. We have precedents for documents that create registries and are never updated.
- Robert: Dan's objection is that there are particular code points that seem to have higher level of protection.
- Dan: The ones that are in there are fine. 11 are allocated, and 12 to 15 are for future use. I'm concerned about the status of future docs.
- Stewart: It says that anything that uses 12 to 15 must have gone through IETF review.
- Dan: I don't believe that's sufficient.
- Stewart: What else is needed?
- Dan: I don't know.
- Robert: As I understand it, an informational RFC that registers these might have to update this RFC.
- Stewart: This tells you how to add new code point. We never have to update others like this.
- Dan: It would modify the table in the registry.
- Robert: Following the procedure that's established. The table in this doc seeds the registry, but isn't the registry.
- Dan: OK. I would prefer more clear wording in this doc.
- Stewart: There is precedent for this. 4446 set up initial pseudowires registries. That was a BCP.
- Dan: I am clearing.
- Robert: Do you want a comment that you want extra clarity that this is just a seed? I'd like Adrian to consider making this informational, but please clear my discuss.
- Amy: I will clear for you. Adrian wants this to go to point raised, writeup needed.
2.1.2 Returning Items
- (none)
2.2 Individual Submissions
2.2.1 New Items
- Metalink/HTTP: Mirrors and Cryptographic Hashes in HTTP Header Fields (Proposed Standard)
draft-bryan-metalinkhttp-20
Token: Alexey Melnikov
Discusses/comments (from ballot 3640):
- Lars Eggert: Discuss [2011-02-15]:
INTRODUCTION, paragraph 4: "This document specifies Metalink/HTTP: Mirrors and Cryptographic Hashes in HTTP header fields, a different way to get information that is usually contained in the Metalink XML-based download description format. Metalink/HTTP describes multiple download locations (mirrors), Peer-to-Peer, cryptographic hashes, digital signatures, and other information using existing standards for HTTP header fields. Clients can use this information to make file transfers more robust and reliable."
DISCUSS: The document title and this summary aren't really accurate. In addition to describing how to store Metalink info in HTTP header fields, a large part of the document (Section 7) is actually specifying how Metalink clients MUST/SHOULD/MAY operate.
Section 3.3., paragraph 1: "There are two types of mirror servers: preferred and normal. Preferred mirror servers are HTTP mirror servers that MUST share the same ETag policy as the originating Metalink server and/or MUST provide Instance Digests using the same algorithm as the Metalink server."
DISCUSS: Section 1 said "SHOULD share the same ETag policy" - which is it?
Section 7., paragraph 13: "If the object is large and gets delivered slower than expected, then the Metalink client MAY start a number of parallel ranged downloads (one per selected mirror server other than the first) using mirrors provided by the Link header fields with "duplicate" relation type. Metalink clients SHOULD use the location of the original GET request in the "Referer" header field for these ranged requests.
DISCUSS: I realize that this spec doesn't really cover the client, but I find this description of permitted client operation problematic. What it basically says is "if the download is slow, open more connections." This is NOT a good general practice. There need to be limits on the number of parallel connections, ideally based on observing how the aggregate throughput changes as connections are opened - blindly opening connections once the path bottleneck is filled is pointless. (There is some text later in this section that goes in this direction, but not far enough.)
- Lars Eggert: Comment [2011-02-15]:
Section 3.2., paragraph 1: "Entries for a mirror servers can have a "geo" value, which is a [ISO3166-1] alpha-2 two letter country code for the geographical location of the physical server the URI is used to access. A client can use this information to select a mirror, or set of mirrors, that are geographically near (if the client has access to such information), with the aim of reducing network load at inter-country bottlenecks."
s/can/MAY/? The document is generally pretty sloppy in its use of RFC2119 terms; it would be very good if the authors would go over it once more.
Section 4., paragraph 1: "Entries for metainfo files, which describe ways to download a file over Peer-to-Peer networks or otherwise, are specified with the Link header fields [RFC5988] and a relation type of "describedby" and a type parameter that indicates the MIME type of the metadata available at the URI. Since metainfo files can sometimes describe multiple files, or the filename may not be the same on the Metalink server and in the metainfo file but still have the same content, an optional name parameter can be used."
s/optional/OPTIONAL/ and/or s/may/MAY/
Section 4.1., paragraph 1: "Full Metalink/XML files for a given resource can be specified as shown in the example in Section 4."
Specify-by-example isn't how things are usually done in the IETF. It would be good to have an actual specification.
- Alexey Melnikov: Comment [2011-02-15]:
IETF LC ends 1 day after the assigned telechat day (i.e. on February 18th).
- Peter Saint-Andre: Discuss [2011-02-16]:
Overall I don't see any insuperable problems with this specification, although the protocol introduces the possibility of several kinds of amplification attacks and denial of service attacks (see RFC 4732, which could usefully be added to the references). Robert Sparks and I chatted about those a bit today and I concur with the DISCUSS he has posted.
In addition, I have a concern with the following text from Section 7.1.1: "ETags can not be used for verifying the integrity of the received content. But it is a guarantee issued by the Metalink server that the content is correct for that ETag. And if the ETag given by the mirror server matches the ETag given by the Metalink server, then there is a chain of trust where the Metalink server authorizes these responses as valid for that object."
The term "chain of trust" is a bit strong here, given that "trust chain" is a synonym for "certification path" according to RFC 4949. In addition, the presence of an identical ETag does not guarantee that the mirror is truly *authorized* by the Metalink server, because a malicious mirror could simply copy whatever ETag it finds at the Metalink server (this is noted later in the section). The concepts of trust and authorization are weak here, so I suggest that we use other terms, except in cases where the client really can determine that the mirror is authorized (e.g., via a cryptographically signed Metalink XML file or HTTP header).
- Robert Sparks: Discuss [2011-02-16]:
The automated handling of the Link headers by MetaLink clients suggested by this document may need some more discussion, at least in the security considerations section. Apologies if I've missed where this is already discussed.
1) What prevents a malicious server from returning a 200 with many Link: headers, all indicating rel=duplicate, perhaps indicating non-overlapping subsets of the entity, and all pointing to a victim, driving many, possibly parallel, connection attempts?
2) When a Link (indicating an HTTP resource) is followed, does anything prevent that referenced server from also replying with MetaLink headers in its response? If not, what prevents loops, intentionally or unintentionally created, from being followed? If a client would automatically follow these, especially in parallel, exponential attacks against the victims in item 1) are possible. At the very least, a client could be sent into an infinite ping-pong loop.
- Sean Turner: Discuss [2011-02-14]:
This is a preliminary discuss (and not yet sent to anybody).
#1) Sec 2 Says: "Valid algorithms are found in the IANA registry named "Hypertext Transfer Protocol (HTTP) Digest Algorithm Values" at <http://www.iana.org/assignments/http-dig-alg/http-dig-alg.xhtml>."
Then, Sec 10.3 says: "Currently, some of the digest values defined in Instance Digests in HTTP [RFC3230] are considered insecure."
This could confuse some people. Section 2 should be modified to say: "Algorithms used in the Instance Digest field are registered in the IANA registry named "Hypertext Transfer Protocol (HTTP) Digest Algorithm Values" at <http://www.iana.org/assignments/http-dig-alg/http-dig-alg.xhtml>. This document restricts the use of these algorithms."
#2) Sec 3: Confused by the following: "[[Some organizations have many mirrors. Only send a few mirrors, or only use the Link header fields if Want-Digest is used?]]"
Was this supposed to be removed or is additional information required?
#3) Sec 3.2: Are there any privacy considerations that need to be addressed with the use of the geo tag?
#4) Sec 5: Only specifies OpenPGP signatures. I'm curious why this choice? I
would think you'd want to reuse existing security built in browsers based on TLS
and OpenPGP isn't the mandatory to implement scheme it's X.509. Also, any reason S/MIME isn't there? ...
#5) There are multiple schools of thought about putting requirements in the security considerations. If you're going to put them in the security considerations, then I think a pointer to the algorithm requirements from section 6 to section 10 needs to be included.
#6) Sec 7: Need to say something about what to do if the signature is included. Does it to validate back to a trust anchor. Point to OpenPGP/RFC5280 for validation rules.
#7) Section 10: (I wrote this before I got to section 7 - will revisit it)
a) Because Mirrors "SHOULD" include an Instance Digest instead of "MUST" include them, then I think you need to say something about using Mirrors can lead to substitution attacks and how you might mitigate them (user performs some action). Maybe this could be worked in to the spoofing paragraph (i.e., the case when no instance digest is specified).
b) You also need to say something about using multiple mirrors when downloading.
What happens when one supports an instance digest and the other doesn't (as in the last para of Section 2). What happens when the 1st one the client connected to supports it but the second doesn't. How is this supposed to work and can the client do anything to figure out that they got something they can cryptographically verify?
- Sean Turner: Comment [2011-02-14]:
#1) Sec 7: r/A Range limit is optional,/A Range limit is OPTIONAL,
#2) Section 7: r/fieldss)/fields).
#3) Sec 7.1.1: r/merging of ranges from multiple responses must be verified/ merging of ranges from multiple responses MUST be verified
#4) Sec 7.1.1: r/fieldss is./fields is.
Telechat:
- Elliptic Curve Algorithms for Cryptographic Message Syntax (CMS) Asymmetric Key Package Content Type (Proposed Standard)
draft-turner-akf-algs-update-03
Token: Tim Polk
Note: Sean Turner (turners@ieca.com) is the document Shepherd.
IPR: Certicom's Statement of IPR Related to draft-turner-akf-algs-update-02
Discusses/comments (from ballot 3682):
- Adrian Farrel: Comment [2011-02-16]:
Can I express my considerable concern about the wasted space on page one of this document without which you would have completed it in only three pages.
Telechat:
- Amy: No discuss. No objection, approved.
- Elliptic Curve Algorithms for Cryptographic Message Syntax (CMS) Encrypted Key Package Content Type (Proposed Standard)
draft-turner-ekpct-algs-update-03
Token: Tim Polk
Note: Sean Turner (turners@ieca.com) is the document Shepherd.
IPR: Certicom's Statement of IPR Related to draft-turner-ekpct-algs-update-02
Discusses/comments (from ballot 3683):
- Alexey Melnikov: Comment [2011-02-10]:
3. SignedData: "If an implementation encapsulates an EncryptedKeyPacakge with a"
typo: EncryptedKeyPackage
Telechat:
- Amy: No discuss. No objection, approved.
- Scalable Operation of Address Translators with Per-Interface Bindings (Proposed Standard)
draft-arkko-dual-stack-extra-lite-05
Token: Ralph Droms
Discusses/comments (from ballot 3692):
- Stewart Bryant: Comment [2011-02-17]:
I agree that this looks a lot more like informational that standards track.
I also agree that the introduction should be updated to reflect the exhaustion of the IPv4 address space.
- Adrian Farrel: Discuss [2011-02-16]:
I support this document, but...
I struggled with this document to understand what there is to implement. It all seemed a bit "obvious". Is this really a BCP or Informational?
Shouldn't section 4 talk about what to do when an interface has used up the available number of IP addresses? Creating a "parallel" virtual interface may not be a big deal, but creating the first virtual interface when a physical insterface is "full" seems like a major operational step
- Adrian Farrel: Comment [2011-02-16]:
I didn't really find that Section 2 "Solution Outline" was an outline of the solution. It looks more like an overview of the problem space and the benefits of the yet-to-be-introduced solution.
Maybe Section 3 should also say that "internal realm" and "external realm" are derived from somewhere?
Section 3: "This document uses the term mapping as defined in [RFC4787] to refer to state at the NAT necessary for network address and port translation of sessions."
Could you put "mapping" in quotes to stop the reader getting confused that you are refering to a process of "term mapping".
Section 4: Strictly speaking, isn't there a limit to the "arbitrary number" of devices served by a NAT? So it isn't really arbitrary?
Maybe take the chance to update the info about the IANA free pool?
- Tim Polk: Comment [2011-02-16]:
(1) Some of the introductory material is out of date. Specifically, the IANA free pool has now been exhausted but the document states:
"At the time of writing, the IANA "free pool" contained only 12 unallocated unicast IPv4 /8 prefixes."
This should be corrected, since the date on the RFC will be long after the free pool was depleted.
(2) I support Adrian's discuss. Feels like informational or BCP. Given that the free pool is exhausted I lean towards BCP, but that would require another
IETF Last Call.
- Peter Saint-Andre: Comment [2011-02-15]:
Thanks for this clearly written document.
This document feels Informational (not Standards Track) to me, but I'm fine with publication as Proposed Standard.
Telechat:
- Amy: Will go into AD follow-up, because discuss-holder not on.
- Jari: I will discuss by email. We have a number of documents, and this should go in the same category with those. We have three authors, and one is new. He wants to make some changes, and we're discussing that.
- Stewart: If a new author wants to do a major edit, that needs to go for further discussion.
- Lars: One option is that he takes his name off the doc. What he wants to do will probably need another last call.
- Stewart: I want to see what he has to say, and would not be happy with this doing through until that happens. Would it help if someone put a defer on it?
- Jari: Someone can hold a discuss for that. I also want to see Mark's concerns, but I might not agree with them. There's no practical action needed.
- Stewart: I'm inclined to change mine to discuss, saying that I want to hear one of the author's comments first.
- Amy: I'll put this in AD follow-up.
- Special-Use Domain Names (Proposed Standard)
draft-cheshire-dnsext-special-names-01
Token: Ralph Droms
Discusses/comments (from ballot 3693):
- Alexey Melnikov: Comment [2011-02-14]:
I agree with a comment that this document should register existing special names in the registry, or make a more compelling argument about why the registry is needed.
- Tim Polk: Discuss [2011-02-16]:
I expected the document to seed the registry with entries (at a minimum) for the special domain names identified in the introduction:
"Analogous to Special-Use IPv4 Addresses [RFC5735], DNS has its own concept of reserved names, such as "example.com", "example.net", and "example.org", or any name falling under the top level pseudo-domain "invalid" [RFC2606]."
Without those entries (or a plan to create those entries), I don't quite see that this document accomplishes anything.
- Tim Polk: Comment [2011-02-16]:
last sentence of section 2: "reservation of a Special-Use Domain Names" - s/Names/Name/
- Dan Romascanu: Discuss [2011-02-14]:
The OPS-DIR review performed by Jouni Korhonen raised the issue bellowed. I would like to see it addressed before approving this document:
In section 4, check step 2. Do algorithmically generated names fall into this category? If yes, these should be mentioned in the draft as well. ...
- Peter Saint-Andre: Comment [2011-02-14]:
Although I do not object to publication of this document, I agree that it would be preferable for this document to seed the registry with initial registrations.
- Robert Sparks: Comment [2011-02-15]:
Thanks for this effort - I expect this registry (as long as its registration policy is Standards Action) to be a very useful tool.
Will you be updating draft-cheshire-dnsext-multicastdns to explicitly request registration of .local (pointing to section 23 of that draft?)
- Sean Turner: Discuss [2011-02-16]:
The first one is a DISCUSS-DISCUSS
#1) Is adding a new required section in an RFC done this in way? It seems like this ought to come from a WG or be part of the style guide?
#2) Use of the word "needs" in Section 3 seems like it ought to be MUST. Is there a time when you wouldn't do the items it suggests?
#3) Shouldn't the "Special Name Considerations Section" just be part of the IANA considerations section?
- Sean Turner: Comment [2011-02-16]:
1) +1 to including values. Maybe some from http://www.ietf.org/mail-archive/web/dnsext/current/msg10557.html ?
2) There really aren't any security considerations. Could move the last sentence to section 4.
Telechat:
- Amy: Some discusses here. Will we need a revised ID? Or make it AD follow-up?
- Dan: Mine is on the way to being resolved by editing. I don't know what Ralph wants to do with that. My changes aren't heavy.
- Sean: Mine was discuss-discuss. Do we normally specify a new section that must go into an RFC in this way, or does it just go into the style guide?
- Russ: We do not touch the style guide. IESG is not in charge of that.
- Sean: By approving this, are we saying we need a new section in all docs?
- Russ: We're saying that if you specify a particular thing, you have to do it in this way.
- Sean: OK. I was looking at it as another thing like sec consid. But this only goes into docs that are registering this. I also wonder about words like "needs", and whether they should be "MUST". We can talk about that by email.
- Michelle: Can someone who has a discuss hold it for IANA? I want my boss to look at it.
- Sean: I'll do that.
- Amy: Revised ID needed.
2.2.2 Returning Items
- (none)
3. Document Actions
3.1 WG Submissions
3.1.1 New Items
- Transient Binding for Proxy Mobile IPv6 (Experimental)
draft-ietf-mipshop-transient-bce-pmipv6-07
Token: Jari Arkko
Note: Vijay Devarapalli (vijay@wichorus.com) is the Document Shepherd
IPR: NEC Europe Ltd.'s Statement about IPR related to draft-ietf-mipshop-transient-bce-pmipv6-04
IPR: Qualcomm Incorporated's Statement about IPR related to draft-ietf-mipshop-transient-bce-pmipv6-07
Discusses/comments (from ballot 3238):
- Adrian Farrel: Comment [2010-08-26]:
Clearing my Discuss on the basis of Jari's answer: "That's a good question to ask. The answer is yes."
- Russ Housley: Comment [2011-02-15]:
Do either of the IPR statements related to this document cause pause?
- Alexey Melnikov: Comment [2010-08-26]:
6. IANA Considerations: "This specification also adds one status code value to the Proxy Binding Acknowledge message, the PBU_ACCEPTED_TB_IGNORED_SETTINGSMISMATCH status code. The PBU_ACCEPTED_TB_IGNORED_SETTINGSMISMATCH status code is described in Section 4.7. Its value must be assigned from the same number space used for the Mobile IPv6 Binding Acknowledgement status values, as defined in [RFC3775], and must be smaller 128."
I am looking at <http://www.iana.org/assignments/mobility-parameters/mobility-parameters.xhtml> and I am not finding "Binding Acknowledgement status" sub-registry. Am I looking in a wrong place, or is it named differently?
Telechat:
- Amy: No discuss. No objection, approved.
- PCC-PCE Communication and PCE Discovery Requirements for Inter-Layer Traffic Engineering (Informational)
draft-ietf-pce-inter-layer-req-15
Token: Stewart Bryant
Note: Julien Meuric (julien.meuric@orange-ftgroup.com) is the document shepherd.
Discusses/comments (from ballot 3583):
- Russ Housley: Comment [2011-02-16]:
(blank)
- Dan Romascanu: Comment [2011-02-17]:
Section 4.6. - Impact on Network Operation seems descriptive and contains no requirements (as do sections 4.1-4.5). If this is the case it should be explicitely stated.
Telechat:
- Stewart: Please put this on hold so I can make sure I don't miss anything.
- Amy: Approved, point raised, writeup needed.
- Issues with IP Address Sharing (Informational)
draft-ietf-intarea-shared-addressing-issues-03
Token: Jari Arkko
Note: Julien Laganier (julienl@qualcomm.com) is the document shepherd.
Discusses/comments (from ballot 3633):
- Ralph Droms: Discuss [2011-02-16]:
I don't understand this sentence:
17. IPv6 Transition Issues: "[...] Shared addresses should be drawn from space designated as such [RFC1918]. Otherwise their use will break the widely implemented assumption that public IPv4 addresses are globally unique addresses and hence break many protocols and applications, [...]"
Which "shared addresses" are under discussion here? Isn't the motivation for this document the need to share public addresses because of IPv4 address exhaustion?
Later in the same section: "Issues created by sharing public address space across multiple hosts are specifically addressed in [I-D.thaler-port-restricted-ip-issues].
Isn't thaler-port-restricted-ip-issues just focused on issues with A+P addressing, not generally public address space sharing issues?
Does address sharing affect any other transition technologies, or just 6-to-4?
- Ralph Droms: Comment [2011-02-16]:
In Figure 1, while reverse DNS is affected (more precisely, broken) by NAT without address sharing, in my opinion it is affected differently (more broken) by address sharing. Might deserve "xx"?
- Lars Eggert: Discuss [2011-02-16]:
I'm adding a placeholder discuss to make sure the discussion between the authors and the tsv-dir reviewer terminates and we have a version submitted that addresses all comments.
- Lars Eggert: Comment [2011-02-15]:
Section 1., paragraph 1: "Authority (IANA) were completed on Feburary 3, 2011 [IPv4_Pool]."
Nit: s/Feburary/February/
Section 1., paragraph 3: "Over the long term, deploying IPv6 is the only way to ease pressure on the public IPv4 address pool without the need for address sharing mechanisms that give rise to the issues identified herein. In the short term, maintaining growth of IPv4 services in the presence of IPv4 address depletion will require address sharing."
Given the huge list of issues, I find it surprising to see that the document says "In the short term (...) IPv4 address depletion will require address sharing." The document should much more strongly argue for deploying IPv6 as the solution. It does in a few places, but I think the message bears repeating. Put it in the footer! :-)
Section 3., paragraph 3:
> +------------------------------------------------+--------+---------+
> | Issue | 1st | 3rd |
> | | party | parties |
> +------------------------------------------------+--------+---------+
It would be good for each issue in the table below to indicate which section discusses it in more detail. This is not at all clear from the headings of the subsequent sections. Add a column for this?
Section 5.1., paragraph 3: "A potential problem with dynamic allocation occurs when one of the subscriber devices behind such a port-shared IPv4 address becomes infected with a worm, which then quickly sets about opening many outbound connections in order to propagate itself. Such an infection could rapidly exhaust the shared resource of the single IPv4 address for all connected subscribers. It is therefore necessary to impose limits on the total number of ports available to an individual subscriber to ensure that the shared resource (the IPv4 address) remains available in some capacity to all the subscribers using it."
Limits aren't the only way of handling this. You can also kill off established connections when the port space runs out. If you do this randomly, a user with many connections will be proportionally more likely to get hit, which is what is needed. The benefit of the "kill" scheme is that you can support a wider variety of sharing patterns compared to fixed limits.
Section 5.2.2., paragraph 2: "For example, the use of DNS SRV records [RFC2782] provides a potential solution for subscribers wishing to host services in the presence of a shared-addressing scheme. SRV records make it possible to specify a port value related to a service, thereby making services accessible on ports other than the Well-Known ports. It is worth noting that this mechanism is not applicable to HTTP."
HTTP as well as many other legacy protocols.
Section 13.1., paragraph 0: "13.1. Abuse Logging and Penalty Boxes"
An addition to this section: There are web tie-ins into different black lists that some web site owners subscribe to which redirect clients to a URL that basically says "hey, your machine is infected." Sometimes, they even prevent their site from then working for that users, in order to "give incentives" to fix the problem. With address sharing, someone else's worm can hence interfere with my ability to do stuff. (And I already see this today behind the Nokia NAT, because some clown here has an infected Windows box on the intranet...)
- Alexey Melnikov: Comment [2011-02-17]:
13.6. Policing Forwarding Behaviour: "If some form of IPv6 ingress filtering is deployed in the broadband network and DS-Lite service is restricted to those subscribers, then tunnels terminating at the CGN and coming from registered subscriber IPv6 addresses cannot be spoofed. Thus a simple access control list on the tunnel transport source address is all that is required to accept traffic on the southbound interface of a CGN."
Is "southbound" a common terminology?
17. IPv6 Transition Issues: "Subscribers allocated with private addresses will not be able to utilise 6to4 to access IPv6, but may be able to utilise Teredo."
This needs an Informative reference.
The first reference to HTTP needs an Informative reference.
- Peter Saint-Andre: Comment [2011-02-15]:
Section 12 on Traceability refers to "the offending activity". Given the principle of innocent until proven guilty, I suggest "a particular activity".
- Robert Sparks: Discuss [2011-02-15]:
This document calls out to draft-thaler-port-restricted-ip-issues for several important discussions, but that document has not been refreshed since Feb-10, and I'm not finding any other signs of activity around it. What is the plan for moving that document forward?
- Robert Sparks: Comment [2011-02-15]:
Please consider the text proposed by Richard Barnes
Telechat:
- Jari: I will discuss with Robert over email. Lars, I agree with some of your issues, maybe not all. How do you feel?
- Lars: I can clear. Can Amy do it for me? I just wanted to be sure we didn't approve it while there's still discussion going on about it.
- Jari: I also want to ensure the discussion is complete. Hold the discuss, and clear when we're done. Revised ID needed.
- Framework for GMPLS and PCE Control of Wavelength Switched Optical Networks (WSON) (Informational)
draft-ietf-ccamp-rwa-wson-framework-12
Token: Adrian Farrel
Note: Lou Berger (lberger@labn.net) is the document shepherd.
Discusses/comments (from ballot 3689):
- Russ Housley: Comment [2011-02-15]:
Please consider the comments from the Gen-ART Review by Pete McCann on 7-Feb-2011.
Telechat:
- Amy: No discuss. No objection, approved. Will go into point raised, writeup needed.
3.1.2 Returning Items
- (none)
3.2 Individual Submissions Via AD
3.2.1 New Items
- TOTP: Time-based One-time Password Algorithm (Informational)
draft-mraihi-totp-timebased-07
Token: Sean Turner
Note: Hannes Tschofenig (Hannes.Tschofenig@gmx.net) is the document shepherd.
IPR: VeriSign's Statement about IPR related to RFC 4226, draft-mraihi-mutual-oath-hotp-variants-08, draft-mraihi-totp-timebased-01, draft-ietf-keyprov-dskpp-07, draft-ietf-keyprov-pskc-01, and None
IPR: VeriSign's Statement about IPR related to RFC 4226, draft-mraihi-mutual-oath-hotp-variants-08, draft-mraihi-totp-timebased-01, draft-ietf-keyprov-dskpp-07, and draft-ietf-keyprov-pskc-02
Discusses/comments (from ballot 3571):
- Russ Housley: Comment [2011-02-16]:
Please consider the questions raised on the Gen-ART Review by Ben Campbell on 14-Feb-2011. He asks about Section 5.2:
Is there a requirement that the proover must not make a second attempt inside a given time window? If so, that was not clear from the text. If there is not such a requirement, are there security implications if the proover does send multiple messages inside the same tick? It is not really a one time pad if that happens is it?
- Alexey Melnikov: Discuss [2011-02-12]:
I am generally in favor of getting this document published. However I would like to clarify a couple of things before recommending approval of this document.
3. Algorithm Requirements: "R8 - The TOTP algorithm SHOULD be used for online application."
Can you please explain this requirement?
6. Resynchronization: "Also, it is important to note that the longer a prover has not sent an OTP to a validation system, the longer (potentially) the accumulated clock drift between the prover and the verifier. In such cases, the default synchronization may not be proper when the drift exceeds beyond allowed threshold. Additional authentication measures SHOULD be used for the validation system to safely authenticate the prover."
What are these measures? I.e. how can the SHOULD be satisfied.
- Alexey Melnikov: Comment [2011-02-12]:
Abstract: "This document describes an extension of one-time password (OTP) algorithm, namely the HAMC-Based"
typo: HMAC-Based
1.2. Background: "The default HMAC-SHA-1 function could be replaced by HMAC-SHA-256 or HMAC-SHA-512 to leverage HMAC implementations based on SHA-256 or SHA-512 hash functions."
Missing references for SHA-256/512.
5.1. General: "All the communications SHOULD take place over a secure channel e.g. SSL/TLS, IPsec connections."
Missing informative references for TLS and IPSec.
- Dan Romascanu: Discuss [2011-02-14]:
1. The IANA Considerations section states: "The OTP algorithm defined in this document can be referred by a URI defined in a separate document. [ALGP] is such an attempt that defines various OTP related algorithm URIs. There is no registration needed in this document."
However [ALGP] is according to Section 9.2 draft-hoyer-keyprov-pskc-algorithm-profiles-01.txt which I could not find in the tracker. Is there some kind of mistake, maybe a typo or a change of name of the document?
2. The Time-step size is RECOMMENDED and has a default value of 30 seconds. Are there cases when this value can be different, how is it changed if such cases exist and how can a network operator know what is the Time-step size value on a client?
- Peter Saint-Andre: Comment [2011-02-15]:
I concur with with the discusses from Dan Romascanu, Robert Sparks, and Alexey Melnikov.
- Robert Sparks: Discuss [2011-02-15]:
1) This document contains a sizable "Code Component" in Appendix A, but does not appear to be following the TLP recommendations for stating copyright. Is that intentional?
2) What are the consequences of the generator and consumer of a TOTP having different system parameter values configured for X (say the recommended 30s at a generator, and 90s at a consumer)? X does not appear to be transmitted. Can this mismatch be detected? Similarly, what are the consequences of mismatched T0 values?
- Robert Sparks: Comment [2011-02-15]:
Stronger rationalization for the default of 30s for X would be welcome. From the existing text, it seems to have been selected expecting that the only use will be humans logging into websites. If that's accurate, it would help to explicitly state it in the document. If it's not accurate, more explanation is needed.
Telechat:
- Sean: The authors are addressing the discusses by email. Revised ID needed.
- US Secure Hash Algorithms (SHA and SHA based HMAC and HKDF) (Informational)
draft-eastlake-sha2b-07
Token: Russ Housley
Note: I agreed to sponsor this document since I was the sponsor for RFC 4634.
Discusses/comments (from ballot 3576):
- Alexey Melnikov: Comment [2011-02-16]:
id-sha224 OBJECT IDENTIFIER ::= {{ joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) csor(3) nistalgorithm(4) hashalgs(2) 4 }
Just to double check: the last component is 4 here, right?
- Dan Romascanu: Comment [2011-02-15]:
(empty)
- Sean Turner: Comment [2011-02-15]:
A fine document that I'm glad is being published.
Telechat:
- Amy: No discuss. No objection, approved.
- Suite B Cryptographic Suites for Secure Shell (Informational)
draft-igoe-secsh-suiteb-05
Token: Tim Polk
Note: need a shepherd... should review to see if we can go standards track even with ECC
IPR: Certicom's Statement about IPR related to RFC 4346, RFC 5246, RFC 5289, RFC 4492, RFC 2409, RFC 4306, RFC 4754, RFC 4753, RFC 4869, RFC 4253, RFC 2633, RFC 3278, RFC 4347, RFC 4366, RFC 4109, RFC 4252, RFC 3850, RFC 3851, RFC 5008, draft-ietf-tls-rfc43...
IPR: Certicom's Statement about IPR related to RFC 4346, RFC 5246, RFC 5289, RFC 4492, RFC 2409, RFC 4306, RFC 4754, RFC 4753, RFC 4869, RFC 4253, RFC 2633, RFC 3278, RFC 4347, RFC 4366, RFC 4109, RFC 4252, RFC 3850, RFC 3851, RFC 5008, draft-ietf-tls-rfc43...
IPR: Certicom's Statement about IPR related to RFC 4346, RFC 5246, RFC 5289, RFC 4492, RFC 2409, RFC 4306, RFC 4754, RFC 4753, RFC 4869, RFC 4253, RFC 2633, RFC 3278, RFC 4347, RFC 4366, RFC 4109, RFC 4252, RFC 3850, RFC 3851, RFC 5008, draft-ietf-tls-rfc43...
IPR: Certicom's Statement of IPR Related to RFC 4492, RFC 5289, RFC 5430, RFC 4754, RFC 4869, RFC 4109, RFC 5656, RFC 3278, RFC 5753, RFC 5754, RFC 5008, draft-igoe-secsh-suiteb-02
Discusses/comments (from ballot 3601):
- Russ Housley: Comment [2011-02-16]:
Please consider the comments from the Gen-ART Review by Miguel Garcia on 25-Feb-2011 (which are the same as the comments in the earlier review on 10-Jan-2011):
- The document lacks an IANA section. If there is no action for IANA, the section should say that, e.g., including something like "This document has no actions for IANA." The author should consider whether this document requires an IANA action or not.
- The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords and a reference to RFC 2119 exists in the Normative References section.
- There are a number of unused references, including: AEAD, RFC4250, SSH-Auth, GCM.
Telechat:
- Amy: No discuss. No objection, approved.
- Sean: Tim wants it as point raised, so he can check the comments.
- Amy: Point raised, writeup needed.
- The A+P Approach to the IPv4 Address Shortage (Experimental)
draft-ymbk-aplusp-08
Token: Ron Bonica
Discusses/comments (from ballot 3673):
- Ralph Droms: Discuss [2011-02-17]:
Discuss-discuss, which I will clear after the telechat:
* a+p supports and encourages the extended use of IPv4 while providing no incentive or support for the transition away from IPv4 to IPv6
* any effort spent on correcting technical issues with a+p would be better spent on resolving issues impeding the transition to IPv6
- Lars Eggert: Discuss [2011-02-15]:
DISCUSS: The last item of Pasi Sarolahti's tsv-dir review requires a response.
INTRODUCTION, paragraph 1: "Intended status: Experimental"
DISCUSS: The body of the document does not discuss at all in which way this technology is to be considered experimental, and in which kinds of deployments this technology may be experimented with. In fact, Section 5 is worded in way that suggests a readiness for global deployment. While I understand that this is the opinion of the authors, that is not what Experimental RFCs are for. We had several BOFs on this topic that all failed to convince the community of the value of this approach; I'm surprised to see the same content back with an Experimental label for publication on the IETF Stream.
INTRODUCTION, paragraph 10: "This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. This document may not be modified, and derivative works of it may not be created, and it may not be published except as an Internet-Draft."
DISCUSS: The document has an IETF Trust Provisions (28 Dec 2009) Section 6.c(ii) Publication Limitation clause. If this document is intended for submission to the IESG for publication, this constitutes an error.
Section 5.3.4., paragraph 0: "5.3.4."Limitations of the A+P approach"
DISCUSS: Just having reviewed draft-ietf-intarea-shared-addressing-issues, this section doesn't even
begin to scratch the surface when it comes to limitations. I don't want you to duplicate all the content from draft-ietf-intarea-shared-addressing-issues here, but a reference to this document plus an upfront summary of the limitations described therein need to be added here.
- Adrian Farrel: Comment [2011-02-15]:
I know the RFC Editor can fix this, but in the spirit of devolving work... You need to not describe the document as a "draft"
It is not a requirement, but I think it is helpful if Experimental RFCs give some scope to the experiment both in terms of how it is "contained" and how the success of the experiment will be judged. This need not be a lot of text.
- Dan Romascanu: Discuss [2011-02-16]:
The issues raised by Tina Tsou in her review were not addressed at the technical level. I would like to see a response on these issues before approving the document. If these were already answered please point me to the answer.
- Robert Sparks: Comment [2011-02-15]:
Support Lars' discuss on providing details on evaluating the experiment
Please consider adding the text proposed by Richard Barnes
This example is somewhat misleading: "(e.g., VoIP clients register a public IP and a single delegated port from the CPE, and accept incoming calls on that port)".
Most VoIP clients will ask for a separate port for the voice media from the one used for signaling.
Telechat:
- (updated to version -09 after "FINAL Agenda" distributed)
- Ron: Dan, is what I wrote last night OK?
- Dan: I think so, and I responded with a question about some of the text that needs editing. Otherwise it's fine.
- Ron: We can clear this up in an RFC-ed note.
- Dan: I will edit and delete all resolved comments and leave the DISCUSS for the only open issue (#5).
- Ron: In Ralph's case there were three points. One is that this doesn't progress v6. It does use v6 as a tunneling technology between the gateways. DS-lite is in the same boat.
- Ralph: I understand the point. I think it's a weak argument. AplusP can use a variety of tunneling techniques. It doesn't provide an impetus to go to v6. DS-lite only runs over v6.
- Ron: If you look at sec 5.2, smap... there's important information in the v6 address.
- Ralph: Only if you use smap. But there are ways that don't use v6.
- Ron: If you didn't use smap, how would you get the v4 information across? The default mode does use v6. But even if it didn't promote the use of v6, if we applied that criterion to every draft, lots of things, such as nat444, would be unacceptable.
- Ralph: Does nat444 require additional protocol spec? That's a little different. It's not something we're being asked to do protocol work on.
- Ron: This is an experimental RFC. The question we're being asked is whether this experiment does harm to the Internet. The bar is low.
- Ralph: My answer, personal opinion, is that promoting a technique that requires us to do some work and will extend IPv4 without an incentive to go to v6 is in my mind not good for the Internet.
- Ron: We will see things that extend v4. 444, AplusP, we'll see it. If we set this criterion, we have good reason to put discuss on everything we see from the LISP wg. We will put discusses on lots of things. Do we want to do that?
- Jari: Ron is basically right in this argument. The issue is not so much that we shouldn't let this go forward, but an issue of what the doc says. It's making statements about this being applicable to mobile networks -- I disagree. We need a clear label that this is really experimental.
- Ron: We can negotiate changing the text for that.
- Jari: There's been a lot of email, and as I understand it when I talk to these guys, they would like to have an RFC because they want to promote vendor implementations. One vendor was implementing this, and there's not huge takeup. We need to be careful about recommending many solutions for this space. Let's make clear what's an IETF recommendation and what's not. It doesn't have to be a lot of text. I can volunteer to write some.
- Ron: That talks to Lars's and Tim's discusses.
- Ralph: I will go along with the additional text disclaiming it as experimental. More recognition that this really is an experiment, and doesn't have consensus.
- Ron: Lars's and Tim's are essentially the same. One part of Lars's made me read the draft again... we talked about requiring changes to the end system. Most end systems won't be changed at all. They will think they have the right to use the whole port range. They do say that if you want to have your end host be part of the AplusP system, you can, but most won't.
- Lars: This really changes the architecture in a way that no longer when you have an IP address do you have the whole port range. That means that you now need one of the CPE deployments. You now get port-restricted Internet connectivity. That's the harm to the Internet. Ports are now being used in routing.
- Ron: There are two pieces to the AplusP system. One is the router in the soho environment. [...missed a bunch...]
- Lars: NATs give you the entire port range. AplusP fails silently. It's very clear that if you plug it in and you don't know that you can't use some port, there's a problem. We had two failed BoFs on this technology. There's strong consensus that this shouldn't be done in the IETF. Even experimental, I think goes against consensus. No other technology has had two failed BoFs and then became experimental. It should not be published through the IETF stream.
- Ron: There's a big difference between "no" to a BoF and "no" to an experimental RFC. One is that there's not enough energy to work on it. We're not sure why this failed. Would this experiment cause danger to the Internet.
- Lars: There's no limitation to this experiment.
- [...scribe was dropped from call...]
- Jari: [...] Do we have some feeling in the IESG as to which of the four options we should go to?
- Ron: I would be happy with 3, to add some text that talks about the limitations and the lack of IETF consensus.
- Dan: I prefer 3, because if case 4 comes, we have to have the discussion again. We don't solve something, but just postpone the problem.
- Jari: There is an argument that we could have more influence on the content with option 3 than 4.
- Lars: I see no reason to publish this doc on any stream. There's nothing that this does that we can't do with another technology, and it limits the ports. I'm willing to hold this discuss until I step down. I don't understand how we can bring this forward again as experimental. This has consistently failed when it's been brought up before.
- Ron: One vote for throw it out completely, and some number for option 3.
- Jari: Lars, what if this doc explains at the beginning that the experiment changes the Internet architecture in this way.
- Lars: If the authors could describe the down-sides accurately, that might be OK. But the authors think they have a good thing here.
- Ron: One thing I could do is join the author list myself, and write that text.
- Lars: The entire doc reads like this is a really good idea and they suggest it for wide deployment. We can't fid that with an RFC-ed note or a paragraph in the intro. The entire tone of the doc needs to be changed.
- Ron: I can be responsible for adding a section, and you can hold your discuss until you see that.
- Lars: If we can agree that this is a limited experiment, lab testing, not in a production environment. If it's strongly enough phrased, it might be... I still don't get past the point that it's failed twice and we're still publishing it.
- Ron: As long as it's possible to add some text about the experiment....
- Lars: I'd like text that says that it failed to get IETF consensus twice. I really want to throw it out.
- Ron: If we put text in the doc that says this is an experiment and breaks some things, then all but one discuss can be cleared.
- Ralph: It's assumed that AplusP function will be in a CPE, but not in a host... I'd like to see some discussion on that, saying that you could put it in a host, but it would be wrong. I think that would also reduce some of the complexity in the doc. If the authors feel strongly that AplusP should go all the way out to the host, that's a different story.
- Ron: In fact, it's assumed NOT to be in the CPE, and I'd like to add something about that. I'd be willing to ask the authors to strip out the section about it being useful in mobility.
- Ralph: That would make me somewhat more comfortable. As I looked at the technical issues in the doc, I found that some details were described imprecisely. Separating NAT from tunneling function, and the signalling function is entirely separate, but that's not clear through the rest of the document.
- Russ: In order to finish the agenda close to on time, we need to move on. If Ron's proposal isn't sufficient, we can talk more next week.
- Jari: Ron, can we talk before you approach the authors?
- Ron: OK. This one is revised ID needed.
3.2.2 Returning Items
- (none)
3.3 IRTF and Independent Submission Stream Documents
3.3.1 New Items
- Design Goals for Scalable Internet Routing (Informational)
draft-irtf-rrg-design-goals-06
Token: Jari Arkko
Note: Independent submission via IRTF. Joel Halpern (jmh@joelhalpern.com) is the document shepherd.
Discusses/comments (from ballot 3700):
- (none)
Telechat:
- Amy: No discuss. No objection, approved.
- Russ: To expedite... all seven of these docs have no overlap with IETF work and look OK to publish. I propose that we ask about all seven in one go.
- Amy: Does anyone have any objection to any of these?
- Russ: No objections, they're all approved.
- Amy: No objection message will go to the IRTF on Monday.
- Using Self-Delimiting Numeric Values in Protocols (Informational)
draft-irtf-dtnrg-sdnv-08
Token: Ralph Droms
Note: IRTF Submission. Elwyn Davies (elwynd@dial.pipex.com) is the document shepherd.
Discusses/comments (from ballot 3701):
- Ralph Droms: Comment [2011-02-15]:
I have one comment with my independent reader hat on. I was a little surprised, after several potential uses of SDNVs were described earlier in the document, to read:
"In general, it seems like the most promising use of SDNVs may be to define the Length field of a TLV structure to be an SDNV whose value is the length of the TLV's Value field. As previously discussed, this leverages the strengths of the SDNV format and limits the effects of its weaknesses."
I was left wishing for a little more explanation of why the authors make this statement and wondering why the other potential uses for SDNVs were judged less promising.
- Peter Saint-Andre: Comment [2011-02-15]:
The introduction states: "One example of SDNVs being used outside of the DTN protocols is in Hixie's Web Socket protocol [I-D.hixie-thewebsocketprotocol], which includes a binary frame length indicator field identical to an SDNV."
Referencing draft-hixie-thewebsocketprotocol-76 seems problematic, given that this individual I-D was superseded by draft-ietf-hybi-thewebsocketprotocol and the work of the IETF's HYBI WG. If this text is not really needed here, I would urge its removal to prevent confusion regarding the canonical documentation of the WebSocket protocol.
Telechat:
- (Handled with first item in 3.3.1.)
- Bundle Security Protocol Specification (Experimental)
draft-irtf-dtnrg-bundle-security-17
Token: Sean Turner
Note: IRTF submission. Elwyn Davies (elwynd@dial.pipex.com) is the document shepherd.
Discusses/comments (from ballot 3702):
- (none)
Telechat:
- (Handled with first item in 3.3.1.)
- Compressed Bundle Header Encoding (CBHE) (Experimental)
draft-irtf-dtnrg-cbhe-08
Token: Ron Bonica
Note: IRTF submission. Elwyn Davies (elwynd@dial.pipex.com) is the document shepherd.
Discusses/comments (from ballot 3703):
- Alexey Melnikov: Comment [2011-02-16]:
I don't believe this document is conflicting with ongoing IETF work, so I have no objections to its publication.
However I have a small set of mostly editorial nits I would like the document editor to consider:
...
Telechat:
- (Handled with first item in 3.3.1.)
- Delay-Tolerant Networking Metadata Extension Block (Experimental)
draft-irtf-dtnrg-bundle-metadata-block-09
Token: Peter Saint-Andre
Note: IRTF submission. Elwyn Davies (elwynd@dial.pipex.com) is the document shepherd.
Discusses/comments (from ballot 3704):
- Peter Saint-Andre: Comment [2011-02-15]:
In accordance with RFC 5742, I recommend that the IESG take the following position regarding this IRTF-stream document:
"The IESG has concluded that there is no conflict between this document and IETF work."
This recommendation has been entered in the datatracker.
In addition, and outside the scope of IESG review in accordance with RFC 5742, I have the following technical comments, which the author is free to consider or
not as desired:
1. The definition of the URI metadata type does not mention Internationalized Resource Identifiers (IRIs); is it envisioned that IRIs could be supported via transformation into URIs as specified in RFC 3987?
2. Section 4.1 states: "Unless determined by local policy, the specific processing steps that must be performed on bundles with metadata blocks containing metadata of type URI are expected to be included as part of the URI encoding of the metadata."
It is unclear to this reader (a) how the processing steps are to be encoded in the URI and (b) if such processing steps are intended to override or supplement the processing steps defined in RFC 3986 for URIs in general.
Telechat:
- (Handled with first item in 3.3.1.)
- Delay-Tolerant Networking Previous Hop Insertion Block (Experimental)
draft-irtf-dtnrg-bundle-previous-hop-block-12
Token: Tim Polk
Note: IRTF submission. Elwyn Davies (elwynd@dial.pipex.com) is the document shepherd.
Discusses/comments (from ballot 3705):
- (none)
Telechat:
- (Handled with first item in 3.3.1.)
- Delay-Tolerant Networks (DTN) Bundle Protocol IANA Registries (Informational)
draft-irtf-dtnrg-iana-bp-registries-01
Token: Jari Arkko
Note: IRTF submission. Elwyn Davies (elwynd@dial.pipex.com) is the document shepherd.
Discusses/comments (from ballot 3706):
- Dan Romascanu: Comment [2011-02-16]:
(blank)
Telechat:
- (Handled with first item in 3.3.1.)
4 Working Group Actions
4.1 WG Creation
Telechat:
- Amy: We have a note for Ralph for ARMD. That needs to be in by next week for it to be ready for Prague. Needs to go in no later than next Wednesday.
- Ralph: OK.
4.1.1 Proposed for IETF Review
- (none)
4.1.2 Proposed for Approval
- (none)
4.2 WG Rechartering
4.2.1 Under evaluation for IETF Review
- (none)
4.2.2 Proposed for Approval
- (none)
5. IAB News We can use
- Hannes: I have sent information about the workshop earlier. We haven't had an IAB call this week. We had previously decided to do a talk on privacy in the summer meeting. Olaf had sent some messages, provided a status update on the RSE process. He had also sent mail to the IETF announce list about ISOC BoT candidates.
- Russ: When does the IAB need to have the ISOC BoT nominees?
- Hannes: Feb 28.
6. Management Issues
- Tracking of pending media type/charset/URI registrations (Alexey Melnikov)
Telechat:
- Alexey: Larry Masinter is asking if there could be a way of tracking requests, on a web page or something.
- Michelle: I haven't looked into this. Some of these are managed on mailing lists, which we don't get involved in. I'd be interested in talking about this further to see if we can find out exactly what Larry's looking for.
- Alexey: He wants to find out whether registration was submitted to the expert, and whether the expert has acted on it. It's not always clear what the status is.
- Michelle: Shall I follow up with Larry and get more information?
- Alexey: Yes, and copy me. There might be other use cases for this. And for some registrations, there are a lot of requests to track.
- Michelle: I'll get in touch with Larry, see what cases he's referring to, and see what we can do to make it better.
- Amy: Adding an action item for Alexey and Michelle.
- Add 2 TLS Aria Cipher Suites to draft (Sean Turner)
Telechat:
- Sean: The authors noticed that they forgot two suites in the IANA considerations. I hope that after IETF last call we can add them later. I want to verify that that's the right way.
- ... agreement
- Alexey: "IESG doesn't object unless there are other last-call objections."
- Inviting W3C XML experts to attend Sunday Reception/Apps Area meeting
in Prague (Alexey Melnikov)
)
Telechat:
- Alexey: Russ, did you think about this?
- Russ: Yes. I'd like to understand whether the IETF will benefit by having these folks join Monday meetings?
- Alexey: Yes, the IETF will benefit.
- Russ: I'd like to offer them complimentary Monday passes.
- Alexey: That's perfect, yes.
- Russ: If one wants to stay for the week, they should register. This way, they register with the day pass procedure, and I need their names to comp them.
- Alexey: Peter, can you send email to them and copy me and Russ?
- Peter: We can also talk about putting something on the apparea agenda.
- Russ: We're also shooting ourselves in the foot if we don't also put rtcweb on Monday.
- Alexey: It's not necessarily the same people. These will be XML people.
- Russ: Different part of W3C?
- Alexey: Yes. We can put rtcweb on Monday, but it's not necessary.
- Russ: We just got their proposed charter for their version of real-time web. OK, so we will offer complimentary Monday passes for our fellow standards workers.
- Early RFC number for martini gin spec (Gonzalo)
Telechat:
- Gonzalo: This is the SIP Forum, not an SDO. We told them they need to develop their specs in the IETF. They did that in the martini WG. We approved it a few weeks ago. They are having a big marketing effort, and they would like to release their specs, which reference the IETF work ASAP. They're asking for an early RFC number allocation. Or we could expedite the publication. We don't really think it's extremely urgent... they just need the number. I'd like opinions.
- Sandy: FYI, when the IESG asks for early allocation it's the same as expedited publication request. Otherwise, people don't know how to find the document when they have the number.
- Gonzalo: OK, then... do we want to expedite the publication of this? It would be a good signal for them. They did what we asked when we asked them to bring it to the IETF.
- Russ: On the mail list, I asked when they need the number.
- Gonzalo: As soon as possible. They want to publish as soon as possible to get this at the same time they publish their spec.
- Alexey: How long will it take them to publish their spec?
- Robert: I don't know for sure, but I think it's *very* soon after they get the number. The SIP Connect specs have been held up for martini for several months, with much angst. I'm of mixed mind on asking for expedited processing, but I fall on the side of asking to do this. it would make it easier for us to make sure they continue to do the right thing next time.
- Russ: Sandy Right now it's in edit state. If we do nothing, how long will it take?
- Sandy: Probably 4 to 5 weeks before auth48.
- Russ: I agree, then, that we'd like you to turn it around in, say, two weeks.
- Sandy: Michelle, there is IANA stuff in the doc.
- Russ: Anyone think asking for publication by 4 March -- auth48 by then -- would be unreasonable? Anyone object? No... OK, Gonzalo, please put a ticket in to make the request.
7. Agenda Working Group News
- Jari Arkko (Internet)--- no
- Ron Bonica (O & M)--- We'll probably have a straw-man charter for ARMD soon. Looking for chairs, and I have candidates.
- Stewart Bryant (Routing)--- no
- Gonzalo Camarillo (RAI)--- no
- Ralph Droms (Internet)--- no
- Lars Eggert (Transport)--- no
- Adrian Farrel (Routing)--- no
- David Harrington (Transport)--- no
- Russ Housley (General)--- The specification for community interaction with datatracker and the datatracker update for WG charters have both been sent to me for publication as RFCs. If you haven't reviewed them yet, do that now.
- Alexey Melnikov (Apps)--- no
- Tim Polk (Security)--- no
- Dan Romascanu (O & M)--- IPFIX folks are back with a request. Can we get a room for Saturday? I sent the secretariat a request for a room with 20 seats, power, ethernet.
- Peter Saint-Andre (Apps)--- no
- Robert Sparks (RAI)--- no
- Sean Turner (Security)--- no
1406 EST Adjourned
Appendix: Snapshot of discusses/comments
(at 2011-02-17 07:36:25 PST)
draft-ietf-tsvwg-iana-ports
- Stewart Bryant: Comment [2011-02-15]:
I have one question which is almost a discuss discuss. Should IANA reserve/have
a special request process for services that contain IETF key words that imply
critical IETF services (IETF, BGP, MPLS...) so no one can pass of a proprietary
design as one approved by the IETF.
- Adrian Farrel: Comment [2011-02-15]:
You will need to not have citations from the Abstract.
---
I am worried that this document should discuss deprecation. I don't
think it is important enough for a Discuss, but would appreciate the
authors considering this. IMHO, it is subtly different from
de-assignment.
- Alexey Melnikov: Comment [2011-02-15]:
I need to check if IETF LC comments regarding anonymous reviewers should be
addressed
- as per document authors this is out of scope for this document and
will be described in another document.
(Currently internal processes of the IANA ports and services design team are not
documented by any RFC. This document doesn't change that.)
- Tim Polk: Comment [2011-02-16]:
(1) In section 7.2, the word "strives" and phrase "strive to" are used
repeatedly in an effort to give IANA some wiggle room. While wiggle room is
probably a necessity, it would be helpful to explain when the wiggle room may
reasonably be required. It would probably be good to require additional
information in the request whenever the submitter asks IANA to violate these
principles.
This *might* help avoid some appeals.
(2) In 8.2, the process for de-assignment can only be initiated by the Assignee:
The Assignee of a granted port number assignment can return the port
number to IANA at any time if they no longer have a need for it.
Section 8.4, revocation, would presumably cover the case where the process was
initiated by someone other than the Assignee. However, there doesn't seem to be
a mechanism for a 3rd party to indicate they believed specific ports could
safely be de-assigned/revoked. Should this section provide instructions (e.g.,
email destination, preferred subject line, required contents) for such
submissions?
[Note: the remainder of 8.4 seems entirely satisfactory to process such a
request...]
(3) Waiting to see what Alexey determines about anonymous reviewers :)
- Peter Saint-Andre: Discuss [2011-02-15]:
I am strongly in favor of this document and will probably change my ballot to
"Yes" once we have a chance to discuss the following two issues.
1. [addressed by existing text, clarified through discussion]
2. Regarding port numbers, Section 8.1.1 states:
Note that
the applicant MUST NOT use the requested port prior to the
completion of the assignment.
This seems quite unrealistic, because developers (and developer communities) use
ports all the time when designing and testing application protocols Prohibiting
such experimentation strikes me as detrimental to innovation and opposed to the
IETF's principles of "rough consensus and running code".
- Robert Sparks: Comment [2011-02-17]:
1) I can't see how "IANA strives to" is functionally in any way different from
"IANA SHOULD". What do you expect either IANA or the expert reviewers to do
differently given those different phrases as guidance?
2) This document should acknowledge that the conversation around non-anonymous
expert review happened, call out the conclusion (I believe we saw community
consensus that it was important), and recommend the work that would need to
happen to put that in place.
- Sean Turner: Comment [2011-02-17]:
(I didn't think of this but it might be a good idea)
It would be nice to have something that would allow a 3rd party to indicate that
a service name/port number can be de-assigned. For example, the assignee is
unreachable and their company have gone belly up. Their protocol was never
widely deployed and ten years later it's completely gone. A good netizen could
inform IANA about this and then IANA could determine whether it's true and de-
assign the name/number.
draft-ietf-isis-ieee-aq
- Tim Polk: Discuss [2011-02-16]:
The security considerations state:
If zero configuration methods are used to auto configure NNIs or
UNIs there are intrinsic security concerns that should be mitigated
with authentication procedures for the above cases. Such procedures
are beyond the scope of this document.
While these procedures are beyond the scope of this document, it would be
helpful to identify which procedures the authors have in mind (or note that such
procedure have yet to be developed).
- Tim Polk: Comment [2011-02-16]:
- Dan Romascanu: Discuss [2011-02-14]:
1. The following convention is defined for the document in Section
> The lower case forms "must", "must not", "shall", "shall not",
"should", "should not" and "may" in this document are to be
interpreted in the sense defined in [RFC2119], but are used where
the normative behavior is defined in documents published by SDOs
other than the IETF.
There are two problems here that attracted my attention:
- should really any form of "must" or "should" ,etc. that appears in this
document be interpreted in the sense defined in [RFC2119]? This does not seem to
be the intention, and I would prefer to make clear that this interpretation
applies only in the sections that deal with the IEEE 802.1 documents.
- The keywords "recommended" and "optional" are missing from the list. Is this
intentional? While I could not find any instances of "recommended" I did find a
few instances of "optional" which I would think should be interpreted in the
sense defined in [RFC2119] - for example in section 4.1
2. In the IANA considerations section:
> The MT-Capability TLV is the only TLV requiring a new sub-registry.
Type
value 144 (TBD) is requested, with a starting sub-TLV value of
1, and
managed by Standards Action.
Is really Standards Action necessary? Why
would not Expert Review be sufficient?
- Peter Saint-Andre: Comment [2011-02-16]:
I agree with Dan Romascanu's DISCUSS regarding lower-case conformance keywords
-- they are confusing.
In Section 17, please expand "DOS" to "Denial of Service" and add a reference to
RFC 4732.
- Sean Turner: Comment [2011-02-17]:
I support Tim's discuss.
Also, is this draft going to be held by the RFC editor while the 802.1aq draft
goes final? The normative reference is to a DRAFT of the IEEE spec.
draft-ietf-6man-prefixlen-p2p
- Ralph Droms: Comment [2011-02-14]:
Pedantic, editorial nits about this text from the introduction:
address,
except those that start with the binary value 000,
s/address/addresses/
s/those/those unicast addresses/ (to clarify that
"those" == addresses and not IIDs)
- Lars Eggert: Comment [2011-02-15]:
Section 6., paragraph 3:
> a) Addresses with all zeros in the rightmost 64 bits SHOULD NOT be
> assigned as unicast addresses, to avoid colliding with the Subnet-
> Router anycast address [RFC4291].
>
> b) Addresses in which the rightmost 64 bits are assigned the
> highest 128 values, (i.e., ffff:ffff:ffff:ff7f to ffff:ffff:ffff:
> ffff), SHOULD NOT be used as unicast addresses to avoid colliding
> with Reserved Subnet Anycast Addresses [RFC2526].
Any reason these are not MUST NOTs?
- Adrian Farrel: Comment [2011-02-17]:
I have reduced my position from a Discuss after useful discussion with two of
the authors about whether an "updates" clause would be useful/relevant.
It would be good to find a way to dilute the language that appears to say the
I-D is fixing some specific issues in a specific RFC. Maybe a way forward would
be to be more positive about this document "This document provides a definitive
statement on..." "This document clarifies issues in a number of previous RFCs
that have led to misunderstandings..." "This document offers latest guidance /
best common practice on the use of..."
I'll leave this with the
authors/shepherd/AD to think about, and if you think it is silly or wrong or
impossible, then it's your document and this is only a Comment.
- Sean Turner: Comment [2011-02-16]:
#1) Sec 3: s/does not apply/do not apply
#2) Sec 5.1: s/which uses medium/which use a medium
draft-ietf-isis-reg-purge
- Ralph Droms: Discuss [2011-02-16]:
A brief DISCUSS that will be easy to clear...
Following up to get a bit of history filled in, section 3.3.1 of RFC
3563 indicates that, as of the time of publication of RFC 3563,
ISO/IEC JTC1 would take over the IS-IS registry:
Until JTC1 provides the registry service for IS-IS, IANA is requested
to temporarily maintain such a registry as described below. Upon
notification from JTC1, the registry management authority (i.e.,
value allocation) will be transferred to JTC1. [...]
[...] IETF SHALL keep JTC1/SC6 informed of TLV codepoint
values allocated, and JTC1/SC6 SHALL refer allocation requests
arising within JTC1 constituencies to the IANA registry process.
Has this transfer of registry service to JTC1 taken place or (as I
assume) is the IANA registry still authoritative? Is there still a
need to notify JTC1 of the change to the registry proposed in this
document?
- Lars Eggert: Comment [2011-02-15]:
Agree with Dan that this document should be on a telechat AFTER it
passes IETF last call (unless this is urgent in some way?)
Section 4., paragraph 1:
> This document requests that IANA modify the IS-IS 'TLV Codepoints
> Registry' by adding a column in the registry for 'Purge'. A 'y' in
> this column indicates that the TLV for this row MAY be found in a
> purge. A 'n' in this column indicates that the TLV for this row MUST
> NOT be found in a purge.
It would be slightly more self-explanatory if the registry column was
titled "Allowed in Purge".
- Tim Polk: Discuss [2011-02-16]:
This is a fine document, and I support its publication, but...
I was surprised to find an extensive update to the purge processing and
generation
rules in this document. The title, abstract, and introduction gave
me no clue that
there would be new processing rules. Perhaps that merits a
mention somewhere
before section 3?
- Dan Romascanu: Comment [2011-02-14]:
I have no objection with approving the document as it stands right now but I
observe that there is an IETF Last Call running for it and lasting six days
after the IESG telechat date. I suggest that any approval be conditional, and in
case substantial comments are submitted as Last Call comments after the IESG
telechat they are brought to the attention of the IESG.
draft-ietf-isis-purge-tlv
- Ralph Droms: Comment [2011-02-16]:
Balloting no objection assuming there is an easy answer to my question
(posted to draft-ietf-isis-reg-purge-00) about the IANA ISIS-TLV
registry and notifying ISO JTC1.
- Tim Polk: Comment [2011-02-16]:
In the Intro, this document states:
Field experience has observed several circumstances where an IS can
improperly generate a purge. These are all due to implementation
deficiencies or implementations that predate [ISO TC1] and generate a
purge when they receive a corrupted LSP.
In the security considerations, it is noted that:
Therefore, all implementations in a domain implementing
authentication MUST be upgraded to receive the POI TLV before any IS
is allowed to generate a purge with the POI TLV.
Since you need to touch every ISIS implementation in the domain anyway, is it
worth stating that
implementations SHOULD be updated for consistency with [ISO
TC1] (i.e., and not generate a purge
when they receive a corrupted LSP) at the
same time?
- Dan Romascanu: Comment [2011-02-14]:
> This document requests that IANA assign code point 13 for the 'Purge
Originator Identification' TLV from the IS-IS 'TLV Codepoints
Registry'. The additional values for this TLV should be: IIH:n,
LSP:y, SNP:n, Purge:y.
I assume that this is OK with this document but usually an Internet-Draft cannot
/ should not make a request for a specific value, but just require a code point
value and recommend that this value be 13.
- Sean Turner: Comment [2011-02-16]:
Please add a pointer for where I can find the definition of system ID.
draft-ietf-pim-registry
- Lars Eggert: Comment [2011-02-15]:
Section 3.2., paragraph 1:
> Assignment of new message types is done according to the "IETF
> Review" model, see [RFC5226].
It'd be good to add "or IESG Approval" here - there are sometimes
cases where that shortcut is needed.
- Tim Polk: Comment [2011-02-16]:
I can't remember if there is a precedent for registry documents achieving PS.
The decision to reserve the value 15 to support extensibility might be
justification, but that seems relatively weak. So, I support discussing
Robert's issue, but do not have a particularly strong position either way. If
anyone can point out precedent justifying going PS that would be enough for
me...
- Dan Romascanu: Discuss [2011-02-17]:
> 3.2. Assignment of new message types
> Assignment of new message types is done according to the "IETF
Review" model, see [RFC5226].
Adding new message types would update this document whose intended status is PS.
It looks like "IETF Review" policy is not enough, as IETF Review does not
mandate a standards track document, but just WG or AD-sponsored documents that
go through IETF Lasc Call (but still could be Informational or Experimental).
":Standards Action" policy seems to be needed in order to update this document.
Note that if Robert's DISCUSS is resolved by donwngrading the intended status of
this document to Informational, than "IETF Review" would be sufficient.
- Robert Sparks: Discuss [2011-02-15]:
Why is the intended status PS? This isn't a candidate for progression on the
standards ladder (an interop report will never make sense).
draft-turner-akf-algs-update
- Adrian Farrel: Comment [2011-02-16]:
Can I express my considerable concern about the wasted space on page one of this
document without which you would have completed it in only three pages.
draft-turner-ekpct-algs-update
- Alexey Melnikov: Comment [2011-02-10]:
3. SignedData
If an implementation encapsulates an EncryptedKeyPacakge with a
typo: EncryptedKeyPackage
SignedData [RFC5652], then it MAY support the signature scheme ECDSA
[I-D.mcgrew-fundamental-ecc].
draft-arkko-dual-stack-extra-lite
- Stewart Bryant: Comment [2011-02-17]:
I agree that this looks a lot more like informational that standards track.
I also agree that the introduction should be updated to reflect the exhaustion
of the IPv4 address space.
- Adrian Farrel: Discuss [2011-02-16]:
I support this document, but...
---
I struggled with this document to understand
what there is to
implement. It all seemed a bit "obvious". Is this really a BCP
or Informational?
---
Shouldn't section 4 talk about what to do when an
interface has used up the available number of IP addresses? Crea ting a
"parallel" virtual interface may not be a big deal, but creating the first
virtual interface when a physical insterface is "full" seems like a major
operational step
- Adrian Farrel: Comment [2011-02-16]:
I didn't really find that Section 2 "Solution Outline" was an
outline of the solution. It looks more like an overview of the
problem space and the benefits of the yet-to-be-introduced
solution.
---
Maybe Section 3 should also say that "internal realm" and
"external realm" are derived from somewhere?
---
Section 3
This document uses the term mapping as defined in [RFC4787] to refer
to state at the NAT necessary for network address and port
translation of sessions.
Could you put "mapping" in quotes to stop the reader getting confused
that you are refering to a process of "term mapping".
---
Section 4
Strictly speaking, isn't there a limit to the "arbitrary number" of
devices served by a NAT? So it isn't really arbitrary?
---
Maybe take the chance to update the info about the IANA free pool?
- Tim Polk: Comment [2011-02-16]:
(1) Some of the introductory material is out of date. Specifically, the IANA
free pool has now been exhausted but the document states:
At the time of writing, the IANA "free pool" contained only 12 unallocated
unicast IPv4 /8 prefixes.
This should be corrected, since the date on the RFC will be long after the free
pool was depleted.
(2) I support Adrian's discuss. Feels like informational or BCP. Given that
the free pool is exhausted I lean towards BCP, but that would require another
IETF Last Call.
- Peter Saint-Andre: Comment [2011-02-15]:
Thanks for this clearly written document.
This document feels Informational (not Standards Track) to me, but I'm fine with
publication as Proposed Standard.
draft-cheshire-dnsext-special-names
- Alexey Melnikov: Comment [2011-02-14]:
I agree with a comment that this document should register existing special names
in the registry, or make a more compelling argument about why the registry is
needed.
- Tim Polk: Discuss [2011-02-16]:
I expected the document to seed the registry with entries (at a minimum) for the
special domain names identified in the introduction:
Analogous to Special-Use IPv4 Addresses [RFC5735], DNS has its own
concept of reserved names, such as "example.com", "example.net", and
"example.org", or any name falling under the top level pseudo-domain
"invalid" [RFC2606].
Without those entries (or a plan to create those entries), I don't quite see
that this document accomplishes anything.
- Tim Polk: Comment [2011-02-16]:
last sentence of section 2: "reservation of a Special-Use Domain Names" -
s/Names/Name/
- Dan Romascanu: Discuss [2011-02-14]:
The OPS-DIR review performed by Jouni Korhonen raised the issue bellowed. I
would like to see it addressed before approving this document:
o In section 4, check step 2. Do algorithmically generated
names fall into this category? If yes, these should be
mentioned in the draft as well. There are a number of cases
and deployments where names are generated on fly (by the
end host application) using available execution/service
environment context awareness, other information sources like
certain hardware dongles/smartcards and specific suffixes.
Those are in most cases treated differently in application
software and occasionally also by the name resolution APIs
and libs (reference to check step 3).
If algorithmically generated names fall into special names
category I see documenting those as a big challenge.. if
existing legacy also needs to be documented under the newly
created IANA registry.
- Peter Saint-Andre: Comment [2011-02-14]:
Although I do not object to publication of this document, I agree that it would
be preferable for this document to seed the registry with initial registrations.
- Robert Sparks: Comment [2011-02-15]:
Thanks for this effort - I expect this registry (as long as its registration
policy is Standards Action) to be a very useful tool.
Will you be updating draft-cheshire-dnsext-multicastdns to explicitly request
registration of .local (pointing to section 23 of that draft?)
- Sean Turner: Discuss [2011-02-16]:
The first one is a DISCUSS-DISCUSS
#1) Is adding a new required section in an RFC done this in way? It seems like
this ought to come from a WG or be part of the style guide?
#2) Use of the word "needs" in Section 3 seems like it ought to be MUST. Is
there a time when you wouldn't do the items it suggests?
#3) Shouldn't the "Special Name Considerations Section" just be part of the IANA
considerations section?
- Sean Turner: Comment [2011-02-16]:
1) +1 to including values. Maybe some from http://www.ietf.org/mail-
archive/web/dnsext/current/msg10557.html ?
2) There really aren't any security considerations. Could move the last
sentence to section 4.
draft-ietf-mipshop-transient-bce-pmipv6
- Adrian Farrel: Comment [2010-08-26]:
Clearing my Discuss on the basis of Jari's answer:
"That's a good question to ask. The answer is yes."
- Russ Housley: Comment [2011-02-15]:
Do either of the IPR statements related to this document cause pause?
- Alexey Melnikov: Comment [2010-08-26]:
6. IANA Considerations
This specification also adds one status code value to the Proxy
Binding Acknowledge message, the
PBU_ACCEPTED_TB_IGNORED_SETTINGSMISMATCH status code. The
PBU_ACCEPTED_TB_IGNORED_SETTINGSMISMATCH status code is described in
Section 4.7. Its value must be assigned from the same number space
used for the Mobile IPv6 Binding Acknowledgement status values, as
defined in [RFC3775], and must be smaller 128.
I am looking at <http://www.iana.org/assignments/mobility-parameters/mobility-
parameters.xhtml> and I am not finding "Binding Acknowledgement status" sub-
registry. Am I looking in a wrong place, or is it named differently?
draft-ietf-pce-inter-layer-req
- Russ Housley: Comment [2011-02-16]:
- Dan Romascanu: Comment [2011-02-17]:
Section 4.6. - Impact on Network Operation seems descriptive and contains no
requirements (as do sections 4.1-4.5). If this is the case it should be
explicitely stated.
draft-ietf-intarea-shared-addressing-issues
- Ralph Droms: Discuss [2011-02-16]:
I don't understand this sentence:
17. IPv6 Transition Issues
[...]
Shared addresses should be drawn from space designated as such
[RFC1918]. Otherwise their use will break the widely implemented
assumption that public IPv4 addresses are globally unique addresses
and hence break many protocols and applications, [...]
Which "shared addresses" are under discussion here? Isn't the
motivation for this document the need to share public addresses
because of IPv4 address exhaustion?
Later in the same section:
Issues created by sharing public address
space across multiple hosts are specifically addressed in
[I-D.thaler-port-restricted-ip-issues].
Isn't thaler-port-restricted-ip-issues just focused on issues with A+P
addressing, not generally public address space sharing issues?
Does address sharing affect any other transition technologies, or just
6-to-4?
- Ralph Droms: Comment [2011-02-16]:
In Figure 1, while reverse DNS is affected (more precisely, broken) by
NAT without address sharing, in my opinion it is affected differently
(more broken) by address sharing. Might deserve "xx"?
- Lars Eggert: Discuss [2011-02-16]:
I'm adding a placeholder discuss to make sure the discussion between the authors
and the tsv-dir reviewer terminates and we have a version submitted that
addresses all comments.
- Lars Eggert: Comment [2011-02-15]:
Section 1., paragraph 1:
> Authority (IANA) were completed on Feburary 3, 2011 [IPv4_Pool].
Nit: s/Feburary/February/
Section 1., paragraph 3:
> Over the long term, deploying IPv6 is the only way to ease pressure
> on the public IPv4 address pool without the need for address sharing
> mechanisms that give rise to the issues identified herein. In the
> short term, maintaining growth of IPv4 services in the presence of
> IPv4 address depletion will require address sharing.
Given the huge list of issues, I find it surprising to see that the
document says "In the short term (...) IPv4 address depletion will
require address sharing." The document should much more strongly argue
for deploying IPv6 as the solution. It does in a few places, but I
think the message bears repeating. Put it in the footer! :-)
Section 3., paragraph 3:
> +------------------------------------------------+--------+---------+
> | Issue | 1st | 3rd |
> | | party | parties |
> +------------------------------------------------+--------+---------+
It would be good for each issue in the table below to indicate which
section discusses it in more detail. This is not at all clear from the
headings of the subsequent sections. Add a column for this?
Section 5.1., paragraph 3:
> A potential problem with dynamic allocation occurs when one of the
> subscriber devices behind such a port-shared IPv4 address becomes
> infected with a worm, which then quickly sets about opening many
> outbound connections in order to propagate itself. Such an infection
> could rapidly exhaust the shared resource of the single IPv4 address
> for all connected subscribers. It is therefore necessary to impose
> limits on the total number of ports available to an individual
> subscriber to ensure that the shared resource (the IPv4 address)
> remains available in some capacity to all the subscribers using it.
Limits aren't the only way of handling this. You can also kill off
established connections when the port space runs out. If you do this
randomly, a user with many connections will be proportionally more
likely to get hit, which is what is needed. The benefit of the "kill"
scheme is that you can support a wider variety of sharing patterns
compared to fixed limits.
Section 5.2.2., paragraph 2:
> For example, the use of DNS SRV records [RFC2782] provides a
> potential solution for subscribers wishing to host services in the
> presence of a shared-addressing scheme. SRV records make it possible
> to specify a port value related to a service, thereby making services
> accessible on ports other than the Well-Known ports. It is worth
> noting that this mechanism is not applicable to HTTP.
HTTP as well as many other legacy protocols.
Section 13.1., paragraph 0:
> 13.1. Abuse Logging and Penalty Boxes
An addition to this section: There are web tie-ins into different
black lists that some web site owners subscribe to which redirect
clients to a URL that basically says "hey, your machine is infected."
Sometimes, they even prevent their site from then working for that
users, in order to "give incentives" to fix the problem. With address
sharing, someone else's worm can hence interfere with my ability to do
stuff. (And I already see this today behind the Nokia NAT, because
some clown here has an infected Windows box on the intranet...)
- Alexey Melnikov: Comment [2011-02-17]:
13.6. Policing Forwarding Behaviour
If some form of IPv6 ingress filtering is deployed in the broadband
network and DS-Lite service is restricted to those subscribers, then
tunnels terminating at the CGN and coming from registered subscriber
IPv6 addresses cannot be spoofed. Thus a simple access control list
on the tunnel transport source address is all that is required to
accept traffic on the southbound interface of a CGN.
Is "southbound" a common terminology?
17. IPv6 Transition Issues
Subscribers allocated with private addresses will not be able to
utilise 6to4 to access IPv6, but may be able to utilise Teredo.
This needs an Informative reference.
The first reference to HTTP needs an Informative reference.
- Peter Saint-Andre: Comment [2011-02-15]:
Section 12 on Traceability refers to "the offending activity". Given the
principle of innocent until proven guilty, I suggest "a particular activity".
- Robert Sparks: Discuss [2011-02-15]:
This document calls out to draft-thaler-port-restricted-ip-issues for several
important discussions, but that document has not been refreshed since Feb-10,
and I'm not finding any other signs of activity around it. What is the plan for
moving that document forward?
- Robert Sparks: Comment [2011-02-15]:
Please consider the text proposed by Richard Barnes at
<https://www.ietf.org/ibi
n/c5i?mid=6&rid=49&gid=0&k1=933&k2=55495&tid=1297789532>
draft-ietf-ccamp-rwa-wson-framework
- Russ Housley: Comment [2011-02-15]:
Please consider the comments from the Gen-ART Review by Pete McCann
on 7-Feb-2011. The comments cab be found at:
http://www.softarmor.com/rai/temp-gen-art/
draft-ietf-ccamp-rwa-wson-framework-10-mccann.txt
draft-mraihi-totp-timebased
- Russ Housley: Comment [2011-02-16]:
Please consider the questions raised on the Gen-ART Review by
Ben Campbell on 14-Feb-2011. He asks about Section 5.2:
Is there a requirement that the proover must not make a second
attempt inside a given time window? If so, that was not clear
from the text. If there is not such a requirement, are there
security implications if the proover does send multiple messages
inside the same tick? It is not really a one time pad if that
happens is it?
- Alexey Melnikov: Discuss [2011-02-12]:
I am generally in favor of getting this document published. However I would like
to clarify a couple of things before recommending approval of this document.
3. Algorithm Requirements
R8 - The TOTP algorithm SHOULD be used for online application.
Can you please explain this requirement?
6. Resynchronization
Also, it is important to note that the longer a prover has not sent
an OTP to a validation system, the longer (potentially) the
accumulated clock drift between the prover and the verifier. In such
cases, the default synchronization may not be proper when the drift
exceeds beyond allowed threshold. Additional authentication measures
SHOULD be used for the validation system to safely authenticate the
prover.
What are these measures? I.e. how can the SHOULD be satisfied.
- Alexey Melnikov: Comment [2011-02-12]:
Abstract
This document describes an extension of one-time password (OTP)
algorithm, namely the HAMC-Based
typo: HMAC-Based
1.2. Background
The default HMAC-SHA-1 function could be replaced by HMAC-SHA-256 or
HMAC-SHA-512 to leverage HMAC implementations based on SHA-256 or
SHA-512 hash functions.
Missing references for SHA-256/512.
5.1. General
All the communications SHOULD take place over a secure channel e.g.
SSL/TLS, IPsec connections.
Missing informative references for TLS and IPSec.
- Dan Romascanu: Discuss [2011-02-14]:
1. The IANA Considerations section states:
> The OTP algorithm defined in this document can be referred by a URI
defined in a separate document. [ALGP] is such an attempt that
defines various OTP related algorithm URIs. There is no registration
needed in this document.
However [ALGP] is according to Section 9.2 draft-hoyer-keyprov-pskc-algorithm-
profiles-01.txt which I could not find in the tracker. Is there some kind of
mistake, maybe a typo or a change of name of the document?
2. The Time-step size is RECOMMENDED and has a default value of 30 seconds. Are
there cases when this value can be different, how is it changed if such cases
exist and how can a network operator know what is the Time-step size value on a
client?
- Peter Saint-Andre: Comment [2011-02-15]:
I concur with with the discusses from Dan Romascanu, Robert Sparks, and Alexey
Melnikov.
- Robert Sparks: Discuss [2011-02-15]:
1) This document contains a sizable "Code Component" in Appendix A, but does not
appear to be following the TLP recommendations for stating copyright. Is that
intentional?
2) What are the consequences of the generator and consumer of a TOTP having
different system parameter values configured for X (say the recommended 30s at a
generator, and 90s at a consumer)? X does not appear to be transmitted. Can this
mismatch be detected? Similarly, what are the consequences of mismatched T0
values?
- Robert Sparks: Comment [2011-02-15]:
Stronger rationalization for the default of 30s for X would be welcome. From the
existing text, it seems to have been selected expecting that the only use will
be humans logging into websites. If that's accurate, it would help to explicitly
state it in the document. If it's not accurate, more explanation is needed.
draft-eastlake-sha2b
- Alexey Melnikov: Comment [2011-02-16]:
id-sha224 OBJECT IDENTIFIER ::= {{ joint-iso-itu-t(2)
country(16) us(840) organization(1) gov(101)
csor(3) nistalgorithm(4) hashalgs(2) 4 }
Just to double check: the last component is 4 here, right?
id-sha256 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2)
country(16) us(840) organization(1) gov(101)
csor(3) nistalgorithm(4) hashalgs(2) 1 }
id-sha384 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2)
country(16) us(840) organization(1) gov(101)
csor(3) nistalgorithm(4) hashalgs(2) 2 }
id-sha512 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2)
country(16) us(840) organization(1) gov(101)
csor(3) nistalgorithm(4) hashalgs(2) 3 }
- Dan Romascanu: Comment [2011-02-15]:
- Sean Turner: Comment [2011-02-15]:
A fine document that I'm glad is being published.
draft-igoe-secsh-suiteb
- Russ Housley: Comment [2011-02-16]:
Please consider the comments from the Gen-ART Review by Miguel Garcia
on 25-Feb-2011 (which are the same as the comments in the earlier
review on 10-Jan-2011):
- The document lacks an IANA section. If there is no action for IANA,
the section should say that, e.g., including something like "This
document has no actions for IANA." The author should consider
whether this document requires an IANA action or not.
- The document seems to lack the recommended RFC 2119 boilerplate,
even if it appears to use RFC 2119 keywords and a reference to
RFC 2119 exists in the Normative References section.
- There are a number of unused references, including: AEAD,
RFC4250, SSH-Auth, GCM.
draft-ymbk-aplusp
- Ralph Droms: Discuss [2011-02-17]:
Discuss-discuss, which I will clear after the telechat:
* a+p supports and encourages the extended use of IPv4 while providing
no incentive or support for the transition away from IPv4 to IPv6
* any effort spent on correcting technical issues with a+p would be
better spent on resolving issues impeding the transition to IPv6
- Lars Eggert: Discuss [2011-02-15]:
DISCUSS: The last item of Pasi Sarolahti's tsv-dir review requires a
response.
INTRODUCTION, paragraph 1:
> Intended status: Experimental
DISCUSS: The body of the document does not discuss at all in which way
this technology is to be considered experimental, and in which kinds
of deployments this technology may be experimented with. In fact,
Section 5 is worded in way that suggests a readiness for global
deployment. While I understand that this is the opinion of the
authors, that is not what Experimental RFCs are for. We had several
BOFs on this topic that all failed to convince the community of the
value of this approach; I'm surprised to see the same content back
with an Experimental label for publication on the IETF Stream.
INTRODUCTION, paragraph 10:
> This Internet-Draft is submitted in full conformance with the
> provisions of BCP 78 and BCP 79. This document may not be modified,
> and derivative works of it may not be created, and it may not be
> published except as an Internet-Draft.
DISCUSS: The document has an IETF Trust Provisions (28 Dec 2009)
Section 6.c(ii) Publication Limitation clause. If this document is
intended for submission to the IESG for publication, this constitutes
an error.
Section 5.3.4., paragraph 0:
> 5.3.4. Limitations of the A+P approach
DISCUSS: Just having reviewed
draft-ietf-intarea-shared-addressing-issues, this section doesn't even
begin to scratch the surface when it comes to limitations. I don't
want you to duplicate all the content from
draft-ietf-intarea-shared-addressing-issues here, but a reference to
this document plus an upfront summary of the limitations described
therein need to be added here.
- Adrian Farrel: Comment [2011-02-15]:
I know the RFC Editor can fix this, but in the spirit of devolving work...
You need to not describe the document as a "draft"
---
It is not a requirement, but I think it is helpful if Experimental RFCs give
some scope to the experiment both in terms of how it is "contained" and how the
success of the experiment will be judged. This need not be a lot of text.
- Dan Romascanu: Discuss [2011-02-16]:
The issues raised by Tina Tsou in her review
https://www.ietf.org/ibin/c5i?mid=6&rid=49&gid=0&k1=933&k2=55308&tid=1297852737
were not addressed at the technical level. I would like to see a response on
these issues before approving the document. If these were already answered
please point me to the answer.
- Robert Sparks: Comment [2011-02-15]:
Support Lars' discuss on providing details on evaluating the experiment
Please consider adding the text proposed by Richard Barnes at
<https://www.ietf.
org/ibin/c5i?mid=6&rid=49&gid=0&k1=933&k2=55496&tid=1297789602>
This example is somewhat misleading:
"(e.g., VoIP clients register a
public IP and a single delegated port from the CPE, and accept
incoming calls
on that port)".
Most VoIP clients will ask for a separate port for the voice
media from the one used for signaling.
draft-irtf-rrg-design-goals
- (none)
draft-irtf-dtnrg-sdnv
- Ralph Droms: Comment [2011-02-15]:
I have one comment with my independent reader hat on. I was a little
surprised, after several potential uses of SDNVs were described earlier
in the document, to read:
In general, it seems like the most promising use of SDNVs may be to
define the Length field of a TLV structure to be an SDNV whose value
is the length of the TLV's Value field. As previously discussed,
this leverages the strengths of the SDNV format and limits the
effects of its weaknesses.
I was left wishing for a little more explanation of why the authors make
this statement and wondering why the other potential uses for SDNVs
were judged less promising.
- Peter Saint-Andre: Comment [2011-02-15]:
The introduction states:
One example of SDNVs being used outside of the
DTN protocols is in Hixie's Web Socket protocol
[I-D.hixie-thewebsocketprotocol], which includes
a binary frame length indicator field identical to an
SDNV.
Referencing draft-hixie-thewebsocketprotocol-76 seems problematic, given that
this individual I-D was superseded by draft-ietf-hybi-thewebsocketprotocol and
the work of the IETF's HYBI WG. If this text is not really needed here, I would
urge its removal to prevent confusion regarding the canonical documentation of
the WebSocket protocol.
draft-irtf-dtnrg-bundle-security
- (none)
draft-irtf-dtnrg-cbhe
- Alexey Melnikov: Comment [2011-02-16]:
I don't believe this document is conflicting with ongoing IETF work, so I have
no objections to its publication.
However I have a small set of mostly editorial nits I would like the document
editor to consider:
Was the URI registration checked by Graham Klyne (the Designated URI Expert
Reviewer)? I doubt he will have any issues with this, but it would be better to
check this earlier.
4. IANA Considerations
URI scheme syntax:
This specification uses the Augmented Backus-Naur Form (ABNF)
notation of [RFC2234], including the core ABNF syntax rule for DIGIT
This should be RFC 5234, but I think RFC Editor will fix that.
defined by that specification.
o ipn-uri := "ipn:" ipn-hier-part
o ipn-hier-part := node-nbr nbr-delim service-nbr ; a path-rootless
o node-nbr := 1*DIGIT
o nbr-delim := "."
o service-nbr := 1*DIGIT
s/:=/=
The following field is missing from the IANA registration template:
References.
Include full citations for all referenced documents. Registration
templates for provisional registration may be included in an
Internet Draft; when the documents expire or are approved for
publication as an RFC, the registration will be updated.
This field should just point to the draft itself.
draft-irtf-dtnrg-bundle-metadata-block
- Peter Saint-Andre: Comment [2011-02-15]:
In accordance with RFC 5742, I recommend that the IESG take the following
position regarding this IRTF-stream document:
The IESG has concluded that there is no conflict between this
document and IETF work.
This recommendation has been entered in the datatracker.
In addition, and outside the scope of IESG review in accordance with RFC 5742, I
have the following technical comments, which the author is free to consider or
not as desired:
1. The definition of the URI metadata type does not mention Internationalized
Resource Identifiers (IRIs); is it envisioned that IRIs could be supported via
transformation into URIs as specified in RFC 3987?
2. Section 4.1 states:
Unless determined by local policy, the specific
processing steps that must be performed on bundles with metadata
blocks containing metadata of type URI are expected to be included as
part of the URI encoding of the metadata.
It is unclear to this reader (a) how the processing steps are to be encoded in
the URI and (b) if such processing steps are intended to override or supplement
the processing steps defined in RFC 3986 for URIs in general.
draft-irtf-dtnrg-bundle-previous-hop-block
- (none)
draft-irtf-dtnrg-iana-bp-registries
- Dan Romascanu: Comment [2011-02-16]: