IESG Narrative Minutes
Narrative Minutes of the IESG Teleconference on 2015-01-08. These are not an official record of the meeting.
Narrative scribe: John Leslie (The scribe was sometimes uncertain who was speaking.)
Corrections from: (none)
1 Administrivia
2. Protocol Actions
2.1 WG Submissions
2.1.1 New Items
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
2.1.2 Returning Items
2.2 Individual Submissions
2.2.1 New Items
Telechat:
2.2.2 Returning Items
2.3 Status Changes
2.3.1 New Items
Telechat:
2.3.2 Returning Items
3. Document Actions
3.1 WG Submissions
3.1.1 New Items
Telechat:
Telechat:
3.1.2 Returning Items
3.2 Individual Submissions Via AD
3.2.1 New Items
Telechat:
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
Telechat:
3.4.2 Returning Items
1221 EST no break
4 Working Group Actions
4.1 WG Creation
4.1.1 Proposed for IETF Review
4.1.2 Proposed for Approval
4.2 WG Rechartering
4.2.1 Under evaluation for IETF Review
Telechat::
4.2.2 Proposed for Approval
5. IAB News We can use
6. Management Issues
Telechat::
Telechat::
Telechat::
Telechat::
Telechat::
Telechat::
7. Agenda Working Group News
Amy: please make your reservations quickly for coming IETF week
1253 EST Adjourned
(at 2015-01-08 07:30:02 PST)
draft-ietf-mile-enum-reference-format
This looks a bit random:
The aggregate classes that constitute ReferenceName:
ID
One. ID. Name of the reference.
I see that it's analogous to similar statements in RFC 5070, but it would be
nice if you wrote it out less tersely. As written it looks like a
mistake--like something got left out when the document was rendered.
In 3 Security Considerations
Producers of IODEF [IODEF] content SHOULD be careful to ensure a
proper mapping of enumeration reference ID elements to the correct
SpecIndex. Potential consequences of not mapping correctly include
inaccurate information references and similar distribution of
misinformation.
I'm not understanding why SHOULD is appropriate. When would a producer not
ensure a proper mapping?
("SHOULD be careful to" seems like "SHOULD" would be appropriate, but I'll
leave that up to you)
I have read and re-read the Abstract, Introduction, and shepherd write-up. I think the Abstract gives the false impression that this extension is not to be used with IODEF v1. I believe it is your intention that this feature should become selectively available in enhanced v1 implementations. The confusion arises because of: While this memo does not update IODEV v1, this enumeration reference format is used in IODEF v2 and is applicable to other formats that support this class of enumeration references. This sounds like, but does not say, the format is not to be used with v1 deployments. (NB "IODEV"???) I think you need: While this memo does not update IODEF v1 because it is not necessary for IODEF v1 implementations to support the enumeration reference format, new or upgraded IODEF v1 implementation may include support for the format. Furthermore, the enumeration reference format is used in IODEF v2 and is applicable to other formats that support this class of enumeration references. This also (I think) helps explain why this is a stand-alone document and not part of the 5070bis document.
These are nits only, feel free to ignore entirely or fix as you prefer. - The write-up says that this updates 5070 but the abstract says it does not. I'm fine either way but it's a little confusing. (That is, I agree with Adrian.) - Maybe expand IDS in abstract - Maybe expand CVE, CCE etc too - "readily apparent" makes me think I'm reading a patent, and thus slightly less happy:-) - I don't know what "trust SHOULD extend" might mean (but it's harmlessly ok I think) - I was surprised you didn't at least include the CVE as an initial registration.
None of these comments are highly important, and none are meant to block the
document. Please consider these and discuss them with me if you think it's
appropriate... but I'll leave it to the authors/shepherd/working group/AD to
decide whether to make any changes. Thanks.
I'm not happy with the 2119 "SHOULD"s in the Security Considerations. None of
them appear to be protocol-related: they're all sound advice, and such advice
should definitely be given, but it would fit better with both 2119 and
reasonable understanding if these were just put in terms of sage advice with
reasons and consequences given (which you are giving; thanks).
In particular, "producers ... SHOULD be careful to ensure ..." is certainly not
in compliance with 2119; I'd say "It is very important that producers of IODEF
[IODEF] content ensure a proper mapping...."
I'm not sure what "SHOULD be preferred" even means, so I think fixing this one
is important. If what you mean is that if <some entity> is receiving
enumeration reference IDs and has a choice between a trusted source and an
untrusted one, it should use the trusted source, then please say it that way,
and don't use passive voice.
Similarly, "trust SHOULD extend from... to...": this would be far better if we
got rid of the passive voice and said that it's highly recommended that
<entity> use third parties for which there is a trust relationship <that meets
these criteria>.
In the IANA Considerations...
I note that you have ABNF grammar to define "abbreviation", and presume that
grammar is for the designated expert's use, and not really aimed at IANA.
That's fine (just see below).
Version: The version of the enumeration (i.e. the referenced
specification) as a free-form string from the printable ASCII
character set excepting white space.
It might be good, I think, to have ABNF here as well, also for the designated
expert... lest some DE in the future wonder which characters are part of "the
printable ASCII character set" and which are "white space".
Thank you for giving good instructions to the DE; that's important.
I would lost the "MUST", and just say that the designated expert will review
any specification that is associated with the request. Again, this isn't a
protocol interop issue, which is what 2119 language is generally for.
opsdir review looked fine
draft-ietf-pce-rfc7150bis
As explained in the write-up: "A diff allows to quickly spot the new text."
A new section called "Differences from RFC 7150", with your text below, and a
table of content to highlight this section is a very good practice IMO.
This document obsoletes RFC 7150 making two changes to that document:
- Clarification that the TLV is available for use in any PCEP object
(existing or future) that supports TLVs.
- The allocation of a different code point for the VENDOR-INFORMATION
object. This change became necessary because of an inadvertant
clash with codepoints used in another Internet-Draft that had been
deployed without IANA allocation. The PCE working group has
conducted a survey of implementations and deployments of RFC 7150
and considers that this change is safe and does not harm early
implementers of RFC 7150.
Thanks for your work on this draft. I see the concern listed in the security considerations section for possible abuse on the size of PCEP messages and this addition helping with more opportunities for bloat. The security considerations section points to authentication and integrity to protect against this, but normally that would be coding practices (limits to size/length of fields, etc.). I noticed the SecDir review had a similar observation. Is there a reason that can't be done? Are there are limits for the defined object type that can help? https://www.ietf.org/mail-archive/web/secdir/current/msg05331.html Thanks, Kathleen
It's a little hard to gather the context here just from reading the document and the shepherd write-up, so apologies if this is an obvious question: is there a plan in place to get the object-class value 32 registered? If not, what is to prevent the same scenario from arising again once 32 is unassigned, other than general knowledge among WG participants that 32 is in use but has not been registered?
draft-ietf-rtgwg-remote-lfa
Stewart and Mike have been diligent in discussing my concerns and
updating the document (specifically the definitions) to produce a
version that lets me clear my Discuss. They also picked up some of my
Comments along the way so I have pruned them from this page. There are
still a number of Comments I'd love them to address, but none of these
is blocking.
===
Although it causes some pain with abbreviations and a little more care
in explanation, you need to put the Introduction as the first section in
the document. The RFC editor will insist on this, so it is better if you
do it now and get the wording exactly how you would like it.
---
You are using RFC 5714 as a Normative Reference by making me go there
for the definition of terms. Please move it to the correct section.
---
IMHO your definition of FIB is rather loose. Fortunately (?) "FIB" is
barely used in this document, so it might not be important, but if you
wanted to fix it:
- you are talking about IP packets in this document
- the actions are, I think, limited to forwarding actions
---
Throughout the text, the terms P-space, Q-space, and extended P-space
are used rather loosely. For example, when discussing Figure 1 you say
"S's extended P-space", but this is really "S's extended P-space with
respect to S-E". Someone familiar with the work might say that it is
obvious from the context that we are discussing the link S-E, and it is,
but the terminology needs to be tight.
---
Section 2
B
has equal-cost paths via B-A-S-E and B-C-D-E and so may go through
S-E.
I don't think B is going anywhere. Maybe...
B
has equal-cost paths to E via B-A-S-E and B-C-D-E and so may reach E
through S-E.
---
Section 2
In MPLS networks the targeted LDP
protocol needed to learn the label binding at the repair tunnel
endpoint is a well understood and widely deployed technology.
But it would still benefit from a citation or a forward reference to
section 7.
---
I enjoyed 3.2
relatively rare as is the incidence of failure in a well managed
network.
So, managing my network well is protection against back-hoes. Nice.
---
In 3.2
Multiple
repairs MAY share a tunnel end point.
1. s/repairs/repair tunnels/
2. s/MAY/may/ since this is not an implementation or operational choice,
but a fact of life.
---
In 4.2 you have truncated...
The repair tunnel endpoint needs to be a node in the network
reachable from S without traversing S-E.
...and...
o The repair tunneled point MUST be reachable from the tunnel source
without traversing the failed link; and
You mean "reachable using the normal FIB", I think.
---
Section 4.3
The preceding text has mostly described the computation of the remote
LFA repair target (PQ) in terms of the intersection of two
reachability graphs computed using SPFs.
"mostly"?
"reachability graphs"? Were they? Or were they reachability sets?
---
Your pseducode in 4.3 invokes an unresolved (and undescribed) function
Compute_Forward_SPF().
Actually, I think this is a bogus line that can be deleted.
---
I think the introduction of "pseudonode" in 4.3 may be a little without
context.
---
Section 7
If for any reason the TLDP session cannot
not be established
s/cannot not/cannot/
---
I think [RFC5424] and [RFC3411] are pretty poor references to give in
section 7. You appear to be saying that an implementation that cannot
establish a TLDP session should write a MIB module, standardise it, and
then report an error.
Can't you find an existing LDP MIB module that reports Session-up
failures?
Or maybe just delete "using any well known mechanism such as Syslog
[RFC5424] or SNMP [RFC3411]."
---
I think you can strengthen the security considerations. You have:
To prevent their use as an attack vector IP repair tunnel endpoints
(where used) SHOULD be assigned from a set of addresses that are not
reachable from outside the routing domain.
1. "To prevent their use" is surely consistent with a "MUST".
The fact that you want to say "SHOULD" means that you need to turn
the text around...
IP repair tunnel endpoints (where used) SHOULD be assigned from a set
of addresses that are not reachable from outside the routing domain.
This would prevent their use as an attack vector.
2. You can add a note about what traffic can be placed into a repair
tunnel. You already have this earlier in the document, and it is
worth restating.
3. I think you should also make note of whether the repair tunnel is
advertised by the routing protocol as an available link.
- 3.2 1st para: I'm sure that IPsec would have downsides (possibly fatal) as a tunneling mechanism, but OTOH, it might also have some benefits if the endpoints are in the same domain but not all non-endpoints traversed by the tunnel are. That's probably too much of a change to include unless you really wanted to, but I thought I'd just ask in case. - 4.3 - this is probably insignificant but is there a potential DoS if I can try force a node to run this (or an equivalent) algorithm frequently? - I agree with Adrian's points about the security considerations. One question on that (I only skimmed this, sorry) - Adrian said: "You can add a note about what traffic can be placed into a repair tunnel. You already have this earlier in the document, and it is worth restating." Which text is that? Is there a requirement somewhere that the new tunnel described here SHOULD have the same security properties as the link(s) for which it's a backup?
Suresh Krishnan made two points in his Gen-ART review that should probably be taken into account.
Throughout the doc there is a word we see. The queen would be so proud of what we write. For we are so amused by this strange use, it is some sixteen times "we" does appear. Perhaps we'd like the passive voice instead.
Thanks for your work on this draft. I support Adrian's comments on additions/changes for the security considerations section and would like to see them added. Additionally, Adrian raised the point of having the introduction first. As someone outside of routing, I think this would make the draft easier to read. The terminology section should state that it is using figure 1 in each of the definitions. When the order is changed so this section follows the introduction, that may be more clear, but a statement to that effect would be helpful IMO.
The title should be changed to "Remote Loop-Free Alternate (LFA) Fast Re-Route (FRR)", but it's not critical to do that now: the RFC Editor will do it if you don't. Otherwise: I found this to be an easy and understandable read. Thanks.
draft-ietf-tls-prohibiting-rc4
Does this document prevent the use of RC4 using an opportunistic security
scheme? It sounds like if I am doing OS (where I *will* back off to cleartext
if TLS fails) and I encounter a peer that only does RC4, then I MUST use
cleartext and MUST NOT use RC4. That seems problematic. I offer the following
possible change:
OLD
o TLS servers MUST NOT select an RC4 cipher suite when a TLS client
sends such a cipher suite in the ClientHello message.
o If the TLS client only offers RC4 cipher suites, the TLS server
MUST terminate the handshake. The TLS server MAY send the
insufficient_security fatal alert in this case.
NEW
o TLS servers MUST NOT select an RC4 cipher suite when a TLS client
sends such a cipher suite in the ClientHello message and another
secure cipher suite is available.
o If the TLS client only offers RC4 cipher suites, the TLS server
MUST terminate the handshake unless the client and server are
negotiating a session using Opportunistic Security [RFC7435]. If
the handshake is terminated, the TLS server MAY send the
insufficient_security fatal alert.
(Note that I'm fine with the "MUST NOT include RC4 for the client". That seems
perfectly justified.)
Thanks for writing this important document. I agree with the action it specifies.
Enthusiastically in support. It was pointed out to me today that some PCI-DSS [1] auditors are still requiring RC4 [2]. Hopefully this document will help fix that situation. [1] http://en.wikipedia.org/wiki/Payment_Card_Industry_Data_Security_Standard [2] http://forums.iis.net/t/1193152.aspx [3] http://www.purehacking.com/blog/gordon-maddern/beast-vs-rc4-ciphers-vs-pci
Thanks for your work on this draft!
I do agree with Pete's question
about time, thanks.
draft-ietf-kitten-cammac
Thanks for your work on this draft. I'd like to see the update Barry requested be added per Ben's response to his comment.
I'd be happier if this document made it clear what, exactly, is being updated in RFC 4120. I gather it's Section 6 of this document that's making the update, assigning an Authorization Data Types value (4120, Section 7.5.4) and a Key Usage Number (4120, Section 7.5.1). Is that correct? Might you change Section 6 to explicitly say that, and refer to the sections in 4120 that are being updated?
I agree with Barry's suggested changes.
draft-ietf-xrblock-rtcp-xr-post-repair-loss-count
Thank you for a nicely written specification.
1. post-repair loss count: 16 bits
Total number of packets finally lost after applying one or more
loss-repair methods, e.g., FEC and/or retransmission, during the
actual sequence number range indicated by begin_seq and end_seq.
This metric MUST NOT count the lost packets for which repair might
still be possible. Note that this metric MUST measure only primary
source RTP packets.
I see the MUST above, and the RECOMMENDED below.
Thus it is RECOMMENDED that this report block should be generated
only for those source packets that have no further chance of being
repaired and not for any other packets. This block needs to specify
its own measurement period to avoid ambiguity in calculating the
post-repair loss count.
I was expecting a MUST instead of RECOMMENDED.
Did the WG discuss that point?
In which situation would you need this exception, and what could you actually
deduce if you apply it?
2. Question:
The relationship
between the metrics in this report block and the pre-repair loss
metric of RTCP XR could be expressed in the following formula:
cumulative number of packets lost = post-repair loss count +
repaired loss count + to be repaired lost packet
"cumulative number of packets lost" is the metric from RTCP SR/RR.
"post-repair loss count" and "repaired loss count" are the metrics
defined in this draft.
Am I correct that it's difficult (if not impossible) to compare those values
with a small granularity because: 1. RFC 3550 section 6.4.1 SR: Sender Report
RTCP Packet sends the "cumulative number of packets lost" with timestamps 2.
draft-ietf-xrblock-rtcp-xr-post-repair-loss-count sends "post-repair loss
count" and "repaired loss count" with sequence numbers. On top of that, the
intervals are different!
- The abstract mentions: This document defines an RTP Control Protocol (RTCP) Extended Report (XR) Block that allows reporting of post-repair loss count metrics for a range of RTP applications. This draft introduces two metrics: post-repair loss count and repaired loss count This is slightly confusing. I believe you want to include the two metrics in the abstract. Alternatively: NEW: This document defines an RTP Control Protocol (RTCP) Extended Report (XR) Block that allows reporting of post-repair loss-related metrics for a range of RTP applications. - In addition, another metric, repaired loss count, is also introduced in this report block for calculating the pre-repair loss count during the this range, the this -> chose one.
fine with this one once benoit's discuss is resolved I hope in favor of being uniformly must.
draft-ietf-ospf-te-metric-extensions
These are mainly nits or questions, other than the first. That would have been a discuss if I knew of a specific threat, but since this is just a general concern, it's not a discuss. I'd appreciate a bit of a chat about it though. - I'd have thought that these TLVs would be sent more often than others, and that (if enormous amounts of money are in play) then use of OSPF authentication might be more likely needed (or some equivalent security mechanisms). I'd even speculate that if enormous amounts of money are in play, then confidentiality may become a requirement (since if I can observe say A bit settings then that might give me insight into traffic levels - sort of a lights burning at night in central bank implies interest-rate change attack). Can you say why none of that needs to be mentioned at all? Was any of that considered by the WG? (Can you send a relevant link to the archive?) - intro: "extremely large amounts of money" aren't usually explicit motivations for protocol features and I hope that that continues to be the case. I'd encourage you to remove that phrase. Similarly, "faster" is a fine requirement but "fast than the competition" is not, so a bit more wordsmithing might be good. (Those are, I think, defensible points as we ought not over-specialise our requirements, but to be honest I'd also be happier if protocol development was not explicitly motivated soley by increasing already-enormous amounts of money.) - intro: saying the "measurement of delay SHOULD NOT vary significantly based upon the offered traffic load" is odd. Clearly the delay experienced can vary based on the load, so I'm not sure what you're saying. And nor is it clear why this is a SHOULD NOT, as opposed to a MUST NOT. Maybe you need to explain that some more? - section 3: Doesn't the A bit definition assume that both senders and receivers know the thresholds (or enough about those). That seems a bit odd to me, but I expect you've thought it through. Same thing with the averaging period I guess (though section 7 does specify a 30s default as a SHOULD). Or am I missing that one could calculate those from the various TLVs that are defined? (I think I'm also not understanding bullet point 4 in section 5 which may be related.) - section 3: I don't get what "cannot be used for fail-over purposes" means. I think you mean "ought not" since a receiver can do what they want in any case. - The security considerations of RFC 3630, from 2003, is 11 lines long. Has nothing affected OSPF security in the last decade+ that would be worth noting here? - In one response to the secdir review, [1] path shortening attacks were mentioned - I'm not clear myself if that's a deal here, but is text on that needed? Some text that was suggested is "users of the lsas described in this document should be aware of how they might be used in path shortening and other routing attacks." [1] https://www.ietf.org/mail-archive/web/secdir/current/msg05354.html
Thank you for doing this work. It is very important and I can clearly see the use cases. I do have some comments though. I think it would be useful to specify explicitly what the IEEE floating point number format variant is being used. I assume binary32. (Also noted in the Gen-ART review.) I am a bit surprised by the A bit design. Would it be useful to add some rationale for why this approach has been taken? As I read the document I find it difficult to understand why the bit carries extra value for the receiver. It does signal an exceptional condition, but at the same time, any real action (e.g., Step B in Section 3) seems to be something that should be based on the calculation of the actual bandwidths and delays rather than the flag itself. Or did I misunderstand this? Also, it would be useful to specify what information must be understood in the network for the A bit usage. Do all nodes have to the same understanding of the threshold throughout the network? Or just the sending node? Finally, I would have preferred to see some defaults for the various configurable values, and some discussion of the requirements for the values. Again, do the measurement period for instance have to be aligned across a network, or not? A section on management considerations might be appropriate.
From an OPS point of view, I'm mainly interested in what is out of scope, as written in the writeup: "There has been much discusson as to how these metrics would be collected and how they will be used. These topics were deemed to to be out of scope". So I'll wait for a companion document. I agree with Alissa and Stephen that the following paragraph is confusing: "While this document does not specify how the performance information should be obtained, the measurement of delay SHOULD NOT vary significantly based upon the offered traffic load. Thus, queuing delays and/or loss SHOULD NOT be included in any dynamic delay measurement."
A couple of minor, non-blocking comments, just looking for a little clarification: -- Section 7 -- I can't imagine that the "SHOULD" in the first paragraph is an appropriate 2119 key word: no one can tell whether or not care was taken, so this can't be a protocol issue. Please just say "Therefore it is important to set these values carefully." For the remaining "SHOULD"s, "SHOULD NOT", and "RECOMMENDED" in this section: remembering that "SHOULD" means that "there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course," how can someone reading this understand and weigh those implications? I can't: I have no idea why these recommendations are being made, and what the implications are of making different choices. Can you help me here? Or are these just recommended values, in the lower-case, plain English sense?
I agree with Stephen that the specified use cases seem to warrant a stronger recommendation to provide authentication and confidentiality. The tools are available, so why are they not being recommended in this instance?
= Section 1 = "While this document does not specify how the performance information should be obtained, the measurement of delay SHOULD NOT vary significantly based upon the offered traffic load. Thus, queuing delays and/or loss SHOULD NOT be included in any dynamic delay measurement." Agree with Stephen's comment here -- this is confusing. I'm not sure normative language makes a whole lot of sense here at all if "the measurement" means "the quantity you actually measure" as opposed to "the quantity that you report after measuring." Also, how would loss be reported in a delay measurement? (I can imagine ways, but they seem contrived.) = Section 4.2.7 = "Implementations MAY also permit the configuration of an offset value (in microseconds) to be added to the measured delay value to advertise operator specific delay constraints." Do I understand correctly that there is no way specified to communicate this offset value? If this is a matter for local configuration, it seems a bit odd to use normative language and describe it in the definition of the sub-TLV. = Section 4.4.5 = "When set to a value of all 1s (2^24 - 1), the link packet loss has not been measured." I noted that in the case of delay, the way to signal that delay has not been measured is to not send or withdraw the sub-TLV, whereas for loss it is to send a specific value. Why do this differently for different measurements? = Section 7 = I agree with Barry's comments here.
draft-dawkins-iesg-one-or-more
I reviewed this and provided feedback during IETF last call (which is, IMHO, correct behaviour for IESG discussion of process RFCs). All of my comments have been accommodated.
A pure nit, that can be entirely ignored: - is "the IESG continues to be responsible for specifying the positions that Nomcom would fill each year" quite correct? I know we discussed before that the IESG's job descriptions aren't quite requirements-to-be-met but rather our idea of what's needed, and that it's up to nomcom to decide if they agree or not. Maybe it'd be better to say the IESG need to tell nomcom what they think is needed each year and avoid any imperatives (in this case "specifying").
This draft is unnecessary process-wonkery. The cited RFCs provide at best an oblique suggestion, rather than clearly normative rules. Certainly nothing as clear as the provision in RFC 3710 that "the IESG can ... change the number of ADs assigned to an area". If we need an RFC for this, we also need an RFC to fix the assertion in RFC 2026 that "RFCs can be obtained from a number of Internet hosts using ... gopher", since AFAICT the RFC editor has dropped support for that protocol.
Thanks for your work on this draft. I have some comments inline to consider: I'm wondering if the word "significantly" can be dropped in the following sentence of the introduction as I didn't think the intent was to increase overall size of the IESG. In particular, this change is not intended to increase the size of the IESG significantly. Just a nit as I was having trouble reading this sentence (first sentence of the last paragraph of section 2) - remove first instance of 'that' and would recommend changing "is" to "remains", change from: Note that the requirement in RFC 3777 ([RFC3777], BCP 10) that the Nominating Committee review (approximately) half the positions for the IESG each year is unchanged. To: Note the requirement in RFC 3777 ([RFC3777], BCP 10) that the Nominating Committee review (approximately) half the positions for the IESG each year remains unchanged.
consensus status should be set to yes.
status-change-rfc20-ascii-format-to-standard
I'm with Joel. More unnecessary process-wonkery.
I don't particularly like that we are using the status change construct to move things that aren't on the Standards Track (which have the appropriate Standards Track boilerplate at the top of the document) to the Standards Track; I think doing so without writing something down about when we think that is appropriate is an accident waiting to happen. I'll probably get more torqued about this when we try to move Informational or Experimental documents to the Standards Track. And I think jumping straight to Internet Standard is fishy. (And I think this is a dubious thing to do in light of RFC 2026 section 7, which, ironically enough, itself references ANSI X3.4-1986). But I think once we do write down such an explanation of when it is appropriate to use the status change tool, we'd find that RFC 20 is the kind of thing that we would want to do that with: It's something that gets referenced from Standards Track documents, if we wrote down RFC 20 today it would be on the Standards Track, and it satisfies all of the requirements for being on the Standards Track. So I'm not going to object. I won't ballot "Yes", because if I were the sponsor of this document, I'd get the explanation of when we should and should not use the status change tool *before* I went on to approve of this document, but I'm not going to stand in the way of this.
There is a pending errata report to clarify that the appendices referred to are from the ANSI doc, not here in RFC 20. There is no value in reissuing this with another RFC number.
I think this is a bad idea and unecessary but I won't belabor the point.
draft-ietf-grow-irr-routing-policy-considerations
I'd like to see some discussion of the points raised by Terry Manderson in his Routing Directorate review during the IETF last call period (circulated on the Grow list at http://www.ietf.org/mail-archive/web/grow/current/msg03015.html). By preference this discussion should be between the authors, WG, and reviewer. But I'd be happy to step in and own the discussions if that will help.
Thanks for this. I learned from reading it and following some links etc. I think other readers will be similarly educated. - I agree with Adrian's request that the routing review be discussed. In particular, wrt the relationship between this work and the RPKI - it'd be good that that be (checked as having been) documented correctly. No disrespect to the authors here, but the RPKI vs. IRR stuff here is not that crisply described - most likely (I'm guessing) because that relationship is just in reality vague. But if I'm recalling correctly some of the very capable authors here aren't the biggest fans of the RPKI so it'd be good for them and this document that their description of RPKI be challenged now a little bit rather than that be done later (if that has not already happened, which may well be the case). - 5.1, I'd be interested in why RFC2725 is now seen as then having been a barrier to deployment and whether or not that is still considered to be the case. Put another way - was the problem the security requirements or the design provided in 2725? (Note, I'm not asking for any change, just wondering.) - section 6 has a "[REF?]" that's presumably an undone TBD
Thanks for writing an interesting document. This reference clearly needs a fix: BGP soft-reconfiguration [REF?]
I see you have some high-level considerations that could encompass the various security properties that would be expected, but would prefer to see them spelled out a bit. For instance, in the first paragraph of the security considerations section: "operators may want to be circumspect about ingesting contents from external parties" Wouldn't you want to see integrity protection so that the operators would have some level of assurance that the source is who they think it is and that the data has not been tampered. This might apply to the described examples where FTP is used to share information. Authentication would be helpful here too. Then, if automation increases, you would also want confidentiality (session encryption for privacy and security reasons). C This this is a summary of current state, this is just a comment. But I would think these properties are used in the current state - at least integrity protection and authentication. (Security's CIA principle) Thanks.
I find some of the writing throughout the document to be a bit hard to get
through -- not to the extent that I think it's a serious problem, but enough so
that I'd say this is making the reader work a bit too hard. Some examples:
While these resources
are generally allocated by hierarchical authorities, a general
mechanism for formally verifying (such as through cryptographic
mechanisms) when parties have been allocated resource remains an open
challenge. We generally define such a system a Resource
Certification System, and we note that some candidate examples of how
such a general system might be implemented and deployed exist[.]
The structure of both of these sentences makes understanding them require a bit
of rewinding and re-parsing, at least for me. Phrases such as "have been
allocated resource" seem odd ("allocated resources" or "allocated a resource"
would seem better). Phrases such as "some examples exist" are straightforward,
but get harder when a long modifying phrase is stuck in before "exist", as
here. This is an example; there are other such bits in the document.
In the end, it's probably fine, though I think it'd be a good idea to alert the
RFC Editor to watch for complicated sentences whose structure makes then a bit
difficult to read smoothly. Below I suggest a few specific sentences that I
hope the authors will re-do themselves, before it goes to the RFC Editor.
-- Section 4.1 --
One of the largest weaknesses often cited with the IRR system is that
the data contained within the IRRs is out of date or lacks integrity.
This is largely attributable to the fact that existing IRR mechanisms
do not provide ways for a relying party to (cryptographically) verify
the validity of an IRR object. That is, there has never existed a
resource certification infrastructure that enables a resource holder
to authorize a particular autonomous system to originate network
layer reachability advertisements for a given IPv4 or IPv6 prefix.
Two questions here:
1. The last sentence is written as a clarification of the one before it ("that
is..."), but seems to veer. Would it perhaps be better to say, "...that
enables a resource holder to verifiably authorize...", or, "...that enables a
resource holder to provide verifiable authorization that a particular
autonomous system may originate..." ?
2. This clearly explains the "lacks integrity" piece, but adding cryptographic
verifiability will not fix out-of-date information, will it? Isn't there also
an issue of keeping the information current in the first place, which is not
mentioned here?
-- Section 4.5 --
Only now is an
experimental test bed that reports to provide this function
I think "purports" is the word you're looking for here.
-- Section 5.2 --
An ISP's customers may not adequately plan for pre-planned
maintenance or, more likely, need to rapidly begin announcing a new
IP prefix as a result of, for example, an emergency turn-up of the
ISP customer's new downstream customer.
I'm having trouble making sense of this sentence. The subject seems to change
throughout the sentence, starting as "an ISP's customers", and shifting to the
ISP later. Can you please re-word this, perhaps splitting it into two
sentences? (It'd also be nice if you'd use "might" to refer to something that
might happen, and save "may" for referring to something that's *allowed* to
happen.)
It is likely that the length of time at which IRRs mirror
changes will have to be dramatically reduced with a corresponding
reduction in time at the ISPs that, in turn, need to evaluate whether
changes in a set of IRR resources need to get reflected in updated
router policies that will get pushed out to ASBR's, connected to
peering circuits, on their network.
I get this one, in the end, but it's also in need of splitting into two, please.
-- Section 6 --
Ultimately, either of the two scenarios above further lengthen the
effective time it would take for changes in IRR resources to take
affect within BGP in the network.
That should be "take effect", not "take affect". And I think the combination
of "effective time" and "take effect" can be confusing, so maybe try some
rewording?
I support Adrian's Discuss on the need to have Terry's review comments
addressed.
I also found this draft a bit hard to read and parse - though not to the extent
of pulling out specific examples, but please do think about Barry's comments as
well.
Although the abstract and intro claim that the draft will provide a discussion
of the existing or remaining concerns, I would STRONGLY (not quite DISCUSS
but...) like them to be pulled out more clearly. Without this, the draft seems
to be more retrospective and rambling than clearly articulating what was a
problem, what changed, and what still remained as a problem.
For instance, from reading the draft, I would say that:
a) Getting fresh IRR data is still a problem. Pull mechanisms use long
intervals based
upon historic problems (see Sec. ...) and push mechanisms are not fully
described.
b) RPKI provides a solution only for verifying route origination but this is
not sufficient
for verifying IRR data because such data also includes asnum, etc.
c) Stale data in IRRs: incentives don't exist for removing stale data and
overriding the
existing data requires work and has the risk of black-holing if the data
wasn't really stale
d) Propogation delay across different ISPs affect how rapidly changes can
occur. e) Configuration based on the new IRR data is less operator-intensive
because of the ability
to use NetConf to deliver the updates, but a lack of vendor-agnostic
models still makes such updates complicated.
f) Router capabilities are rarely a problem anymore. (Incremental updates
of prefix-lists,
more static memory, BGP extensions to push new config in without
traffic-impacting side-effects).
I'm sure I've missed some and maybe gotten a few wrong- but I'd really like to
see some actual takeaways. This currently leaves me feeling like I had a good
dinner conversation chatting about how bad the old times were but without any
action items or guidance for the future to improve.
I think this is a good document to publish. Thanks for the effort. I agree with Adrian that Terry's review comments need to be addressed.
I agree with many of the other ADs' comments on this document.
draft-ietf-httpauth-hoba
(1) It does not seem to me that the mechanism defined in this document actually conforms to the framework for HTTP authentication. The general framework defined in RFC 7235 is all scoped to a resource -- you can implement authorization for a specific resource, without impacting anything else on the server. HOBA, by contrast, requires the authenticating resource to be also be correlated to several resource under .well-known, meaning that it will not be usable in a large number of deployment circumstances. Was this issue discussed in the WG, and was there input from the broader HTTP community? (2) What is your justification for using a SHA-1 based signature in a new protocol, when it is being actively deprecated elsewhere, in particular the web PKI? (3) "RSA modulus lengths of at least 2048 bits SHOULD be used." -> MUST
Given that the size of the header seems to be a concern (since you're not passing the key in the header), why are there no ECC signing algorithms defined? It seems like if you used any of the normal curves, you could comfortably pass the key along with the authentication value. The HOBA-TBS construction seems really unnecessarily complicated. Other than in the "origin" component, there are no ":" characters allowed in any of the components, so if you could remove the unnecessarily pretty serialization of the origin, you could just use ':' as a delimiter. Or leave the origin, and delimit with something like %x20. Either way, this length construction seems like a pain to implement by comparison. "alg = 1*2DIGIT" - In general, it seems unwise to limit code point spaces unnecessarily. In addition to the funny title of Section 6.2.2, the contents seem kind of risible as well. Making a OTP is 100% equivalent to the mechanism recommended in Section 6.2.3, and arguably more likely to deploy (since the OTP doesn't have special semantics of being a URI). Please update the algorithms so that the reader doesn't have to go look up which algorithm this is (PKCS1 vs. PSS). OLD: "RSA is defined in Section 8.2 of [RFC3447]" NEW: "RSA indicates the RSASSA-PKCS1-v1_5 defined in Section 8.2 of [RFC3447]" Given how convoluted the use case is here, an example would be very helpful. At the very least to demonstrate the syntax of the WWW-Authenticate header.
Yay HOBA! Very good that we are finally doing this thing. Totally nitty things here. Barry covered anything substantive that I found: - Use of the word "we" always makes me gag in IETF documents. Blech. For example, in 1.2 (2 times): OLD We use this term when describing something that is NEW This term is used when describing something that is Passive voice is under-rated for some things. There are 9 other uses of "we" throughout the doc. We would be happy if we changed them. - The last paragraph of section 2 is (a) ungrammatical and (b) seems more like it belongs in section 1. - Grammatical 2119 fussiness: OLD UAs MAY optimise their use of challenges by pre-fetching a challenge NEW To optimise their use of challenges, UAs MAY pre-fetch a challenge
One small point left: -- Section 8.2 -- I don't think you need to say "a la LinkedIn," and I think it's a bad idea to have us link a company's name to a password compromise forever in an RFC. Especially when it's not necessary.
This document would benefit from some section somewhere giving a set of clear,
numbered steps, saying who sends, who receives, and who does what with what
input at each step. I will propose such text.
Minor editorial nit: you use "a HOBA" fairly consistently, but "an HOBA"
appears twice. Oughta fix.
The abstract appears to overstate the password issue. It'd be better for the
abstract to say that it eliminates the transmission of passwords and their
storage on the server, which are really the points. The introduction might
expand on that a little, noting that passwords might still be used in the user
interfaces, but they would be exclusively client-side things, never transmitted
and never seen by servers.
-- Section 2 --
The definition of "alg" says "the encoding of RSA-SHA256 is 0x30," but the ABNF
above says "alg = 1*2DIGIT", which implies "30", not "0x30". As I look at
Section 9.3, I think I see the problem and my confusion. I don't think you
want "a single octet" here (otherwise, how would you encode 12 or 99? Don't
you really want something like this?:
OLD
o alg: specifies the signature algorithm being used encoded as a
single octet as defined in Section 9.3. RSA-SHA256 MUST be
supported, RSA-SHA1 MAY be supported. The IANA registered
algorithm values are encoded as ASCII numbers; for example, the
encoding of RSA-SHA256 is 0x30.
NEW
o alg: specifies the signature algorithm being used. RSA-SHA256
MUST be supported, RSA-SHA1 MAY be supported. The IANA
registered algorithm values (see Section 9.3) are encoded as one-
or two-digit ASCII numbers. For example, RSA-SHA256 (number
0) is encoded as the ASCII character "0" (0x30), while a future
algorithm registered as number 17 would be encoded as the
ASCII characters "17" (0x3137).
END
-- Section 3 --
The "realm" attribute MUST NOT appear more than once.
Does that mean that "challenge" and max-age can appear more than once? If not,
why call it out for "realm" and not for the others?
It might be good if the description of "max-age" made it clear that it's for
the purpose of allowing multiple uses (multiple sigs). As it is, it looks like
it's there to limit the delay before the challenge is answered (once). Maybe
just a forward ref to Section 8 is good enough here.
-- Section 4 --
The second paragraph starts by saying that localStorage is required, and gives
a reference. It ends by saying that localStorage is not required, because
IndexedDB works too, and it gives a reference. That's not a disaster, but it's
sloppy, and it'd be better to say it all up front. It also makes me wonder
whether the security considerations about attacks on localStorage do or don't
also apply to IndexedDB.
Another very minor point: I would avoid using "a hassle for users" in an
international document that non-native speakers are expected to understand.
"Difficult for users" seems just as good and more understandable to all.
Does the server really use session cookies to navigate around a site? Or does
the server give the client a session cookie for the client to use to navigate?
-- Section 6.2 --
It seems odd to put the NOT RECOMMENDED mechanism in the middle; I suggest
switching sections 6.2.2 and 6.2.3.
-- Section 8 --
The first paragraph doesn't say enough to make sense to me. Perhaps a few more
words about why?
-- Section 8.3 --
The chances that a typical user (consider my mother) will know or care about
this, much less will "request" anything is vanishingly small. Can you say
anything here about what can be done that would have any practical utility?
-- Section 9.3 --
Please create a new HOBA signature algorithms registry as follows,
with the specification required rule for updates. New HOBA signature
algorithms SHOULD be in use with other IETF standards track protocols
before being added to this registry.
I don't think the SHOULD is really right -- who is the target? This needs to
be cast as instructions to the designated expert, perhaps as, "The designated
expert will review other uses of requested new HOBA signature algorithms, with
particular consideration to their use in other IETF standards track protocols."
Perhaps there's also another word or two to say about what the DE should
consider?
-- Sections 9.4 and 9.5 --
Might there be any advice for the designated expert, anything at all?
Agree with Barry
Good stuff! Couple of comments.
= Logging out =
The intro says
"Logout features can be useful for UAs, so HOBA defines a way to
close a current HTTP "session", and also a way to close all
current sessions, even if more than one session is currently
active from different UAs for the same account."
But the method specified in 6.3 seems to only accomplish the first of these
(assuming the recommendation about server deletion of cookies related to "the
session" is meant to be specific to one session). What is the method for
logging out of all sessions associated with different UAs for the same account?
= Section 6.1 =
Either the device identifier/device identifier type bits are underspecified, or
it's not clear to me how they are meant to be used. What other device
identifier types are expected to be used in the future, such that a registry of
them is necessary? To me it seems like you would want UAs/users to take some
care with the precision of the device identifiers shared with servers -- e.g.,
"Alissa's laptop" seems like it could be useful and fairly safe, whereas "IMEI
013584009812219" seems like total overkill and a bad idea. (As an aside, it
might be good to provide some guidance about this in the document.) The
creation of the registry makes me wonder if more structured device identifiers
of the IMEI-ilk are envisioned, and if so what the purpose of them is expected
to be?
Also, I would suggest
s/if absent then the "string" form of device identifier MUST be used./if absent
then the "string" form of device identifier defined in Section 9.5 MUST be used.
= Section 8 =
"Binding my CPK with someone else's account would be fun and
profitable so SHOULD be appropriately hard."
Sarcasm translates pretty poorly across cultures. I would suggest saying what
you actually mean here.
= Section 8.2 =
If you want to leave in the LinkedIn reference, or any specific example, it
needs a citation.
satisfied with the rersults from david black's opsdir review.
draft-higgs-hbbtv-urn
I may have misunderstood John Klensin's point, but I thought he was saying that at some point we ought to be asking for reviews on the URNbis mailing list because we might get something useful back, and that he didn't think it was important to start that habit with this document. I agree that there's no reason to hold this document up while we decide whether or not we want to start asking for reviews of documents like this one.
I do not agree that there are no new security considerations here. This is a case where we are enabling better Internet access from, and importantly also to, devices that have traditionally not been on the net. There are many cases where the implementation of such devices are not sufficiently robust to withstand the threats that are seen on the Internet. And there have been cases already where browsers built in to TV sets have been found to not even honor the SOP. I would therefore encourage the authors to include a note about that, ideally with some reference to material that would help relevant device developers to do a good job on security. (This is not a DISCUSS as I think the probability of such new text being useful is probably too small to insist, but who knows it might help so would be good to include.) I fully agree that holding this up for some urnbis work would not be justified.
I agree with Stephen's comment and would also like to see some text added around those points in the Security Considerations section.
John Klensin has raised an issue that this should be held up until the urnbis working group has finished its work on updating the URN namespace registration documents. I don't agree: I think we need to proceed with namespace requests as we have done, and have any new mechanisms take effect only when the documents defining them are complete and approved.
I went to look at the URN-NID discussion of this draft and found a short thread [1]. It doesn’t seem like Ted’s question about structure was ever really addressed. I looked back at a couple of other recent NID registrations [2] [3] and they both provide more information about the URN structure than the HbbTV document does. But perhaps the authors of the HbbTV doc were using a different document as an example, e.g., RFC 5328 [4]. It’s unclear to me whether in general we should be preferring the approach taken in [2] and [3] or the approach taken in [4], and since the HbbTV authors didn’t answer that part of Ted’s question I don’t know if they favor the [4] approach or just missed it. I bring this up on this thread because if we’re going to say the URN-NID list provides sufficient review, at least the reviews that appear there should have full responses. Not clear to me whether that occurred in this case or not. [1] http://www.ietf.org/mail-archive/web/urn-nid/current/msg01276.html [2] http://tools.ietf.org/html/draft-murdock-nato-nid-03 [3] http://tools.ietf.org/html/draft-ietf-salud-alert-info-urns-14 [4] http://tools.ietf.org/html/rfc5328
from suzanne wolf opsdir review Hello, I have reviewed this document as part of the Operational directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the operational area directors. Document editors and WG chairs should treat these comments just like any other last call comments. Assessment: this looks ready to go, with one suggestion, below. The text, and the datatracker history, suggest this is a straightforward registration of what's largely a proprietary namespace, in support of interoperability among HBBTV participants and the larger internet. From a quick reading of RFC 3406, I think this looks completely consistent with the purpose of the registry. From an ops perspective, imagining I might see an hbbtv URN in the wild, I think the draft answers the key questions I'd have, namely whether this URN space is published and reserved, format rules, and where to go for more information about how to validate or use such URNs. The only gap I can see against the RFC 3406 criteria is in the "Community Considerations" section, which RFC 3406 suggests should describe whether the registry is open or closed. The document is clear that the HBBTV Association is the registration authority, but doesn't say whether only HBBTV members can participate in developing/publishing specifications that define entries in this registry, or there's a process for non-members to do so, i.e. that these URNs could be legitimately in use outside of the HBBTV Association's specifications. It's implied elsewhere that these URNs will be included only in specifications developed within the HBBTV association, but as a possibly-curious operator of internet services, I'd appreciate a sentence or two more about how open the process might be. The requested registry entry just seems to be the open documentation that this namespace exists and where to go to find out more about how particular URNs in it might be used. This promotes interoperability and should make operators' lives slightly easier for being available. thanks, Suzanne
conflict-review-kucherawy-dmarc-base
This document has been discussed on the DMARC WG mailing list. Several comments have been sent, leading to updates to the document, but nobody has expressed any concern about a conflict between this work and the work of the WG. Indeed, this document's publication as an Independent Submission is anticipated in the WG charter and will provide a basis for some of the work to be undertaken. This document does introduce some new IANA registries with Designated Experts, and the appointment of the DEs will fall to the IESG, but we've done this in the past. I see no conflicts.
I offer a couple of comments that I hope the ISE and authors might find useful. Other than these couple of things, this is a fine document. And even with this issues, I don't think there is any conflict with publishing this. - 2.3 says: "Although DMARC does not introduce third parties to the email handling flow, it also does not preclude them. Third parties are free to provide services in conjunction with DMARC." Given the fiasco with mailing lists, I think that the text is not factually correct. - 9.5 I expected this to be much more prominent. I think it'd be useful were that the case as folks may first hear about dmarc because of the list breakage thing and only telling them about that on p41, and then without very much text at all isn't great. For example while rfc6377 does explain how adsp discardable can get you bounced from a list, I think this draft should also, at the very least via a direct reference to that section of 6377. I can understand that it isn’t easy to know what to say about that, but the text describing that ought not be sort of in an implicit out of the way corner as is currently the case;-)
It seems pretty obvious to me that this work should have gone through the WG.
Adding to Pete's comment: not only is it OK in this case for an ISE document to ask the IESG to appoint DEs, but it's in fact necessary to the work in the DMARC working group.