IESG Narrative Minutes
Narrative Minutes of the IESG Teleconference on 2013-10-26. These are not an official record of the meeting.
Narrative scribe: John Leslie and Susan Hares (The scribe was sometimes uncertain who was speaking.)
Corrections from: Ted, Martin, Pete, Barry
1 Administrivia
- Roll Call 1133 EDT Amy:
- Jari Arkko--- y -- may leave early
- Richard Barnes--- y
- Stewart Bryant--- y
- Gonzalo Camarillo--- y
- Benoit Claise--- y
- Michelle Cotton--- y
- Spencer Dawkins--- y
- Adrian Farrel--- y
- Stephen Farrell--- y
- Heather Flanagan--- regrets
- Sandy Ginoza--- y
- Brian Haberman--- y
- Joel Halpern---
- Susan Hares--- y
- Russ Housley--- y
- Joel Jaeggli--- muted
- Barry Leiba--- y
- Ted Lemon--- y
- John Leslie--- y
- Cindy Morgan--- y
- Ray Pelletier--- regrets
- Carlos Pignataro--- regrets
- Pete Resnick--- likely regrets
- Martin Stiemerling--- y
- Sean Turner--- y
- Amy Vezza--- y
- Guests:
- Bash the Agenda
- Amy: any new? any other changes?
- Approval of the Minutes of the past telechat
- October 10 minutes--- approved
- September 26 narrative minutes--- approved
- October 10 narrative minutes--- approved
- Review of Action Items from last Telechat
- Jari Arkko to draft a call for nominations for the IESG appointment to the IAOC for 2014
Jari: in progress
2. Protocol Actions
2.1 WG Submissions
2.1.1 New Items
2.1.2 Returning Items
-
Byte and Packet Congestion Notification (Best Current Practice)
draft-ietf-tsvwg-byte-pkt-congest
[txt]
Token: Martin Stiemerling (tsv area)
Discusses/comments [ballot]:
-
Adrian Farrel: Comment [2013-10-23 14:48]:
Two small points that you don't need to discuss with me.
(see link)
-
Stephen Farrell: Comment [2013-10-23 14:49]:
Just a few nits. Interesting read.
(see link)
-
Pete Resnick: Comment [2013-10-23 21:27]:
Please do address Barry's comments.
Administrivia: Sounds to me like this document should be part of BCP 41 so that all of this information is in the same place. An RFC Editor note should be added to let the RFC Editor know that.
-
Benoit Claise: Discuss [2013-10-24 06:50]:
This is a DISCUSS-DISCUSS, i.e. a discussion between the IESG members.
The authors don't need to take any action at this point in time.
Clarification question: what is the connection between this draft and the AQM WG? AQM is supposed to obsolete RFC 2309, and at the same time, this document updates RFC 2309.
I see that draft-ietf-aqm-recommendation normatively references draft-ietf-tsvwg-byte-pkt-congest So should this document (at least section 2, the recommendations) be part of draft-ietf-aqm-recommendation? To add to the/my confusion, the document abstract speaks about Codel and PIE, which, IIRC, are the two protocols discussed in AQM.
What will be the situation when draft-ietf-aqm-recommendation will be a RFC? This RFC will obsolete RFC 2309, and reference (or maybe obsolete) draft-ietf-tsvwg-byte-pkt-congest, which in turn will update RFC 2309. How do you see this working? Is this an issue? I would like to discuss this with responsible AD during the IESG telechat. Hence my DISCUSS-DISCUSS.
One proposal is that draft-ietf-aqm-recommendation copies the recommendations from draft-ietf-tsvwg-byte-pkt-congest (btw, it does that with the current version), and that it references the draft-ietf-tsvwg-byte-pkt-congest, which justifies the recommendations. An informational reference would be good enough, and would avoid some confusion... I guess.
A (cleaner) alternative is for draft-ietf-tsvwg-byte-pkt-congest to be a companion document to draft-ietf-aqm-recommendation, in the AQM WG. Advantage: it doesn't update RFC 2309. Drawback: some extra delay.
-
Benoit Claise: Comment [2013-10-24 06:50]:
No sure what 'strongly deprecated' means.
"For the specific case of RED, this means that byte-mode queue measurement will often be appropriate although byte-mode drop is strongly deprecated."
-
Barry Leiba: Comment [2013-10-22 10:51]:
I have a few non-blocking comments that I'd like you to consider. The first few are more important, and please feel free to chat with me about them:
-- Section 2.1 --
"In this case, if the resource is bit-congestible, the AQM implementation SHOULD measure the length of the queue in bytes and, if the resource is packet-congestible, the implementation SHOULD measure the length of the queue in packets. No other choice makes sense, because the number of packets waiting in the queue isn't relevant if the resource gets congested by bytes and vice versa. For example, the length of the queue into a transmission line would be measured in bytes, while the length of the queue into a firewall would be measured in packets."
If no other choice makes sense, under what conditions might there be a reason to do otherwise (with respect to the SHOULDs)? In other words, why are these not 'MUST'?
"To avoid the pathological effects of drop tail, the AQM can then"
This non-transport guy doesn't know what a 'drop tail' is. Is it worth having the document say what it is, or is it a common enough term of art that we can say 'It's just me,' and never mind?
"Exceptions to these recommendations MAY be necessary"
This should not be a 2119 'MAY'; please make it 'may' (or 'might', to avoid the question).
-- Section 8 --
"o When network equipment measures the length of a queue, if it is not feasible to use time it is recommended to count in bytes if the network resource is congested by bytes, or to count in packets if is congested by packets."
I find that sentence to be very hard to read. In particular, I had trouble parsing 'to use time it is recommended to count'. I suggest this, tweaked if this isn't exactly what you mean:
NEW: o When network equipment measures the length of a queue, if it is not feasible to measure the time in queue, it is recommended to measure the byte count if the network resource is congested by bytes, or to measure the packet count if it is congested by packets.
END
Or perhaps this is even clearer?:
NEW: o When network equipment measures the length of a queue, it is best to measure the time in queue. If that is not feasible, it is recommended to measure the byte count (if the network resource is congested by bytes) or the packet count (if the resource is congested by packets).
END
The rest of the comments are very minor, so please consider them, but there's no need to respond about them:
(see link)
-
Sean Turner: Comment [2013-10-23 18:21]:
Looks good to me.
-
Joel Jaeggli: Comment [2013-10-22 23:26]:
Outside of the general precept of don't implement AQM with byte drop mode with which I whole heartedly endorse;
I have concerns whether sections 3.2 and 4.2.3 constitute advice, or best practice.
4.2.3 makes no mention at all of UDP cases.
"Although there are no known proposals, it would also be possible and perfectly valid to make control packets robust against drop by explicitly requesting a lower drop probability using their Diffserv code point [RFC2474] to request a scheduling class with lower drop."
two points:
1. If you do this with a flow with a mix of control and flow packets you can helpfully introduce more reordering than normal in forwarding devices that use the dscp bits as an additional source of entropy by hashing different packets from the same flow onto links of the same cost but unequal lengths (or across linecards). (why you can safely use those bits as a source of entropy in your own network comes up in point 2)
2. it is common to to point ubiquity to reset dscp bits at administrative boundaries for sanitary purposes. because different operators treat traffic differently, because wireless operators do in fact prioritize tcp connection setup or dns queries over other parts of flows, to ameliorate number 1 and so on. So... doesn't work on the internet is probably a bit of an issue.
the reference:
"no longer exists so a stable reference needs to be found
"[DupTCP] Wischik, D., 'Short messages', Royal Society workshop on networks: modellingand control, September 2007, <http://www.cs.ucl.ac.uk/staff/ucacdjw/Research/shortmsg.html>.
http://www.cs.ucl.ac.uk/staff/ucacdjw/Research/shortmsg.html
Error 404
Not found - file doesn't exist or is read protected [even tried multi]
This user URL no longer exists. The user has either left UCL-CS or changed name or user-class, or the home filestore is offline.
It is cited a rational for:
"Although not brought to the IETF, a simple proposal from Wischik [DupTCP] suggests that the first three packets of every TCP flow should be routinely duplicated after a short delay. It shows that this would greatly improve the chances of short flows completing quickly, but it would hardly increase traffic levels on the Internet, because Internet bytes have always been concentrated in the large flows. It further shows that the performance of many typical applications depends on completion of long serial chains of short messages. It argues that, given most of the value people get from the Internet is concentrated within short flows, this simple expedient would greatly increase the value of the best efforts Internet at minimal cost."
Which sounds like a not insignificant change to tcp notwithstanding that duplicate packet handling works just fine in general? I assume unless I'm misreading it, that they're referring to the first three packets after the handshake and not the handshake itself.
Telechat:
- Amy: a discuss
- Martin: we need to discuss Benoit's DISCUSS
- Benoit: I wondering ... need to update 2309... clarification question
- Martin: updating recommendation ... we should not drop packets by size... much more guidance... still valid to publish this; we don't have any new recommendations yet
- Benoit: two years from now, 2309 obsoleted, this still updates 2309?
- Barry: there's nothing wrong with having a current document listing as updating an obsolete document: it's just a metadata thing
- Benoit: I'll clear
- Russ?: has a decision been made about making this part of BCP 41?
- Martin: good point... I would say yes...
- Russ: RFCed note
- Amy: approved, pending a note
2.2 Individual Submissions
2.2.1 New Items
-
Early IANA Allocation of Standards Track Code Points (Best Current Practice)
draft-cotton-rfc4020bis
[txt]
Token: Adrian Farrel (None area)
Discusses/comments [ballot]:
-
Stephen Farrell: Comment [2013-10-22 09:24]:
- What if an IRTF RG wants to run this process? Should we include text on that? Did anyone ask Lars/the-IRSG? (I think we have a case of that in the works now btw.) I realise that this says its only for IETF stream, which is fine, but we might be better off just checking if the IRTF want to play the same game now.
- Why 1 year for the temporary registration? Would 'at least one year' be better? Why 'at most' one renewal? I don't object, but that seems like it might make more and not less work.
-
Jari Arkko: Comment [2013-10-23 10:05]:
Thank you for writing this document.
-
Richard Barnes: Comment [2013-10-23 19:49]:
<rant>
It's appropriate that this document is on the same telechat as draft-kolkman-proposed-standards-clarified -- both documents are about the bloat in the RFC approval process. The stability criteria laid out in this document basically mean that a protocol has to be feature-frozen (at least as regards the code point) before an early allocation can be made. But an early allocation can only be useful if there's some significant amount of time between the allocation and the approval of the RFC.What are we doing in the intermediate time?
</rant>
-
Benoit Claise: Comment [2013-10-22 03:31]:
Note: I had an interesting discussion with Michelle, who clarified a few things, and saved many emails.
Feel free to engage on the discussion on points 1 to 5.
1. I would add a clarification that IANA assigns the code point(s) as soon as the document is approved by the IESG. I had to ask Michelle, so I guess I'm not the only who was not sure about this. Therefore, this procedure is not applicable to documents sitting in the RFC editor queue (we know that they can sit there for a long time, waiting for a normative reference).
2. "If the document progresses to the point at which IANA normally makes code point allocations, it is the responsibility of the authors and the WG chairs to remind IANA that there were early allocations, and of the code point values so allocated, in the IANA Considerations section of the RFC-to-be."
I believe it's the responsibility of the authors and document shepherd/WG chairs. If the document left the WG already (IETF LC), so the chairs are not involved.
So maybe "it is the responsibility of the authors and the WG chairs (or the document shepherd if the document left the WG) to remind IANA that there were early allocations"
Same remark for this sentence
"If an early allocation expires before the document progresses to the point where IANA normally makes allocations, the authors and WG chairs may repeat the process in section 3.1 to request renewal of the code points. At most, one renewal request may be made; thus, authors should choose carefully when the original request is to be made."
Discussing with Michelle, she thinks that this procedure doesn't really apply to situations where the draft left the WG (IETF LC), because it's not too far from IESG approval. So this procedure is not really worth it.
One way or the others, this should be clarified. Clarifying first the point 1 would help in solving this point 2.
3. section 3.1
"2. The WG chairs determine whether the conditions for early allocations described in section 2 are met; particularly, conditions (c) and (d).
"3. The WG chairs gauge whether there is consensus within the WG that early allocation is appropriate in the case of the given document."
3 is basically the means to check (d), right?
NEW: 2. The WG chairs determine whether the conditions for early allocations described in section 2 are met; particularly, conditions (c) and (d). The WG chairs gauge the consensus for (d) within the WG.
4. "If the document progresses to the point at which IANA normally makes code point allocations, it is the responsibility of the authors and the WG chairs to remind IANA that there were early allocations, and of the code point values so allocated, in the IANA Considerations section of the RFC-to-be. Allocation is then just a matter of removing the 'Temporary' tag from the allocation description."
So basically, you want to the IANA considerations section to clearly specify that a temporary code point has been allocated, with a RFC editor or IANA Note. Shouldn't you clearly spell that out?
5. 3.3. Expiry
"As described in Section 3.1, each Temporary assignment is recorded in the registry with the date of expiry of the assignment. If an early allocation expires before the document progresses to the point where IANA normally makes allocations, the authors and WG chairs may repeat the process in section 3.1 to request renewal of the code points. At most, one renewal request may be made; thus, authors should choose carefully when the original request is to be made."
Is there some sort of automatic notification: without it, I'm sure people will forgot
PURELY EDITORIAL (take it or leave it)
(see link)
-
Barry Leiba: Comment [2013-10-18 04:40]:
I agree with Sean's discuss.
-- Section 3.1 --
"5. If the Area Directors approve step 4, the WG chairs request IANA to make an early allocation."
Obligatory nit: we request an action, not an actor. The chairs 'request that IANA make an early allocation.'
-
Stewart Bryant: Comment [2013-10-20 23:49]:
This is an update that we need to make.
I do however have a question concerning the one year lifetime of an early allocation. Given that wa have a lot of experience since RFC4020 was published, what does the evidence say about the 1+1 year lifetime.
My qualitative experience suggests that it is a bit short, but presumably we have statistical evidence that gives us a firm view on what it should be.
-
Sean Turner: Comment [2013-10-19 12:42]:
The RFC editor's note addresses my concerns. Thanks!
-
Joel Jaeggli: Comment [2013-10-21 22:17]:
I have concerns about the lifetime being a bit short.
More deeply albiet probably not addressable I have concerns about the actual effectiveness of the revocation procedure. TCP 465 reminds me of how badly this can go sideways even when things are penciled in and then removed.
Telechat:
- Amy: a discuss
- Adrian: Ted, I think your concern is misplaced, early allocation does not become a permanent allocation
- Ted: pretty hard to take it back
- Adrian: if that's the case, we probably have to say early allocation is simply a bad idea
- Ted: I think the benefits outweigh the risk -- less likely the bad idea will happen; 5226 metadata should say updated by 4020bis
- Adrian: we have Barry and Michelle working on 5226bis
- Barry: we could say something in 5226bis, but I don't see how 4020bis updates 5226
- Michelle: I suspect our reviews of the latest versions will be complete in a week or so... then LastCall... shortly after Vancouver
- Ted: self-healing, just need a mention in 5226bis; when I hunted for a reference to 4020, didn't find one... not even contain the word "early"; mentions "commandeered" code-points
- Michelle: I don't see a problem adding language about early allocations
- Barry: if you come up with something specific, it could be reasonable
- Ted: I do not intend to block the document, I just wanted to make sure we discussed this
- Adrian: I'd prefer not to redo LastCall
- Adrian: Is there an issue with "one year"
- JoelJ: I haven't seen a case needing more than one year
- Michelle: I don't recall seeing a problem; but there may be more use in the future
- JoelJ: I noted in my comment squatting on a port number
- Stewart: interesting if Michelle has the facts...
- Michelle: I could scour that info for Vancouver
- Adrian: Ted, are you clearing?
- Ted: I have cleared
- Amy: this is approved; are notes ready?
- Benoit: I commented about IANA ?? I'm wondering if it makes sense to ask for early allocation as soon as we approve a document
- Michelle: I think there's a mention...
- Adrian: I think IANA puts an entry in the registry referring to RFC-to-be
- Benoit: I'm just looking for the value
- Michelle: we get notice when it's approved, we put in a place-holder without an RFC number
- Adrian: it can happen that author and RFCed see "oops, there's an error"
- Benoit: at what point in time do I know I have the particular value
- Russ?: I think that's AUTH48
- Benoit: that could be two years later
- Russ: if you know it'll take that long, you should ask for early-allocation
- Adrian: the number is there, with perhaps four-nines certainty
- Jari: when you approve AUTH48, then it's certain
- Russ: if you're worrying about shipping product, I'd ship
- Jari: this doesn't seem like a problem for this document
- Adrian: Amy, yes, the notes are ready
-
File Transfer Protocol HOST Command for Virtual Hosts (Proposed Standard)
draft-hethmon-mcmurray-ftpext-ftp-hosts
[txt]
Token: Barry Leiba (app area)
Discusses/comments [ballot]:
-
Ted Lemon: Discuss [2013-10-23 21:10]:
Section 3, paragraph 1:
"This command MUST be issued before the user is authenticated, as this will allow the authentication scheme and set of legal users to be dependent upon the virtual host that is chosen."
Does this mean 'if the user agent is going to send a HOST command, it MUST send it before it authenticates?' Or does it mean 'User agents implementing this specification MUST send a HOST command before authenticating?' I think it means the latter, but it could be read as meaning the former.
-
Ted Lemon: Comment [2013-10-23 21:10]:
Section 3.1 copies ABNF from RFC 3986 rather than incorporating it by reference. The reader most likely knows what an IPv4 address and an IPv6 address looks like, and if they don't they can refer to RFC 3986. So I would really encourage you to incorporate these by reference rather than copying the text. Copying the text invites errors, and I don't think it adds value.
-
Pete Resnick: Comment [2013-10-21 18:16]:
Section 3, para 1: 'legal' is weird here. Don't you mean 'authorized'?
Section 3.1: Why are these copied in here as opposed to being included by reference? Especially given that you've got a change to hostname and not to the literals, you're bound to cause confusion by mixing them. But we've seen this before and I leave it to the authors and AD to make the right choice.
Section 3.2.2, para 5: 'An exception to the above statement...' Which above statement are you talking about?
-
Stephen Farrell: Comment [2013-10-23 19:33]:
- I support Sean's DISCUSS points
section 1 - 'Such an arrangement presents some problems for FTP servers, as an FTP server distinguishes incoming FTP connections by their IP addresses rather than their DNS names.' is a bit confusing,
I think s/IP address/inbound destination IP address/ would clarify. I was temporarily confused by that fwiw.
section 3 - with a host, auth, host sequence the 2nd host command gets a 503 response. But what else happens, if anything? You probably should say if its not implied by the 503.
3.1 - say if a server is behind a NAT/CGN. Then it might be genuinely presented with an IP address literal that's not the one by which it knows itself. Very much a corner case, but do you really want that MUST for sending a 504 in that case? Actually now that I think about that, it might be a real issue for WebRTC handling of ftp: URLs maybe. I guess there might also be a corner case wrt MPTCP there too, can't recall.
3.2.1 - corner case - with an OTP REIN isn't quite what its supposed to be, but that's independent of HOST I guess
Appendix A - I'm not sure all of the paths-not-taken are required to be 'unworkable' so the appendix title seems odd.
-
Jari Arkko: Discuss [2013-10-23 10:43]:
Thanks for writing this document. It seems OK and the Gen-ART reviewer, Merat, was also largely OK with it. However, before recommending the approval I wanted to ask for clarification on two points to make sure that implementors can read this spec accurately.
I had trouble understanding what the 'chooses not conform' on page 17 means. Did you mean 'chooses not to use'?
Similarly, on page 18, I did not understand this: 'a server implementation MUST treat an additional HOST command that was sent before a user has been authenticated as though a previous HOST command was not sent.' Can you clarify?
-
Jari Arkko: Comment [2013-10-23 10:43]:
See also Meral's Gen-ART review.
-
Spencer Dawkins: Comment [2013-10-22 04:54]:
I have a few comments that you might wish to consider, along with any other comments you receive during IESG evaluation.
In section 3.1. Syntax of the HOST command
"The 'hostname' (given as a parameter) specifies the virtual host to which access is desired. This SHOULD be the same host name that was used to obtain the IP address to which the FTP control connection was made, after any client conversions have been completed that convert an abbreviated or local alias to a complete (fully qualified) domain name, but before resolving a DNS alias (owner of a CNAME resource record) to its canonical name."
I'm not understanding why this is a SHOULD. Does something break in the protocol if you don't do this? Can the server-FTP process even tell that the user-FTP process has specified a host name that wasn't used to obtain the IP address?
In section 3.2. HOST command semantics
"Upon receiving the HOST command, before authenticating the user-PI, a server-FTP process SHOULD validate that the hostname given represents a valid virtual host for that server, and, if it is valid, establish the appropriate environment for that virtual host."
I'm not understanding why this is a SHOULD. Is this just so a server-FTP process that treats all of its virtual hosts as identical doesn't have to reject a HOST command from a user-FTP process that uses the HOST command to be robust in the presence of virtual hosts that aren't identical?
In section 3.2.1. REIN command semantics
"As specified in [RFC0959], the REIN command returns the state of the connection to what it was immediately after the transport connection was opened. This specification makes no changes to that behavior. The effect of a HOST command MUST be reset if a REIN command is performed, and a new HOST command MUST be issued afterwards in order to connect to a virtual host."
I think I was able to figure out what this is saying, but the (I think) similar text at the beginning of Section 4 was much easier for me to understand. You might consider stealing some of that phrasing, perhaps something like
"As specified in [RFC0959], the REIN command returns the state of the connection to what it was immediately after the transport connection was opened. This specification makes no changes to that behavior. In this situation, the server implementation MUST reset the authentication environment as though a previous HOST command was not sent, and a new HOST command MUST be issued afterwards in order to connect to a virtual host."
Thank you for including Appendix A. It was helpful to me as a reviewer.
-
Brian Haberman: Comment [2013-10-22 07:02]:
I have no objection to the publication of this document, but I do have a non-blocking comment that I think would be useful to consider. The examples supplied in section 3.1 (top of pg. 8) are educational, but I am concerned about the use of link-local IPv6 addresses. The examples do not seem like they need to use link-local IPv6 addresses, so using global addresses out of the documentation space (RFC 3849) would be a good choice. My concern about using link-local IPv6 addresses is that their use requires more information than just the address. In order to handle the non-uniqueness of these addresses, users have to specify which interface to use for the communication (e.g., 'ftp FE80::1:2:3:4%en0'). RFC 4007 (section 11) discusses the reason for needing this additional information. Given that, I would suggest changing the example to use the defined documentation (i.e., global) address range.
-
Sean Turner: Discuss [2013-10-23 16:56]:
One of the big issues with TLS is how to represent and verify the identity of applications (see RFC 6125). RFC 5280 specifies how the FTP URI is used in the certificate something like ftp://192.0.2.1. s3.1 of this document says that the address can include square brackets. Is this document updating RFC 5280? Does the server_name included in the TLS handshake also include these brackets?
This draft draws a comparison to HTTP for this draft's HOST command, I would like to draw another to the HTTP Basic Authentication schemes which when used MUST be paired with TLS. And that is ... if the 'security' extensions from RFC 2228 are to be used after a HOST command is issued or if the user name and password are to be exchanged after a HOST command then TLS MUST be used.
s3.2: I'm unsure why these are not MUSTs:
"Upon receiving the HOST command, before authenticating the user-PI, a server-FTP process SHOULD validate that the hostname given represents a valid virtual host for that server, and, if it is valid, establish the appropriate environment for that virtual host."
"If the hostname specified is unknown at the server, or if the server is otherwise unwilling to treat the particular connection as a connection to the hostname specified, the server SHOULD respond with a 504 reply."
Telechat:
- Amy: couple of discusses
- Barry: mumble, I'm getting audio dropouts... Sean, have you gotten a response?
- Sean: I have not
- Barry: authors need to respond; Ted, I don't see the point of having the document say "if you implement this document, then..."
- Ted: right now the document reads ambiguously
- Barry: I don't agree
- Ted: can be read two ways
- Barry: they're the same
- Ted: you could read this as saying you're required to implement this
- Barry: I don't strongly object to saying "if host command is sent, it must be sent before...", but it seems out of place compared to other extensions
- Ted: if this came up the same way in the future, I'd probably put a discuss on that
- Barry: does any other AD have this issue
- Richard: mumble (distorted audio)
- (several): didn't understand what Richard said
- Barry: we'll make the change, but it still seems bizarre to me... authors still have a lot of responding to do; revised-ID needed
- (Barry, several days later via email: Richard said something. We couldn't understand him. He compensated for that by posting "+1 to Barry" in the jabber room, and Brian responded to that with "+2".)
-
Characterization of Proposed Standards (Best Current Practice)
draft-kolkman-proposed-standards-clarified
[txt]
Token: Jari Arkko (gen area)
Discusses/comments [ballot]:
-
Adrian Farrel: Comment [2013-10-19 06:06]:
Abstract
Does the IESG review Proposed Standard RFCs or does it review Internet-Drafts requested for publication as Proposed Standard RFCs?
Similar issue at the top of the Introduction.
Section 1: 'This document exclusively updates...'
Could mean 'This document updates only...' or 'No other document updates...'
Suggest you mean the former and change to it.
I should find this document even more excellent if the Abstract and Introduction both made a summary statement of the 'new' characterization so that lazy readers picked this up easily and clearly.
-
Pete Resnick: Comment [2013-10-19 15:04]:
Abstract: The word 'new' strikes me as odd here. Saying 'new' implies that first we're changing the characterization, and then we're going to start behaving in accordance with it. What we're doing is updating the characterization to reflect reality. The Intro gets this right. A suggested update to the Abstract; do with it as you see fit:
"RFC 2026 describes the review performed by the IESG on IETF Proposed Standard RFCs and states the maturity level of those documents. Since its publication, reviews have become more stringent than described by RFC 2026. This document clarifies those descriptions and updates RFC 2026 by providing a current and more accurate characterization of Proposed Standards."
Section 2:
"the IETF strengthened its review of Proposed Standards, basically operating as if the Proposed Standard was the last chance for the IETF to ensure the quality of the technology and the clarity of the Standard Track document."
I suggest adding to this sentence: 'before it is deployed on the Internet'. I think this may also address Benoit's comment.
"The IETF review is possibly more extensive than that done in most other SDOs owing to..."
Whether or not the above is true, I think saying it this way, even with the 'possibly', is just hubris. (Given the audience for this document, it has the potential to cause grumbling.) I suggest 'The IETF review is at least as extensive as that in most other SDOs owing to...'
-
Stephen Farrell: Comment [2013-10-22 14:16]:
- 'exemplified by technical review by the full IESG at the last stage of specification development' might be problematic if the recent discussion about changing the role of the IESG in document review bears fruit. I'm ok that we say that since I'd not bet on the other discussion resulting in short-term change, but it might be prudent to re-word just in case. Not sure I can think of a good rewording though that'd be worth including.
- Did section 4 get any reaction in IETF LC or before? If not, I bet we regret that last sentence.
- Given the non-IETF audience at which this is partly aimed, it might make sense to say that all proposed standards contain an analysis of security considerations or something.
- I agree Benoit's point is important to make and missing.
-
Richard Barnes: Comment [2013-10-23 19:42]:
In general, this document does a really good job of clarifying things that should have been made clear long ago.
'''The IETF review is possibly more extensive than that done in most other SDOs owing to the cross-area technical review performed by the IETF.'''
This seems like an unnecessary dig at other SDOs. Maybe the following?
'''The IETF review is especially extensive owing to the cross-area technical review performed by the IETF.'''
-
Benoit Claise: Comment [2013-10-18 06:27]:
In section 2, I believe that you're missing the argument that many Proposed Standards are actually deployed on the Internet, as stable protocols. This proves the point that the community deemed unnecessary to upgrade to Internet Standard (for the sake of upgrading, i.e. without some specifications improvements/changes/errata integration).
-
Barry Leiba: Comment [2013-10-18 04:29]:
Spencer's comment looks correct to me.
-
Spencer Dawkins: Comment [2013-10-17 20:30]:
In 4. Further Considerations
"While less mature specifications will usually be published as Informational or Experimental RFCs, the IETF may, on occasion, publish a specification that still contains areas for improvement or certain uncertainties about whether the best engineering choices are made."
I'm almost sure this means 'something like publish a proposed standard', but that's not what it says, so I'm guessing.
Telechat:
- Amy: one discuss
- Jari: we'll have to discuss that; hopefully others will say what they think we should do;
- Barry: has to happen between Dave and Olaf and the community on the IETF list
- Russ: I suggest you get a revision posted so we can have discussion in Vancouver
- Jari: agree, mumble, discuss in Vancouver
- Barry: it is a change from what we do
- Russ: I disagree. when we did RFC 6410, community objected to too many changes "at once"
- Jari: I agree discussion with the community needs to happen; revised-ID needed
2.2.2 Returning Items
2.3 Status Changes
2.3.1 New Items
2.3.2 Returning Items
3. Document Actions
3.1 WG Submissions
3.1.1 New Items
-
Terms used in Ruting for Low power And Lossy Networks (Informational)
draft-ietf-roll-terminology
[txt]
Token: Adrian Farrel (rtg area)
Note: Michael Richardson (mcr@sandelman.ca) is the document shepherd.
Discusses/comments [ballot]:
-
Stephen Farrell: Comment [2013-10-22 15:50]:
- The definition of LBR assumes that there is only one per LLN which is probably not an intentional limitation. To fix: s/The LBR/An LBR/g
- RAM - NVRAM is RAM but wouldn't fit this definition. Deleting the definition would be best here I'd say. Chances of it being needed are smaller than of getting it wrong.
- Schedule - a single device can have a power duty-cycle schedule, e.g. if an LBR is not a challenged device, so the 'two or more' here is just wrong.
- Sleepy Node - that definition is broken. A node can be in a power state that's not asleep but where the radios are off. Even ACPI has multiple sleep states, as do processors so this just isn't binary.
- Timeslot - 'fixed time interval' is tricky - do you mean fixed duration (and cycle) or fixed (modulo cycle) when compared to UTC?
-
Martin Stiemerling: Comment [2013-10-22 01:26]:
I was about to raise a DISCUSS, just for the reason that nobody has really read the document ;)
The title says 'Terms used in Ruting for Low power And Lossy Networks', but it should read 'Terms used in Routing for Low power And Lossy Networks.
So please replace 'Ruting' by 'Routing' in the title.
-
Jari Arkko: Comment [2013-10-23 22:15]:
Thanks for writing this good document!
-
Richard Barnes: Discuss [2013-10-23 18:46]:
Simple question: Why do we have both this document, 'Terms used in Ruting for Low power And Lossy Networks', and draft-ietf-lwig-terminology, 'Terminology for Constrained Node Networks'? Are LLNs and 'constrained node networks' really so different, or is this just document multiplication due to poor coordination? I'm being slightly facetious here, but it seriously does seem like these two things are closely enough related that it could be quite helpful to have both sets of information in the same place.
-
Richard Barnes: Comment [2013-10-23 18:46]:
The typo in the title does not really inspire confidence in the level of review this document has received.
-
Benoit Claise: Comment [2013-10-22 03:48]:
I'm pretty sure that JP doesn't live in Boxborough any longer ;-)
Below is the OPS-DIR review from Dan Romascanu. Take it or leave it.
(see link)
-
Spencer Dawkins: Comment [2013-10-22 05:13]:
In addition to Stewart's comments, and Benoit-channeling-Dan's comments, which I agree with, I had a few comments you might wish to consider along with any other comments you receive during IESG evaluation.
(see link)
-
Brian Haberman: Comment [2013-10-22 07:09]:
I agree with Benoit/Dan that there are some definitions that are globally accepted and don't need to be in this document.
Question 8 of the shepherd write-up says that an IPR disclosure was filed against this draft. Really?
-
Stewart Bryant: Comment [2013-10-22 04:37]:
(see link)
-
Sean Turner: Comment [2013-10-23 15:25]:
I'm with Joel.
-
Joel Jaeggli: Comment [2013-10-22 21:59]:
needs another rev to capture all the comments otherwise fine.
Telechat:
- Amy: couple of discusses
- Adrian: my discuss first: suggestion that we merge with ??-terminology document... seems a fine idea, ROLL-WGC agreed; I propose we put it into AD-followup while I chase authors and chairs
- Brian: I'm willing to work through that
- Stewart: if there are conflicting uses of terms, it would help to at least document the conflict
- Adrian: AD-followup
- Richard: should I hold my discuss?
- Adrian: yes
-
Evaluation of existing GMPLS encoding against G.709v3 Optical Transport Networks (OTN) (Informational)
draft-ietf-ccamp-otn-g709-info-model
[txt]
Token: Adrian Farrel (rtg area)
Discusses/comments [ballot]:
-
Pete Resnick: Comment [2013-10-23 21:03]:
I have a question regarding this document. I am not making it a DISCUSS because (a) my availability to have a DISCUSSion this week and next is limited and (b) even if the answer to this question is the worst imaginable, I'm not convinced we should hold up publication to DISCUSS it:
What charter item for CCAMP does this document fulfill? I can't figure out what major output of the WG this document is intended to advance, and I don't even see a milestone for this item in the milestone list. Is this supposed to be input to some other document? Neither the intro nor the abstract make this obvious.
-
Spencer Dawkins: Comment [2013-10-22 07:10]:
I did have one comment, which you might consider along with any other feedback you receive during IESG evaluation.
In section 3.2. Control Plane considerations
"What is shown in the example is that the TS granularity processing is a per layer issue: even if the ODU3 H-LSP is created with TS granularity client at 2.5Gbps, the ODU2 H-LSP must guarantee a 1.25Gbps TS granularity client."
I don't understand what 'must guarantee a client' means here. Is that a term of art in optical networking? I'm guessing this is saying something like 'must guarantee support for a client', but I'm guessing.
-
Stewart Bryant: Comment [2013-10-22 04:38]:
Figure 7 addresses the scenario in which the restoration of the ODU2
I think you mean Figure 10
ISCD + IACD need expansion
-
Sean Turner: Comment [2013-10-23 18:18]:
Warren's secdir review seemed to have some useful editor comments. Please consider them.
Telechat:
- Amy: no discusses, hearing no objection, approved
- Adrian: some comments I need to work through, point-raised please
-
A Thesaurus for the Terminology used in Multiprotocol Label Switching Transport Profile (MPLS-TP) drafts/RFCs and ITU-T's Transport Network Recommendations. (Informational)
draft-ietf-mpls-tp-rosetta-stone
[txt]
Token: Adrian Farrel (rtg area)
Discusses/comments [ballot]:
-
Benoit Claise: Comment [2013-10-24 05:52]:
Section 1.1 'contributing authors' should be called 'Contributors' section. See http://www.ietf.org/proceedings/62/slides/editor-0.pdf, slide 37
Let's not invent a new term.
OAM stands for 'Operations, Administration and Maintenance' Section 1 mentions 'Operation, Administration and Management'. Please correct this.
-
Barry Leiba: Comment [2013-10-21 21:05]:
The well done shepherd writeup clearly tells us that this document has been widely reviewed and is widely seen as a useful tool. Given that and a quick breeze through it, I see nothing that I might even consider objecting to.
-
Spencer Dawkins: Comment [2013-10-22 09:22]:
I would be a 'Yes' if I understood the technology better. This is very good, and very helpful. I wish I'd had a doc like this as a Gen-ART reviewer.
I did have a couple of questions you might want to consider, along with any other comments you receive during IESG evaluation.
(see link)
-
Joel Jaeggli: Comment [2013-10-22 22:28]:
looks good. earlier reviews I've seen raise no red flags after the recent edit.
Telechat:
- Amy: no discusses, hearing no objection, approved
- Adrian: need to deal with comments, point-raised, please
3.1.2 Returning Items
3.2 Individual Submissions Via AD
3.2.1 New Items
-
AES-CCM ECC Cipher Suites for TLS (Informational)
draft-mcgrew-tls-aes-ccm-ecc
[txt]
Token: Sean Turner (sec area)
IPR: Certicom's Statement of IPR relating to draft-mcgrew-tls-aes-ccm-ecc-00
IPR: Certicom Corp. Statement about IPR Related to draft-mcgrew-tls-aes-ccm-ecc-00
Discusses/comments [ballot]:
-
Ted Lemon: Comment [2013-10-23 20:18]:
The document describes these cipher suites as being useful for constrained nodes, but needed on other nodes so that they can interoperate with constrained nodes that use it. This implies to me that a node that is not constrained might want to use a different algorithm. I don't have enough of a clue about ciphers to know if this means that this cipher suite is weaker, but that's what I'm tempted to assume. If in fact it is weaker, then the encouragement to implement it on non-constrained nodes ought to be accompanied by an admonishment never to volunteer to use it when the communicating partner supports a better cipher suite. Is the fact that I don't see this admonition because it is felt to be obvious, or is made in some other document, or am I just mistaken about the reason behind recommending this cipher suite specifically for constrained nodes?
-
Stephen Farrell: Comment [2013-10-23 10:24]:
- While I hate to see more TLS ciphersuites being added to the zoo, these will be used as the algs are baked in various bits of h/w.
- The write up talks about existing implementations. Are the codepoints really still ok for IANA to pick or has the horse really left the barn? I'm not asking to encourage naughtiness, but it'd be a shame if some zigbee stuff was out there already and wasn't going to be changed.
- The 'cert SHOULD be signed with ECC' seems like an odd SHOULD, I think you mean its more likely to work in more environments if you use ECC all the way up and don't have any RSA, but if so, it'd maybe be better to say that.
- A reference to the brainpool curves in TLS RFC in appendix A would probably be useful.
-
Richard Barnes: Comment [2013-10-23 19:14]:
Like Spencer, I'm confused by the requirement in Section 2 that 'the server's certificate SHOULD contain a suitable ECC public key, SHOULD be signed with a suitable ECC public key'. Section 2.2 of RFC 4492 has the following requirement for ECDHE_ECDSA ciphersuites: 'In ECDHE_ECDSA, the server's certificate MUST contain an ECDSA-capable public key and be signed with ECDSA.' Isn't that the same as what's in this document, only stronger?
The Security Considerations refers to 'The IV construction in Section 2...', but Section 2 refers to the 'nonce input'. Should probably change 'IV' to 'nonce' to align with Section 2 and RFC 6655.
-
Benoit Claise: Comment [2013-10-23 07:38]:
Not the expert on that topic. No feedback.
-
Spencer Dawkins: Comment [2013-10-22 10:56]:
This might not even be a comment, but a question. In Section 1. Introduction,
(see link)
Telechat:
- Amy: no discusses, hearing no objection, approved
- Sean: point-raised, please
3.2.2 Returning Items
3.3 Status Changes
3.3.1 New Items
3.3.2 Returning Items
3.4 IRTF and Independent Submission Stream Documents
3.4.1 New Items
-
IETF conflict review for draft-yokota-mext-ha-init-flow-binding
conflict-review-yokota-mext-ha-init-flow-binding
[txt]
Token: Brian Haberman
Discusses/comments [ballot]:
-
Pete Resnick: Comment [2013-10-23 18:10]:
I am presuming that the IANA allocations (all of which are under 'Standards Action or IESG Approval') are OK. There's no guidance in 6275 as to when these things ought to be approved, and I assume we're going to see a Management Item at some point to approve these allocations, but I trust that the INT ADs will let the rest of us know that these allocations are fine.
Telechat:
- Amy: no discusses, hearing no objection, conflict-review approved
- Brian: Amanda uncovered an issue with IANA section: asking for four registrations, I sent a note to Nevil to clarify that
- Amy: approved
- Brian: does it make sense to add note about IANA-considerations clarification?
- Amy: not sure what you're asking, did you send email already
- Brian: yes, would it help to add text here
- JoelJ: open an IANA ticket, if anything
-
IETF conflict review for draft-dtnrg-ltp-cbhe-registries
conflict-review-dtnrg-ltp-cbhe-registries
[txt]
Token: Spencer Dawkins
Discusses/comments [ballot]:
Telechat:
- Amy: no discusses, hearing no objection, conflict-review approved
- Michelle: think we got this Tuesday, we haven't had time to to review all the new registries
- Amy: could be approved-point-raised
- Michelle: did the rest of the IESG not get this before Tuesday
- Spencer: four protocols the IRTF has, seemed OK
- JoelJ: we're not asked is this good, just if it conflicts
- Michelle: conflict-review can go out, I can tell Lars/Nevil we need more time
- Amy: is this point-raised?
- Spencer: no point-raised, we're only approving re conflicts
-
IETF conflict review for draft-turner-additional-methods-4kis
conflict-review-turner-additional-methods-4kis
[txt]
Token: Barry Leiba
Discusses/comments [ballot]:
Telechat:
- Amy: no discusses, hearing no objection, approved
- Barry: note OK
3.4.2 Returning Items
-
IETF conflict review for draft-hoffine-already-dotless
conflict-review-hoffine-already-dotless
[txt]
Token: Joel Jaeggli
Discusses/comments [ballot]:
-
Ted Lemon: Comment [2013-10-23 19:50]:
Oops, I forgot to clear this discuss after our conversation last time. Sorry for the delay.
-
Adrian Farrel: Comment [2013-10-07 10:03]:
I would prefer that the ISE could work with the authors so that the point of concern is added to the text of the document and does not need to be present as an IESG note. That said, if the authors are unwilling, I would support an IESG note.
But some typos and clarification might help...
(see link)
-
Martin Stiemerling: Comment [2013-10-09 01:49]:
I don't see the need to add an IESG statement here, but I will trust that the other DISCUSS positions will be enough to take care of this.
-
Jari Arkko: Comment [2013-10-09 13:26]:
Agree that text in doc is better than IESG note. Assuming the text would be strong enough. The current IESG note is strong enough.
-
Benoit Claise: Comment [2013-10-10 00:39]:
After a discussion with Joel, I now understand and support his point of view. Wanted to vote YES, but I'm not sure what it means for a conflict review.
Joel gave me two good arguments why this IESG note is a good thing:
- ccTLD operators (the ones who created the dotless domains) have no obligations to ICANN. They can do what they want, regardless of the ICANN guidelines.
- As the authors don't state an opinion, this document might be perceived as: here is a way to 'search' dotless domains, have your own opinion for yourself, we don't state ours. The topic is too important. The IESG should stress the message: published dotless domains should not be used.
The document already contains:
"This document lists data about dotless TLDs, but does not address the policy and technology issues other than to point to the statements of others."
"The Internet Architecture Board (IAB) issued a statement called 'Dotless Domains Considered Harmful' [IAB-DOTLESS] in July, 2013."
"This document lists the known dotless domains; it does not express an opinion whether or not there are security considerations with the existence of dotless domains."
What the ideal (for me) would be:
1. The authors refers to [SAC053] ICANN Security and Stability Advisory Committee, “SSAC Report on Dotless Domains”, SAC053. 23 February 2012. Retrieved from SAC053, and cut and paste the recommendation.
Recommendation: Dotless domains will not be universally reachable and the SSAC recommends strongly against their use. As a result, the SSAC also recommends that the use of DNS resource records such as A, AAAA, and MX in the apex of a Top-Level Domain (TLD) be contractually prohibited where appropriate and strongly discouraged in all cases.
2. An IESG note expressing that the IESG supports the Recommendation in [SAC053], and that published dotless domains should be removed.
-
Spencer Dawkins: Comment [2013-10-07 16:14]:
I trust that the right thing will happen, based on discussion so far ...
-
Stewart Bryant: Comment [2013-10-09 04:44]:
This is *not* my area of expertise, but as far as I can see the draft is factually reporting the existing dotless domains, and describing how to generate a list of the current set.
I cannot see any harm in reporting the results of a measurement on the Internet, or a method of generating a list, and thus I cannot see the reason to include the IESG statement.
-
Sean Turner: Comment [2013-10-10 08:34]:
no note please
Telechat:
- Amy: no discusses, hearing no objection, conflict-review approved
- JoelJ: notes OK
3.4.3 For Action
1238 EDT break
1244 EDT back
- Jari Arkko--- (left)
- Richard Barnes--- y
- Stewart Bryant--- y
- Gonzalo Camarillo--- y
- Benoit Claise--- y
- Michelle Cotton--- y
- Spencer Dawkins--- y
- Adrian Farrel--- ?
- Stephen Farrell--- y
- Heather Flanagan---
- Sandy Ginoza--- y
- Brian Haberman--- y
- Joel Halpern---
- Susan Hares--- y
- Russ Housley--- y
- Joel Jaeggli--- y
- Barry Leiba--- y
- Ted Lemon--- y
- John Leslie--- y
- Cindy Morgan--- y
- Ray Pelletier--- regrets
- Carlos Pignataro---
- Pete Resnick---
- Martin Stiemerling--- y
- Sean Turner--- y
- Amy Vezza--- y
4 Working Group Actions
4.1 WG Creation
4.1.1 Proposed for IETF Review
- (none)
4.1.2 Proposed for Approval
- Source Packet Routing in Networking (spring)
Token: Stewart
Telechat::
- Amy: a blocking comment
- Stewart: Brian, we had side email conversation, your concern is clarity of IPv6 security issue; given text, I don't see how anyone could get an extension approved without addressing that
- Brian: I wondered if anyone else agreed ordering should be mentioned
- Stewart: don't see how that could happen
- Ted: concerned that the IESG might have to be bad-guy
- Sean: I mentioned as comment, trusting ADs to make it clear early enough
- Spencer: mumble, previous proposal
- Stewart: everyone has got the message that in IPv6 case we can not go forward with anything which does not address this vulnerability
- Brian: looking it notional milestones, you're expecting it to take a while
- Stewart: I'd worry about it if the architecture didn't talk about it; likewise the next two; also, milestones can be split into two documents, with responsible chairs, I don't see how the problem could arise
- Brian: I'm willing to move to abstain... I'm concerned that everybody understand why source-routing went away and don't see how the problems could go away
- Joel: I wouldn't let it through without addressing the issue
- Brian: I'm changing to abstain
- Stewart: special tools-planning milestone... don't see where I specify the chairs...
- Amy: after you add chairs and text changes, just tell us... approved pending chairs and edits
4.2 WG Rechartering
4.2.1 Under evaluation for IETF Review
- (none)
4.2.2 Proposed for Approval
- IPv6 Maintenance (6man)
Token: Brian
Telechat::
- Amy: any objection to rechartering (no blocks), hearing none, approved
- MBONE Deployment (mboned)
Token: Joel
Telechat::
- Amy: no blocking comments, hearing no objection, approved
5. IAB News We can use
- Russ: two things, statement went out yesterday to MIF? to reopen ??... also, several RIRs have asked for delay in trust anchor
6. Management Issues
- Approving IANA registry entries for draft-yokota-mext-ha-init-flow-binding (Brian Haberman)
Telechat::
- Brian: actually two mobility headers and two mobility options
- Ted: I don't think either is a scarce resource, right?
- Brian: no... mark it as approved
- Michelle: IANA considerations of the document needs to be fixed
- Brian: yes
- Contact changes for multiple multicast assignments (Michelle Cotton)
Telechat::
- Michelle: extensive, but sanity check; we researched, seems OK; some concern who's the change controller, default is asking IESG
- Brian: I went digging around, think you're in good shape; we could talk in Vancouver about managing individual registration process
- Michelle: I'll send a separate email to schedule time for that; discussed, IESG had no issue
7. Agenda Working Group News
- Gonzalo Camarillo (RAI)--- none
- Benoit Claise (O & M)--- none
- Spencer Dawkins (Transport)--- closed BEHAVE
- Adrian Farrel (Routing)--- ROLL one WGC wants to step down, starting to look for replacement
- Stephen Farrell (Security)--- none
- Brian Hamerman (Internet)--- in process of closing MIP4, last document expected in Vancouver
- Joel Jaeggli (O & M)--- none
- Barry Leiba (Applications)--- nothing
- Ted Lemon (Internet)--- nope
- Pete Resnick (Apps)---
- Martin Stiemerling (Transport)--- no thanks
- Sean Turner (Security)--- ?? closing tomorrow
- Jari Arkko (General)---
- Richard Barnes (RAI)--- nothing
- Stewart Bryant (Routing)--- not today
1311 EDT Adjourned
Appendix: Snapshot of discusses/comments
(at 2013-10-24 07:30:03 PDT)
draft-ietf-tsvwg-byte-pkt-congest
-
Adrian Farrel: Comment [2013-10-23 14:48]:
Two small points that you don't need to discuss with me.
---
I think the RFC Editor will have indigestion with your acronym soup.
You might want to have a go at that before they have to ask you to.
---
Appendix A
Routers using a memory architecture based on fixed size buffers with
borrowing may also still be prevalent in the Internet.
I don't find that statement very helpful. Of course, it is true. But a
little more science or substantiation might help.
-
Stephen Farrell: Comment [2013-10-23 14:49]:
Just a few nits. Interesting read.
intro: the "long term goal" isn't stated, I took you to
mean "following this BCP's main recommendations" but it
could be something else too, as written.
intro: I don't get what it'd mean for TCP congestion
control to scale with packet size (or not). Seems like
an odd phrase here unless you're saying that TCP
congestion control runs into bigger and bigger issues as
packet size increases to infinity or something which
might be equally odd.
intro: is non-negligible right to describe the material
you then tell me the busy reader can safely neglect to
read? (Total nit, sorry;-)
-
Pete Resnick: Comment [2013-10-23 21:27]:
Please do address Barry's comments.
Administrivia: Sounds to me like this document should be part of BCP 41 so that
all of this information is in the same place. An RFC Editor note should be
added to let the RFC Editor know that.
-
Benoit Claise: Discuss [2013-10-24 06:50]:
This is a DISCUSS-DISCUSS, i.e. a discussion between the IESG members.
The authors don't need to take any action at this point in time.
Clarification question: what is the connection between this draft and the AQM
WG? AQM is supposed to obsolete RFC 2309, and at the same time, this document
updates RFC 2309.
I see that draft-ietf-aqm-recommendation normatively references
draft-ietf-tsvwg-byte-pkt-congest So should this document (at least section 2,
the recommendations) be part of draft-ietf-aqm-recommendation? To add to the/my
confusion, the document abstract speaks about Codel and PIE, which, IIRC, are
the two protocols discussed in AQM.
What will be the situation when draft-ietf-aqm-recommendation will be a RFC?
This RFC will obsolete RFC 2309, and reference (or maybe obsolete)
draft-ietf-tsvwg-byte-pkt-congest, which in turn will update RFC 2309. How do
you see this working? Is this an issue? I would like to discuss this with
responsible AD during the IESG telechat. Hence my DISCUSS-DISCUSS.
One proposal is that draft-ietf-aqm-recommendation copies the recommendations
from draft-ietf-tsvwg-byte-pkt-congest (btw, it does that with the current
version), and that it references the draft-ietf-tsvwg-byte-pkt-congest, which
justifies the recommendations. An informational reference would be good enough,
and would avoid some confusion... I guess.
A (cleaner) alternative is for draft-ietf-tsvwg-byte-pkt-congest to be a
companion document to draft-ietf-aqm-recommendation, in the AQM WG. Advantage:
it doesn't update RFC 2309. Drawback: some extra delay.
-
Benoit Claise: Comment [2013-10-24 06:50]:
No sure what "strongly deprecated" means.
For the specific case of RED, this means that byte-mode queue
measurement will often be appropriate although byte-mode drop is
strongly deprecated.
-
Barry Leiba: Comment [2013-10-22 10:51]:
I have a few non-blocking comments that I'd like you to consider. The first
few are more important, and please feel free to chat with me about them:
-- Section 2.1 --
In this case, if the resource is bit-congestible, the AQM
implementation SHOULD measure the length of the queue in bytes and,
if the resource is packet-congestible, the implementation SHOULD
measure the length of the queue in packets. No other choice makes
sense, because the number of packets waiting in the queue isn't
relevant if the resource gets congested by bytes and vice versa. For
example, the length of the queue into a transmission line would be
measured in bytes, while the length of the queue into a firewall
would be measured in packets.
If no other choice makes sense, under what conditions might there be a reason
to do otherwise (with respect to the SHOULDs)? In other words, why are these
not "MUST"?
To avoid the pathological effects of drop tail, the AQM can then
This non-transport guy doesn't know what a "drop tail" is. Is it worth having
the document say what it is, or is it a common enough term of art that we can
say "It's just me," and never mind?
Exceptions to these recommendations MAY be necessary
This should not be a 2119 "MAY"; please make it "may" (or "might", to avoid the
question).
-- Section 8 --
o When network equipment measures the length of a queue, if it is
not feasible to use time it is recommended to count in bytes if
the network resource is congested by bytes, or to count in packets
if is congested by packets.
I find that sentence to be very hard to read. In particular, I had trouble
parsing "to use time it is recommended to count". I suggest this, tweaked if
this isn't exactly what you mean:
NEW
o When network equipment measures the length of a queue, if it is
not feasible to measure the time in queue, it is recommended to
measure the byte count if the network resource is congested by
bytes, or to measure the packet count if it is congested by packets.
END
Or perhaps this is even clearer?:
NEW
o When network equipment measures the length of a queue, it is
best to measure the time in queue. If that is not feasible,
it is recommended to measure the byte count (if the network
resource is congested by bytes) or the packet count (if the
resource is congested by packets).
END
-------------------------------
The rest of the comments are very minor, so please consider them, but there's
no need to respond about them:
-- Section 1 --
This document provides recommendations of best current practice for
how we should correctly scale congestion control functions with
respect to packet size for the long term. It also recognises that
expediency may be necessary to deal with existing widely deployed
protocols that don't live up to the long term goal.
What does that second sentence mean? What, exactly, may be necessary? What
widely deployed protocols are involved here? Or is this theoretical?
-- Section 3 --
This section is informative. It justifies the recommendations given
in the previous section.
May I suggest, "It further explains", rather than, "It justifies" ?
-- Section 3.1 --
Imagine a scenario where the same bit rate of packets will contribute
the same to bit-congestion of a link irrespective of whether it is
sent as fewer larger packets or more smaller packets.
The antecedent of "it" is unclear, and appears to be the link. I think you
want, "...of whether the data is sent as...." Of course, if you prefer "the
data are", feel free.
-- Section 3.3 --
However, in order to do this, the
queuing algorithm has to make assumptions about the transport, which
become embedded in the network.
May I suggest, "However, in order to do this, the queuing algorithm has to make
assumptions about the transport, and those assumptions become embedded in the
network." ?
-- Section 4 --
The rest of this section is structured accordingly.
Srsly? I suggest dropping that paragraph.
-- Section 4.2.4 --
In Table 2, it's not immediately clear to the eye where the row separation is
in the first column. The word "or" is the clue, but I suggest adding another
blank line, or maybe a line of "-----".
I also suggest saying "Table 2 summarises", rather than "Table 2 aims to
summarise"... unless you really do think it has failed. :-)
-- Section 8 --
o When network equipment decides whether to drop (or mark) a packet,
it is recommended that the size of the particular packet should
not be taken into account
I think "should not be part of the decision" is better.
At the transport layer the IETF should continue updating congestion
control protocols to take account of the size of each packet that
indicates congestion.
Does this mean "each packet that has been marked"? Should it be said that way
instead?
-
Sean Turner: Comment [2013-10-23 18:21]:
Looks good to me.
-
Joel Jaeggli: Comment [2013-10-22 23:26]:
Outside of the general precept of don't implement AQM with byte drop mode with
which I whole heartedly endorse;
I have concerns whether sections 3.2 and 4.2.3 constitute advice, or best
practice.
4.2.3 makes no mention at all of UDP cases.
...
Although there are no known proposals, it would also be possible and
perfectly valid to make control packets robust against drop by
explicitly requesting a lower drop probability using their Diffserv
code point [RFC2474] to request a scheduling class with lower drop.
two points:
1. If you do this with a flow with a mix of control and flow packets you can
helpfully introduce more reordering than normal in forwarding devices that use
the dscp bits as an additional source of entropy by hashing different packets
from the same flow onto links of the same cost but unequal lengths (or across
linecards). (why you can safely use those bits as a source of entropy in your
own network comes up in point 2)
2. it is common to to point ubiquity to reset dscp bits at administrative
boundaries for sanitary purposes. because different operators treat traffic
differently, because wireless operators do in fact prioritize tcp connection
setup or dns queries over other parts of flows, to ameliorate number 1 and so
on. So... doesn't work on the internet is probably a bit of an issue.
the reference:
no longer exists so a stable reference needs to be found
[DupTCP] Wischik, D., "Short messages", Royal
Society workshop on networks: modelling
and control , September 2007, <http://
www.cs.ucl.ac.uk/staff/ucacdjw/Research/
shortmsg.html>.
http://www.cs.ucl.ac.uk/staff/ucacdjw/Research/shortmsg.html
Error 404
Not found - file doesn't exist or is read protected [even tried multi]
This user URL no longer exists. The user has either left UCL-CS or changed name
or user-class, or the home filestore is offline.
It is cited a rational for:
Although not brought to the IETF, a simple proposal from Wischik
[DupTCP] suggests that the first three packets of every TCP flow
should be routinely duplicated after a short delay. It shows that
this would greatly improve the chances of short flows completing
quickly, but it would hardly increase traffic levels on the Internet,
because Internet bytes have always been concentrated in the large
flows. It further shows that the performance of many typical
applications depends on completion of long serial chains of short
messages. It argues that, given most of the value people get from
the Internet is concentrated within short flows, this simple
expedient would greatly increase the value of the best efforts
Internet at minimal cost.
Which sounds like a not insignificant change to tcp notwithstanding that
duplicate packet handling works just fine in general? I assume unless I'm
misreading it, that they're referring to the first three packets after the
handshake and not the handshake itself.
draft-cotton-rfc4020bis
-
Stephen Farrell: Comment [2013-10-22 09:24]:
- What if an IRTF RG wants to run this process? Should we include
text on that? Did anyone ask Lars/the-IRSG? (I think we have a
case of that in the works now btw.) I realise that this says its
only for IETF stream, which is fine, but we might be better off
just checking if the IRTF want to play the same game now.
- Why 1 year for the temporary registration? Would "at least one
year" be better? Why "at most" one renewal? I don't object, but
that seems like it might make more and not less work.
-
Jari Arkko: Comment [2013-10-23 10:05]:
Thank you for writing this document.
-
Richard Barnes: Comment [2013-10-23 19:49]:
<rant>
It's appropriate that this document is on the same telechat as
draft-kolkman-proposed-standards-clarified -- both documents are about the
bloat in the RFC approval process. The stability criteria laid out in this
document basically mean that a protocol has to be feature-frozen (at least as
regards the code point) before an early allocation can be made. But an early
allocation can only be useful if there's some significant amount of time
between the allocation and the approval of the RFC. What are we doing in the
intermediate time? </rant>
-
Benoit Claise: Comment [2013-10-22 03:31]:
Note: I had an interesting discussion with Michelle, who clarified a few
things, and saved many emails.
Feel free to engage on the discussion on points 1 to 5.
1.
I would add a clarification that IANA assigns the code point(s) as soon as the
document is approved by the IESG. I had to ask Michelle, so I guess I'm not
the only who was not sure about this.
Therefore, this procedure is not applicable to documents sitting in the RFC
editor queue (we know that they can sit there for a long time, waiting for a
normative reference).
2.
If the document
progresses to the point at which IANA normally makes code point
allocations, it is the responsibility of the authors and the WG
chairs to remind IANA that there were early allocations, and of the
code point values so allocated, in the IANA Considerations section of
the RFC-to-be.
I believe it's the responsibility of the authors and document shepherd/WG
chairs. If the document left the WG already (IETF LC), so the chairs are not
involved. So maybe
it is the responsibility of the authors and the WG chairs (or the document
shepherd if the document left the WG) to remind IANA that there were early
allocations
Same remark for this sentence
If an early
allocation expires before the document progresses to the point where
IANA normally makes allocations, the authors and WG chairs may repeat
the process in section 3.1 to request renewal of the code points. At
most, one renewal request may be made; thus, authors should choose
carefully when the original request is to be made.
Discussing with Michelle, she thinks that this procedure doesn't really apply
to situations where the draft left the WG (IETF LC), because it's not too far
from IESG approval. So this procedure is not really worth it. One way or the
others, this should be clarified. Clarifying first the point 1 would help in
solving this point 2.
3.
section 3.1
2. The WG chairs determine whether the conditions for early
allocations described in section 2 are met; particularly,
conditions (c) and (d).
3. The WG chairs gauge whether there is consensus within the WG that
early allocation is appropriate in the case of the given
document.
3 is basically the means to check (d), right?
NEW:
2. The WG chairs determine whether the conditions for early
allocations described in section 2 are met; particularly,
conditions (c) and (d). The WG chairs gauge the consensus
for (d) within the WG.
4.
If the document
progresses to the point at which IANA normally makes code point
allocations, it is the responsibility of the authors and the WG
chairs to remind IANA that there were early allocations, and of the
code point values so allocated, in the IANA Considerations section of
the RFC-to-be. Allocation is then just a matter of removing the
"Temporary" tag from the allocation description.
So basically, you want to the IANA considerations section to clearly
specify that a temporary code point has been allocated, with a RFC
editor or IANA Note. Shouldn't you clearly spell that out?
5.
3.3. Expiry
As described in Section 3.1, each Temporary assignment is recorded in
the registry with the date of expiry of the assignment. If an early
allocation expires before the document progresses to the point where
IANA normally makes allocations, the authors and WG chairs may repeat
the process in section 3.1 to request renewal of the code points. At
most, one renewal request may be made; thus, authors should choose
carefully when the original request is to be made.
Is there some sort of automatic notification: without it, I'm sure people will
forgot
PURELY EDITORIAL (take it or leave it)
- regarding
4. IANA Considerations
This document defines procedures for early allocation of code points
in the registries with the "Specification Required", "RFC Required",
"IETF Review", and "Standards Action" policies and as such directly
affects IANA. This document removes the need for registries to be
marked as specifically allowing early allocation. IANA is requested
to clean up the registries by removing any such markings.
Maybe I didn't read carefully the first time. I was confused by a registry
entry being marked temporary and the IANA note at the top of a registry.
NEW: This document removes the need for registries to be
marked as specifically allowing early allocation.
IANA is requested to clean up the registries by removing registry notes.
Editorial:
- "format, semantic" or "formats, semantics" in
The format, semantics, processing, and other rules related to
handle the protocol entities defined by the code points
(henceforth called "specifications") must be adequately described
in an Internet-Draft.
-
Barry Leiba: Comment [2013-10-18 04:40]:
I agree with Sean's discuss.
-- Section 3.1 --
5. If the Area Directors approve step 4, the WG chairs request IANA
to make an early allocation.
Obligatory nit: we request an action, not an actor. The chairs "request that
IANA make an early allocation."
-
Stewart Bryant: Comment [2013-10-20 23:49]:
This is an update that we need to make.
I do however have a question concerning the one year lifetime of an early
allocation. Given that wa have a lot of experience since RFC4020 was published,
what does the evidence say about the 1+1 year lifetime.
My qualitative experience suggests that it is a bit short, but presumably we
have statistical evidence that gives us a firm view on what it should be.
-
Sean Turner: Comment [2013-10-19 12:42]:
The RFC editor's note addresses my concerns. Thanks!
-
Joel Jaeggli: Comment [2013-10-21 22:17]:
I have concerns about the lifetime being a bit short.
More deeply albiet probably not addressable I have concerns about the actual
effectiveness of the revocation procedure. TCP 465 reminds me of how badly this
can go sideways even when things are penciled in and then removed.
draft-hethmon-mcmurray-ftpext-ftp-hosts
-
Ted Lemon: Discuss [2013-10-23 21:10]:
Section 3, paragraph 1:
This command MUST be
issued before the user is authenticated, as this will allow the
authentication scheme and set of legal users to be dependent upon the
virtual host that is chosen.
Does this mean "if the user agent is going to send a HOST command, it MUST send
it before it authenticates?" Or does it mean "User agents implementing this
specification MUST send a HOST command before authenticating?" I think it
means the latter, but it could be read as meaning the former.
-
Ted Lemon: Comment [2013-10-23 21:10]:
Section 3.1 copies ABNF from RFC 3986 rather than incorporating it by
reference. The reader most likely knows what an IPv4 address and an IPv6
address looks like, and if they don't they can refer to RFC 3986. So I would
really encourage you to incorporate these by reference rather than copying the
text. Copying the text invites errors, and I don't think it adds value.
-
Pete Resnick: Comment [2013-10-21 18:16]:
Section 3, para 1: "legal" is weird here. Don't you mean "authorized"?
Section 3.1: Why are these copied in here as opposed to being included by
reference? Especially given that you've got a change to hostname and not to the
literals, you're bound to cause confusion by mixing them. But we've seen this
before and I leave it to the authors and AD to make the right choice.
Section 3.2.2, para 5: "An exception to the above statement..." Which above
statement are you talking about?
-
Stephen Farrell: Comment [2013-10-23 19:33]:
- I support Sean's DISCUSS points
section 1 - "Such an arrangement presents some problems
for FTP servers, as an FTP server distinguishes incoming
FTP connections by their IP addresses rather than their
DNS names." is a bit confusing, I think s/IP
address/inbound destination IP address/ would clarify.
I was temporarily confused by that fwiw.
section 3 - with a host, auth, host sequence the 2nd
host command gets a 503 response. But what else happens,
if anything? You probably should say if its not implied
by the 503.
3.1 - say if a server is behind a NAT/CGN. Then it might
be genuinely presented with an IP address literal that's
not the one by which it knows itself. Very much a
corner case, but do you really want that MUST for
sending a 504 in that case? Actually now that I think
about that, it might be a real issue for WebRTC handling
of ftp: URLs maybe. I guess there might also be a
corner case wrt MPTCP there too, can't recall.
3.2.1 - corner case - with an OTP REIN isn't quite what
its supposed to be, but that's independent of HOST I
guess
Appendix A - I'm not sure all of the paths-not-taken are
required to be "unworkable" so the appendix title seems
odd.
-
Jari Arkko: Discuss [2013-10-23 10:43]:
Thanks for writing this document. It seems OK and the Gen-ART reviewer, Merat,
was also largely OK with it. However, before recommending the approval I wanted
to ask for clarification on two points to make sure that implementors can read
this spec accurately.
I had trouble understanding what the "chooses not conform" on page 17 means.
Did you mean "chooses not to use"?
Similarly, on page 18, I did not understand this: "a server implementation MUST
treat an additional HOST command that was sent before a user has been
authenticated as though a previous HOST command was not sent." Can you clarify?
-
Jari Arkko: Comment [2013-10-23 10:43]:
See also Meral's Gen-ART review.
-
Spencer Dawkins: Comment [2013-10-22 04:54]:
I have a few comments that you might wish to consider, along with any other
comments you receive during IESG evaluation.
In section 3.1. Syntax of the HOST command
The "hostname" (given as a parameter) specifies the virtual host to
which access is desired. This SHOULD be the same host name that was
used to obtain the IP address to which the FTP control connection was
made, after any client conversions have been completed that convert
an abbreviated or local alias to a complete (fully qualified) domain
name, but before resolving a DNS alias (owner of a CNAME resource
record) to its canonical name.
I'm not understanding why this is a SHOULD. Does something break in the
protocol if you don't do this? Can the server-FTP process even tell that the
user-FTP process has specified a host name that wasn't used to obtain the IP
address?
In section 3.2. HOST command semantics
Upon receiving the HOST command, before authenticating the user-PI, a
server-FTP process SHOULD validate that the hostname given represents
a valid virtual host for that server, and, if it is valid, establish
the appropriate environment for that virtual host.
I'm not understanding why this is a SHOULD. Is this just so a server-FTP
process that treats all of its virtual hosts as identical doesn't have to
reject a HOST command from a user-FTP process that uses the HOST command to be
robust in the presence of virtual hosts that aren't identical?
In section 3.2.1. REIN command semantics
As specified in [RFC0959], the REIN command returns the state of the
connection to what it was immediately after the transport connection
was opened. This specification makes no changes to that behavior.
The effect of a HOST command MUST be reset if a REIN command is
performed, and a new HOST command MUST be issued afterwards in order
to connect to a virtual host.
I think I was able to figure out what this is saying, but the (I think) similar
text at the beginning of Section 4 was much easier for me to understand. You
might consider stealing some of that phrasing, perhaps something like
As specified in [RFC0959], the REIN command returns the state of the
connection to what it was immediately after the transport connection
was opened. This specification makes no changes to that behavior.
In this situation, the server implementation MUST reset the
authentication environment as though a previous HOST command was not
sent, and a new HOST command MUST be issued afterwards in order
to connect to a virtual host.
Thank you for including Appendix A. It was helpful to me as a reviewer.
-
Brian Haberman: Comment [2013-10-22 07:02]:
I have no objection to the publication of this document, but I do have a
non-blocking comment that I think would be useful to consider. The examples
supplied in section 3.1 (top of pg. 8) are educational, but I am concerned
about the use of link-local IPv6 addresses. The examples do not seem like they
need to use link-local IPv6 addresses, so using global addresses out of the
documentation space (RFC 3849) would be a good choice. My concern about using
link-local IPv6 addresses is that their use requires more information than just
the address. In order to handle the non-uniqueness of these addresses, users
have to specify which interface to use for the communication (e.g., "ftp
FE80::1:2:3:4%en0"). RFC 4007 (section 11) discusses the reason for needing
this additional information. Given that, I would suggest changing the example
to use the defined documentation (i.e., global) address range.
-
Sean Turner: Discuss [2013-10-23 16:56]:
One of the big issues with TLS is how to represent and verify the identity of
applications (see RFC 6125). RFC 5280 specifies how the FTP URI is used in
the certificate something like ftp://192.0.2.1. s3.1 of this document says
that the address can include square brackets. Is this document updating RFC
5280? Does the server_name included in the TLS handshake also include these
brackets?
This draft draws a comparison to HTTP for this draft's HOST command, I would
like to draw another to the HTTP Basic Authentication schemes which when used
MUST be paired with TLS. And that is ... if the "security" extensions from RFC
2228 are to be used after a HOST command is issued or if the user name and
password are to be exchanged after a HOST command then TLS MUST be used.
s3.2: I'm unsure why these are not MUSTs:
Upon receiving the HOST command, before authenticating the user-PI, a
server-FTP process SHOULD validate that the hostname given represents
a valid virtual host for that server, and, if it is valid, establish
the appropriate environment for that virtual host.
If the hostname specified is unknown at the server, or if the server
is otherwise unwilling to treat the particular connection as a
connection to the hostname specified, the server SHOULD respond with
a 504 reply.
draft-kolkman-proposed-standards-clarified
-
Adrian Farrel: Comment [2013-10-19 06:06]:
Abstract
Does the IESG review Proposed Standard RFCs or does it review Internet-
Drafts requested for publication as Proposed Standard RFCs?
Similar issue at the top of the Introduction.
---
Section 1
"This document exclusively updates..."
Could mean "This document updates only..." or "No other document
updates..."
Suggest you mean the former and change to it.
---
I should find this document even more excellent if the Abstract and
Introduction both made a summary statement of the "new" characterization
so that lazy readers picked this up easily and clearly.
-
Pete Resnick: Comment [2013-10-19 15:04]:
Abstract: The word "new" strikes me as odd here. Saying "new" implies that
first we're changing the characterization, and then we're going to start
behaving in accordance with it. What we're doing is updating the
characterization to reflect reality. The Intro gets this right. A suggested
update to the Abstract; do with it as you see fit:
RFC 2026 describes the review performed by the IESG on IETF Proposed
Standard RFCs and states the maturity level of those documents.
Since its publication, reviews have become more stringent than
described by RFC 2026. This document clarifies those descriptions and
updates RFC 2026 by providing a current and more accurate
characterization of Proposed Standards.
Section 2:
the IETF strengthened its review of Proposed Standards, basically
operating as if the Proposed Standard was the last chance for the
IETF to ensure the quality of the technology and the clarity of the
Standard Track document.
I suggest adding to this sentence: "before it is deployed on the Internet". I
think this may also address Benoit's comment.
The IETF review is
possibly more extensive than that done in most other SDOs owing to...
Whether or not the above is true, I think saying it this way, even with the
"possibly", is just hubris. (Given the audience for this document, it has the
potential to cause grumbling.) I suggest "The IETF review is at least as
extensive as that in most other SDOs owing to..."
-
Stephen Farrell: Comment [2013-10-22 14:16]:
- "exemplified by technical review by the full IESG at
the last stage of specification development" might be
problematic if the recent discussion about changing the
role of the IESG in document review bears fruit. I'm ok
that we say that since I'd not bet on the other
discussion resulting in short-term change, but it might
be prudent to re-word just in case. Not sure I can think
of a good rewording though that'd be worth including.
- Did section 4 get any reaction in IETF LC or before?
If not, I bet we regret that last sentence.
- Given the non-IETF audience at which this is partly
aimed, it might make sense to say that all proposed
standards contain an analysis of security considerations
or something.
- I agree Benoit's point is important to make and
missing.
-
Richard Barnes: Comment [2013-10-23 19:42]:
In general, this document does a really good job of clarifying things that
should have been made clear long ago.
"""
The IETF review is possibly more extensive than that done in most other SDOs
owing to the cross-area technical review performed by the IETF. """
This seems like an unnecessary dig at other SDOs. Maybe the following?
"""
The IETF review is especially extensive owing to the cross-area technical
review performed by the IETF. """
-
Benoit Claise: Comment [2013-10-18 06:27]:
In section 2, I believe that you're missing the argument that many Proposed
Standards are actually deployed on the Internet, as stable protocols. This
proves the point that the community deemed unnecessary to upgrade to Internet
Standard (for the sake of upgrading, i.e. without some specifications
improvements/changes/errata integration).
-
Barry Leiba: Comment [2013-10-18 04:29]:
Spencer's comment looks correct to me.
-
Spencer Dawkins: Comment [2013-10-17 20:30]:
In 4. Further Considerations
While less mature specifications will usually be published as
Informational or Experimental RFCs, the IETF may, on occasion,
publish a specification that still contains areas for improvement or
^^^^^^^^^^^^^
certain uncertainties about whether the best engineering choices are
made.
I'm almost sure this means "something like publish a proposed standard", but
that's not what it says, so I'm guessing.
draft-ietf-roll-terminology
-
Stephen Farrell: Comment [2013-10-22 15:50]:
- The definition of LBR assumes that there is only one
per LLN which is probably not an intentional limitation.
To fix: s/The LBR/An LBR/g
- RAM - NVRAM is RAM but wouldn't fit this definition.
Deleting the definition would be best here I'd say.
Chances of it being needed are smaller than of getting
it wrong.
- Schedule - a single device can have a power duty-cycle
schedule, e.g. if an LBR is not a challenged device, so
the "two or more" here is just wrong.
- Sleepy Node - that definition is broken. A node can be
in a power state that's not asleep but where the radios
are off. Even ACPI has multiple sleep states, as do
processors so this just isn't binary.
- Timeslot - "fixed time interval" is tricky - do you
mean fixed duration (and cycle) or fixed (modulo cycle)
when compared to UTC?
-
Martin Stiemerling: Comment [2013-10-22 01:26]:
I was about to raise a DISCUSS, just for the reason that nobody has really read
the document ;)
The title says "Terms used in Ruting for Low power And Lossy Networks", but it
should read "Terms used in Routing for Low power And Lossy Networks.
So please replace 'Ruting' by 'Routing' in the title.
-
Jari Arkko: Comment [2013-10-23 22:15]:
Thanks for writing this good document!
-
Richard Barnes: Discuss [2013-10-23 18:46]:
Simple question: Why do we have both this document, "Terms used in Ruting for
Low power And Lossy Networks", and draft-ietf-lwig-terminology, "Terminology
for Constrained Node Networks"? Are LLNs and "constrained node networks"
really so different, or is this just document multiplication due to poor
coordination? I'm being slightly facetious here, but it seriously does seem
like these two things are closely enough related that it could be quite helpful
to have both sets of information in the same place.
-
Richard Barnes: Comment [2013-10-23 18:46]:
They typo in the title does not really inspire confidence in the level of
review this document has received.
-
Benoit Claise: Comment [2013-10-22 03:48]:
I'm pretty sure that JP doesn't live in Boxborough any longer ;-)
Below is the OPS-DIR review from Dan Romascanu. Take it or leave it.
It is a well written and seems to be a useful document. My only editorial
question is whether it really is necessary to include here definitions of
very common terms like MAC or LAN, which can be found in other standards
like the IEEE standards. Such terms do not have a different meaning in roll.
The only definition that somehow differs from the common used definition is
definition of Data sink as 'A device that collects data from nodes specific
in an LLN.'. Is this something specific to roll? The text implies some
active role for 'data sinks' ('device that collects data') while in other
environments a data sink is just a device that receives data. If this is a
mistake better fix this.
-
Spencer Dawkins: Comment [2013-10-22 05:13]:
In addition to Stewart's comments, and Benoit-channeling-Dan's comments, which
I agree with, I had a few comments you might wish to consider along with any
other comments you receive during IESG evaluation.
I'm thinking this text
HVAC: Heating, Ventilation and Air Conditioning. A term applied to
the comfort level of an internal space.
should be something like
HVAC: Heating, Ventilation and Air Conditioning. A term applied to
mechanisms used to maintain the comfort level of an internal space.
^ inserted text ^
I understand what this text is saying
P2P: Point To Point. This refers to traffic exchanged between two
nodes (regardless of the number of hops between the two nodes).
but wonder if it should be something like
P2P: Point To Point. This refers to traffic exchanged between two
nodes (regardless of the number of network hops between the two
^ inserted "network"
nodes).
In this text,
Sleepy Node: A sleepy node is a node that may sometimes go into a
sleep mode (i.e. go into a low power state to conserve power) and
temporarily suspend protocol communication. When no in a sleep mode,
^not, I think
the sleepy node is in a fully powered on state where it has the
capability to perform communication.
-
Brian Haberman: Comment [2013-10-22 07:09]:
I agree with Benoit/Dan that there are some definitions that are globally
accepted and don't need to be in this document.
Question 8 of the shepherd write-up says that an IPR disclosure was filed
against this draft. Really?
-
Stewart Bryant: Comment [2013-10-22 04:37]:
Ruting - typo
==
Channel: Radio frequency sub-band
I think that this is a most unfortunate truncation in a document used about
routing, since we have other channels such as OAM channels. Might I propose
that you use "Radio Channel" a term which would normally be acceptable to radio
engineers and which would not confuse network engineers.
==
Channel Hopping: A procedure by which field devices synchronously change
channels during operation.
This may need some clarification I imagine you refer to RX TX pairs sync rather
than TX TX sync in any case you should probably expand the meaning.
==
Closed Loop Control: A procedure whereby a device controller controls
an actuator based on input information sensed by one or more field
devices.
To be closed loop, surely you need to emphasis that the actuator causes an
effect that has a (normally negative feedback) impact on the sensor to result
in a converged behaviour.
==
Open Loop Control: A process whereby a plant operator manually
manipulates an actuator over the network where the decision is
influenced by information sensed by field devices.
Surely OLC has nothing to do with manual intervention and everything to do with
the absence of feedback.
==
Schedule: An agreed execution, wake-up, transmission, reception,
etc., time-table between two or more field devices.
Schedule does not normally imply synchronisation, are you sure this term is not
going to lead to confusion? ==
-
Sean Turner: Comment [2013-10-23 15:25]:
I'm with Joel.
-
Joel Jaeggli: Comment [2013-10-22 21:59]:
needs another rev to capture all the comments otherwise fine.
draft-ietf-ccamp-otn-g709-info-model
-
Pete Resnick: Comment [2013-10-23 21:03]:
I have a question regarding this document. I am not making it a DISCUSS because
(a) my availability to have a DISCUSSion this week and next is limited and (b)
even if the answer to this question is the worst imaginable, I'm not convinced
we should hold up publication to DISCUSS it:
What charter item for CCAMP does this document fulfill? I can't figure out what
major output of the WG this document is intended to advance, and I don't even
see a milestone for this item in the milestone list. Is this supposed to be
input to some other document? Neither the intro nor the abstract make this
obvious.
-
Spencer Dawkins: Comment [2013-10-22 07:10]:
I did have one comment, which you might consider along with any other feedback
you receive during IESG evaluation.
In section 3.2. Control Plane considerations
What is shown in the example is that the TS granularity processing is
a per layer issue: even if the ODU3 H-LSP is created with TS
granularity client at 2.5Gbps, the ODU2 H-LSP must guarantee a
1.25Gbps TS granularity client.
I don't understand what "must guarantee a client" means here. Is that a term of
art in optical networking? I'm guessing this is saying something like "must
guarantee support for a client", but I'm guessing.
-
Stewart Bryant: Comment [2013-10-22 04:38]:
Figure 7 addresses the scenario in which the restoration of the ODU2
I think you mean Figure 10
ISCD + IACD need expansion
-
Sean Turner: Comment [2013-10-23 18:18]:
Warren's secdir review seemed to have some useful editor comments. Please
consider them.
draft-ietf-mpls-tp-rosetta-stone
-
Benoit Claise: Comment [2013-10-24 05:52]:
Section 1.1 "contributing authors" should be called "Contributors" section.
See http://www.ietf.org/proceedings/62/slides/editor-0.pdf, slide 37
Let's not invent a new term.
OAM stands for "Operations, Administration and Maintenance"
Section 1 mentions "Operation, Administration and Management". Please correct
this.
-
Barry Leiba: Comment [2013-10-21 21:05]:
The well done shepherd writeup clearly tells us that this document has been
widely reviewed and is widely seen as a useful tool. Given that and a quick
breeze through it, I see nothing that I might even consider objecting to.
-
Spencer Dawkins: Comment [2013-10-22 09:22]:
I would be a "Yes" if I understood the technology better. This is very good,
and very helpful. I wish I'd had a doc like this as a Gen-ART reviewer.
I did have a couple of questions you might want to consider, along with any
other comments you receive during IESG evaluation.
In section 1.1 Contributing Authors
Italo Busi, Ben Niven-Jenkins, Enrique Hernandez-Valencia, Lieven
Levrau, Dinesh Mohan, Stuart Bryant, Dan Frost, Matthew Bocci,
^ this isn't Stewart Bryant, is it? :-)
Vincenzo Sestito, Vigoureux, Yaacov Weingarten
In section 3.19 Maintenance Entity Group End Point (MEP):
Maintenance Entity Group End Points (MEPs) are the end points of a
pre-configured (through the management or control planes) ME. MEPs
are responsible for activating and controlling all of the OAM
functionality for the ME. A source MEP may initiate an OAM packet to
be transferred to its corresponding peer or sink MEP, or to an
intermediate MIP that is part of the ME. See also [RFC6371] section
3.3 and [ITU-T G.8113.1], [ITU-T G.8113.2] clause 6.3.
Are "peer" and "sink" being used as synonyms? Is that normal optical
terminology? in which case, tell me "yes" ...
-
Joel Jaeggli: Comment [2013-10-22 22:28]:
looks good. earlier reviews I've seen raise no red flags after the recent edit.
draft-mcgrew-tls-aes-ccm-ecc
-
Ted Lemon: Comment [2013-10-23 20:18]:
The document describes these cipher suites as being useful for constrained
nodes, but needed on other nodes so that they can interoperate with constrained
nodes that use it. This implies to me that a node that is not constrained
might want to use a different algorithm. I don't have enough of a clue about
ciphers to know if this means that this cipher suite is weaker, but that's what
I'm tempted to assume. If in fact it is weaker, then the encouragement to
implement it on non-constrained nodes ought to be accompanied by an
admonishment never to volunteer to use it when the communicating partner
supports a better cipher suite. Is the fact that I don't see this admonition
because it is felt to be obvious, or is made in some other document, or am I
just mistaken about the reason behind recommending this cipher suite
specifically for constrained nodes?
-
Stephen Farrell: Comment [2013-10-23 10:24]:
- While I hate to see more TLS ciphersuites being added to the
zoo, these will be used as the algs are baked in various bits
of h/w.
- The write up talks about existing implementations. Are the
codepoints really still ok for IANA to pick or has the horse
really left the barn? I'm not asking to encourage naughtiness,
but it'd be a shame if some zigbee stuff was out there already
and wasn't going to be changed.
- The "cert SHOULD be signed with ECC" seems like an odd
SHOULD, I think you mean its more likely to work in more
environments if you use ECC all the way up and don't have any
RSA, but if so, it'd maybe be better to say that.
- A reference to the brainpool curves in TLS RFC in appendix A
would probably be useful.
-
Richard Barnes: Comment [2013-10-23 19:14]:
Like Spencer, I'm confused by the requirement in Section 2 that "the server's
certificate SHOULD contain a suitable ECC public key, SHOULD be signed with a
suitable ECC public key". Section 2.2 of RFC 4492 has the following
requirement for ECDHE_ECDSA ciphersuites: "In ECDHE_ECDSA, the server's
certificate MUST contain an ECDSA-
capable public key and be signed with ECDSA." Isn't that the same as what's
in this document, only stronger?
The Security Considerations refers to "The IV construction in Section 2...",
but Section 2 refers to the "nonce input". Should probably change "IV" to
"nonce" to align with Section 2 and RFC 6655.
-
Benoit Claise: Comment [2013-10-23 07:38]:
Not the expert on that topic. No feedback.
-
Spencer Dawkins: Comment [2013-10-22 10:56]:
This might not even be a comment, but a question. In Section 1. Introduction,
This document describes the use of Advanced Encryption Standard (AES)
[AES] in Counter with CBC-MAC Mode (CCM) [CCM] in several TLS
ciphersuites. AES-CCM provides both authentication and
confidentiality and uses as its only primitive the AES encrypt
operation (the AES decrypt operation is not needed). This makes it
^^^ ^^^ ^^^^^^^ ^^^^^^^^^ ^^ ^^^ ^^^^^^
amenable to compact implementations, which is advantageous in
constrained environments. Of course, adoption outside of constrained
environments is necessary to enable interoperability, such as that
between web clients and embedded servers, or between embedded clients
and web servers.
My first interactive programming language was APL, often described as a
http://en.wikipedia.org/wiki/Write-only_language ("I can write any program in
APL, I just can't read them"), so this made me curious.
I can imagine an implementation for a constrained environment that only
encrypts sensor information, and never receives control information, so doesn't
need to include decryption, but is it obvious to everyone but me how the
encrypted information is used, if there is no defined decrypt operation? Or is
this a missing reference to some other specification that describes what you do
with the authenticated and encrypted zeros and ones? I'm looking at
Implementations of these ciphersuites will interoperate with
[RFC4492], but can be more compact than a full implementation of that
RFC.
in section 2 - is that related? But I'm just guessing.
If this is a stupid question, I apologize for interrupting, of course. Please
carry on.
Also in section 2,
o The server's certificate SHOULD contain a suitable ECC public key,
^^^^^^
SHOULD be signed with a suitable ECC public key, and the elliptic
curve and hash function SHOULD be selected to ensure a uniform
security level; guidance on acceptable choices of hashes and
curves that can be used with each ciphersuite is detailed in
Section 2.2.
I'm not questioning any other SHOULD in the document, but if the server's
certificate doesn't contain a suitable ECC public key, can you still do
something useful?
conflict-review-yokota-mext-ha-init-flow-binding
-
Pete Resnick: Comment [2013-10-23 18:10]:
I am presuming that the IANA allocations (all of which are under "Standards
Action or IESG Approval") are OK. There's no guidance in 6275 as to when these
things ought to be approved, and I assume we're going to see a Management Item
at some point to approve these allocations, but I trust that the INT ADs will
let the rest of us know that these allocations are fine.
conflict-review-dtnrg-ltp-cbhe-registries
conflict-review-turner-additional-methods-4kis
conflict-review-hoffine-already-dotless
-
Ted Lemon: Comment [2013-10-23 19:50]:
Oops, I forgot to clear this discuss after our conversation last time. Sorry
for the delay.
-
Adrian Farrel: Comment [2013-10-07 10:03]:
I would prefer that the ISE could work with the authors so that the point of
concern is added to the text of the document and does not need to be present as
an IESG note. That said, if the authors are unwilling, I would support an IESG
note.
But some typos and clarification might help...
1. Give a reference for the IAB statement.
2. s/the the/the/
3. Give a reference for the IETF consensus on the operation of the
root zone and expected behaviour of resolvers.
4. s/The authors of hoffine-already-dotless-01 do not take/This document does
not state/ 5. s/they are harmful/dotless domains are harmful/ 6. s/should
remove them/should stop publishing them/ (not sure about this change)
-
Martin Stiemerling: Comment [2013-10-09 01:49]:
I don't see the need to add an IESG statement here, but I will trust that the
other DISCUSS positions will be enough to take care of this.
-
Jari Arkko: Comment [2013-10-09 13:26]:
Agree that text in doc is better than IESG note. Assuming the text would be
strong enough. The current IESG note is strong enough.
-
Benoit Claise: Comment [2013-10-10 00:39]:
After a discussion with Joel, I now understand and support his point of view.
Wanted to vote YES, but I'm not sure what it means for a conflict review.
Joel gave me two good arguments why this IESG note is a good thing:
- ccTLD operators (the ones who created the dotless domains) have no
obligations to ICANN. They can do what they want, regardless of the ICANN
guidelines. - As the authors don't state an opinion, this document might be
perceived as: here is a way to "search" dotless domains, have your own opinion
for yourself, we don't state ours. The topic is too important. The IESG should
stress the message: published dotless domains should not be used.
The document already contains:
This document
lists data about dotless TLDs, but does not address the policy and
technology issues other than to point to the statements of others.
...
The Internet Architecture Board (IAB)
issued a statement called "Dotless Domains Considered Harmful"
[IAB-DOTLESS] in July, 2013.
...
This document lists the known dotless domains; it does not express an
opinion whether or not there are security considerations with the
existence of dotless domains.
What the ideal (for me) would be:
1. The authors refers to [SAC053] ICANN Security and Stability Advisory
Committee, “SSAC Report on Dotless Domains”, SAC053. 23 February 2012.
Retrieved from SAC053, and cut and paste the recommendation.
Recommendation: Dotless domains will not be universally reachable and the
SSAC recommends strongly against their use. As a result, the SSAC also
recommends that the use of DNS resource records such as A, AAAA, and MX in
the apex of a Top- Level Domain (TLD) be contractually prohibited where
appropriate and strongly discouraged in all cases.
2. An IESG note expressing that the IESG supports the Recommendation in
[SAC053], and that published dotless domains should be removed.
-
Spencer Dawkins: Comment [2013-10-07 16:14]:
I trust that the right thing will happen, based on discussion so far ...
-
Stewart Bryant: Comment [2013-10-09 04:44]:
This is *not* my area of expertise, but as far as I can see the draft is
factually reporting the existing dotless domains, and describing how to
generate a list of the current set.
I cannot see any harm in reporting the results of a measurement on the
Internet, or a method of generating a list, and thus I cannot see the reason to
include the IESG statement.
-
Sean Turner: Comment [2013-10-10 08:34]:
no note please
conflict-review-gieben-auth-denial-of-existence-dns
conflict-review-jabley-dnsop-anycast-mapping