IESG Narrative Minutes
Narrative Minutes of the IESG Teleconference on 2010-12-16. These are not an official record of the meeting.
Narrative scribe: Barry Leiba and Susan Hares (The scribe was sometimes uncertain who was speaking.)
Corrections from:
1 Administrivia
2. Protocol Actions
2.1 WG Submissions
2.1.1 New Items
mplsFrrGeneralProtectionMethod OBJECT-TYPE
SYNTAX INTEGER {
unknown(1),
oneToOneBackup(2),
facilityBackup(3)
}
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"Indicates which protection method is to be used for fast
reroute on this device. Some devices may require a reboot
if this variable is to take affect after being modified.
The value of unknown(1) is read-only and cannot be set.
If the value of unknown(1) is set an inconsistentValue error
MUST be returned. It is provided to correct any
misconfiguration."
::= { mplsFrrGeneralObjects 1 }
187 forcesMIB FORCES-MIB [RFC5813]
188 pwTcStdMIB PW-TC-STD-MIB [RFC5542]
189 sshtmMIB Secure Shell Transport Model MIB [RFC5592]
The allocation request in this document must be changed and final allocation of OIDs left only to IANA.
Telechat:
event-param =/ min-interval-param
subexp-params =/ min-interval-param
min-interval-param = "min-interval" EQUAL delta-seconds
event-param =/ max-interval-param
subexp-params =/ max-interval-param
max-interval-param = "max-interval" EQUAL delta-seconds
event-param =/ average-interval-param
subexp-params =/ average-interval-param
average-interval-param = "average-interval" EQUAL delta-seconds
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
2.1.2 Returning Items
2.2 Individual Submissions
2.2.1 New Items
2.2.2 Returning Items
Telechat:
Telechat:
3. Document Actions
3.1 WG Submissions
3.1.1 New Items
Telechat:
Telechat:
Telechat:
Telechat:
3.1.2 Returning Items
3.2 Individual Submissions Via AD
3.2.1 New Items
Telechat:
Telechat:
3.2.2 Returning Items
Telechat:
3.3 IRTF and Independent Submission Stream Documents
3.3.1 New Items
Telechat:
Telechat:
3.3.2 Returning Items
4 Working Group Actions
4.1 WG Creation
4.1.1 Proposed for IETF Review
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
4.1.2 Proposed for Approval
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:
Telechat:
The W3C has requested expedited processing for draft-mcgrew-fundamental-ecc. W3C XMLEnc and XMLDsig 1.1 are going to Candidate Recommendation in January, and they have a normative reference to this document, and early assignment of an RFC number would be much appreciated.
Telechat:
Telechat:
7. Agenda Working Group News
1450 EST Adjourned
(at 2010-12-16 07:31:51 PST)
draft-ietf-mpls-fastreroute-mib
These issues are based on the RTG Area review.
I understand that the reviewers and editors have agreed text. I will clear when
the next version is posted.
There is no way in the MIB to read or set a value for "SE Style preferred" as
defined in RFC4090 Section 4.3. This means there is no way to tell from looking
at an instance of the MIB whether the ingress node is allowed to reroute the
protecting LSP without tearing it down. Equally there is no way to read or set a
value for "Bandwidth protection desired" as defined in RFC4090.
Section 4.2.2 explains how to identify a a detour LSP in the MIB, however the
fields used for identification differ from those described in RFC4090 Section
6.1 so it is not clear to me how one could map between an RSVP-TE message and
the corresponding MIB entry for that detour LSP. This should be described.
Section 4.2.2. includes the following two paragraphs:
A detour LSP is also considered as an instance of a protected
TE tunnel. Therefore, each detour LSP SHOULD have an entry in
the mplsTunnelTable (defined in the MPLS-TE-STD-MIB[RFC3812]).
In the mplsTunnelTable, the higher 16 bits of the tunnel instance
SHOULD be used as a detour instance. Note that for the protected
TE tunnel instances, the higher 16 bits of the tunnel instance
MUST all be set to zero.
The first paragraph is fine and included here for context. The second paragraph
is extremely difficult to parse, partly because it is not explicit as to when it
is referring to a detour LSP Vs a protected LSP. Do you mean that for protected
LSPs the high order 16 bits should be set to 0 and for protecting LSPs the high
order 16 bits should be used as a detour instance. So in the case of a detour
LSP, it has two mplsTunnelTable entries - one with the high order bits set to 0
and one with the high order bits set to the detour instance?
Section 4.2.3. The example in this section places the mplsTunnelInstance for the
protected LSP in the high order bits and the mplsTunnelInstance for the detour
LSP in the low order bits. However section 4.2.2 specifics that they should be
the other way round, i.e. protected LSP instance in the low order bits and
detour LSP instance in the high order bits.
From the RtgArea review: "The document defines three MIB modules but it only provides an example of how it could be used for the MPLS-FRR-ONE2ONE-STD-MIB. Personally I find examples of how to use MIBs extremely helpful when I have had to make use of a MIB for configuration or diagnostics. I would suggest adding examples of usage for the other two MIBs specified in the document."
1) I think the following is invalid. Is it legal to have different max-access
for different enumerations in the same object?
mplsFrrGeneralProtectionMethod OBJECT-TYPE
SYNTAX INTEGER {
unknown(1),
oneToOneBackup(2),
facilityBackup(3)
}
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"Indicates which protection method is to be used for fast
reroute on this device. Some devices may require a reboot
if this variable is to take affect after being modified.
The value of unknown(1) is read-only and cannot be set.
If the value of unknown(1) is set an inconsistentValue error
MUST be returned. It is provided to correct any
misconfiguration."
::= { mplsFrrGeneralObjects 1 }
2) This error processing would seem to be invalid. inconsistentValue is an
SNMPv3 error code; this object could not be used with SNMPv1 or SNMPv2c. That
would violate RFC1052 and RFC3410 architectural separation of the protocol from
the MIB.
3) mplsFrrGeneralConstraintsEntry talks about what agents must allow. SNMPv3
moved away from the agent/manager terminology to discussion of specific
application functionality, such as Command Responders, because the SNMPv1
concept of agent was no longer valid after Informs were defined.
4) I am not sure how agents know what the LSP signalling allows, especially in a
master/subagent architecture implementation.
5) mplsFrrGeneralConstraintsEntry : [citations] are not allowed in MIB modules
because a MIB module is often distributed separately from the surrounding
document. A REFERENCE clause, or textual mention of an RFC# is acceptable.
6) The MIB does not discuss the persistence of tables and objects across
reboots. That will have an effect in a number of places.
7) mplsFrrGeneralConstraintsRowStatus says no objects can be modified by the
agent, but the rows are read-create; is the manager allowed to modify objects in
the row? (and see previous note about agent/manager terminology)
9) mplsFrrGeneralTunnelARHopProtectTypeInUse seems to only support IPv4. Why?
11) what happens to mplsFrrOne2OnePlrEntry if the corresponding row in the
mplsTunnelTable is deleted?
12) what happens if mplsFrrGeneralConstraintsEntry is created, but the
corresponding row in MplsTunnelIndex does not exist?
13) mplsFrrGeneralConstraintsIfIndexOrZero "That ifIndex of the underlying
physical interface will be used as mplsFrrGeneralConstraintsIfIndexOrZero in
this table to protect the LSPs or tunnel instances determined earlier."
What
happens if the ifIndex values used in ifStackTable change upon device or
management system reinitialization? What is the persistence of
mplsFrrGeneralConstraintsTable?
14) should mplsFrrOne2OnePlrSenderAddrType and mplsFrrOne2OnePlrSenderAddr be
read-write rather than read-create? If read-create, shouldn't there be a
rowstatus object? if read-create, what happens if one of these objects is
deleted?
16) what is the persistence of mplsFrrFacilityDBTable?
what happens to
mplsFrrFacilityDBEntry if ifIndex is not persistent across reinitializations of
the system or the management system?
18) There is a security template for MIB modules that was written to meet exact
requirements. Authors often think they can improve upon the wording, but almost
always get it wrong.
The template has been modifed in this document, in a manner that is
inappropriate. This text is inappropriate because a MIB should not require a
specific version of SNMP be used, or specific SNMPv3 MIB modules be used:
The use of stronger
mechanisms such as SNMPv3 security should be
considered where
possible. Specifically, SNMPv3 VACM and USM MUST be
used with
any v3 agent which implements these MIB modules.
The SNMPv3
standard (STD61) has VACM and USM as mandatory-to-implement, but not mandatory-
to-use. The RFC3410 architecture was designed so different access control models
and different security models and different SNMP message versions can be used
within an SNMP system. The security provided by the SSH Transport Model
(RFC5592) or (D)TLS (RFC 5953) with the Transport Security Model (RFC5591) is
equally strong as USM, and reuses existing security infrastructure. There is no
reason why USM MUST be **used** with any v3 agent that supports this MIB.
8) I am not sure what "object availability" means in
mplsFrrGeneralTunnelARHopEntry
10) mplsFrrGeneralModuleFullCompliance supports the MPLS-FRR-GENERALSTD-MIB
mplsFrrGeneralModuleReadOnlyCompliance supports MPLS FRR MIB
Shouldn't these be consistent in naming the MIB they support?
s/agents/Command Responders/ ??
15) mplsFrrOne2OneModuleFullCompliance supports MPLS-FRR-ONE2ONE-STD-MIB
mplsFrrOne2OneModuleReadOnlyCompliance supports MPLS FRR ONE2ONE MIB
shoudn't these be consistent?
17) RFC4181 says abbreviations should be consistent.
mplsFrrFacilityBackupTunnelEgressLSRId and
mplsFrrFacilityInitialBkupTunnelInvoked are inconsistent.
This makes it harder
for operators to remember whether an name contains "Backup" or "Bkup".
Item #2 in the DISCUSS was modified following input from IANA.
1. David Harrington made a number of comments in his DISCUSS and COMMENT which I
support. Especially issues #2 (SNMPv3 specific error messages) and #18 (security
considerations template) must absolutely be resolved before this document can be
approved.
2. The document used a process which is not recommended pre-assigning mib-2 OIDs
for the roots of the three MIB modules in sections 8.1 to 8.3. We discourage
this practice, as one MIB document designer does not necessarily know what other
authors are doing in their documents. In this case the MIB authors request the
allocation of OIDs already in use:
mib-2 numbers 187-189 have already been assigned:
187 forcesMIB FORCES-MIB [RFC5813]
188 pwTcStdMIB PW-TC-STD-MIB [RFC5542]
189 sshtmMIB Secure Shell Transport Model MIB [RFC5592]
The allocation request in this document must be changed and final allocation of
OIDs left only to IANA.
3. It is not clear to me the reason of defining DEFVAL values for read-only
objects (mplsFrrIncomingDetourLSPs, mplsFrrOne2OneDetourOriginating, and other).
Although bot explicitly forbidden by the SMI rules, read-only objects are filled
in as soon as the agent can complute a meaningful value, so default values are
in effect for a very short time at initialization and typically not used. If
there is any special need in this case it should be described and explained.
1. It is not clear to me what the follwing text means in the DESCRIPTION clause
of mplsFrrGeneralTunnelARHopTable
Note that object
availability in this table is governed by the support of
the Record Route Object in the RSVP-TE signaling of the
implementation.
Does this apply to all objects in the table? How does an operator know that the
fact that this table is not populated is due to the lack of support of the
Record Route Object?
2. OBJECT mplsFrrGeneralConstraintsRowStatus
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
Not requiring write access for a RowStatus object means that the respective
table does not support dynamic row creation. How is it populated? I think that
some explanation is needed for this case.
3. Specifying just RFC4090 with no clause as REFERENCE like for
mplsFrrOne2OnePlrAvoidNodeAddr seems very vague and not useful. Same for RFC3812
provided as REFERENCE for mplsFrrFacilityProtectingTunnelIndex.
#1 Spell out first use of LSR.
#2) On page 7:
a) Need "--" before mplsFrr...?
-- The first value would be:
mplsFrrOne2OneDetourActive.1.6553601
b) Need comma after "= 0" in the following?
mplsFrrOne2OneDetourMergedDetourInst = 0
}
draft-ietf-sipcore-event-rate-control
I have reviewed this document and placed a no-objection vote, even if I do agree
with most of the issues raised by Lars and David. I do think though that despite
its problems and complexity, the document is understandable enough to be
reviewed. I think the right path is to fix the specific issues in the document
rather than to bring the document back to the working group. I do think that the
document should stick to using either rate or frequency terminology, however.
Also, here are some review comments from Ari Keränen who I asked to take another
look at the document:
The abstract should state that this document updates RFC 3265.
5.1. Subscriber Behavior
The value of
this parameter is an integral number of seconds in decimal.
Should that be "decimal integer"? And probably negative values are not
OK (should be stated), but how about zero? Same issue in sections 6.1.
and 7.1.
7.3. Calculating the Timeout
timeout = (average-interval ^ 2) * count / period (1)
It's not really immediately clear how this formula results in correct
timeouts. Say, if one uses average-interval of 10s and period of 100s,
based on quick calculation, it seems that the timeouts would be
0,1,2,...,9 for the first 10 (batches of) messages (10*10*0/100,
10*10*1/100, ...) resulting in all 10 messages being sent during the
first 45 seconds (as opposed to 100 seconds); or didn't I get the
formula right?
9.2. Grammar
min-interval-param = "min-interval" EQUAL delta-seconds
The "delta-seconds" token is not defined.
I fall somewhere between Jari and David regarding the use of "rate"
"frequencey" and "interval" terminology. I agree with Jari that the
document can be reviewed and fixed with editorial updates. However,
this text from section 5.2 is an example of what I think needs to be
fixed, not just improved:
A compliant notifier MUST NOT generate notifications more frequently
than the maximum rate allows for [...]
The specific parameter is a minimum interval, not a maximum rate.
To ensure accurate compliance with the specification, the requirement must
be stated in terms of the parameter, not the inverse of the parameter
(which, speaking pedantically, is not as precise):
A compliant notifier MUST NOT generate notifications with an
interval between notifications less than the currently allowed
minimum interval [...]
Text such as this excerpt from the next paragraph is OK, but could be
improved:
When a local policy dictates a maximum rate for notifications, a
notifier will not generate notifications more frequently than the
local policy maximum rate
which mixes frequency and rate but is still understandable and has no
normative requirements langauge. I think this text would be more
accurate:
When a local policy dictates a minimum interval for notifications,
a notifier will not generate notifications more frequently than the
local policy minimum interval [...]
Section 6., paragraph 0:
> 6. Operation of the Minimum Rate Mechanism
DISCUSS: Assuming that you disallow max_interval := 0, this mechanism
can still be used to get the notifier to generate a notification once
per second. This can put some stress on the network as well as on the
notifier. It's also questionable from the example use cases that a
notification rate that is that aggressive can be useful. Can we define
a useful max_interval that is larger than 1 second? If not, can we add
some strong language here to caution implementers to use the lowest
possible useful rate here? (This also applies to the "adaptive"
variant.)
Section 3.4., paragraph 7: > paremeters are adjusted from the value given by the Nit: s/paremeters/parameters/ Section 7.1., paragraph 4: > The main consequence for the subscriber when applying the adative Nit: s/adative/adaptive/ Section 7.3., paragraph 5: > period: The rolling average period, in seconds. The value of the > "period" parameter is chosen by the notifier, however the notifier > MUST choose a value greater than the value of the "average- > interval" parameter. Additionally, period should be several times larger than the average-interval, because otherwise, not much averaging will happen - the mechanism degrades to the non-adaptive variant.
Just a few nits in a document I found otherwise to be very readable.
idnits points out...
-- The document has a disclaimer for pre-RFC5378 work, but was first
submitted on or after 10 November 2008. Does it really need the
disclaimer?
---
Section 1
none of the event package specifications have defined such a
mechanism.
s/have/has/
---
Section 3.4 Req 7
For example, due to congestion reasons, local policy at
s/due/owing/
---
Section 4.1
In general, the way in which a subscriber generates SUBSCRIBE
requests and processes NOTIFY requests is according to RFC 3265
[RFC3265].
"In general"?
Similarly in section 4.2
In general, the way in which a notifier processes SUBSCRIBE requests
and generates NOTIFY requests is according to RFC 3265 [RFC3265].
1) The document continually refers to both rate and interval - two sides of the
same coin. I find the current approach to handling this very distracting. I
think the document would be clearer if you chose one perspective, explained in
the terminology section how it relates to the other perspective, and then used
the one perspective consistently. Maybe you should rename the parameters to
reflect the rate perspective - e.g., change "min-interval" to "max-rate".
section 1 defines min-interval, and equates it to maximum rate:
"min-interval:
specifies a minimum notification time period (maximum rate) between two
notifications, in seconds. "
This is incorrect; min-interval does not specify
the maximum rate between two notifications; min-interval refers only to the time
period. Maximum rate refers to the ratio of the number of notifications per min-
interval. - min-interval is only the denominator; maximum rate refers to the
numerator/denominator ratio.
section 3.1 says, "The maximum rate applies to the
overall resource list, which means that there is a hard cap imposed by the
maximum rate to the number of notifications the presence client can expect to
receive."
This sentence is inaccurate on at least two points -
a) the sentence
does not stipulate that the rate is a function of the time period; there is no
time period specified here, so it could be interpreted as the number of
notifications received for the lifetime of the client.
b) maximum rate only
indirectly imposes a cap on the number of notifications - i.e., the numerator is
ALWAYS 1. The hard cap per period is imposed by the min-interval, i.e., the cap
is 1/min-interval. The attribute that varies to establish the cap is the min-
interval, never the number of notifications.
The repeated mixing of the interval
and rate leads to inaccuracies in the spec. The spec would be more accurate if
the relation of rate to interval was defined in the termonology, and then the
specification were written from the interval perspective (since this spec is
about standardizing the settings for the interval parameters.)
2) 3.1 talks about "notifications that do not comply with the maximum rate". I'm
not sure quite what that means - I assume it means notifications are generated
faster than they are allowed to be sent. Why not say that?
3) 3.1 says the RLS
will "batch all of the buffered state changes together in a single
notification only
when allowed by the maximum rate." - I don't uinderstand
"when allowed by the maximum rate". The maximum rate is a number. How does that
number "allow" batching?
In addition, section 1 says "it is strictly an
implementation decision whether batching of notifications is
supported, and
by what means." So I don't understand what "allowed by the maximum rate" means
relative to the implementation decision. My impression is that "maximum rate" is
being used to refer to an abstraction of the whole process, and that does not
lead to clear and unambiguous standards specification.
4) 3.1 says "The presence
client can also modify the "min-interval" parameter during the lifetime of the
subscription. For example, if the User Interface (UI) of the application shows
inactivity for a period of time, it can simply pause the notifications by
setting the "min-interval" parameter to the subscription expiration time, while
still keeping the subscription alive. When the user becomes active again, the
presence client can resume the stream of notifications by re-subscribing with a
"min-interval" parameter set to the earlier used value."
This text conflates
the application, the UI, the user, and the presence client. These are
potentially different entities - an application's database of activity might be
a totally different process than its UI. I assume the presence client is an
abstract fucntionality supported by an application - possibly implemented in a
totally different process. and the user obviously is neither the application,
nor the UI, nor the presence client. Is the presence client supposed to have a
mechanism to watch the UI to see whether there is UI activity? or does it detect
inactivity by monitoring protocol acivity? How exactly does it detect this-
which protocols should be watched?
5) in 3.2, "In order to control the actual
state, the location application sets a minimum rate ("max-interval" parameter),
i.e. a maximum time interval between two notifications." Again, this approach of
"here, let me say this three different ways" is distracting. More important,
should this text say that it sends the parameter to the RLS? or does it just set
an internal parameter paid attention to at the presence client?
6) 3.3 says
"The "average-interval" parameter value is used by the notifier to dynamically
calculate the actual maximum time ("timeout" parameter) between two
notifications." timeout is used before being defined - you might need a forward
reference here.
7) 4.1 says "If the subscriber did not include at least one of
the "min-interval, "max-interval", or "average-interval" header field parameters
in the most recent SUBSCRIBE request in a given dialog, it MUST NOT include an
Event header field with any of those parameters in a 2xx response to a NOTIFY
request in that dialog." The "it" in thsi sentence should be replaced by a named
"actor". Is this the server that MUST NOT include things in the response?
8) 4.2
says "A notifier that supports the different rate control mechanisms will comply
with the value given in "min-interval", "max-interval" and "average-interval"
parameters and adjust its rate of notification accordingly. However, if the
notifier needs to lower the subscription expiration value or if a local policy
or other implementation-determined constraint at the notifier can not satisfy
the rate control request, then the notifier can adjust (i.e. increase or
decrease) appropriately the subscriber requested rate control." How do I comply
with a value? I know how to comply weith a standard, but not with a value. The
"will comply" seems to call for a RFC2119 keyword. "will comply" seems to call
for a MUST, but the next sentence discusses the exceptions, so I guess "will
comply" needs to tbe replaced by a SHOULD.
9) 5.1 says "Note that the witnessed
time between two consecutive received notifications may not conform to the
"min-interval" value for a number of reasons. For example, network jitter and
retransmissions may result in the subscriber receiving the notifications with
smaller intervals than the "min-interval" value recommends." Hmmm. Doesn't min-
interval mean do not send notifications more fequently than every X seconds? Am
I missing somethign in my interprwetation? Doesn't this text say that the
receiver might receive the notifications at a rate faster than the rate they are
sent?
10) in 5.5.1, how does one determine the relative sizes of the partial and full
state notifications? Is there a specification that defines the size of a full
state notification? The partial state contains values that are differences
between two full states. Can the size of the partial state be greater than the
size of the full state, when the partial contains only the differences between
two full states - the current full state and the last successfully communicated
full state? And I note that section 5.6 says explicitly "However, even in the
worst case scenario, where each partial update is to a different part of the
full state, a rate controlled notification merging all of these n partial states
together should at a maximum be the size of a full-state update." So why SHOULD
implementations check whether the partial state notification is smaller than the
full state notification?
11) Is it true that the maximum size should never
exceed the size of a full state notification? For example, could the size vary
depending on the encoding language, or the compression algorithm?
12) As with
all SHOULDs, what is the acceptable exception to not checking this? What are the
full implications if a notifier sends a partial notification instead of a full
notification when the partial and full are the same size? (If the partial can
never be bigger than the full, and the only time you would substitute a full for
a partial is when the partial is not smaller than the full, then they must be
the same size) I assume the subsequent baseline would be changed when the full
was sent, and not when the partial was sent. Is there a significant operational
impact from this happening, that doesn't occur using "accumulated" partials
anyway? If there are implications, why is this not a MUST?
13) Is there a
specification that defines the datatypes supported for calculating differences?
(Note that SMIv2 defines Counter64 datatypes, but failed to define an unsigned64
datatype, which would be necessary for representing the difference between two
Counter64s.
14) What is an accumulated partial state notification? where is this
defined?
15) With partial notifications, the notifier needs to maintain a
separate buffer for each subscriber since each subscriber may have a different
value for the maximum rate of notifications. How large a buffer is required of
compliant implementations? How many subscriptions must a compliant
implementation support? What happens if an implementation runs out of buffer
space? (note that this partial-notification requirement is not discussed in
terms of operational considerations, or in terms of possible DoS under security
considerations, including those of RFC 5263)
16) in 6.2, "A compliant notifier
MUST generate notifications when state changes occur or when the time since the
most recent notification exceeds the value in the "max-interval" parameter.
Depending on the event package and subscriber preferences indicated in the
SUBSCRIBE request, the NOTIFY request sent as a result of a max-interval
expiration MUST contain either the current full state or the partial state
showing the difference between the current state and the last successfully
communicated state.", Section 6.1 mentions sending an etag in the ntoification,
presumably instead of a full or partial state. Wouldn't this violate the MUST in
section 6.2?
17) in section 9.3, it states "A subscriber that wishes to update
the value for maximum, minimum or adaptive minimum rate of notifications can do
so by including all desired values for the "min-interval", "max-interval" and
"average- interval" parameters in an Event header field of the 2xx response to a
NOTIFY request." Shouldn't "can do so by including all desired" be "MUST include
all desired", since not including a value shuts off that specific feature?
In 9.2:
event-param =/ min-interval-param
subexp-params =/ min-interval-param
min-interval-param = "min-interval" EQUAL delta-seconds
event-param =/ max-interval-param
subexp-params =/ max-interval-param
max-interval-param = "max-interval" EQUAL delta-seconds
event-param =/ average-interval-param
subexp-params =/ average-interval-param
average-interval-param = "average-interval" EQUAL delta-seconds
delta-seconds is not defined in the document. I think it is coming from RFC
3261, but this needs to be stated explicitly.
I support the issues raised by David and Alexey in their DISCUSSes
1. In Section 3.4, the parameter names do not belong in the requirement
definitions because they are implementations of the requirements. Thus I
suggest:
REQ1: The subscriber must be able to set a maximum rate
of notifications in a specific subscription.
REQ2: The subscriber must be able to set a minimum rate
of notifications in a specific subscription.
REQ3: The subscriber must be able to set an adaptive
minimum rate, which adjusts the minimum rate of
notifications based on a moving average.
REQ7: The notifier must be allowed to use a policy in which
the maximum rate, minimum rate, and adaptive minimum
rate are adjusted from the value given by the subscriber.
2. In Sections 5.1, 6.1, and 7.1, what is "an integral number of seconds in
decimal"? An integral number sounds like an integer, i.e., a whole number, i.e.,
not a decimal number. Please clarify.
draft-ietf-morg-list-specialuse
From this example in section 5.4 and a brief e-mail exchange with Barry:
==> Set new use for SavedDrafts; MyDrafts changes automatically:
C: t3 SETMETADATA "SavedDrafts" (/shared/specialuse "\Drafts")
S: * METADATA "MyDrafts" (/shared/specialuse NIL)
S: t3 OK SETMETADATA complete
I infer that, in this example, only one mailbox on the server can have
the \Drafts attribute. This text from section 2 gives a hint that a
server may have a restriction that only one mailbox at a time may be
assigned a specific special use attribute:
All of the above attributes are OPTIONAL, and any given server or
message store may support any combination of the attributes, or none
at all. In some server or message store implementations it might be
possible for multiple mailboxes to have the same special-use
attribute.
It would make the restriction explicit to add text here to the effect of "Some
servers or message store implementations may restrict the use of
special use attributes so that only one mailbox is assigned each
special use attribute."
I don't think it is appropriate to use RFC2119 terminology in the Abstract. It is probably also not appropriate in the Introduction. --- It would be nice to capitalise the section headings. --- Section 7 LIST response: There are no security issues with conveying special- use information to a client. Really. Doesn't the exchange of information imply that there is potential to intercept the information. Knowledge of the message store usage may be valuable to someone attempting to access messages.
draft-ietf-tls-ssl2-must-not
Adrian has an interesting point.
however, this version does not provide the expected level of security. I think it provided exactly the "expected" level of security. Maybe you mean "does not provide a sufficiently high level of security."
draft-ietf-avt-rtp-svc
This is initially a Discuss Discuss
I have two issues that I would like to understand before taking a position:
1) The document discusses a MANE as a type of middlebox. I would like to
understand whether the content server and user explicitly request the services
of a MANE to modify the content, or whether it's services are imposed on the
stream by a third party?
If the server or the user request the services of the MANE, and the traffic is
explicitly addressed there this fine. If one the other hand the MANE just sits
in the path and does this, issues of compliance with the Internet Architecture
and issues of net-neutrality apply.
2) I would like to understand whether this draft proposes modification to the
output of an ITU-T codec. If it does, has the draft been liaised to ITU-T to
ensure that the stream is conferment to their specification.
[Updated. One issue added at the beginning.]
Issue for the AD to address:
The shepherding write-up doesn't list anything in response to the following
question:
In the case of a Media Type review, on what date was the request
posted?
The registration template was posted to ietf-types@iana.org for 2 weeks review:
<http://www.ietf.org/mail-archive/web/ietf-types/current/msg00996.html>
Please add this to the ballot write-up, as this is going to be sent out on
approval.
--------------------
In Section 7.1:
Encoding considerations:
This type is only defined for transfer via RTP (RFC 3550).
This text is not valid for this field in the registration template. It must be
moved to the "Restrictions on usage:" field of the template (which is missing
from this section).
Please check the Section 4.8 of RFC 4288 for the list of valid values for this
field.
The registration template is also missing the following fields:
Interoperability considerations:
Applications that use this media type:
Please read RFC 4288 for possible values of these fields.
In Section 7.1: "Public specification:" --> "Published specification:"
I concur with Alexey's DISCUSS regarding compliance with RFC 4288. Section 4.5.1 states: When SST is in use, Section 5.4 of [I-D.ietf-avt-rtp-rfc3984bis] applies with the following modifications. And Section 4.6 states: Section 5.6 of [I-D.ietf-avt-rtp-rfc3984bis] applies with the following modifications. Does this specification modify 3984[bis], or does it only extend 3984[bis]?
It would help to more clearly call out the consequences rewriting RTCP has on the way SRTP can be used. Currently the document only mentions this (and not as directly as it could) in an "Informative Note". Pointing to the last paragraph in the Security Considerations section of 3894bis would help.
#1) Section 3.1: It's probably worth pointing out where the normative
definitions are. That is, add "Where there is a discrepancy, the definitions in
[H.264] are normative."
#2) Section 3.1 the bit about section 3.1.2: If you're copying the definitions
and then changing them, then it would greatly aid the reader if you said which
ones you're changing and how.
#1) The RFC editor will make you remove the reference in the abstract. #2) Abstract: r/in_Annex/in Annex #3) Expand HDTV and Mbps. #4) Section 4.4, last para: Wouldn't it be easier to say SST is the default?
draft-ietf-xmpp-address
In the Gen-ART Review by Elwyn Davies on 30 November 2010, one issue
was discovered that is easily addressed. I think consistent terms
will aid future readers and implementers.
s4.3.1, last para: There should be a formal definition of 'Bare JID'
as it is extensively used in draft-ietf-xmpp-3920bis. Note that
almost all the cases where 'Bare JID' is used, both in this document
and 3920bis add a expansion that this means <localpart@domainname>,
except for one instance in s8.1.2.1 of 3920bis where it means just
<domainname> (also referred to as 'Mere Dominname' elsewhere in
3920bis!).
I just can't possibly resist not having a DISCUSS on this document ;-). Below
are my review comments:
4). DISCUSS DISCUSS:
Should domainpart be migrated to IDNA2008 now? Apps Area
is pretty much requiring use of IDNA2008 in all documents.
draft-ietf-sieve-notify-presence
In Section 2, the first time XMPP is mentioned there is no reference to the XMPP spec. The reference only appears later. Adding a reference the first time XMPP appears in the text would be useful.
dnd - Do Not Disturb; the user should not be disturbed now s/should not/does not wish to/ ?
[This is a preliminary discuss. I may have additional issues before the
telechat, but wanted to raise this issue now
in hopes of resolving it
beforehand.]
The first and third paragraphs of the security considerations section seem to be
in conflict. The first paragraph states
that "implementations MUST ensure that
users can not create scripts that access the presence information of others
without the proper access controls." The third paragraph advocates "caching
presence tests for periods of time, even
across Sieve script instances." Is it
reasonable to expect an implementation to ensure that the different script
instances *all* satisfy the access controls?
1.The language in the Security Considerations section is inconsistent in the way
it deals with the actions needed to be considered by implementations to mitigate
the security threats described in this section.
While the first paragraph ends with:
> In addition, implementations MUST
ensure that users can not create scripts that access the presence
information of others without the proper access controls.
the third one says:
> Implementations might consider providing options for rate limiting,
or for caching presence tests for periods of time, even across Sieve
script instances.
For consitency purposes it would be better to use 2119 language in both places
or none. My preference would be for a MAY or SHOULD to be used in the later
case.
2. The OPS-DIR review by Peter Koch questioned the free format of the status
information for:
> Description: A human-readable description of the user's availability
status. This is similar to the presence element with the same
name that's defined in Section 2.2.2.2 of RFC 3921.
Syntax: There is no formal definition for the values this item may
take. It is free-form and may be in any language, and is meant
for human consumption.
I think that it would be better to clarify that as per RFC 3921 this is a
natural language description (which is more clear than 'any language') and that
Sieve already specifies that strings are in UTF-8 (RFC 5228, section 2.1)
As far as I can tell so far, nothing in this document would make it hard to later extend its ideas to cover other types of presence information, up to and including queries against current location (PIDF-LO) enabling rules like "only send me an SMS notification if I'm in the country" - so, I'm entering this as a comment instead of a discuss. Please consider further reinforcing that these notification capability parameter values are going to be derived from potentially several inputs, including calendars as well as presence servers. It would help to informatively reference PIDF (RFC3863), especially in the registration of the "status" element, pointing to PIDF's "note" element in section 4.1.6. Also please consider calling out considering RPID and PDIF-LO when choosing new capability parameter names in the discussion of adding new presence items.
draft-ietf-mpls-ip-options
This document attempts to fill a very important gap in the the standards. I look
forward to changing this DISCUSS to a YES when the following issues are
addressed:
- In order to implement a compliant version of MPLS, the authors must read this
document. Therefore, this document UPDATES RFC 3031
- Is the scope of this document correct, or should we address all IETF
encapsulation types (IP-in-IP, MPLS, IPEC). It seems that they should all work
the same way. RFC 2003 (IP-in-IP) includes some very fuzzy language about IP
options "generally" not being copied to the outer header, but it doesn't seem to
have addressed the issue.
- Does encapsulation (of any type) scuttle the intent of some IP options. If so,
we might want to drop some packets at the head end of the LSP rather than
forwarding them without the intended per-hop processing.
- In the introduction, you say "The IP packet header provides for various IP options as originally specified in [RFC791]." Not all options are defined in 791. Some are defined in RFCs 1191, 1385, 1393, 2213, and 4782. - In the introduction, you say "IP options extend the IP packet header length beyond the minimum of 20 octets. As a result, IP packets received with header options are typically handled as exceptions and in a less efficient manner due to their variable length and complex processing requirements. For example, many router implementations, punt such IP option packets from the hardware forwarding (fast) path into the software forwarding (slow) path causing high CPU utilization." Even when the forwarding plane can parse a variable length header, it still needs to punt to the control plane, because the forwarding plane may not have the clock cycles or intelligence required to process the option. - in the introduction, your use of the word "transparent" is imprecise. Transparent means that you can see one thing through another (e.g., glass is transparent). IP options are not transparent when encapsulated in MPLS. MPLS would be transparent if you could see the IP header through it. - In Section 4, you say: When processing of signaling messages or data packets with more specific forwarding rules is enabled, this policy SHOULD NOT alter the specific processing rules. What are these more specific forwarding rules?
In Section 4. Ingress Label Edge Router Requirement "Further, how an ingress LER processes the IP header options of packets before MPLS encapsulation is out of scope since the IP packets are received as they enter the MPLS domain." The IP packet is not actually received in the IP component of the LSR, it is forwarded. You could delete "since the IP packets are received as they enter the MPLS domain.", or perhaps say "since these are processed before they enter the MPLS domain."
Section 5.1., paragraph 3:
> Further, IPv6 [RFC2460] makes use of extension headers not header
> options and is therefore outside the scope of this document.
DISCUSS-DISCUSS: I want to discuss this on the call, after which I
will clear the DISCUSS. In other words, no author action required at
this time: Is there a separate document in the works for IPv6? Or do
we already have the required mechanism specified?
INTRODUCTION, paragraph 4: > Requirements for Label Edge Router Forwarding of IPv4 Option Packets This document isn't really about requirements, it specifies a required behavior. Suggest to drop "Requirements for" from the title. INTRODUCTION, paragraph 7: > This document specifies how Label Edge Routers (LER) should behave > when determining whether to MPLS encapsulate an IP packet with header > options. Although it's clear from the the title that this document is for IPv4, it would be good to s/IP/IPv4/ throughout, for clarity.
1) Why does this document not Update 3031 and 3032?
2) There is an assumption in this document that packets with IP options SHOULD
be sent through MPLS.
But somebody put those options in. What if the operator
deliberately wanted to have the IP options take
precedence over the MPLS
encapsulation? The document does not discuss the security and operational
considerations of over-riding the IP options and pushing the packets into an
MPLS tunnel. For example,
o Crafted IP strict and loose source route option
packets that
belong to a prefix-based FEC yet bypass MPLS encapsulation
at a
ingress LER may allow an authorized operator to specify explicit IP
forwarding path(s) across an MPLS network and, thereby, achieve
specific
operational goals.
Please consider addressing the issues rasied in the TSVDIR review by James Polk:
I've reviewed this document as part of the transport area
directorate's ongoing effort to review key IETF documents. These
comments were written primarily for the transport area directors, but
are copied to the document's authors for their information and to
allow them to address any issues raised. The authors should consider
this review together with any other last-call comments they receive.
Please always CC <mailto:tsv-dir@ietf.org>tsv-dir@ietf.org if you
reply to or forward this review.
Summary:
This is a well written, concise and needed modification to MPLS.
That said, I don't understand why the 1st minor issue below is
present. Recommend (fairly strongly) adding the
"Document Updates: RFC 3031, RFC 3032"
as mentioned below on this first page of this RFC to be.
Transport Issues:
There are no issues
minor issues:
- S2 "Motivation", last sentence is
"We believe that this document adds
details that have not been fully addressed in [RFC3031] and [RFC3032]
as well as complements [RFC3270], [RFC3443] and [RFC4950]. "
I find it surprising that this document does not formally update 3031
and 3032, given that it is mandatory to implement, optional to
invoke. ISTM, as an outsider to MPLS, this would in fact be the case
given the impact of/to IP stacks not adhering to this proposed standard.
- Section 5.2 is about Router Alert Options, and states "At the time
of this writing ...". I wonder if this subsection is valid, or needs
another review against this IntArea ID
http://tools.ietf.org/html/draft-ietf-intarea-router-alert-considerations-02
to still be valid in a month or two once the IntArea ID (currently in
WGLC) is processed by the IESG and RFC-Editor?
IMO - these two docs are progressing near enough to each other to
each consider what the other says - with or without a normative or
informative reference in either or both docs to the other.
[dbh: the draft-ietf-intarea-router-alert-considerations draft does reference
the mpls-ip-options draft as an example of tunneling to avoid RAO. The two
drafts are closely linked, and authors should watch closely to make sure they
stay in sync through the approval/publication process.]
nits:
- I'm surprised to see the Abstract on page 2. I thought we
collectively fixed the case in which the Abstract can be on any page
other than page 1.
- at the page Footer, in the middle of the line, there isn't a "short
document name" - which has been there on all previous well formed IDs
and RFCs that I have seen (which of course is not all of them). It is
recommended the authors pick a short form name for the subject of
this doc for this location, such as
LER Header Option Behaviors
- S3, 4th para, second to last sentence is:
"First a downstream LSR may
have not have sufficient IP routing information to forward the packet
resulting in packet loss. "
recommend removing the first instance of "have". The sentence reads
better without it.
- S3, 4th para, last two sentences
list a "First" and a "Second" reason correctly, but are missing
required commas after each word (i.e., "First, ...", and "Second, ..." )
- S3, 5th para, 1st sentence is lacking commas here:
"...FEC, yet are forwarded
into an IP/MPLS network without being MPLS-encapsulated,
present..."
- S5.1, last bullet has this:
"...MPLS encapsulation at a ingress LER ..."
^^^^^
s/a/an
James
Nice document in general. Thanks!
One simple but discuss-worthy issue:
Shouldn't this update RFCs 3031 and 3032?
The conformance requirements could be stated more clearly. In the abstract "invoked" seems to be the wrong word. To me at least, it implies that the feature gets turned on as part of the protocol run. In light of the discuss issue, it also isn't clear if it is mandatory to implement in any MPLS LSR, LER, or only implementations of this document.
I support Ron's DISCUSS and item #1 in David's DISCUSS
I support Dave's first and Tim's discuss position.
draft-ietf-v6ops-3177bis-end-sites
This document is spot-on, much needed, and its about time we publish it. I can warmly recommend it being approved as it is. I do have a few comments on other AD's comments, however. Regarding David's Discuss on IPv6-IPv6 address translation, I think the current text in the document is actually completely appropriate and should not be changed. It is indeed the case that we must avoid a situation where address translation becomes necessary from a mere tight address allocation policy reason. Regarding Robert's Discuss on IETF role, I think the text would probably read better and be more acceptable to you if it said ... the IETF's role ... *in this case*. That is what I think the authors meant. The IETF should not, IMO, dictate the exact allocation size but rather provide guidelines, for the reasons stated in the document. Regarding the possible need to ask for IAB's approval, I think this document is clearly within IETF's scope, the working group and the community is behind this proposal and I see no formal reason to ask previous authors (including the IAB) for a permission. From a basic politeness stance, maybe we should check with the IAB though. I propose that this be done as a "for information" query rather than as a formal review period, and the AD who holds the discuss can clear when we are satisfied that the IAB has had enough time to respond if they feel the need to.
In section 1, the text asserts that IPv6/IPv6 NATS must be avoided. I think
should be avoided is more accurate, since we cannot predict the future needs of
an applicant. We can certainly try to avoid assigning non-contiguous ranges, but
we cannot guarantee it. Therefore "must" seems inapprorpiate.
"The exact choice of how much address space to assign end sites is an issue for the operational community. The role of the IETF is limited to providing guidance on IPv6 architectural and operational considerations. This document provides input into those discussions." I suggest this might be better worded as "This document provides input to the discussions of how much address space to assign end sites, as guidance to the operations community."
DISCUSS DISCUSS: The original document came from IAB+IESG. Does this document
need to also be approved by IAB?
This text (which occurs twice in the document) is problematic:
"The role of the
IETF is limited to providing guidance on IPv6 architectural and operational
considerations."
The IETF's role, in general, is clearly much larger. It is not necessary for
this document to attempt to define
or limit what the IETF's role is or isn't. I
suggest deleting the sentences.
This appears to obsolete 3177, not update it.
draft-ietf-morg-fuzzy-search
In reading the text there are a number of cases where "a" or "the" is missing in conjunction with "server" For example: Old IMAP protocol extension enabling server to New IMAP protocol extension enabling a server to ====== This text looks redundant: Note A revised version of this draft document will be submitted to the RFC editor as a Proposed Standard for the Internet Community. Discussion and suggestions for improvement are requested, and should be sent to morg@ietf.org. ======= From the security section: Implementation of this extension might enable a denial-of-service attack if the implementation isn't careful to prevent them. I am not sure that the implementer can resist a DoS attack, they can only implement this feature to be resistant to one. Implementations should test at least the behavior of large messages that contain very long words and/or unique random strings. I think that the implementers need to test the feature ON large messages
INTRODUCTION, paragraph 5: > Note > A revised version of this draft document will be submitted to the RFC > editor as a Proposed Standard for the Internet Community. Discussion > and suggestions for improvement are requested, and should be sent to > morg@ietf.org. This section should be removed. Section 4., paragraph 1: > Servers SHOULD assign a search relevancy score for each matched > message when the FUZZY search key is given. Relevancy scores are > given in range 1-100, where 100 is the highest relevancy. The > relevancy scores SHOULD use the full 1-100 range, so that clients can > show them to users in a meaningful way, such as a percentage value. Any particular reason why the range isn't 0-100? At least in my mind, a relevance of "1" still means "a tiny bit relevant", which is not "not relevant."
Thanks for this document which carefully skirts around defining "fuzzy" in an
admirable way.
I found a couple of small points which I think need a little attention.
---
I found the PARTIAL return option important and was surprised to see it
"hidden" in Section 6. Surely the nature of a fuzzy search (or indeed
any search) is that it could return a large number of matches. Therefore
the PARTIAL option is needed in all cases.
The solution is to pull this out into its own section "Limiting the
number of returned messages"
---
Should Section 8 also suggest rate limiting (at the server) fuzzy search
requests either globally or from specific clients/users? Should there be
a consideration for the ability to limit (at a server) which
clients/users can issue fuzzy searches?
The Gen-ART Review by Brian Carpenter on 2010-12-14 points out that
the title page header shoulf indicate that this document updates
RFC 3501. In particular, this document extends the formal syntax of
search-key to add '"FUZZY" / '.
I've cleared based on the RFC Editor note. There is no new discuss or comment text below. Previous Discuss text: ----- The draft should be a little more clear that different servers implementations are very likely to return a different set of results for the same search. A user should net expect the results of a search to be consistent over time, even when using the same service (since the service provider may choose a new implementation, or upgrade their existing implementation, resulting in a completely different "fuzzy" algorithm being applied). Also, service load might be distributed over several server instances (using multiple SRV records perhaps) - if the different instances are not running identical algorithms, search results will be different. Should the document constrain a given instance of a server to produce the same results when given the same search? I suggest not, given the observations above. ---- Previous Comment Text ---- Consider also pointing out that a user may end up with different search results when using a dedicated imap client on their user device than when using a web interface into the same email store. Has the group considered adding way for the client to influence the level of fuzziness? Does the current mechanism make it hard to add that later if the group decided it was useful?
draft-ietf-tcpm-tcp-timestamps
2*MSL Term not defined in the document.
Stylistic suggestion: in the bullets in section 2, either include the parenthetical "(creating a connection in the SYN-RECEIVED state)" in every sub-bullet or only the first. Where ISN comparisons are performed in the rules in section 2, is the comparison strictly "less than", or is the (rather unlikely event of) wraparound considered?
The Timestamps option, specified in RFC 1323 [RFC1323], allows a TCP to include a timestamp value in its segments, that can be used to s/TCP/TCP implementation/?
section 3: s/are important for TCPs that/are important for TCP connections that/ s/break prevent/prevent/ appendix A: "the workaround in RFC 1337" - can you be more specific?
I expected a few (minor) changes following the Gen-ART Review by Francis Dupont on 2010-12-10. The changes have not appeared yet.
Nice document, very clear presentation.
I have some relatively minor issues with the Security Considerations section,
plus a discuss-discuss issue.
(1)
The first paragraph doesn't really seem to describe a security issue. I
wonder if the
the text should be focused on the (lack of) security implications
when only one of the
communicating peers implements the specification. (As I
understand it, this algorithm
never does any worse than the current state.)
(2)
It seems there is a very minor attack that is enabled by this enhancement -
certainly nothing that would preclude using this technique, but still there:
an attacker could spoof a SYN that met the requirements and prevent a
host from releasing unneeded resources (after the normal TIME_WAIT passed).
This attack could already be performed using the ISNs; this document
just expands the range of messages that could be used.
Now to the discuss-discuss: is this really a BCP? I personally would lean
to standards track, but want to hear what others think.
I support Tim's discuss.
draft-cheshire-dnsext-dns-sd
Section 18., paragraph 1:
> IMPORTANT NOTE: Once draft-ietf-tsvwg-iana-ports is published, most
> of this IANA Considerations section can be deleted.
DISCUSS: Would it make sense to replace this section with a normative
reference to draft-ietf-tsvwg-iana-ports? (Currently, it's not even
cited as a reference?)
This document has quite a list of ID nits that should be fixed before publication (outdated references, not using example domains/prefixes, etc.)
I see no reason to hold up the publication of this document especially
in the light of existing deployments, but I do have two small issues
I would like to discuss.
---
The Introduction (fairly) says:
This document simply specifies
a convention for how existing resource record types can be named and
structured to facilitate service discovery.
I don't understand what it is about this I-D that is on the standards
track.
I see from the proto-writeup that:
An earlier revision of this document was reviewed by the IETF and
the IESG for publication as Informational. The current revision
has been updated based on feedback from the earlier reviews.
I went back to the history in the data tracker and I am puzzled.
AFAICS, revision -04 was the version that received the publication
request, and that showed:
Category: Standards Track
Indeed, draft-cheshire-dnsext-dns-sd-00.txt also shows that intention.
So, I don't think there is historic reason for this disposition.
There is a good deal of 2119 langauge, and I wonder what the consequence
would be of not abiding by this language. Would it break
interoperability or mean that the SD function could not be provided by a
particular DNS server?
Possibly it is the word "convention" used in several places that is
inconsistnet with "standards track".
---
A question for the sponsoring AD.
Has this version of the document been reviewed by the DNSEXT working
group? I can't find any informaiton on this in the write-up, but the
DNSEXT charter says...
The WG will review DNS protocol related work which may originate
elsewhere in the IETF, including AD-sponsored submissions or drafts
in other working group.
Pasi Sarolahti did a TSVDIR review and raised a couple of points:
1) In several places the document appears to assume that TCP and UDP are
the only valid transport protocols to be used in service
records. Then, Section 7 says:
"the first label of the pair is an
underscore character followed by the Application Protocol Name, and
the second label is either "_tcp" or "_udp".
For applications using other transport protocols, such as SCTP, DCCP,
Adobe's RTMFP, etc., the second label of <Service> portion of its
DNS-SD name should be "_udp"."
This is confusing. Why wouldn't other transport protocols use
their own protocol labels, for example "_sctp" or "_dccp"?
(There is ongoing work for defining UDP encapsulation for SCTP and
DCCP. In such case the meaning of "_udp" would be even more complicated.)
Generally, I think it would be good to keep a mindset that DNS-SD could be
used with any transport protocol, not just TCP and UDP, even if they
are the dominant protocols today.
DBH: the use of _tcp has issues either way, and the TSVDIR debated this comment,
with no clear resolution. I think the TSV community needs to have this debate
and provide some guidance for future documents. In the meantime, I think the
document might do well to mention that it could be used with other protocols,
and to state that this specification might need to be updated in the future to
accommodate a different naming scheme.
DBH: I agree that using _udp for other protocols is confusing and should NOT be
done. Is there a justification for not using _sctp, etc.?
update: Mail with
Lars crossed with my entering the DISCUSS:
"The transport being included in the
SRV RR was a historical mistake. But it can't be rolled back. So TCP services
use _tcp and all others _udp. (Yes, even SCTP and DCCP.)"
Can we add this
justification to the document to answer the question before it gets asked?
2) Section 6.3, on TXT records:
"The intention of DNS-SD TXT records is to convey a small amount of
useful additional information about a service. Ideally it SHOULD NOT
be necessary for a client to retrieve this additional information
before it can usefully establish a connection to the service"
As a more minor note, I don't think the sentence should be written in
normative language, instead of just using a non-capitalized "should
not" as recommendation for the usual case with TCP. With some
protocols connecting just based on the port number in the SRV record
might not be possible. For example DCCP with its service codes could
be one such case (in the spirit of thinking of possible future
protocols that might use this service).
DBH: Gnereally when SHOULD is used, I like a discussion of a known exception to
justify why it is not MUST. I think the DCCP case is an exception that might be
explained in the document to justify the SHOULD keyword.
I generally support publication of this document. I have a small list of
comments I would like to discuss before recomending its final approval:
4.1 Structured Instance Names
In addition, because Service Instance Names are not constrained by
the limitations of host names, this document recommends that they
be stored in the DNS, and communicated over the wire, encoded as
straightforward canonical precomposed UTF-8, Unicode Normalization
Form C [UAX15]. In cases where the DNS server returns a negative
response for the name in question, client software MAY choose to
retry the query using "Punycode" [RFC 3492] encoding, beginning with
This reference is not defined and it needs to be a Normative one.
5. Service Name Resolution
In the event that more than one SRV is returned, clients SHOULD
correctly interpret the priority and weight fields -- i.e. lower
numbered priority servers should be used in preference to higher
numbered priority servers, and servers with equal priority should be
selected randomly in proportion to their relative weights.
Why is this a SHOULD? I thought compliance with DNS SRV document makes this a
MUST.
18. IANA Considerations
This document specifies the following IANA allocation policy for
unique application protocol names:
I don't think it is very clear if this is asking IANA to establish
a new registry, or use an existing registry.
Allowable names:
* Must be no more than fifteen characters long
* Must consist only of:
- lower-case letters 'a' - 'z'
- digits '0' - '9'
- the hyphen character '-'
* Must begin and end with a lower-case letter or digit.
* Must contain at least one lower-case letter 'a' - 'z'
* Must not already be assigned to some other protocol in the
existing IANA "list of assigned application protocol names
and port numbers" [ports].
This is missing one rule from draft-ietf-tsvwg-iana-ports-08.txt:
hyphens MUST NOT be adjacent to other hyphens
4.1 Structured Instance Names
The <Instance> portion of the Service Instance Name is a single DNS
label, containing arbitrary precomposed (Unicode Normalization Form C
[UAX15]) UTF-8-encoded text [RFC 3629]. It is a user-friendly name.
It MUST NOT contain ASCII control characters (byte values 0x00 -
0x1F) but otherwise is allowed to contain any characters, without
restriction, including spaces, upper case, lower case, punctuation --
including dots -- accented characters, non-roman text, and anything
else that may be represented using UTF-8.
How does this interact with draft-ietf-tsvwg-iana-ports? I think it would be
worth pointing out here to sections that define more restricted formats.
6.4 Rules for Keys in DNS-SD Key/Value Pairs
The characters of "Key" MUST be printable US-ASCII values
(0x20-0x7E), excluding '=' (0x3D).
This needs a reference to US-ASCII.
[RFC 2434] Narten, T., and H. Alvestrand, "Guidelines for Writing
an IANA Considerations Section in RFCs", RFC 2434,
October 1998.
While RFC Editor is likely to fix this automatically, it would be better to
update this reference to point to RFC 5226.
I do not want to hold up publication of this document, so I am entering this as a comment, but hope the authors will take the time to review the use of non- example domain names in sections 4.1 and the various subsections of 14. I am not sure that the use of non-example domains in section 4.1 adds anything that "example.com" wouldn't provide: a conventional unicast DNS domain name, such as "ietf.org.", "cs.stanford.edu.", or "eng.us.ibm.com." Since section 14 is a worked example, I expect that no revisions are possible, but the authors should consider the ramifications of readers playing along at home...
I strongly support publication of this document. However, I have a few comments.
1. Section 6.4 states:
The "Key" MUST be at least one character. Strings beginning with an
'=' character (i.e. the key is missing) SHOULD be silently ignored.
Why is this SHOULD not a MUST? How would an application behave if it did not
silently ignore zero-length keys?
2. Section 7 states:
Application Protocol Names may be no more than fifteen characters
(not counting the mandatory underscore), conforming to normal DNS
host name rules: Only lower-case letters, digits, and hyphens; must
begin and end with lower-case letter or digit. In addition,
Application Protocol Names must contain at least one lower-case
letter. This is to prevent service names such as "80" or "6000-6063"
which could be misinterpreted as port numbers or port number ranges.
I think we need conformance terms here (e.g., "MUST NOT be" instead of "may be
no"), because later sections (e.g., 7.1, 18) assume that the fifteen-character
rule is a hard limit.
3. It seems that the IANA Considerations should simply normatively reference to
draft-ietf-tsvwg-iana-ports, or provide only the minimal information that is not
covered by that document.
1. The User Interface Considerations might be more appropriate as an appendix.
(Apologies in advance for the pedantic nature of this question)
Does the special meta-query definition in section 9 (where PTR record's rdata
is restricted to be a two-label name like _http._tcp.) update the definition of
PTR? In particular, does the SHOULD in the last paragraph update the existing
definition that the result is a pointer to a location in the domain name space
(i.e. root->_tcp->_http)?
Why is the SHOULD in the last paragraph of section 5 not a MUST? (In the event
that more than one SRV is returned, clients SHOULD correctly interpret the
priority and weight fields)
What document contains the normative text that constrains SRV lookups for
protocols like SCTP and DTLS to use the token _udp? This document should
reference it. If there isn't such a document, I'm not sure we have community
consensus that it's the correct standard use of SRV.
This document contains several instances of opinion and observation that are not going to be useful for building interoperable implementations of the protocol. Earlier versions of draft-cheshire-dnsext-multicast had similar text that was polished out as it was completed, leaving a better document for implementers. Please consider a similar editorial pass for this document.
draft-cheshire-dnsext-multicastdns
This document has quite a list of ID nits that should be fixed before publication (outdated references, not using example domains/prefixes, etc.)
Thank you for providing a new revision that addresses the previous IETF
last call issues.
I found two small concerns that I hope will be really easy to
adddress and will not hold the document up.
I found the use of 2119 language a bit patchy. It would be really good
if the authors took a pass on the document to check consistency. Some
examples from Section 3:
If this happens, the computer
(or its human user) SHOULD cease using the name, and may choose to
attempt to allocate a new unique name for use on that link.
Is that MAY?
This document recommends a single flat namespace for dot-local host
names, (i.e. the names of DNS "A" and "AAAA" records, which map names
to IPv4
and IPv6 addresses), but other DNS record types (such as
those used by DNS
Service Discovery [DNS-SD]) may contain as many
labels as appropriate for the
desired usage, up to a maximum of 255
bytes, plus a terminating zero byte at
the end. Name length issues
are discussed further in Appendix C.
Is that RECOMMENDED and MAY?
In summary: It is
required that the protocol have the ability to detect and handle name
conflicts, but it is not required that this ability be used for every
record.
REQUIRED and NOT REQUIRED?
---
The mDNS port (5353) is currently shown in the registry with Stuart's
coordinates (Stuart Cheshire <cheshire&multicastdns.org>). Shouldn't
we be asking IANA to replace or update with a reference to the RFC this
document will become?
This is NOT a discuss. I am simply using this flag in the tracker tool to make
sure that I read the right version of the document. I am highly likely to be a
YES on this doc. I have been educated about my earlier questions about is this
should be PS or not and am happy with the current plan.
I strongly support publication of this document. However, I have several
comments:
1. In Section 5.3 ("Continuous Multicast DNS Querying"), the third paragraph
states in part:
... the interval between the first two queries
SHOULD be at least one second, the intervals between successive
queries SHOULD increase by at least a factor of two
Is there a good reason why an implementation would override these
recommendations? If not, do they deserve to be required instead of recommended?
Also, perhaps a reference to the "truncated binary exponential backoff"
algorithm from the Ethernet spec (IEEE Standard 802.3) would be appropriate
here.
2. Section 10 ("Resource Record TTL Values and Cache Coherency") states:
"Various techniques are available to minimize the impact of such stale data."
Perhaps it would be appropriate to provide a description of, or pointer to, such
techniques.
3. Section 23 ("IANA Considerations") contains normative text about how
implementations are to handle the the designated link-local domains. This
normative text doesn't comprise instructions to IANA and thus belongs somewhere
else. Section 12 ("Special Characteristics of Multicast DNS Domains") seems like
an appropriate home for this text, i.e., the paragraph starting with "These
domains" as well as the seven bullet points that follow.
For consistency with RFC 5395, all occurrences of "pseudo-RR" should be replace with "meta-RR" and it would not hurt to add a reference to RFC 5395 (or the rfc5395bis draft which is being fast tracked).
draft-ietf-ipfix-mediators-framework
Ari Keränen had these comments:
IPFIX, PSAMP and quite a few other abbreviations are never expanded.
Section 5.3:
[...]
value of the "flowKeyIndicator" needs to be modified when
modifying the data structure defined by an original Template.
At least for someone not familiar with the protocol, it was not clear
how the value needs to be modified in this case.
From a protocol conversion point of view, this intermediate entity may provide conversion into IPFIX, or conversion of IPFIX transport protocols (e.g., from UDP to SCTP) to improve the export reliability. I assume that you mean to improve export reliability over a sub-network (or a network segment) since you cannot improve the reliability of the UDP segment, or an SCTP segment using a low reliability mode. ======= TLS & DTLS used without expansion
Expand the IPFIX acronym in the title, Abstract, and Introduction. All acronyms need to be expanded on their first use. When referring to a particular section (e.g., Section 2), the word "Section" needs to be capitalized.
Abstract: > This document describes a framework for IPFIX Mediation. This > framework extends the IPFIX reference model by defining the IPFIX > Mediator components. For the uninitiated, it would be good to add a sentence about what "IPFIX mediation" *is*.
Just a couple of very small points that could be fixed with an RFC
Editor's note.
---
Are we sure this document does not update the IPFIX architecture making
it an Update to RFC 5470?
---
I think that RFC 5470 needs to be a Normative reference.
Also RFC 5655 for its use in Section 9.
Possibly some of the others (e.g., those referenced from Section 9),
although I don't feel strongly
Section 8 says:
IPFIX Mediation reuses the general information models from [RFC5102]
and [RFC5477]. However, several Intermediate Processes would
potentially require additional Information Elements as follows:
Is "would potentially" code for "the Information Model is out of scope
for this document"?
draft-ietf-opsec-protect-control-plane
This is a good document, but I had trouble with one aspect. The document
talks about filtering and rate limiting ICMP traffic and entirely dropping
all fragmented packets. The document seemed to be unclear whether such
drastic measures are to be applied to the traffic destined to the router
itself or all traffic flowing through this. Dropping all fragmented
traffic through the router would be a very unfortunate design, and would
have severe impacts to the service that it provides to Internet users.
Please clarify that you meant to filter only traffic destined to the
device itself, i.e., with a destination address being one of the
router's addresses.
Ari Keränen had this comment:
4. Security Considerations
The filter above leaves the router susceptible to discovery from any
host in the Internet. If network operators find this risk
objectionable, they can reduce the exposure by restricting the sub-
networks from which ICMP Echo requests or traceroute packets are
accepted.
In practice this does not help much, since, e.g., TCP scanning would be
still possible.
For network deployments where the protocols used rely on IP options, the filter
is simpler to design in that it can drop all packets with any IP option set.
That looks the wrong way round.
"Modern router architecture design maintains a strict separation of forwarding and router control plane hardware and software." Firstly I agree with the sentiment of this statement, however whilst this is true in all high end core routers, and in many mid range routers, it is not universally true. The crossover point between distributed designs and classic designs depends on the current ability of CPUs and is thus always in a state of flux It is also worth noting that the need to provide isolation and stability for the cp with work conservation and fast discard of rouge cp packets has been known and incorporated into designs for at least the past 30 years. ====== o Drop all IP packets that are fragments There is some text on this later, but the reader would find it useful to have this explained up front. At least a forward reference would be useful.
It might be useful to add DHCP to the example because of the DHCP relay function, rate limiting inbound DHCP traffic from clients and restricting traffic from servers to a list of known DHCP servers.
Appendix A., paragraph 0:
> Appendix A. Configuration Examples
DISCUSS: I believe that the sequence of configuration commands in
appendix A.1 and A.2 constitute "code" (components intended to be
directly processed by a computer). This means that some boilerplate
text needs to be inserted, see
http://trustee.ietf.org/docs/IETF-Trust-License-Policy.pdf
Section 3., paragraph 0: > 3. Method You should be MUCH more clear that Section 3.1 gives a particular EXAMPLE of how one might set up a filter to protect the control plane, and that any actual deployments SHOULD NOT blindly follow that example without considering the network setup at hand. Section 4., paragraph 1: > The filter above leaves the router susceptible to discovery from any > host in the Internet. If network operators find this risk > objectionable, they can reduce the exposure by restricting the sub- > networks from which ICMP Echo requests or traceroute packets are > accepted. Several techniques for tracerouting exists, and "traceroute" packets are therefore not so easy to identify. What can be done is preventing "TTL expired" ICMP responses from being sent, but that can have drawbacks.
Section 1 While software instructions run on both planes, the router control plane software is usually not optimized for high speed packet handling. Did you actually mean "router control plane *hardware* is usually not optimized"? It seems to me that the software *will* be optimized since who would not want their control plane to scale well?
Nice document. Clear presentation, much appreciated. +1 on Sean's discuss...
I support Sean's DISCUSS
draft-ietf-v6ops-incremental-cgn
I think we need a document like this and it should be in the V6OPS
scope to produce one. In particular, I would like to see a recommendation
and operational considerations to use CGN + tunneled IPv6 service at
an ISP. That seems a very likely configuration in many places.
However, I'm somewhat unhappy with some parts of the document. In
particular:
- it portrays this as a new solution as opposed to recommended
application of existing components
- it brings in some IMHO unnecessary extensions and references
- its treatment of IPv6-IPv4 translation aspects seems outdated
(referring to NAT-PT)
My suggestion is to go through the document once more and remove
extra material and take the above focus comments into account, to
see if you can cast the document in slightly different terms.
More detailed comments:
The document says:
ISPs facing only one pressure out of
two could adopt either CGN (for shortage of IPv6 addresses) or 6rd
(to provide IPv6 connectivity services).
I think you mean IPv4 addresses.
The document says:
In order to
enable IPv4 hosts to access the IPv6 Internet and IPv6 hosts to
access IPv4 Internet, NAT-PT [RFC2766, RFC4966] (or its replacement)
can be integrated with the CGN.
This is wrong. The replacement is already an RFC (or about to become
one), and there is no reason to switch the reference to the right
specification. Pointing to the old specification is harmful.
Sections 2.3 and 2.4 would be better cast as "just use existing
forwarding, NAT, and tunneling technology", than as something where
you describe behaviour. I had to read the text multiple times to
determine what was actually going on, and AFAICT there is no
difference to the application of normal IP forwarding rules and
tunnel termination logic. I think the usual rules are clearer
than what the document describes, e.g.,
firstly checks whether the packet is a normal IPv4 packet
or a v6-over-v4 tunnel packet. For a normal IPv4 packet, the CGN
translates packet source address from a CGN-scope private IPv4
address into a public IPv4 address, and then send it to IPv4
Internet. The CGN records the v4-v4 address mapping information for
inbound packets, just like normal NAT does. For a v6-over-v4 tunnel
packet, the CGN needs to decapsulate it
seems to be saying that we should particularly check tunnel packets,
but I think the normal way is that the tunnel packet, being addressed
to the CGN device will naturally enter different processing than
packets routed/natted through it.
Section 2.5 should mention MTU effects.
The document says:
An ISP can provide its IPv6-only customers with a network-layer
translation service to satisfy this need. Such a service is not fully
defined at this time, so we refer to it non-specifically as "NAT64".
Current work in the IETF is focused on one particular proposal
[I-D.ietf-behave-v6v4-xlate-stateful]. The NAT64 service can be
provided as a common service located at the border between the ISP
and the IPv4 Internet, beyond the dual stack CGN from the customer's
viewpoint. It may be integrated into CGN devices too.
This is quite outdated.
The document says:
[I-D.boucadair-dslite-interco-v4v6] describes a proposal to enhance a
DS-lite solution with an additional feature to ease interconnection
between IPv4 and IPv6 realms. Home users may encounter the problem of
reaching legacy IPv4-only public services from IPv6-only clients.
This problem already exists in early phases, but will become more
serious over time.
I'm concerned that we are unnecessarily listing all kinds of extensions
that we don't even know are needed and which are definitely not in
the current IETF agenda. Suggest deleting this paragraph. And delete
this as well while you are at it:
If a different technology than v4-v4 NAT is chosen for IPv4 address
sharing, for example [I-D.ymbk-aplusp], the present approach could be
suitably modified, for example replacing the v4-v4 NAT function by
the A+P gateway function.
The document says:
For example, the appearance of IPv6 Route Advertisement messages or
DHCPv6 messages can be used as a signal the availability of DS-Lite
CGN. When an ISP decides to switch from incremental CGN to DS-Lite
CGN, it may be that only a configuration change or a minor software
update is needed on the CGNs. The home gateway can then detect this
change and switch automatically to DS-Lite mode. The only impact on
the home user will be to receive a different IPv6 prefix.
I'm not sure I understand what I need to do here as an implementor,
and whether all the necessary pieces in RAs are already defined.
The document says nothing of prefix delegation. Maybe it should, or
should at least point out that discussion about prefix delegation
can be found in several of the references.
The document says:
For dual-stack ISP networks, dual-stack home gateways can
simply switch off the v6-over-v4 function and forward both IPv6 and
IPv4 traffic directly while the dual-stack CGN only keeps its v4-v4
NAT function. This approach is considered an unlikely choice, since
we expect ISPs to choose the approach described as incremental CGN
here because they want to avoid or are unable to complete dual-stack
deployment completely.
This text is somewhat confusing. I *think* you are saying that you can
do all this in dual stack ISP network, but that if you were adopting
this specification to begin with you did not have a dual stack network.
Please clarify/rewrite, and make sure that the document does not seem
to recommend against deploying dual stack ISP networks...
Ari Keränen had these questions:
1. Introduction
A smooth transition mechanism is also described in this document. It
introduces an integrated configurable CGN device and an adaptive HG
device. Both CGN and HG are re-usable devices during different
transition periods. It avoid potential multiple upgrade.
What does the last sentence mean?
2. An Incremental CGN Approach
Most consumers remain primarily IPv4.
Should that be, e.g., "Most consumers remain primarily in IPv4-only
networks"?
2.4. Behavior of Dual-stack CGN
When a dual-stack CGN receives a data packet from a dual-stack home
gateway, it firstly checks whether the packet is a normal IPv4 packet
or a v6-over-v4 tunnel packet.
How is this check performed? And what if the host (i.e., not the HG) is
using some v6-over-v4 mechanism; would that cause problems with the check?
ISPs facing only one pressure out of two could adopt either CGN (for shortage of IPv6 addresses) Do you mean "shortage of IPv4 addresses"? ======= Modified GRE [RFC2784] with additional auto-configuration mechanism is also suitable to support v6-over-v4 tunneling. Do you mean "modified GRE" in which case how is it modified, or do you mean GRE supplemented by a signalling protocol to set up tunnels? ======== The security text on tunnel security seems a little light. If the ISP is going to consider the tunnel as own infrastructure and not needing to be policed, the ISP needs to consider policing those tunnel endpoint addresses at the boundary of the network. When an ISP decides to switch from incremental CGN to DS-Lite CGN, it may be that only a configuration change or a minor software update is needed on the CGNs. The home gateway can then detect this change and switch automatically to DS-Lite mode. This seems very speculative
An important document; thank you.
I found a few nits you might want to try to fix along the way.
---
Section 1
Based on this fact, the Internet industry appears to
have reached consensus that global IPv6 deployment is inevitable and
has to be done expediently.
Do you mean "it is expedient" or "it has to be done expeditiously"?
---
"CPE" needs to be expanded on first use.
---
It seems (to me, and from the usage made in the document) capriscious
that 5969 should be a normative reference, but 5569 informational.
---
Section 2.2
Other tunneling mechanisms
such as 6over4 [RFC2529], 6to4 [RFC3056], the Intra-Site Automatic
Tunnel
Addressing Protocol (ISATAP) [RFC5214] or Virtual Enterprise
Traversal (VET)
[RFC5558] are also considered.
The passive voice is to be avoided!
By whom are these other tunneling mechanisms considered, to what end,
and with
what result?
---
Section 2.4
When a dual-stack CGN receives a data packet from a dual-stack home
gateway, it firstly checks whether the packet is a normal IPv4 packet
or a v6-over-v4 tunnel packet.
You need to say how it checks.
This is a reiteration of Sean Turner's discuss. I am entering as a discuss
(rather than No Objection with
a supporting comment) so I can be involved in any
subsequent discussion.
This seems like a perfect document for Experimental. Running an experiment
while we work through the
security issues seems like a nice lead-in to an
informational or standards track specification. The current
spec doesn't feel
fully baked (esp with respect to security) imho.
This is a DISCUSS-DISCUSS (i.e., nothing for the authors to do at this time).
The security considerations include the following two statements:
Further security analysis will be needed to understand double NAT security
issues and tunnel security issues.
and
[RFC4891] describes how to protect tunnels using IPSec, but it is not clear
whether doing so would be an important requirement.
Taken together I've got ask why this isn't experimental?
This one is normal discuss:
It's worth noting early that the proposal has not fully addressed the security
considerations and that further analysis may show that the proposal might not be
worth adopting based on what is found during the study of the security
considerations.
Figure 1: Is it supposed to to be "6 to 4" as opposed to "6 o 4" in the tunnel? Or is the "o" just supposed to be over?
draft-ietf-bmwg-reset
I have no issues with this document, but Ari Keränen found some small
problems in his review:
2.2. Recovery Time Measurement Methods
There are two accepted methods to measure the 'recovery time':
Is the meaning of "accepted" as in "no other method SHOULD be used" or
as in "currently widely used" (or something else)?
4.2. Software Reset Test
A software reset is initiated for example from the DUT's Command
Line Interface (CLI).
The CLI abbreviation is used already in Section 4.1. Would make sense to
move the expanded form there.
The second part of the test "Procedure" (6 lines of text) seems to be
identical for all the test cases. Perhaps this text could be in the
draft just once and have that single instance referenced in the test
case descriptions.
"The tester / operator MAY use either method for recovery time
measurement depending on the test tool capability. However, the
Frame-loss method SHOULD be used if the test tool is capable of (a)
counting the number of lost frames per stream, and (b) transmitting
test frame despite the physical link status, whereas Time-stamp
method SHOULD be used if the test tool is capable of (a) time-
stamping each frame, (b) monitoring received frame's timestamp, and
(c) transmitting frames only if the physical link status is UP."
The document should explain
1) Why is the phy link status is only applicable in the second case?
2) Any guidance on choice of method if an equipment can do both?
====
The scaling considerations consider the RIB not the FIB. To some extent this is
reasonable in that the number of routes is a topology factor and the number of
FIB entries is an implementation issue. However given that in many routers it is
FIB update time that dominates the topic is worthy of greater discussion. One
particular case where FIB entries come into play is when you get ECMPs (which
increases FIB entries) another is BGP free core (which reduces them).
====
When power cycle tests (and maybe some of the other tests) are conducted, I
would expect that the outage would be dominated by the specifics of the routing
protocols, which are not particularly well characterized by this test? In
particular it's difficult to see how to fairly test this without some
characteristic of the routing behavior the routing peers being reported in the
test results.
It looks to me as though a number of these tests might require that
forwarding state is re-established from an external source (e.g.,
re-learned from neighbors). Are these situations explicitly excluded
from the set of benchmarking methodologies described in this document,
in which case it would be really nice to call this out in the Scope
section.
If control plane interactions with neighbors were needed, you would
have a much wider field to describe in order to ensure "fair" reuslts
for the DUT.
---
Further to Russ's Discuss, I find the following paragraph in Section
4.1 confusing:
Reset procedures that do not require the physical removal and
insertion of a hardware component are RECOMMENDED. These include
using the CLI or a physical switch or button. If such procedures
cannot be performed (e.g., for lack of platform support, or because
the corresponding Test Case calls for them), human operation time
SHOULD be minimized across different platforms and Test Cases as
much as possible, and variation in human operator time SHOULD also
be minimized across different vendors products as much as practical,
by having the same person perform the operation, and by practicing
the operation.
Surely the variations in operator time will not matter. For example,
the time that a card is out for will not change the test, which is
measuring the time to recover from when the card is reinsterted. Thus,
there is no fear of variation between vendors' products becuase the
ease or insertion of a card is not relevant to the atomic event of
the card being (finally) inserted.
More of an issue would be how you synchronize the timing event with
the reinsertion of the card.
That means hat your Recommendation is sound, but the motivation is
suspect.
"BMWG" is used without expansion. --- Section 3 In order to provide consistent and fairness s/constistent/consistence/
The Gen-ART Review by Joel Halpern on 27-Nov-2010 included two
questions. I think that the should be answered before the
document is approved:
Is there a reason that section 4.1.1.1 on reset of a single-RP device
refers to simple removal and re-insertion, without explaining the
caveats that section 4.1.2 (line card removal and re-insertion)
provides about using a method to avoid having the human time for
the removal and reinsertion have a significant effect on the
operation?
Also, should the same caveat not be applied to section 4.3.1 on
Power Interruption? There seems to be an implicit assumption that
the human operation will be sufficiently fast, and the recovery
sufficiently slow, that the human element does not matter. At the
very least, it would seem that this should be articulated.
draft-linowski-netmod-yang-abstract
s/suggests to enhance/suggests enhancing/
I like this extension to YANG, but I haven't reviewed it in enough details to vote Yes.
I would like to know why the authors chose not register the yang module in Appendix B.
This document defines what seems like a worthwhile experiment. Overall, the specification does not always clearly explain the relationship between this extension and YANG itself (e.g., by relating things like complex types to particular extension points in RFC 6020), the text is sometimes difficult to understand (e.g., the document does not provide very detailed justifications for various design decisions, and there are numerous grammatical errors), and the document is sometimes poorly organized (e.g., often there are no introductory paragraphs before lists and no explanations of the tables, which seem to be merely stuck in the middle of the text without any context). These problems could be fixed if and when the experiment is completed and a follow-up specification is proposed on the standards track, but I don't think it's worth spending a lot of time to fix them now. On the other hand, the document provides many examples, thus helping the reader to understand the proposed extensions. Here are several more concrete comments... 1. The following text is a bit presumptuous: After successful usage this experimental specification can be republished at IETF as a proposed standard possibly as part of a future version of YANG. I suggest the following: If this experimental specification results in successful usage, it is possible that the protocol defined herein could be updated to incorporate implementation and deployment experience, then pursued on the standards track, perhaps as part of a future version of YANG. 2. In Section 1.2, the text does not explain that the bullet points are examples and therefore not exhaustive. 3. No reference is provided for the "TM Forum SID". 4. In Section 4, please make sure that the registrations provide all information in one place (e.g., it's not appropriate to point to the "Authors' Addresses" block for the Registrant Contact). 5. The namespaces are mostly of the form "http://example.com/*", but it appears that they might be intended for wider use (not merely as examples). If so, I suggest using URNs in the ietf tree, or more stable URLs.
draft-arkko-ipv6-transition-guidelines
It like the IETF last call on this doc "ends 2010-12-27". Should it
be on this week's agenda?
Excellent document: thanks.
Holding a Discuss until the IETF LC completes
Nit Section 4.2 There are several types tunneling mechanisms s/types/types of/
This is a discuss-discus. To be clear, I am not asking for any changes in the
document with respect to this issue at this time.
Section 3, Principles, opens with the following statement:
The end goal is network-wide native IPv6 deployment, resulting in the
obsolescence of transitional mechanisms based on encapsulation,
tunnels, or translation, and also resulting in the obsolescence of
IPv4.
I do not think that these are the goals of someone deploying an IPv6 network on
the Internet. Their motivations
for deploying IPv6 are more likely focused on
address availability and the availability of specific features. Even
more than
that, most IPv6 deployments are more focused on ensuring connectivity with the
installed IPv4 base
than IPv6 purity. Citing obsolescence of IPv4 as a goal
makes the document less convincing to this reader.
I don't think refining the goals would change the set of transition strategies
to be discussed, but I think there is
a tone issue that results from the anti-
IPv4 goals.
A more actionable discuss issue: while this document doesn't create new security
issues, a discussion of the
relevant issues probably should take place in this
spec.
+1 on Ralph's discuss. In light of the Last Call closing 12-27, it seems premature to gauge IETF consensus.
This is a DISCUSS-DISCUSS, as I am not sure that the issue I am raising needs to
be reflected in this document, but I feel it is important enough to be raised
with the IESG in the context of this document. I would expect that a discussion
on the transition mechanisms to IPv6 includes a reference about the network
management tools that need to be used during the transition, and what would be
the requirements from the network management systems during the transition in
the different scenarios. One aspect of the problem is touched by in section 4.3
(addressability of managed systems) but this is only one of the multiple aspects
to be discussed. Is the place for such a discussion in this document?
I hate to just list a bunch of documents as references, but we've just reviewed
draft-ietf-opsec-ip-security and draft-ietf-v6ops-tunnel-security-concerns is
coming down the pipe. Should these and maybe some others you think are
important be listed in the security considerations?
draft-cheshire-dnsext-nbp
I think the document should be clearer whether these requirements
represent some kind of IETF consensus, or just opinions of the
authors. I'm guessing it's the latter, but this guess is mostly based
on the I-D file name (which won't be visible once this becomes an RFC).
I agree with Chris that Section 6 should be more realistic about the
security goals: things like determining the authenticity of received
information, or authority to request some information, can't usually
be done with zero configuration. Even with non-zero configuration, a
security solution that's realistically deployable in e.g. enterprise
environment probably has to be able to leverage existing
authentication and authorization infrastructure (things like Active
Directory, Kerberos, or internal PKIs come to mind). Besides, the
problem solved by DNSSEC (authenticating a hierarchical delegation
structure) is quite different from securing an AppleTalk NBP like
protocol (even if the messages re-use DNS formats).
Section 7 should probably be clearer what actions IANA is expected
to take when this document is approved (I'm guessing it's "none", but
then the text should say "This document has no IANA actions.").
[Holding a discuss for IANA]
This needs a ballot.
I found the security considerations weak, albeit tolerable for this sort of informational document. Some discussion of the usability/deployability/security tradeoffs between a zeroconf home network and a fully managed DNSSEC infrastructure would be informative. Further, I suspect it's a critical requirement to replace Appletalk NBP that "no security" be a protocol option since there's no way to get something with the same ease-of-use/ease-of-deployment profile in a home network. Right now there are two security options proposed: none or manually configured DNS unicast w/ DNSSEC. While I consider the "none" option very important since that's exactly the security I want to deploy on my home WLAN when it comes to this protocol (WPA2-AES is good enough for my home WLAN), there are scenarios where I might want some sort of middle ground without having to administer a DNS infrastructure. For example, "make sure I connect to the same file service as last time", or "make sure I use ipp/tls to the printer service and it's the same printer service I used last time". Has any sort of leap-of-faith SSH-style keying been considered within this framework? Indeed, in a large corporation with outsourced IT, getting competent DNSSEC management is probably not feasible so "grassroots" security might be more viable.
Section 3.15 (Immediate and Ongoing Information Presentation) describes user interface requirements rather than the underlying protocol requirements. I suggest revising this section in terms of the protocol requirements.
I find the name of the document and of the page headers completely misleading. IMO the name should be 'Requirements for Replacing AppleTalk Name Binding Protocol (NBP)'.
The rewritten security considerations include two points a) had the protocol been developed with security in mind then it would have been done differently b) when a new/modern version is designed the requirement is that it have security measures appropriate to the environment in which it will be used. Based on the changes, I'm changing to no objection.
draft-saito-mmusic-sdp-ike
I have no objection to the progress of this document, but I would like to check
two things with my fellow ADs.
I expect the RFC Editor would pick this up, but I wondered why this
document refers to RFC 4306 and not to RFC 5996.
I also wondered whether text (such as in the title and the Abstract)
should refer explicitly to "IKE v2" rather than "IKE".
draft-templin-iron
I am surprise that the document contains no reference to LISP which is operating broadly in this space. ======= SRA is not a defined abbreviation. ======= This needs a few words of clarification - presumably the "locator addresses" are the addresses learned from the relay. After the Client receives an SRA message from the nearby Relay listing the locator addresses of nearby Servers, it sends SRS test messages to one or more of the locator addresses to elicit SRA messages. ======= If this Server fails, the Client will quickly select a new one which will automatically update the VPC overlay network mapping system with a new EP-to-Server mapping. "quickly" is a non-specific metric ======= [I-D.templin-intarea-seal] looks like it should be normative [I-D.templin-intarea-vet] looks like it should be normative Although the RFCeditor may wish to overlook this if there is a concern that these drafts will not be taken to completion.
I have one suggestion about the content of the document. I'd like to see an analysis of how IRON actually "provide[s] scalable PI addressing without changing the current BGP [RFC4271] routing system" along with costs incurred by IRON. How does hiding the EPA addresses inside the IRON locator prefixes reduce the routes in the real Internet core? What is the cost in the routing tables maintained by the relays? How expensive is the anycast routing? How does inter-VPC routing work and how expensive is it? The remainder of my COMMENTs are editorial. In Section 6.1, I think I understand what this text is trying to explain, but I don't think it's correct: It is therefore essential that the Client send the initial packets through its Server to avoid loss of SCMP messages that cannot traverse a NAT in the reverse direction. Does this mean to explain that the Client sends packets through its Server to establish NAT state so SCMP messages from the Server to the Client can traverse the NAT? In Section 6.2, this text uses "into the Internet" in a confusing way, assuming I'm understanding the meaning of the text correctly: The Server then forwards the revised packet into the Internet via a default or more- specific route, where it will be directed to the closest Relay within the destination VPC overlay network. Everywhere else in this section "into the Internet" is used to describe the forwarding of a decapsulated datagram, after the outer header with locator addresses have been removed, into the (non-IRON) Internet. In the text quoted aboce, "into the Internet" seems to mean forwarding of an encapsulated datagram, which is described elsewhere in this section as simply "forwards" or "sends". I suggest rewriting, for consistency, as The Server then forwards to the closest Relay within the destination VPC overlay network. In Figure 6, why would the anycast datagram from Server(A) be delivered to Relay(B) rather than Relay(A) (which presumably would be in the routing fabric for ISP A)? Does it matter? Once Server(B) receives the datagram to be forwarded to Client(B), is it possible for Server(B) to send a redirect to Client(A) so Client(A) can send traffic directly to Client(B)? Stylistic nit in section 6.4.1 (and elsewhere) - why start using the verb "releases" instead of the previously used "forwards" or "sends"? Seems like lots of unnecessary verbiage right after Figure 6; why not something like "..., host A sends packets to host B through its EUN. Client(A), as the defautl router for the EUN, receives the packets, encapsulates them in the IRON encapsulation and forwards them to Server(A). ..." (etc.) All the explanation of routing, etc., seems redundant at this point. Sorry, can't help myself; in section 6.6: The IRON approach to renumbering avoidance therefore depends on VPCs conducting ethical business practices and offering reasonable rates. ... as opposed to the unethical business practices and unreasonably high rates from those evil, greedy ISPs. Seriously, has the renumbering problem simply been moved from the ISPs to the VPCs?
Thank you for bringing this work forward as Experimental and so increasing the documentation and discussion of potential solutions. I feel that it would be helpful if the document contained a pointer to draft- irtf-rrg-recommendation so that the other ideas in the field can be easily found and compared.