Narrative Minutes of the IESG Teleconference on 2009-10-08. These are not an official record of the meeting.
Narrative scribe: John Leslie (The scribe was sometimes uncertain who was speaking.)
Corrections from:
1 Administrivia
2 Protocol Actions
2.1 WG Submissions
2.1.1 New Item
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
2.1.2 Returning Item
2.2 Individual Submissions
2.2.1 New Item
2.2.2 Returning Item
3. Document Actions
3.1 WG Submissions
3.1.1 New Item
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
3.1.2 Returning Item
3.2 Individual Submissions Via AD
3.2.1 New Item
Telechat:
Telechat:
3.2.2 Returning Item
3.3 Independent Submissions Via RFC Editor
3.3.1 New Item
Telechat:
3.3.2 Returning Item
Telechat:
Telechat:
1423 EDT break scheduled
Russ: no break
4 Working Group Actions
4.1 WG Creation
4.1.1 Proposed for IETF Review
Telechat:
4.1.2 Proposed for Approval
Telechat:
4.2 WG Rechartering
4.2.1 Under evaluation for IETF Review
4.2.2 Proposed for Approval
Telechat:
Telechat:
5. IAB News We can use
6. Management Issues
Telechat:
Telechat:
Telechat:
Telechat:
7. Agenda Working Group News
1406 EDT Adjourned
draft-ietf-tcpm-tcpsecure
I don't think that UPDATES is required because an implementer can produce a perfectly compliant implementation without ever reading this document.
This document is well written and clearly explains, without needing to flip back
to RFC 793 and other docs, the attacks and the mitigations.
Whether or not this document updates RFC 793 depends, in my mind, on the meaning
of SHOULD in text like this snippet from section 4.2:
Instead, the handling of the SYN in the synchronized state SHOULD be
performed as follows:
1) If the SYN bit is set, irrespective of the sequence number, TCP
MUST send an ACK (also referred to as challenge ACK) to the remote
peer:
<SEQ=SND.NXT><ACK=RCV.NXT><CTL=ACK>
After sending the acknowledgment, TCP MUST drop the unacceptable
segment and stop processing further.
Does the SHOULD imply a change in TCP as defined by RFC 793 or does it apply in
the sense of "if the stack implemements the mitigations described in this
document, the handling of SYN ..."
I infer from this text in the "Applicability Statement" (section 1.1), that RFC
2119 text is all conditional on "if the stack implements these mitigations":
The mitigations suggested in this draft
SHOULD be implemented in devices that regularly need to maintain TCP
connections of the kind most vulnerable to the attacks described in
this document.
While this may seem like an editorial nit, I think the doc would be clarified
and the issue of updating RFC 793 resolved with an explicit statement about the
RFC 2119 text in the Terminology section.
---
In section 5.1, what is the "ACK
value of [a] data segment"?
---
This text at the beginning of section 5.2
doesn't seem to appear anywhere in sections 3 or 4:
5.2. Mitigation
All TCP stacks MAY implement the following mitigation.
Is there something different about the mitigation in section 5 that is different
from the other mitigations?
I see section 6 clarifies the issue I was getting at:
6. Suggested Mitigation strengths
As described in the above sections, recommendation levels for RST,
SYN and DATA are tagged as SHOULD, SHOULD and MAY respectively.
At the risk of fussiness over an editorial nit, I suggest a clear sentence at
the beginning of sections 3.2 and 4.2 like the one in section 5.2 explicitly
describing the recommendation levels for those mitigations.
[I am adding this so we don't forget to discuss it - Lars]
This document has:
"Updates: 793 (if approved)"
There was a lot of discussion about this in the WG. The authors want
it in, because they want implementors of 793 to also look at this document.
The arguments against having this in the header relate to the fact
that currently only one RFC has "Updates: 793" in its header: RFC 3168,
"The Addition of Explicit Congestion Notification (ECN) to IP". In
addition, this is an optional RFC, this is not a new requirement for
RFC 793/1122 implementations. You may see the discussion in the
TCPM mailing list, with the subject:
[tcpm] another review of draft-ietf-tcpm-tcpsecure[-10]
As a WG chair, on the mailing list I stated:
Wes and I discussed this, and we agree with Lars. "Updates" is
generally for things that are now required if you implement the
cited spec. Tcpsecure doesn't fit that criteria, so the "Updates 793"
doesn't belong on this document. As Lars said, this is less than
perfect, but it is what we currently have.
The larger issue is what does "Updates:" mean in an RFC, and what
should be the criteria for making that decision? We (the WG chairs)
felt that we were getting into a discussion that was well outside
of the scope of the TCPM WG.
So, we would like the IESG to voice an opinion on whether or not
it would be appropriate to add "Updates: 793" to this document. If
the answer is yes, then there are other draft documents in the works
that this would probably affect.
I have a question about the applicability of this that I'd like to understand
the answer to before trying to answer the "updates" question Lars raised.
Imagine we have a client C, talking from the "inside" of a firewall that tracks
TCP state, to a server S on the "outside" of the firewall. If C sends a RST, the
firewall forwards it and clears state, but when the RST arrives at S. The reset
seq # is within the window but not exact. S sends and ACK, but (this is my
question), will the firewall forward the ACK to C or just silently drop it?
I know some firewalls might have the timers to forward traffic for some time
after the RST but do they all and is it long enough? Is there something I am
just not understanding here that would cause this to work? I'm worried that
servers with lots of clients connecting to them not being able to recover TCP
connection in a timely matter might cause more harm that attacks that tear down
TCP connections.
This is a Discuss because I want to talk to the IESG & authors about it before
deciding an opinion on this draft.
Thanks, Cullen
draft-ietf-mboned-lightweight-igmpv3-mldv2
Technical Summary
This document describes lightweight IGMPv3 and MLDv2 protocols (LW-
IGMPv3 and LW-MLDv2), which simplify the standard (full) versions of
IGMPv3 and MLDv2. The interoperability with the full versions and
the previous versions of IGMP and MLD is also taken into account.
Working Group Summary
This draft has received strong support within the working group and
no major controversies were noted.
Document Quality
Multiple implementations of this specification exist. A number of
other vendors have indicated interest/plans to support this
specification. Bharat Joshi provided the most extensive comments
and questions for the document. Authors addressed the questions and
concerns in the document. Otherwise, mailing list traffic regarding
this specification has been minimal. There has been extensive
comments on this proposal during the working group meetings.
Personnel
Lenny Giuliano is the Document Shepherd, Ron Bonica is the
Responsible Area Director.
From the second para of the Introduction: INCLUDE and EXCLUDE filter-modes are introduced to support the source filtering function. "are introduced" by IGMPv3 and/or MLDv2, or ???
Why is this a BCP and not PS?
Section 1., paragraph 5:
> Since LW-IGMPv3 and LW-MLDv2 are fully compatible with the full
> version of these protocols (i.e., the standard IGMPv3 and MLDv2),
> hosts or routers that have implemented the full version do not need
> to implement or modify anything to cooperate with LW-IGMPv3/LW-MLDv2
> hosts or routers.
DISCUSS: They may not need to implement anything, but if they send an
EXCLUDE to a lightweight peer they better be prepared for it to be
ignored. On the call, I'd like to discuss how that affects
interoperability. Is this something that's permitted in the full version?
The Gen-ART Review by Brian Carpenter on 2009-09-01 raises a question about this text: > 1. Introduction ... > Since LW-IGMPv3 and LW-MLDv2 are fully compatible with the full > version of these protocols (i.e., the standard IGMPv3 and MLDv2), > hosts or routers that have implemented the full version do not need > to implement or modify anything to cooperate with LW-IGMPv3/LW-MLDv2 > hosts or routers. I assume this also means that LW-IGMPv3 and LW-MLDv2 are strict subsets of IGMPv3 and MLDv2. If so, it would be useful to say so explicitly.
A document that creates a subset profile of a protocol should not be a BCP.
This should be PS instead of BCP.
This is slightly more than a simple profiling of the parameters of another
protocol - there appears to be additional logic that an implementation will have
to perform correctly. It also doesn't appear to be recommending "full and
immediate instantiation". Rather, it seems to be a good candidate for the normal
PS->DS->S progression.
draft-ietf-ipsecme-ikev2-resumption
This is a well written specification and I was about to vote Yes on it.
However, I thought I saw a few small errors and I wanted to talk to you
to see if we can determine if these really are errors and whether we
need to correct them.
1. The document says:
> Specifically, the SK_xx values are required to
> protect the IKE_AUTH payloads.
At this point in the text, SK_xx has not been defined (I suppose you mean
"any shared key values established by IKEv2"), or even any specific
SK value mentioned. This came out of the blue for me at least. Please
clarify what you meant.
Also,
> AUTH = prf(SK_px, <message octets>)
>
> Each of the initiator and responder uses its own SK_p value, taken
> from the newly generated IKE SA, Section 5.1.
SK_px does not appear in the document, what is it? Neither SK_px or
SK_xx have been used in RFC 4306 either. What about SK_p, do you mean
SK_pr and SK_pi? Again, please be specific in what you actually mean.
Listing which SK values you actually mean here along with their
references might be helpful.
2. The document says:
> When passing a ticket by value to the client, the ticket content MUST
> be integrity protected and encrypted.
>
> A ticket by reference does not need to be encrypted, as it does not
> contain any sensitive material, such as keying material
There are multiple levels of crypto here, perhaps you want to be more
explicit here. You mean that the encryption above is for the ticket
content, but for sure the IKE exchange where you receive the ticket
has to be encrypted, because otherwise it would be easier to
open up a DoS attack where you can create half-ready resumption IKE
SAs if you saw a ticket fly by. The document did say this earlier:
Although the IKE SA is not fully valid until the completion of the
IKE_AUTH exchange, the peers must create much of the SA state
(Section 5) now. Specifically, the SK_xx values are required to
protect the IKE_AUTH payloads.
3. The document says:
> A man-in-the-middle may try to eavesdrop on an exchange to obtain a
> ticket by value and use it to establish a session with the IKEv2
> responder. Since all exchanges where the client obtains a ticket are
> encrypted, this is only possible by listening in on a client's use of
> the ticket to resume a session. However, since the ticket's contents
> are encrypted and the attacker does not know the corresponding secret
> key, a stolen ticket cannot be used by an attacker to successfully
> resume a session. An IKEv2 responder MUST use strong encryption and
> integrity protection of the ticket to prevent an attacker from
> obtaining the ticket's contents, e.g., by using a brute force attack.
>
> A ticket by reference does not need to be encrypted. When an
> adversary is able to eavesdrop on a resumption attempt, as described
> in the previous paragraph, then the ticket by reference may be
> obtained. A ticket by reference cannot be used by an attacker to
> successfully resume a session, for the same reasons as for a ticket
> by value. Moreover, the adversary MUST NOT be able to resolve the
> ticket via the reference, i.e., access control MUST be enforced to
> ensure disclosure only to authorized entities.
This text does not explain the issue that I brought up in item 3.
I would like to see that the half-created state problem is mentioned
in the security considerations text.
Well-written and understandable doc. I have one small editorial comment:
From section 5:
Note 1: The authenticated peer identity used for policy lookups may
not be the same as the IDi payload (see Sec. 3.5 of
[RFC4718]), and if so, MUST be included in the ticket. Note
that the client may not have access to this value.
What is the condition to be checked by "if so" and what is to be included based
on that condition? It would be clearer to include text that explicitly
describes the condition and what is to be included.
INTRODUCTION, paragraph 13: > Abstract Is long, and overlaps with the introduction a lot.
I'm assuming that the malicious corrpution or deletion of stored tickets has only a small disruptive affect on session recovery. That is, an attempt will be made to recover the ticket before dropping abck to the current processing rules (pre-this-draft). --- The use of ! rather than | in protocol object figures is unusual, but not illegal. --- Section 7 identifies the different notification messages by "notification numbers" but the subsequent subsections (7.1 etc.) use the term "Notify Message Type". According to the IANA section and the registry, the latter term is correct.
This is a useful document. Some minor comments/questions below: 4.3.1. Prologue Tickets are intended for one-time use, i.e. a client MUST NOT reuse a ticket. A reused ticket SHOULD be rejected by a gateway. Note that a ticket is considered as used only when an IKE SA has been established successfully with it. Isn't this a recipe for DoS attacks? 7.1. TICKET_LT_OPAQUE Notify Payload The data for the TICKET_LT_OPAQUE Notify payload consists of the Notify message header, a Lifetime field and the ticket itself. The four octet Lifetime field contains a relative time value, the number of seconds until the ticket expires (encoded as an unsigned integer). I suggest saying that the Lifetime is encoded in network byte order.
This is a good document, and I support its publication. There is one issue that
I would
suggest addressing - probably in the security considerations - before
publication, though.
When an IKEv2 responder decides to provide a ticket for session resumption to an
IKEv2
initiator, they are implicitly trusting the initiator to manage this
ticket to ensure that new
sessions are not created for a different user.
Specifically, Section 6.2 states that "when
credentials associated with the IKE
SA are invalidated (e.g. when a user logs out), the ticket
MUST be deleted."
This requirement can only be enforced by the responder, so a rogue
IKEv2
responder could misuse the ticket without user knowledge.
It seems the IKEv2 responder is extending greater trust to the initiator when
providing
a ticket than when they accept the initial connection. I have no
problem with that, but
suspect it should be highlighted somewhere.
Michael Sneed notes in his OPS-DIR review the following: Section 9.1 of the "Security Considerations" could use some clarification: the inability of an attacker to use a stolen unencrypted "ticket by reference" is explained as "for the same reasons as for a ticket by value", but for a "ticket by value" the explanation is that the ticket is encrypted.
draft-ietf-pmol-sip-perf-metrics
I would like to talk about the competitive or anti-competitive nature of metrics
as well as the meaning of putting these on the Standards Track.
In the Abstract the draft says:
"The purpose of
this document is to combine a standard set of common metrics,
allowing interoperable performance measurements, easing the
comparison of industry implementations."
Later on the draft also says
"These metrics will likely be utilized in
production SIP environments for providing input regarding Key
Performance Indicators (KPI) and Service Level Agreement (SLA)
indications; however, they may also be used for testing end-to-end
SIP-based service environments.
First, note that this draft by itself does not allow interoperability unless
there's a standard performance monitoring protocol to transport the standardized
metrics. By itself, this draft allows comparison.
Second, comparing industry implementations on this basis is not necessarily the
best way to compare. We don't even know if it's a good way to compare. Which
metrics are most important to user experience? Aren't there some thresholds on
some measures which are "good enough" and improving beyond those thresholds
offers no noticeable improvement?
I don't see how we have enough confidence to call this a Proposed Standard at
this point; Informational would make much more sense to me -- I would read that
as "here is a set of metrics defined a certain way, and the definitions are for
your information if you choose to use the same metrics."
What is the likely harm of implementations optimizing for these metrics instead
of for a more holistic user experience?
Section 12.1., paragraph 3:
> [GR-512] Telcordia, "LSSGR: Reliability, Section 12", GR-512-
> CORE Issue 2, January 1998.
DISCUSS: Is this a standard by another SDO? (In any event, I believe
it can be made in Informative reference, because it simply points to
the source from where a metric/test was borrowed.)
On some of these, it seems like there were multiple metrics that ended up with
same name but were actually different - for example, SRD in the failure case and
SRD in the success case.
Several metrics seem like they would be messed up by HERFP and forking. By
messed up I mean not useful for anything. In general I think on all the metrics
I would have liked to have a better idea of how they can be used not just
collected.
As far as I understand 4.4.2, it measures timer F which is compiled into the
code so seems pretty useless to measure.
In the second example in 4.4.2, when UA2 sends a BYE, UA2 is the UAC not the
UAS.
SDT seems undefined when answer sends the BYE. Need to consider things like Bye
ALSO, reinvites, REFERS and more.
HpR. I don't think this approach has worked out well on operational networks. I
see more people doing VIA counting at the UAS. One of the many problems with the
approach is, well you have to be at both ends, and if the UAC starts with say 30
(fairly common) and then some B2BUA in the middle resets to 70 (insane but
common and what a strict read of 3261 might say you SHOULD do) you are going to
probably end up with a negative hop count.
SER. This looks very wrong. On a interface where all invites are challenged
(very common for anything offering long distance) this is going to be under 50%.
SEER - the way this is defined you end up with a divide by zero on interfaces
that are redirecting.
SDF - I really have no idea how to implement this in an way that gets consistent
numbers. It not clear what I look for in the Reason to decide I increment the
SDF counter or not.
SCR - I did not understand why this one needed a proxy. I suspect I don't
understand what is being counted.
The SSR does not seem right. If you had lots of 503s, it seems like the the SSR
could go negative.
Section 6.3. totally agree forking SHOULD be considered. In fact I think forking
MUST be considered but we the spec needs to help the implementors know what to
do. Take for example a case where an invite forks to 3 phones that all start
ringing then one of the is answered. From a dialog point of view, 1/3 of the
dialogs worked and the others failed to have a call. From a user point of view
the call was a success. Treating this like a transit ISDN network is not going
to get the metrics that are useful for a SLA.
Overall, I think that if we backed up to the 10,000 foot level and asked what
problem are we going to solve with metrics and what metrics do we need, it would
be much clearer how to evaluate if these metrics worked or not.
Meta Comment: We are still in the experimentation mode of how to bring together the operational and metrics experience of the OPS area with the SIP expertise of the RAI area. I think the ADs have some work to do to see if what improvements can be made
I support Lisa's and Robert's discusses... I believe that publication as Informational would be a reasonable path forward, especially if supported by additional text describing the scope and origins of the metrics.
I have several concerns with this document that are captured in the message went
to the PMOL list at
<http://www.ietf.org/mail-
archive/web/pmol/current/msg00206.html>
draft-ietf-dime-diameter-cmd-iana
ABSTRACT: > The Diameter Base specification, described in RFC 3588, provides a > number of ways to extend Diameter, with new Diameter commands, i.e. ... > This document aligns the extensibility rules of Diameter application > with the Diameter commands offering ways to delegate work on Diameter > to other SDOs to extend Diameter in a way that does not lead to poor > design choices. The first paragraph is unusual for an abstract (and it's repeated in the introduction), and the second paragraph needs to say that this updates RFC3588. Section 4., paragraph 1: > This section describes changes to the IANA consideration sections > outlined in RFC 3588 regarding the allocation of Command Codes by > IANA. And I'm guessing you want to instruct IANA to start applying these as soon as this document is approved?
Currently, Section 3 seems to say that IETF produces better quality specifications than other organizations, and others are more likely to screw up security. I find this a bit negative and arrogant -- when defining a new Diameter application for a system developed in some other organization FOO, I think it's much more likely that FOO understands their system, and its security requirements, better than IETF does.
In the Gen-ART Review by Scott Brim on 2009-09-21: Not a big issue but: if you do revise it, consider putting in a little more about the motivation. Without naming names, what were the "questionable design decisions" and why were they an issue?
Like Pasi, I would favor rewording the Security Considerations section. Carl Wallace had some editorial suggestions in his secdir review: - The first sentence of the abstract (and introduction) is difficult to parse. - In the Introduction, change "the conditions, which" to "the conditions that" and change "were causes" to "were caused". - The document states that it "aligns the extensibility rules for Diameter command codes with those defined for Diameter application identifiers". Since the values are not aligned and there's no mention of "extensibility rules" elsewhere in this document nor in 3588, I suggest something like: "This document changes the allocation rules for Diameter command codes to support usage of vendor specific command codes, similar to the allocation of vendor specific application identifiers."
draft-ietf-yam-rfc1652bis-pre-evaluation
Agree with Adrian. This seems more like a communication with the IESG than
something that needs to be store in the RFC series for perpetuity.
One additional item for our discussion of this doc - procedurally, how will we prepare an IESG response? Do we need to respond to the yam WG uncontionally or only if we think RFC 1652 will not be advanced according to the criteria set out in this doc or otherwise; e.g., Lisa's concern about security?
One of the big questions discussed about whether older email standards could go
to Full Standard was whether the security provisions were sufficient -- whether
authentication and privacy met our modern requirements, or if not, whether Full
Standard was acceptable anyway because of historical considerations.
If that is in fact going to be an issue, then this pre-eval document doesn't
address that or or make the IESG think about that. Future pre-eval documents,
if we stick with this WG model, could reasonably compare the standard's security
to modern requirements. This DISCUSS position is so that we can talk about
these issues on the call.
My "No Objection" vote means the following answers to the questions in Section 3: Yes, I think the proposed changes are suitable. No, I don't think any other changes are necessary. Yes, I consider the downward references acceptable. However, the eventual advancement of RFC 1652 to Full Standard will naturally go through IETF Last Call (this draft did not go through IETF Last Call), where the community has an opportunity to provide more input. My "No Objection" vote here is not a guarantee that I can't change my mind after considering the community input.
This seems like a really weird way to communicate with the IESG, and
I assume we are not supposed to evaluate the draft for publication
as an RFC as I see...
Abstract
THIS INTERNET DRAFT IS WRITTEN TO FACILITATE PROCESSING WITHIN THE
IESG. IT IS NOT MEANT TO BE PUBLISHED AS AN RFC.
1.1. Note to RFC Editor
This Internet-Draft is not meant to be published as an RFC. It is
written to facilitate processing within the IESG.
I think it a shame that community resource has been burnt (e.g. SecDir
review) evaluating this document as a potential RFC.
---
In answer to the questions in Section 3
o Does the IESG believe the proposed changes are suitable during a
move from Draft to Full Standard?
Yes
o Does the IESG believe any other proposed changes are necessary to
satisfy IESG requirements to advance to Full Standard?
I believe that the it is necessary to satisfy any requirements that
arise from community evaluation of the protocol and from the
implementation reports.
o Does the IESG consider the downward references acceptable for a
Full Standard?
I would prefer that we moved the entire collection forward together,
but would tolerate the downrefs if the community approves them.
----
What about draft-dusseault-impl-reports? Not an RFC yet, but good guidance.
Section 2
The universal deployment of this feature is well-known
I suspect this may be an exageration.
This document is not a candidate for standard, which is what one would
expect from the this agenda item entry. The document is a reasonable
way to capture the questions at hand, but an agenda entry that indicates
the document is moving to standard is misleading and confusing.
This document should be moved to the 'Dead' state in the tracker.
I think we are beating a dead horse on a draft like this is not the best way to
get input from IESG - lets find a better way in the future. So ignoring that,
I'd like to get on with what advice the IESG might be able to offer to the WG.
The charter says the WG is going to form a list of proposed changes to
RFC 1652 8BITMIME
RFC 1864 Content-MD5
RFC 2045, 2046, 2047, 2049 MIME base specs
RFC 3282 Content-language
RFC 3461 DSNs
RFC 3462 Multipart/Report
RFC 3463 Enhanced Status Codes
RFC 3464 Message Format for DSNs
RFC 3798 Message Disposition Notification
RFC 4409 Message Submission
RFC 5321 SMTP
RFC 5322 Internet Message Format
then consult with IESG. Are the changes proposed in this draft the complete set
of changes the WG wants to make to the above RFCs?
I also want to discuss the implications of moving a document with known security
limitations
to full standard.
My personal responses wrt to the questions in section 3: (1) I have no issues with the changes proposed. (2) I have not made my mind up whether other changes are needed. (3) I have no issues with the downrefs. Any of those answers could be changed during IETF Last Call for 1652bis.
I find using a draft to drive discussions like this a very useful technique. However, using the balloting/evaluation process this way is a poor fit to the tool and I strongly discourage taking this path again. I currently think the changes proposed are suitable. I don't have a problem with the downward references.
draft-ietf-mpls-tp-oam-requirements
In Section 2.1.3 you say:
The OAM functionality may be deployed in various environments.
o In some environments (e.g., IP/MPLS environments), IP routing and
forwarding capabilities are inherently present in the data plane.
o In some environments (e.g., MPLS-TP environments), IP routing and
forwarding capabilities may not necessarily be present in the data
plane.
The second bullet point is problematic. If solutions MAY be deployed in non-IP
environments, they MUST NOT rely on IP. This is a very strange position to take
in the IETF.
Also, in Section 2.2.12, you say:
The MPLS-TP OAM toolset MUST provide a function to enable the
quantification of the one-way, and if appropriate, the two-way, delay
of a PW, LSP or Section.
o One-way delay is the time elapsed from the start of transmission
of the first bit of a packet by an End Point until the reception
of the last bit of that packet by the other End Point.
It may be very difficult to measure one-way delay without very well-synchronized
clocks.
Section 2.2.11., paragraph 2:
> Note that packet loss ratio is the ratio of the user packets not
> delivered to the total number of user packets transmitted during a
> defined time interval. The number of user packets not delivered is
> the difference between the number of user packets transmitted by an
> End Point and the number of user packets received at an End Point.
DISCUSS: Both the IETF and the ITU-T have detailed packet loss
metrics, and they are even aligned between the two bodies [RFC2680]. I
don't think this document should in passing come up with its own
definitions here.
Section 2.2.12., paragraph 1: > The MPLS-TP OAM toolset MUST provide a function to enable the > quantification of the one-way, and if appropriate, the two-way, delay > of a PW, LSP or Section. Both the IETF and the ITU-T have detailed delay metrics, and they are even aligned between the two bodies [RFC2679][RFC2681]. Should we refer to these here? Section 3., paragraph 1: > A mechanism (e.g., rate limiting) MUST be provided to prevent OAM > packets from causing congestion in the Packet Switched Network. Rate limiting only works in conjunciton with reserved PSN capacity for OAM (limit the rate to at most the reserved capacity.) Section 2.1.1., paragraph 1: > point associated bidirectional LSPs, point-to-point undirectional Nit: s/undirectional/unidirectional/
This is a discuss-discuss; I will clear on the call after discussion.
Is there a reason that the authentication, authorization, and confidentiality
were not specified
as OAM requirements? I would think that these mechanisms
could be "MUST implement,
SHOULD use".
Currently, there is only text in the security considerations, and that text is
fairly weak:
"suggests having some form of authentication, authorization, and
encryption"; "mechanisms
SHOULD be provided"; and "messages MAY be
authenticated".
draft-ietf-mpls-tp-nm-req
In section 2 I strongly recommend to used the conbination NETCONF/YANG as an example rather anything else. But Dan holds that point as part of his DISCUSS.
I hate to play downref police, however:
Section 12.1., paragraph 2:
> [2] Nadeau, T., et al, "Operations and Management (OAM)
> Requirements for Multi-Protocol Label Switched (MPLS)
> Networks", RFC 4377, February 2006.
DISCUSS: ** Downref: Normative reference to an Informational RFC: RFC
4377 (ref. '2')
Section 12.1., paragraph 4:
> [4] Jones, G., "Operational Security Requirements for Large
> Internet Service Provider (ISP) IP Network
> Infrastructure", RFC 3871, September 2004.
DISCUSS: ** Downref: Normative reference to an Informational RFC: RFC
3871 (ref. '4')
If the document had been shepherded according to PROTO, the shepherd would have
had to check for downrefs and they could have been handled during IETF LC...
Section 7., paragraph 0: > 7. Performance Management Requirements Should this section refer to IETF or ITU-T metrics or is it OK to leave this open?
In the Gen-ART Review by Joel Halpern on 25-Sept-2009, asks some
questions that ought to be answered before the document is approved.
Is it reasonable for the references in the following sentence to be
informational? Can one read this document and correctly understand
it without reading these other documents?
In writing this document, the authors assume the reader is
familiar with references [12] and [15].
Will this document will be cited in other (solution or architecture)
documents, which are explaining how they meet these requirements?
If so, there are two loosely related issues:
1) There is some descriptive text which may be intended to also be
providing requirements.
2) The actual requirements are not named or numbered, so it will be
difficult for any other document to say "we provide A-Q, but we
do not provide R for this reason ..."
It's a well written document, with requirements expressed in a clear manner,
with a good usage of solid references.
The following comments if fixed would improved the document and dissipate a few
unclarities:
1. Some text is missing concerning the operating model. An assumption is made
about centralized management from a NMS (probably in a NOC) which has direct and
indirect access to all NEs, this should be clearly articulated. It is less clear
whether the assumption is made about what happens with the faults - are they
logged locally, are alerts generated and sent to the NMS using some kinds of
notification system, etc. ?
2. There is no discussion about the scalability of the management solutions. We
are dealing with large scale deployments, with remote access required to all
nodes, what are the requirements on this respect?
3. In section 2 I strongly recommend to used the conbination NETCONF/YANG as an
example rather than NETCONF/XML.
4. Section 5.3.1 - I suggest that (also) RFC 3877 is mentioned as a reference
for alarms severities
5. It is not clear to me what pro-active and on-demand modes refer to when it
comes to performance monitoring. If pro-active mneans permanent reporting of
performance information I do not see how this scales.
In the second paragraph of section 2 - the capitalization of the keywords is inconsistent.
draft-ietf-simple-interdomain-scaling-analysis
Is there a specific reason not to include the total number of registered users in each scenario in section 2? The enterprise scenario includes: o About half of the registered users were online at peak time. but that doesn't seem useful unless the number of registered users is provided.
A good and thorough job. Thank you.
The Security Considerations section seems light on two counts.
Firstly, the very scaling problems that are described constitute a
security issue since they will gum up the network, CPU, and memory. To
what extent is a system at risk for the uncontrolled use of presence
subscriptions? Can an attack be mounted by simulating a larger number
of subscriptions?
Secondly, it is worth examining the impact on all of the scaling that
is introduced by applying security to the messages that are exchanged.
Of course, it should be noted that disabling security to achieve
better scaling is not recommended, but there may be choices and
implictions.
Fix this with a couple of new paragraphs in an RFC Editor note.
I love the new standard unit "dozens of gigabytes of presence traffic per day"
I support Adrian's discuss.
I like the document and I salute this work - it's one of the first I see anaysing impact of a succesful protocol or application on the Internet load and CPU losd of the hosts and servers. I would have liked to see also some mention of the impact and scalability aspects of the management systems and operator tools. Although that impact is not direct and as easy measurable, it is a serious concern for operators when dealing with succesful protocols.
draft-ietf-speermint-requirements
Minor editorial nit. In section A.1, this sentence doesn't parse:
o IP Network Connectivity:
Session peers should define how the IP network connectivity
between their respective SBEs and DBEs.
WGs are ephemeral - continously refering to the originating SPEERMINT WG in the title and body of the document will read strangely in a few years.
1). DISCUSS DISCUSS, i.e. I intent to clear this part during/after the IESG
telechat:
draft-ietf-speermint-voip-consolidated-usecases-14.txt shows use of DNS queries
for Look-Up Function (LUF) and Location Routing Function (LRF).
Section 5.1 of
draft-ietf-speermint-requirements-07.txt specifies MUST level requirements on
the protocol used for LUF/LRF that include mutual authentication, data integrity
and confidentiality. So I have 2 questions in relationship to this:
A). Would these requirements disqualify use of DNS for the final solution?
B).
If the answer to question A) is yes, doesn't this mean that draft-ietf-
speermint-voip-consolidated-usecases-14.txt becomes inaccurate/misleading the
moment this document is published?
2). I've solicited an additional review of the section 4 from Peter Saint-Andre.
He wrote:
In general, I am concerned about the use of the capitalized keyword MUST
in these requirements, because it could be taken to override local
policies or user-level privacy settings. For example, if we say that an
entity absolutely MUST be allowed to subscribe to the presence of users
in another SSP then operators might take that as saying that a user or a
service-wide admin cannot block an entity from another SSP (or all
entities from another SSP) from subscribing to the user's presence. I
don't think this is what we mean here, but we need to make that clear.
(In particular this applies to the requirement #10)
Requirement #10
The mechanisms recommended for the exchange of presence
information between SSPs MUST allow a user of one SSP's presence
community to subscribe presentities served by another SSP via its
local community, including subscriptions to a single presentity, a
personal, public or ad-hoc group list of presentities.
The phrase "to subscribe presentities" is missing some words. I think
"to subscribe to presentities" is meant. However, I think it is better
to say "to send a presence subscription request to presentities" because
presumably the presentity needs to control who can and cannot see its
presence information via some explicit approval mechanism.
In Section 4:
o Requirement #14: Mappings
Early deployments of SIP based presence and IM gateways are done
in front of legacy proprietary systems that use different names
for different properties that exist in PIDF. For example "Do Not
Disturb" may be translated to "Busy" in another system. In order
to make sure that the meaning of the status is preserved, there is
a need that either each system will translate its internal
statuses to standard PIDF based statuses of a translation table of
I think the first "of" should be "or".
proprietary statuses to standard based PIDF statuses will be
provided from one system to the other.
While this is a useful requirement, is it actually in scope for the WG?
5.3. End-to-End Media Security
It should also be noted that media can be carried in numerous
protocols other than RTP such as SIP (SIP MESSAGE method), MSRP,
XMPP, etc., over TCP ([RFC4571]), and that it can be encrypted over
secure connection-oriented transport sessions over TLS ([RFC4572]).
I think MSRP, XMPP, etc. need informative references.
From review of Section 4 by Peter Saint-Andre:
Requirement #11
The mechanisms recommended for Instant Messaging message exchanges
between SSPs MUST allow a user of one SSP's community to
communicate with users of the other SSP community via their local
community using various methods. Such methods include sending a
one-time IM message, initiating a SIP session for transporting
sessions of messages, participating in n-way chats using chat
rooms with users from the peer SSPs, sending a file or sharing a
document.
Use cases such as sending a file and sharing a document are not IM use
cases. Furthermore, the text seems to imply that an SSP cannot exercise
any granular control over which of the "various methods" are allowed.
Requirement #12
In order to enable sending less notifications between communities,
Usage: "less ... notifications" ==> "fewer ... notifications".
there should be a mechanism that will enable sharing privacy
information of users between the communities. This will enable
sending a single notification per presentity that will be sent to
the appropriate watchers on the other community according to the
presentity's privacy information.
The privacy sharing mechanism must be done in a way that will
enable getting the consent of the user whose privacy will be sent
to the other community prior to sending the privacy information.
if user consent is not give, it should not be possible to this
optimization. In addition to getting the consent of users
regarding privacy sharing, the privacy data must be sent only via
secure channels between communities.
The phrase "secure channels" is not defined. Does this mean SIP
signalling over TLS-encrypted TCP? It would be good to specify what's
meant, or to point to the security considerations.
Requirement #13
It should be possible to send a presence document with a list of
watchers on the other community that should receive the presence
document notification. This will enable sending less presence
document notifications between the communities while avoiding the
need to share privacy information of presentities from one
community to the other.
Usage: "less ... notifications" ==> "fewer ... notifications".
This requirement says nothing about security. Presumably, information
about the recipients of a given notification might also be private and
therefore worthy of protection, just as under Requirement #12.
Requirement #14
Early deployments of SIP based presence and IM gateways are done
in front of legacy proprietary systems that use different names
for different properties that exist in PIDF. For example "Do Not
Disturb" may be translated to "Busy" in another system. In order
to make sure that the meaning of the status is preserved, there is
a need that either each system will translate its internal
statuses to standard PIDF based statuses of a translation table of
proprietary statuses to standard based PIDF statuses will be
provided from one system to the other.
The final sentence is a bit confusing and its directive to SSPs is not
clear, even if we correct "of" to "or" in the middle. I might reword it
as follows:
To make sure that the meaning of the status is preserved, an SSP
should translate its internal statuses to standard PIDF statuses.
I don't think we want to recommend that SSPs exchange translation
tables, because the maintenance issues are significant and there is no
need to do this given that we have PIDF.
The question "Is DNS the right place for putting data that varies based
on who asks?" is out of place in this document. The document doesn't
capture enough of the argument that led to it being included to be
useful to future readers. Please either document that argument or
remove the sentence. Alternatively, find requirements that capture the
concern and state those. (Btw - this language assumes a particular
mechanism for using DNS. Alternates that avoid that question exist -
you can give the different askers different names to ask for, for
example).
The Presence and Instant Messaging requirements don't fit cleanly withthe other
requirements in this document. Requirement 13, in
particular, is a mechanism
stated as a requirement. The realrequirement is to allow policy for more than
one potential recipient to
be passed with a presence document. The last
sentence in Requirement14 is incomplete, which makes it unclear. I suggest
breaking it into
simpler phrases.
Nit: typo: "if user consent is not give,": give should be given
draft-ietf-speermint-voip-consolidated-usecases
Is there a specific intended purpose for these use cases: requirements development, guidance to developers/deployers, ??? Sorry for the minor rant, but the phrase "attempts to 'do something useful'" is a hot button for me. So, I'm going to indulge my inner pedant here. In the Introduction: This document attempts to capture Voice over IP (VoIP) use cases for Session Initiation Protocol (SIP) [RFC3261] based peering. "Attempts to capture" probably isn't a useful result. How about "describes important Voice over IP (VoIP) use cases, as determined by the SPEERMINT working group, ..." And, s/SPEERMING/SPEERMINT" in the header...
RFC 4366 is not referenced in the text, so it should be deleted.
Its not clear whether the call-flows used to depict some of the
use-cases in this document are intended to be one way the use case
could be realized or _the_ way the group is planning to realize the use
case. If it is the latter, the document is bordering on being normative
rather than just informative. Could you add a short explanation
scoping the applicability of the examples early in the document?
Why does the B2BUA in section 5.2 reset Max-Forwards rather than
continuing to decrement it in step 7?
At step 9 of section 5.2, the T-SBE jumps straight to an A lookup. Why
isn't this going through full RFC3263 resolution?
There is at least one instance of a missing semicolon between
header field parameters when the header field is folded (see Contact in
message 8 on page 17). There are other places where there are spurious
;'s (the first Via at the top of page 10). I suggest a careful check,
if not automated review, of the syntax in the examples.
draft-ietf-roll-home-routing-reqs
This is an important area and a document in this space is very welcome.
That being said, I'm not sure what to think of this document. If I had
written a document on this topic, it would probably say very different
things. I realize what the charter of the ROLL WG is, but the biggest
problem this document has is its high focus on the routing tools. There
are plenty of issues in building home networks like this, and one has
to find the right architecture and right tools to solve the issues.
This document goes too far in my opinion as positioning routing protocols
as the solution for some of the problems. Application layer mechanisms
for instance may be far more appropriate for some things.
This is not to say that there are no routing related requirements
in wireless ad hoc home networks. But the requirements seems relatively
easy:
- must support self-organized routing setup for a few dozen
networks and few hundred devices
- must support QoS based routing and forwarding
- must support capability/constraint based routing
So I would suggest that the document be shortened to address my Discuss.
Some specific comments below.
> The routing protocol MUST provide mobility with convergence time
> below 0.5 second if only the sender has moved.
>
> The routing protocol MUST provide mobility with convergence time
> below 4 seconds if the receiver has moved.
This presumes a particular solution to mobility, i.e., doing it at the
routing layer. It is not clear that this would be the right solution.
I would probably personally employ a BAN and a cellular/WLAN uplink
from my phone which would solve the problem at L2, or an application
layer solution that would require nothing from the routing layer
and would work well in any existing network.
> A controller sending commands to a sleeping actuator
> node via ROLL devices will have no problems delivering the packet
> to the nearest powered router, but that router may experience a
> delay until the next wake-up time before the command can be
> delivered.
>
> Sleeping nodes may appear to be non-responsive. The routing
> protocol MUST take into account the delivery time to a sleeping
> target node.
Hmm. I wonder what the real effect to the routing protocol is.
I am absolutely certain that application, transport, layer 2, and even
IP forwarding/queuing techniques change dramatically because of this.
But as far as I can tell, doesn't routing stay unaffected?
> The routing protocol SHOULD support acknowledged transmission. If
> the routing protocol does not support acknowledged transmission,
> some higher-layer transport protocol or application MUST ensure
> delivery of such messages.
Maybe I am misreading the first sentence, but I hope we are not
somehow changing the IP model or forwarding because of ROLL
requirements. IP should deliver packets, unreliably. Routing
should find out what the best and most reliable path is.
Link layers that are inherently very unreliable may increase
their reliability by proper MAC design (and e.g., L2 acknowledgements).
But I'm not sure what all this has to do with routing...
> Unlike other categories of Personal Area Networks (PANs), the > connected home area is very much consumer-oriented. Surely this is not true. I think most sports performance measurement gear, phone & music player, etc. applications are very consumer oriented. Perhaps you meant to say that other ROLL areas (like industrial plant monitoring) are less consumer oriented than home and PAN areas. > One event may cause many actuators to be activated at the same > time. > Using the direct analogy to an electronic car key, a house owner > may activate the "leaving home" function from an electronic house > key, mobile phone, etc. For the sake of visual impression, all > lights should turn off at the same time. At least, it should > appear to happen at the same time. A well-known problem in > wireless home automation is the "popcorn effect": Lamps are turned > on one at a time, at a rate so slow that it is clearly visible. I am wondering what value this paragraph adds. This may be a well known problem, but it is certainly one of poor implementation and/or choice of L2. I have a very hard time seeing this being a problem due to routing, or even being a problem in a well design network. In particular when home networks are naturally quite limited in physical size, unlike factories or commercial buildings. > If assignment of unique addresses is performed by a central > controller, it must be possible to route the inclusion request > from the joining node to the central controller before the joining > node has been included in the network. While this requirement is logical, I wonder to what extent it assumes that we somehow have to redo many of the basic building blocks and concepts that we have in IP networks. Does ROLL require something AUTOCONF-like? I would certainly hope that we can still have subnets and the basics of IP addressing stay the same, and that things like DHCP and DHCP relays work. > In contrast to other applications, e.g. industrial sensors, where > data would mainly be originated by a sensor to a sink and vice > versa, this scenario implicates a direct inter-device > communication between ROLL devices. I'm not convinced that the home network is any more peer-to-peer driven than other environments. Most equipment that we have today is still centrally controlled, even if running on top of IP.
Section 3.4., paragraph 3:
> If possible at all, the routing protocol MUST deliver a health-
> care related message. It is NOT a requirement that such message is
> delivered in less than a second.
> The routing protocol SHOULD support acknowledged transmission. If
> the routing protocol does not support acknowledged transmission,
> some higher-layer transport protocol or application MUST ensure
> delivery of such messages.
DISCUSS: I may be misunderstanding something, but why is reliable
delivery of healthcare *application* data something that the *routing*
protocol needs to do? If end-to-end reliability is required, the app
or app protocol needs to be involved anyway. Clearly routing can aid
this by providing paths to such apps that are more stable, but that's
about it, no?
Section 3.2., paragraph 4: > The routing protocol MUST provide mobility with convergence time > below 0.5 second if only the sender has moved. There's an unstated assumption here regarding the size/diameter of the network. You might want to point to Section 3.5 here. Section 3.8., paragraph 1: > The routing protocol MUST support the ability to isolate a > misbehaving node thus preserving the correct operation of the > overall network. > In other words, if a node is found to fail often compared to the > rest of the network, this node should not be the first choice for > routing of traffic. At least to me, the second paragraph isn't talking about the same thing as the first paragraph. The first one says "never use", the second says "not prefer." Section 2.1., paragraph 3: > acknowledged singlecast messages to each device. Nit: s/singlecast/unicast/ (?)
I have reviewed draft-ietf-roll-home-routing-reqs-08, and have couple
of questions/concerns that I'd like to discuss before recommending
approval of the document:
- The last paragraph of Section 3.4 seems to suggest that the routing
protocol could deliver acknowledgements to applications about whether
an IP packet was delivered or not (but this is more forwarding
than routing thing anyway). I think I'm probably misunderstanding
this text, and the intent was to say something else. But what exactly?
- Sections 3.7 and 5 seem to have conflicting requirements about
security and zero-configuration (adding a new node to the network
without any human intervention is pretty hard to combine with the
requirement to keep unwanted nodes out).
- It looks like [I-D.Hui-HeaderCompression] should be an informative
reference, not normative.
Glad to see this doc - I'm very keen on this work and look forward to being
able to use it. Few issues that if we can resolve them now as requirements, I
think will help get the protocol work done faster.
I'm not comfortable with the discussion of Health Care messages and
specifically:
If possible at all, the routing protocol MUST deliver a health-
care
related message.
I would like the requirements to make it clear if the
requirement is to support safety critical messages or not. I have no problem
with two (or more) levels of QoS where one has a better change of being
delivered than the others but if this is going to specify enough to support
safety critical messages, it needs to be crisp about the requirements that
entails.
I don't think I understand what you mean by the following requirement.
The routing protocol SHOULD support acknowledged transmission.
The way I read this, I would say that IP does not provide that, but an
application on top could. And SHOULD in requirements are pretty confusing to
start with. Can you rephrase this requirement to be more concrete as a
requirement and less of a solution?
Could you put more about the requirements around security and zero
configuration of adding new elements. It must be secure, but new elements can
automatically add themselves and disrupt routing seems contradictory. I also
wonder about about how message integrity and zero conf enrollment will work. I
think it is possible to come up with a set of requirements that represent a
reasonable balance here. Making it really easy to add or replace devices to the
network, while still maintaining security, seems to be the key part of this
system but seems both underspecified in the draft while at the same time being
over constrained. Surely the alarm system case must impose some security
requirements.
What's the requirement to use V6 on a network with 250 devices? The message with a 5 byte payload will take substantial longer and more power to transmit than if one used v4. I realize the HC is designed to solve that problem but it seems like it is layer complexity on top of complexity. I suspect you have the wrong "Status of memo boilerplate". You want the one that has "This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008."
I am supporting Pasi's DISCUSS about conflict of zero-configuration with security. 3.5. Scalability Looking at the number of wall switches, power outlets, sensors of various nature, video equipment and so on in a modern house, it seems quite realistic that hundreds of low power devices may form a home automation network in a fully populated "smart" home. Moving towards professional building automation, the number of such devices may be in the order of several thousands. The routing protocol MUST support 250 devices in the network. Should this be "... MUST support at least 250 devices ...". And to use Chris Newman's trick: why not say 257?
DISCUSS
I support Lars' discuss regarding requirements on applications vs requirements
on the routing protocol.
There are several constants presented as requirements without
motivation. Where did the .5 second, 2 second, and 4 second
convergence times come from? Why is the receiver-moved-only
requirement in 3.2 separated in the text from the sender-moved-only
requirement in 3.6?
What is section 4 informing? If it is truly necessary, then many of the
claims (frequency of switch/remote use, frequency of sensor reporting)
needs to point to some reference for authority. The end of that section
also makes some claims about mechanism ("typically as UDP" for
example) that are out of place. Can the section be deleted?
The paragraph motivating "MUST support 250 devices" is not persuasive
(plugs and switches are not inherently going to be low-power nodes).
What led to the choice of this particular constant?
The prose frequently assumes radio-based wireless. The charter for the group calls out other technologies. Is it possible that some requirements motivated by those other technologies have been missed? You might want to consider devices like robot-vacuum cleaners as nodes that can be both transmitters and receivers that will be highly portable. (Pasi captured this better in his discuss, but this was already written so I'm leaving it here to inform that conversation). Has the group begun to explore the conflict between the authentication requirements in the security consideration section and the zero-configuration for access requirements earlier in the document? If so, capturing some of that discussion would be helpful. If not, there may be related requirements that the group hasn't uncovered yet.
draft-ietf-msec-tesla-for-alc-norm
The Gen-ART Review by Pete McCann raised some points for discussion.
However the discussion has not taken place. Suggestions are made,
and without the discussion it is impossible to tell if these are
good suggestions or not.
> I'd suggest a more prominent reference to RFC 4082, especially to
> section 3.1 that describes the basic idea behind TESLA. You do have
> a reference just before Section 1.1, but perhaps you could add some
> explanatory text here to make it clear that the an overview of the
> use of hash chains to efficiently authenticate a long stream of
> packets is described in RFC 4082.
> Section 2.4.2.2 says:
>
> The sender and receivers use the direct
> time synchronization scheme to synchronize with the various time
> references.
>
> Should this say "indirect time synchronization scheme"?
I believe the following reference must be normative:
[RFC1305] Mills, D., "Network Time Protocol (Version 3)
Specification, Implementation", RFC 1305, March 1992.
as this document describes NTP timestamp format used in various places in the
document.
draft-ietf-rtgwg-lf-conv-frmwk
Very nice document overall! Section 6.5., paragraph 5: > This > could, for example, be achieved by allocating a Type of Service bit > to the task[RFC0791]. This mechanism works identically for both > "bad-news" and "good-news" events. It also works identically for > SRLG failure. There are three problems with this solution: There is no "ToS byte" anymore since DiffServ was published. Using a DSCP for that purpose is also not really in tune with the DiffServ architecture. Suggest to remove this example or point out in the list following this paragraph that that's also a drawback.
Section 3 has Throughout this document we use the term SRLG to describe the procedure to be followed when multiple failures have occurred whether or not they are members of an explicit SRLG. s/to describe/when describing/ --- Echo the point on the the ToS byte. Suggest to completely remove the sentence. --- I think it is unfortunate that section 12 is so skinny. I presume that if I am able to induce micro loops (perhaps by flapping a resource) I could cause considerable network disruption and so using loop prevention or mitigation is a protection.
draft-ietf-rtgwg-ipfrr-framework
How does section 4.2.2 explain the percentages given for various failure modes in section 4.2? I see how section 4.2.2 describes how an analysis could be performed, but I don't see the specific analysis that gives the percentages in section 4.2. Section 4.3 piqued my curiosity; it would be useful (but certainly not necessary) to say more: 4.3. Local Area Networks Protection against partial or complete failure of LANs is more complex than the point to point case. In general there is a trade- off between the simplicity of the repair and the ability to provide complete and optimal repair coverage.
Section 4.1., paragraph 0:
> 4.1. Mechanisms for fast failure detection
DISCUSS: Some of these fast failure detection techniques (the ones
based on observing packet loss) can lead to false positives when used
with very aggressive detection intervals, because losses caused by
transient congestion appear as a failure. I believe it's important to
point out somewhere in this document (maybe in this section) that any
technique used for fast failure detection MUST avoid being confused by
transient congestion. Otherwise, route flapping can occur, with all
the bad effects that has on transport connections & the network in
general.
Section 2., paragraph 2: > Recent advances in routers have reduced this interval to under a > second for carefully configured networks using link state IGPs. > However, new Internet services are emerging which may be sensitive to > periods of traffic loss which are orders of magnitude shorter than > this. It'd be fair to point out that although fast reroute can significantly improve behavior under failures for such applications, it is no panacea. When the characteristics of the backup path are different from the primary path (less available capacity, but also even longer delay), some of those services will still experience some issues.
I like this document and I only have a small Discuss.
Section 1
Distance_opt(A,B) The distance of the shortest path from A to B.
We seem to lack a definition of "distance". I know this is used in RFC
2328, but it is (IMHO) too close to implying hop-count, which is not
what you mean. Maybe "cost" is a better word, but you would still do
well to include a definition such as:
cost The sum of the link metrics for the links in a path.
Section 1 The definition of "E" uses the term "primary next-hop neighbor" but your terminology defines the term "primary neighbor". --- Section 1 Upstream forwarding loop defintion s/none of which are/none of which is/ --- It is a slight editorial concern that some sections have multiple numbered bullet lists using the same ordinals. Could you consider using letters for second lists so there is no confusion between lists?
draft-ietf-ipsecme-ikev2-ipv6-config
The Gen-ART Review by Avshalom Houri on 2009-09-24 raised a concern
about authentication and re-authentication. In particular, I think
that a bit more discussion of this paragraph is needed:
The gateway uses the Link ID to look up relevant local state,
verifies that the authenticated peer identity associated with
the link is correct, and continues the handshake as usual.
The Gen-ART Review by Avshalom Houri on 2009-09-24 suggested a section describing how the requirements in section 3 are being addressed by the solution.
draft-ietf-eai-downgraded-display
I have reviewed draft-ietf-eai-downgraded-display-02, and have couple
of questions/concerns that I'd like to discuss before recommending
approval of the document:
- I found the algorithm in Section 4 extremely difficult to
understand. For example, in Step 2 one could assume the generated
header fields are added to the "edit space" -- but the example later
suggests that's probably not the case. And it's very unclear why Step
6 applies also to "Address Header Fields' Preservation Header Fields",
or what it does for them (I thought those are already processed by
steps 1...5). I'd suggest some rewriting here to add clarity.
- Section 5 says hiding the information from the actual header fields
isn't a problem if the comparison done in step 4 succeeds. But this
step applies only to address header fields, right? What about
non-address header fields?
draft-harkins-emu-eap-pwd
I have reviewed draft-harkins-emu-eap-pwd-08, and have couple of minor
questions/concerns that I'd like to discuss before recommending
approval of the document:
- The document doesn't seem to specify how e.g. the password and
peer-ID entered by the user (character strings) are converted to byte
strings before hashing. (SASLprep processing followed by UTF-8 encoding
would be one obvious choice, but not the only one.)
- The document should specify at least one mandatory-to-implement
algorithm (for DH group/random function/prf/password preprocessing
method) to ensure interoperability.
- RFC 3079 doesn't actually specify how to calculate NtPasswdHash, but
just points to RFC 2759. Probably this document should point to
RFC 2759, too.
- References RFC 4634, RFC 5226, and RFC 3079/2759 look normative
rather than informative.
I imagine the draft is fine and I am just not understanding it. I don't see how
negotiation of PRF happens. If one side supports PRF, A B C D, and the other
side supports C, D, E, F, how do they figure out which one to use? If there is
no way to negotiate this I don't understand how forward compatibility works to
add new PRF later. I see how the server tells the peer which PRF to use but I
don't see how the server finds out what PRFs the peer supports. Can you point me
at what I am missing here.
This is a well written document with good Security considerations.
I have one minor comment/question in relationship to revision 10:
2.6.2. Passwords
o Microsoft: The input password string SHALL be processed to
produce the output PasswordHashHash, as defined in [RFC2759].
Neither RFC 2759, nor this document specify how the input password
is encoded. RFC 2759 says that it is in Unicode, but Unicode has multiple
encodings, which would result in different hashes.
This technique is useful when the server does not have access to
the plaintext password.
I do not have the level of confidence in the cryptographic mechanisms that would be required to support standards track publication, but I am comfortable with publishing as Informational.
draft-iana-ipv4-examples
draft-keromytis-keynote-x509
[edited]
The draft header says "Intended Status: Proposed". This should be Informational.
Section 7., paragraph 1:
> Per [KEYNOTE], IANA should provide a registry of reserved algorithm
> identifiers. The following identifiers are reserved by this document
> as public key identifier encodings:
Does this registry exist or does this draft intend to remind IANA that
this registry should still be created? If the latter, and assuming
that IANA wants to do this for a non-IETF protocol, there is
information missing here (and from [KEYNOTE]) as to what the
allocation policies are.
Some minor editorial suggestions: 1). RFC 3280 --> RFC 5280 2). Add a reference for base64 - RFC 4648
This document is an example where there is no conflict and no need to clarify
the relationship
with IETF specifications. While I have proposed a standard
3932 IESG note in the tracker, I am
advocating publication without any IESG note
whatsoever.
draft-templin-ranger
draft-irtf-mobopts-mmcastv6-ps