IESG Narrative Minutes
Narrative Minutes of the IESG Teleconference on 2010-04-22. These are not an official record of the meeting.
Narrative scribe: John Leslie (The scribe was sometimes uncertain who was speaking.)
Corrections from: (none)
1 Administrivia
2. Protocol Actions
2.1 WG Submissions
2.1.1 New Items
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
2.1.2 Returning Items
Telechat:
2.2 Individual Submissions
2.2.1 New Items
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
2.2.2 Returning Items
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
3.3 Independent Submissions Via RFC Editor
3.3.1 New Items
Telechat:
3.3.2 Returning Items
1254 EDT no break
4 Working Group Actions
4.1 WG Creation
4.1.1 Proposed for IETF Review
Telechat:
4.1.2 Proposed for Approval
Telechat:
Telechat:
4.2 WG Rechartering
4.2.1 Under evaluation for IETF Review
4.2.2 Proposed for Approval
5. IAB News We can use
6. Management Issues
Telechat:
Telechat:
Telechat:
7. Agenda Working Group News
1404 EDT Adjourned
(at 2010-04-22 08:33:12 PDT)
draft-ietf-sipping-config-framework
For what it is worth, I think the configuration model is overly complicated and some of the design decisions do not IMO work well in the Internet environment. For instance, I would prefer discovery and probing of the local network conditions as opposed to expecting there to be a SIP-specific configuration server that delivers such information. For instance, for most networks there will not be a reliable way to provide any information about available bandwidth, due to inability to estimate number of concurrent users, radio conditions, and so on.
Section 3.2., paragraph 5: > In more complex deployments, devices connect via a local network that > is not controlled by the SIP Service Provider, such as devices that > connect via available public WiFi hot spots. In such cases, local > network providers may wish to provide local network information such > as bandwidth constraints to the devices. If by "bandwidth constraints" you mean *available* bandwidth, that'd be a bad example - it's clearly not configuration data. Is there a better example or a better way to phrase this? Section 3.3., paragraph 5: > Additional profile types may also be specified. By whom? The IETF in future RFCs? Anyone out there deploying this framework? (Section 5.3.6 also doesn't make this clear.) Section 6.2.2., paragraph 1: > The > implementer SHOULD use their DNS domain name (e.g., example.com) as > the value of the "vendor" parameter so that it is known to be unique. If you leave this a SHOULD, you cannot depend on it being unique. (Because two vendors may decide to not follow the SHOULD and pick conflicting values.) Section 6.2.3., paragraph 1: > A value of 0 (zero) indicates that the subscribing > user agent must attempt to make the profiles effective immediately > (despite possible service interruptions). s/must attempt to/MUST/ Section 6.10., paragraph 1: > The rate of notifications for the profiles in this framework is > deployment specific, but expected to be infrequent. Hence, the Event > Package specification does not specify a throttling or minimum period > between NOTIFY requests If its expected to be infrequent, you can easily specify a minimum period that won't interfere with operation and will prevent accidental bursts due to misconfiguration, etc. Please do so?
[Updated DISCUSS]
I have some major concerns about lack of data model definition in this document.
Without that it is not possible to write 2 interoperable implementations. The
document says that specific configuration formats are going to be specified in
future documents. Are there any examples of such configuration formats?
[The remaining text is unchanged:]
I have a couple of very minor points and some questions about this document:
1)
5.1.1. Profile Enrollment
Upon failure to obtain the profile using any methods specified in
this framework, the device MAY provide a user interface to allow
for user intervention. This can result in temporary, one-time
data to bootstrap the device. Such temporary data is not
considered to be "configured" and SHOULD NOT not be cached across
resets.
Did you mean "SHOULD be cached" (the "NOT not" part)?
2) ABNF needs to be a Normative reference for this document.
5.2.1. Securing Profile Enrollment Transmission of sensitive profile data also requires message integrity. This can be accomplished by configuring the device with, or by ensuring that the discovery process during profile enrollment provides, a SIPS URI resulting in TLS establishment ([RFC5246]). TLS also prevents offline dictionary attacks when digest authentication is used. Thus, in the absence of TLS, the device MUST NOT respond to any authentication challenges. The last sentence: are you saying that Digest authentication MUST only be used over TLS? 6.2.1. profile-type Profile-type = "profile-type" EQUAL profile-value profile-value = profile-types / token profile-types = "device" / "user" / "local-network" So just to confirm, the values are case insensitive? 6.2.3. effective-by parameter Effective-By = "effective-by" EQUAL 1*DIGIT Does this value have an upper limit? 9.1. Local-network profile Alternatively, certain deployments may require the entities - device and the PDS - to authenticate each other prior to successful profile enrollment. Such networks may pre-configure user identities to the devices and allow user-specific local-network profiles. In such networks the PDS will support digest, and the devices are configured COMMENT: suggest changing "suport digest" to "support Digest authentication" or similar.
I support the discuss positions from Sean, Dan, Peter, and Alexey.
1. I share Alexey's concern about the difficulty of proving interoperability in
the absence of a data model. Actually my conern is even broader, there are so
many cases, and types of profiles, and the framework allows for newer types to
be added that I cannot really see how parts of this document can be tested for
interoperability. Maybe it would be useful to specify what of the whole text in
the RFC is normative - probably most of section 5 and section 6, but not more.
2. In the operational model describe in Figure 3 - I cannot understand the
difference between a 'Device Provider' and a 'Local Network Provider'. If a
device is pre-configured, than its configuration is not subject to the framework
(is it?). If not in all cases I know the 'device provider' is the same as the
network provider (which needs not be only local BTW). Actually networks are
configured by configuring devices.
3. I am unconfortable with the way bootstraping of devices is described in
Section 5.3.1. There are too many methods of doing the same thing, and there is
no requirement for a mandatory method for compliance. Which of the ways of
bootstrapping a device with the required identities and credentials is required,
or if more than one is supported which one is preferred?
4. I find the discussion about Device Types in section 5.3.3 rather expedited
and superficial in what concerns devices that do not directly communicate with
any users like gateways, media servers or SIP servers. These ones have other
functions than of an UA and may be configured by different methods and
protocols, not only the ones that are being mentioned in this document. How do
configuration operations that are performed part by using the framework, part by
using other protocols work together?
[new DISCUSSes added 2010-04-21]
In Section 5.1.4.2, the guidelines for generating a device identifier seem
overly complex. Why not simply re-use the Instance ID guidelines from Section
4.1 of RFC 5626, since the Instance ID is already a "URN that uniquely
identifies the device"?
In Sections 5.2.1 and 5.2.2, this specification references RFC 2818 (HTTP over
TLS) for authentication and server identity checking. Given that communication
here occurs over SIP, the normative reference really should be draft-ietf-sip-
domain-certs, not Section 3.1 of RFC 2818.
Section 2 uses the term "entity" inconsistently -- for example, a Device can "contain entities such as a DHCP client" but the term SIP Service Provider can "refer to ... "public entities". I suggest changing the first instance to "application" and the second to "services". Section 5.1.1 states: The device needs certain data to create an enrollment request, form a Request-URI, and authenticate to the network. This includes the profile provider's domain name, identities and credentials. What are the provider's credentials here? Does this in fact mean the device's or user's credentials with the provider? If so, please express this more clearly. Section 5.2 uses the term "privacy" when the term "data confidentiality" is meant. See RFC 4949 for details (and if possible please align the usage of security terminology with RFC 4949). Section 9.1 that "a PDS may not implement any authentication requirements or TLS". Does this mean that a PDS might happen to operate insecurely, or that it is allowed to (MAY) operate insecurely? Section 11 includes organizational affiliations. This information is not typically included in acknowledgements, since it goes against the IETF tradition of treating people as individuals, not as corporate representatives. In any case, many of the affiliations are out of date.
1) Section 5.3.5 says:
While this framework does not impose specific constraints on any such
framework, it does allow for the propagation of profile content to
the PDS (specifically the PCC) from a network element or the device.
Figure 1 does not show the interaction between the network element. Should
Figure 1 be updated or should Section 5.3.5 be fixed?
2) Sec 5.2.1 caused me to pause a bit. Sec 5.2.1 requires 3921 which requires
digest authentication (HTTP Digest) which uses MD5 (section 5.2.2 also requires
digest authentication). MD5 is well liked anymore. I'd like to see a security
consideration added that says something to the effect of: when RFC 3921 was
published MD5 might have been specified because it was "reasonable choice" but
it probably isn't anymore; use of another hash alg (e.g., SHA-256) is
preferred/recommended as specified in some sip document (not sure where it
should point).
3) The term "mandatory" is not defined and it seems to be specifying conformance
requirements. Please point to where it is defined or modify the text is Sec 6.2
with something like:
OLD:
m - mandatory
s - SHOULD be provided
o - optional
NEW:
m - MUST be provided
s - SHOULD be provided
o - OPTIONAL to be provided
1) 5.1.4.2: r/subscription URI/Subscription URI 2) 5.2: I noted the same thing as Peter did wrt the use of the term "privacy". 3) 5.2.1: I also noted the same thing Alexey did wrt to the use of Digest authentication over TLS. 4) 5.3.2: r/device must enroll/device MUST enroll 5) 5.3.2: I'd like to see some discussion about what happens when the device uses a cached device, user, and local network profile and it's no the same domain/local network which provided the cached data. 6) 5.3.4: r/This framework recommends the device profile to provide the identities and credentials due to a couple of reasons./This framework recommends the device profile provide the identities and credentials due to a couple of reasons. 7) 5.3.4: r/i.e., data that cannot be compromised/i.e., data that cannot be disclosed to unauthorized parties 8) 6.10: r/NOTIFY requests/NOTIFY requests. 9) 9: r/Compromise of sensitive data/Disclosure of sensitive data 10) 9: r/For sensitive data that should not be subject to snooping, privacy is also required./For sensitive data that should not be disclosed to unauthorized parties, privacy is also required. 11) 9.1: r/In such networks the PDS will support digest, and .../In such networks the PDS will support digest authentication, and ...
draft-ietf-opsawg-smi-datatypes-in-xsd
I am troubled by the fact that this does not cover InetAddress from
RFC 2851, i.e., only IPv4 addresses can be mapped. I realize that
the document says it only concerns itself with RFC 2578 datatypes,
but I do not think we should be publishing any RFCs in 2010 that
do not fully support both IPv4 and IPv6. Or is there some companion
document that defines the other types?
Acronyms such as SNMP and SMI should be expanded in the Abstract
Global nit
The phrasing is inconsistent when datatypes are named. Here are a few examples:
XSD datatype "hexBinary"
"hexBinary" XSD datatype
XSD "string" datatype
This is a nitpick, but a consistent phrasing is a little easier on the reader.
(1) I suspect this is clear to the expected audience, so this is a comment
rather than a
discuss, but I found sections 5.2 through 5.5 a bit confusing
since the simple types defined
in section 4 (e.g., OctetString and IpAddress)
seem to be used interchangably with their XSD base types.
Consider 5.5 as an example:
5.5. ObjectIdentifier
This XSD datatype corresponds to the SMI "OBJECT IDENTIFIER"
datatype.
The XSD "string" datatype is also the natural choice to represent an
ObjectIdentifier as XML output, for the same reasons as for the
IpAddress choice.
I did a lot of flipping back and forth between sections to sort this out. It
might be
clearer to say something like
5.5. ObjectIdentifier
The XSD datatype "ObjectIdentifier" corresponds to the SMI "OBJECT
IDENTIFIER"
datatype.
"Objectidentifier" has the XSD base type "string", which is the natural
choice to
represent an ObjectIdentifier as XML output, for the same reasons
as for the
IpAddress choice.
(2) Security Considerations nit
s/are likely to be relevant/will be relevant/
I think the regex for IpAddress could be shortened to something like this (but I
am not a regex expert!):
((0|[1-9]?[0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5])\.){3}(0|[1-9]?[0-9]|1[0-
9][0-9]|2[0-4][0-9]|25[0-5])
I have two comments wrt to this ID: 1) In the security considerations it says: "Security considerations for any given SMI MIB module are likely to be relevant to any XSD/XML mapping of that MIB module" Shouldn't the phrase "likely to be" be removed? When is it not relevant? 2) Is there any reason we can't refer to a later version of the ASN.1? I.e., instead of '87 point to '02?
draft-ietf-mmusic-rfc4756bis
With respect to having this document update RFC3388bis, I guess the reason is
that Section 4.5 of this document updates the ABNF syntax of the group attribute
by adding the new semantics values. The thing is that the complete ABNF syntax
for that attribute would need to include all the semantics that have been
registered by the IANA so far:
http://www.iana.org/assignments/sdp-parameters
I do not think it makes sense to update the ABNF syntax. Other RFCs that have
defined semantics values in the past have not done that. My suggestion would be
to remove Section 4.5 and avoid having this document update RFC3388bis.
Also, the last line of Section 4.5 contains a normative statement that is
already present in Section 4 of RFC3388bis. That statement should be removed as
well while removing the whole Section 4.5.
INTRODUCTION, paragraph 1:
> Updates: 4756, 3388bis, 5576 (if approved)
DISCUSS: I'd like to dissect the relationships between these documents
for a bit. First, does this ID really update 4756, but does not
obsolete it? I'm no media expert, but the way I read it, this seems to
be a complete replacement for 4756. Second, why is this document
updating a yet-to-be-published ID? It would be much less confusing if
3388bis were modified to directly include the changes that this
document makes to it.
Section 1., paragraph 1: > Any application that needs a reliable transmission over an unreliable > packet network has to cope with packet losses. Forward Error > Correction (FEC) is an effective approach that provides reliable > transmission particularly in multicast and broadcast applications > where the feedback from the receiver(s) is potentially limited. FEC doesn't provide complete reliability - it provides *improved* reliability under loss (compared to no FEC), but only to a certain loss rate. Section 3., paragraph 0: > 3. Requirements and Changes from RFC 4756 It would be good to also discuss how exactly this document updates 3388bis and 5576. (3388bis is mentioned, but at least to me it's unclear what the update here is; 5576 is not mentioned.)
Two of my Discuss issues overlap somewhat with points raised by other ADs. I
hope they can all be addressed with relatively small text changes.
---
RFC 4756 needs to be a normative reference (how else can you update it)
I would think that RFC 3388 should also be a normative reference since
I-D.ietf-mmusic-rfc3388bis is updated and itself updates RFC 3388.
---
Section 3.2
It is not clear from reading this section how there is any "Requirement
and Changes from RFC 4756" described.
I presume that [I-D.ietf-fecframe-framework] describes something that
cannot be provided by RFC 4756. The text should say so!
---
Section 4.3
Thus, the 'ssrc-group' attribute MUST only be used at the
media level [RFC5576].
This is fine, but you should describe (presumably with a simple
reference to 5576 error handling) what a receiver does if the
'ssrc-group' attribute is used at some other level.
---
Section 4.4
I find the backward compatibility section confusing. There seems to be a
fix of "does not understand" and "does not support". These are subtly
different cases (although the former inevitably encompasses the latter).
For "does not understand" I do not believe that this document can define
new behaviour. This is because the failure to understand indicates a
legacy implementation that will not implement any of this specification.
Thus, your description must give reference to some pre-existing
specification, and must describe what will happen according to that
specification (not what SHOULD happen according to this sepcification).
If you wish to allow a node that supports this specification (i.e.
"understads") to "not support" the function. Then this is a matter for
new specification. It is not a backward compatibility function, and
should be described in a separate section of the document.
A number of minor nits that you might fix to save the RFC Editor some time and effort. --- Throughout the document, please note that "semantics" should be used as a plural. --- Abstract s/are more than one/is more than one/ s/repair flows/repair flow/ --- Abstract Expand SSRC -- Section 1 OLD receivers choose receiving NEW ?? receivers choose to receive --- Section 1 Expand SSRC --- Section 3.1 OLD associate source and repair flows together NEW associate source and repair flows --- Section 3.1 This document also specifies how the 'group' attribute in SDP is used to group multiple repair flows with one or more source flows. Please insert reference for the 'group' attribute. --- Section 4.1 OLD If there are more than one repair flows NEW If there is more than one repair flow --- Section 4.1 s/transitive relation/transitive relationship/ --- Section 4.2 OLD If none of the repair flows are additive NEW If none of the repair flows is additive
1) I would like to support Lars's discuss regarding 3833bis - why is 3833bis
simply not modified to include the grouping semantics?
2) "the FEC framework requires the source and repair packets to be carried in
different streams." Can you provide a reference for that statement? I'm new to
fecframe, but I read the framework and missed where it said that.
3) If fecframe DOES require this, I will want to understand why it is REQUIRED,
and why this spec should be allowed to ignore the requirement.
1) "It should be noted that" - if you include the rest of the sentence, then it IS noted, so this clause can be eliminated.
Please consider the Gen-ART Review comments from David Black: The IPv4 addresses used in the examples are not from the 192.0.2.0/24 block of addresses for examples - they appear to be IP Multicast addresses, and I'm not sure what IP Multicast addresses are appropriate for use in examples. The 3388bis entry on the Updates: line on the title page is novel. Please add an RFC Editor Note to the Abstract asking the RFC Editor to replace that with the RFC number assigned to draft-ietf-mmusic-rfc3388bis-04 when it is published.
I have a couple of comments I would like to discuss before recommending approval
of this document:
1) 4.4. SDP Offer-Answer Model and Backward Compatibility Considerations
When a node is offered a session with the "FEC-FR" grouping semantics
but it does not support line grouping or the FEC grouping semantics,
the node SHOULD respond to the offer either:
How can a document put a requirement on an implementation that doesn't comply
with this document? I think the possible responses listed later in this section
just follow generic behaviour for a responder that doesn't understand the offer.
(Please correct me if this is not correct.) If that is the case, then I think
you need to replace the uppercased SHOULD with an informative text, ideally
pointing to the document that defines the behaviour.
However, if the node does not understand the "FEC" semantics, it
SHOULD respond to the offer either (1) with an answer that ignores
the grouping attribute, or (2) with a refusal to the request. In the
first case, the sender MUST send a new offer without FEC.
As above.
2) 4.5. ABNF Syntax:
group-attribute = "a=group:" semantics
*(space identification-tag)
I can't find the document where <space> is defined.
semantics = "LS" / "FID" /
"FEC" / ; from [RFC4756] for backward
; compatibility
"FEC-FR" ; from [RFCXXXX]
identification-tag = token
You should specify where <token> is defined. I think you meant RFC 4566.
Please add an ABNF comment to make the clear.
I support Alexey's discuss with respect to section 4.4.
Please spell out "SSRC" on first use. The text "It is RECOMMENDED that the receiver SHOULD do integrity check" is conformance language overload; it is sufficient to say "The receiver SHOULD perform integrity checks..."
Two nits on the security considerations: 1) r/failure of FEC to protect, and/or mishandling of other media payload streams/failure of FEC to protect, and/or mishandle other media payload streams 2) r/do integrity check/do an integrity check
draft-ietf-sipcore-info-events
Abstracts should not contain references.
Section 7.3., paragraph 2:
> Some applications, like sending of DTMF tones, can generate a burst
> of up to 20 messages per second. Other applications, like constant
> GPS location updates, could generate a high rate of INFO requests
> during the lifetime of the invite dialog usage.
>
> Furthermore, SIP messages tend to be relatively small, on the order
> of 500 Bytes to 32K Bytes. SIP is a poor mechanism for direct
> exchange of bulk data beyond these limits, especially if the headers
> plus body exceed the UDP MTU [RFC0768]. Appropriate mechanisms for
> such traffic include HTTP [RFC2616], MSRP [RFC4975], or other media
> plane data transport mechanisms.
DISCUSS: I'd argue that SIP is a poor mechanism for exchanging data
starting with much less than 32KB of data... But the issue I was going
to raise is broader: I'm really missing a statement in this document
that more strongly discourages the sending of frequent or large (and
especially frequent and large) INFO requests/responses. Folks simply
need to understand that the reliability and timeliness of SIP
exchanges can go down in the real world with the size and the rate of
the messages, if UDP is used, and depending on the path. I thought for
a while whether I really want to make this a discuss instead of a
comment, since this issue is a general SIP problem. I decided to make
this a discuss, because unlike other SIP extensions, this one is
completely under the control of the applications, and the application
writers do need to understand the tradeoffs here.
Please consider the Gen-ART Review comments from Brian Carpenter: As a newcomer to the topic, I found the guidance on when to choose the Info-Package mechanism and when to choose an alternative (Section 7) a little weak. I didn't get a strong sense of when it would be clearly idiotic to choose Info-Package (except for bulk data transfer). Maybe an Informational document on this would be helpful. Otherwise, the mechanism seems at some risk of becoming a catch-all for proprietary extensions.
I've reviewed the document and have a small list of issues I would like to
discuss before recommending approval of this document:
1) 10.6. SIP Option Tags
The Info Package specification MAY define SIP option tags, which can
be used as described in [RFC3261].
The registration requirements for option tags are defined in
[I-D.peterson-rai-rfc3427bis].
This reference looks Normative, because an INFO package designer might have to
comply with it.
2) 10.5. Info Package Parameters
NOTE: Info Package parameters defined for specific Info Packages can
share the name with parameters defined for other Info Packages, but
the parameter semantics are specific to the Info Package for which
they are defined.
DISCUSS DISCUSS (will most likely clear once discussed with IESG): Is this
actually a good idea?
3) 11.4. Creation of the Info Packages Registry
The following data elements populate the Info Package Registry.
o Info Package Name: The Info Package Name is a case insensitive
token.
This is in contradiction with a statement in section 6.2:
That is, the Info Package name is case sensitive.
In addition, IANA shall not register multiple Info Package
names that have identical case-insensitive values.
4.2.2. UA Procedures For backward compatibility purpose, even if a UA indicates support of the Info Package mechanism, it is still allowed to enable legacy INFO usages Appendix A. Did you mean to reference Appendix A or Section 9 here? Suggested change in Section 4.2.3: OLD: Similar to SDP answers, the receiver can include the same Recv-Info header field value in multiple responses (18x/2xx) for the same INVITE/re-INVITE transaction, but the receiver MUST NOT include a Recv-Info header field value which is different from a value that the receiver has already included in a response for the same transaction. NEW: Similar to SDP answers, the receiver can include the same Recv-Info header field value in multiple responses (18x/2xx) for the same INVITE/re-INVITE transaction, but the receiver MUST use the same Recv-Info header field value (if included) in all responses for the same transaction.
I support Lars' DISCUSS.
This is a "discuss-discuss" to air some issues that I'm sure have already been
part of the long conversation within the WG.
This document has a dysfunctional relationship with what it labels legacy INFO
usage. Given that legacy INFO usage is so widely considered harmful, it would
help motivate advancement to Proposed Standard if this document provided a more
detailed description of legacy INFO usage and how the WG came to the conclusion
that some uses of INFO for exchange of application data are in fact not abusive.
The WG summary is quite helpful in this regard and similar text could be
included in this document. I would also recommend Appendix A and Section 9 to
that same area of the document because right now the discussion is quite
fragmented.
I realize that the foregoing is somewhat vague. More specifically, I am
concerned about two interrelated issues : (1) interoperability and (2)
migration.
1. Regarding interoperability...
1a. In Section 9.2, the following text is potentially misleading:
Since legacy INFO usages do not have associated Info Packages, it is
not possible to use the Recv-Info and Info-Package header fields with
legacy INFO usages. That is, a UA cannot use the Recv-Info header
field to indicate for which legacy INFO usages it is willing to
receive INFO requests, and a UA cannot use the Info-Package header
field to indicate for which legacy INFO usage an INFO request is
associated with.
As explained in Section 3.2.2, that is not quite true:
If a UA receives an INFO request associated with an Info Package that
the UA has not indicated willingness to receive, the UA MUST send a
469 (Bad INFO Package) response (see Section 11.6), which contains a
Recv-Info header field with Info Packages for which the UA is willing
to receive INFO requests.
It would be clearer to also say in Section 9.2 that UAs can indicate which
packages they support by sending a Recv-Info header in error responses and in
invites.
1b. In Section 9.2, the following text does not clearly describe how the use of
Info-Package overcomes the interoperability problems with legacy INFO:
Due to the problems described above, legacy INFO usages often require
static configuration about for what type of applications and contexts
UAs support the INFO method, and the way they handle application
information transported in INFO messages. That has caused
interoperability problems in the industry. Therefore, a need for a
well defined and documented description of what the information sent
in the INFO is used for has been identified.
Describing how Info-Package solves the interop issues might help motivate
migration away from legacy INFO, which I take to be the main reason we're
considering this spec in the first place.
2. Regarding migration...
2a. In Section 9.1, the following text is not particulately helpful:
For backward compatibility purpose, this document does not deprecate
such usages, and does not mandate users to define Info Packages for
such usages. However, any new usage of INFO SHALL use the Info
Package mechanism defined in this specification.
Unfortunately, we cannot legislate that any new usage of INFO must, shall, will,
or ought to use Info-Package.
2b. In Section 9.3, the following text is not strong enough:
UAs are allowed to enable both legacy INFO usages and Info Package
usages as part of the same invite dialog usage.
This document needs to more strongly encourage user agents to prefer Info-
Package usage over legacy INFO usage (e.g., if you receive Info-Package and
legacy in an invite, prefer Info-Package). In general, this document provides
few incentives for applications using legacy INFO to migrate toward Info-
Package; preferring Info-Package over legacy might help.
In Section 4.2.4, we find the following text: If the receiver of a request which contains a Recv-Info header field rejects the request, both the sender and receiver of the request MUST roll back to the set of Info Packages which was used before the request was sent. This implies that an application must cache the previous Recv-Info data rather than overwriting the old data when it receives the new data. Was this intentional? In Appendix A, please spell out the acronyms on first use -- I doubt that many people know the identity of technologies like ISUP, QSIG, MSCML, or MSML. Also, does the DTMF usage belong here? (See DISCUSS about putting this information together in one section to motivate the discussion.)
I support Lars' DISCUSS position. Sec 6.1: Define "Mandatory". If its meaning is taken from RFC 3291 add something like "Mandatory (as defined in RFC3261) ...."
draft-ietf-netmod-yang-types
This is an excellent, carefully written spec. I do have a few issues,
a couple of small bugs and few others that I would like to talk about
before recommending the approval of this specification. My main issue
is with the patterns and my (in)ability to verify them. The issues
are also related to what the specification draws in from the SNMP
world and what kind of assumptions are valid there (OID value spaces,
for instance). Unfortunately I am not an SNMP expert, so please help
me understand this better.
Section 1:
+-----------------+-----------------------------------------------+
| YANG type | Equivalent SMIv2 type (module) |
+-----------------+-----------------------------------------------+
...
| ip-address | - |
| ipv4-address | - |
| ipv6-address | - |
What about InetAddress, InetAddressIPv4, and so on (RFC 2851)?
It seems that there is a corresponding type, so shouldn't it be
listed in the table above?
Various types use extensive pattern definitions. For instance, the
object identifier definition has this pattern:
pattern '(([0-1](\.[1-3]?[0-9]))|(2\.(0|([1-9]\d*))))'
+ '(\.(0|([1-9]\d*)))*';
I must say that while eat regexps for breakfasts daily, this one was
a bit too much to chew on. And this is probably simplest one in the
draft! Shouldn't the description fields at least explain what the
patterns are indicating?
Also, AFAICT this pattern restricts what numbers the OIDs can begin
with. Do those restrictions match what the various ISO and IANA
registries on this matter say? For instance, does the pattern say
that the first OID value must be a 0, 1 or 2? Why?
This definition:
typedef ipv6-address {
type string {
pattern '((:|[0-9a-fA-F]{0,4}):)([0-9a-fA-F]{0,4}:){0,5}'
+ '((([0-9a-fA-F]{0,4}:)?(:|[0-9a-fA-F]{0,4}))|'
+ '(((25[0-5]|2[0-4][0-9]|[01]?[0-9]?[0-9])\.){3}'
+ '(25[0-5]|2[0-4][0-9]|[01]?[0-9]?[0-9])))'
+ '(%[\p{N}\p{L}]+)?';
pattern '(([^:]+:){6}(([^:]+:[^:]+)|(.*\..*)))|'
+ '((([^:]+:)*[^:]+)?::(([^:]+:)*[^:]+)?)'
+ '(%.+)?';
}
description
"The ipv6-address type represents an IPv6 address in full,
mixed, shortened and shortened mixed notation. The IPv6
address may include a zone index, separated by a % sign.
The zone index is used to disambiguate identical address
values. For link-local addresses, the zone index will
typically be the interface index number or the name of an
interface. If the zone index is not present, the default
zone of the device will be used.
The canonical format of IPv6 addresses uses the compressed
format described in RFC 4291 section 2.2 item 2 with the
following additional rules: The :: substitution must be
applied to the longest sequence of all-zero 16-bit chunks
in an IPv6 address. If there is a tie, the first sequence
of all-zero 16-bit chunks is replaced by ::. Single
all-zero 16-bit chunks are not compressed. The canonical
format uses lower-case characters and leading zeros are
not allowed. The canonical format for the zone index is
the numerical format as described in RFC 4007 section
11.2.";
Uses its own definition of a canonical format, but wouldn't referencing
draft-ietf-6man-text-addr-representation be more appropriate? That
draft has been stuck for a while, but has cleared almost all discusses
now, FYI...
Also, this is just a comment but I have serious trouble mapping
the complex pattern definitions to other things, such as the
canonical text representation rules. How do we know that the
patterns are correct?
From the definition of a date object:
using the following ABFN (replacing double quotes with
Did you mean ABNF (Augmented Backus-Naur Form) instead? You should also
expand the acronym and add a reference.
[RFC3490] Faltstrom, P., Hoffman, P., and A. Costello,
"Internationalizing Domain Names in Applications (IDNA)",
RFC 3490, March 2003.
Should this be pointing to IDNA 2008?
Sec 2: r/overview over/overview of Sec 2: r/(if any)/(- indicates there is no corresponding SMIv2 type) X2
draft-freed-sieve-notary
The following spurious text appears in the IAN section:
To: iana@iana.org
Subject: Registration of new Sieve extensions
There are a couple of error conditions described...
Section 4
The envelope test's ADDRESS-PART argument assumes the string being
tested has the syntax of an email address. None of the new envelope
parts defined here have address syntax, accordingly, it is an error
to specify an ADDRESS-PART argument in conjunction with these new
envelope parts.
Section 7
It is an error to specify :bymode and :bytrace without :bytime.
You should say how these errors are handled. This may be as simple as a
reference to another RFC.
Section 1 For clarity, I suggest... s/users may not be allowed/users might not be allowed/ or s/users may not be allowed/users are not allowed/ --- Section 1 s/sieve/Sieve/ --- Section 4 OLD None of the new envelope parts defined here have address syntax NEW None of the new envelope parts defined here has address syntax
Please consider the Gen-ART Review comments by Spencer Dawkins: Section 7, redirect-deliverby extension, says: > > :bytime specifies the number of seconds within which the message > should be delivered. :bymode specifies whether a notification should > be sent or the message simply returned if the time limit is exceeded. > The default is "return" if :bymode is not specified. See The > semantics of delivery time limits are specified and discussed at > length in [RFC2852]. > Spencer said: I'm not sure if this is a cut-and-paste error or if you really meant to say something that got left out, but someone smarter than I am needs to look at the "See The" here.
Holding DISCUSS on a part of SecDir review by Tero Kivinen:
Also in section 5, it should be made clear that the "bytime" can also
be negative, if the bymode is "notify" and the message is already
pasts is notification time.
Section 5 also says that the "bytime" is "the initial integer part of
the
delive-by extension", but then comments that deliver-by by-time is
decremented
as message passes through the transport infrastructure.
This does not make it
clear whether the sieve filtering system should
also decrement the number while
message is waiting to be processed.
I.e. if message was received earlier, but it
took some time before the
sieve email filter could be run on the message, should
the "bytime" be
the original time from the smtp MAIL FROM BY= part, or whether
it is
decremented.
(This needs to be clarified for both "envelope-deliverby" and
"redirect-deliverby", because the answer is likely to be different for them.)
Also the example in 5.1 is wrong, as it is only true if the sieve
filter is run exactly when the deliver-by expired. It should compare
whether the "bytime" is <= 0, not whether it is equal to 0 (note, that
if the bymode is "return" then the "bytime" never should reach 0, as
at that point mail is returned to the sender.
In section 7 it should be made clear that ":bytime" parameter "<limit:
number>" can be negative too, but it seems that RFC 5228 specifies
that numbers can only be non-negative so I am not sure whether the
usage is correct or not.
Section 5. The first paragraph states: The "envelope-deliverby" extension does not define any new tests or actions, rather, it adds three values to the list of possible (case- insensitive) envelope-part strings defined in Section 5.4 of [RFC5228]. but the text following the list of envelope-part strings states: All of these tests fail unconditionally if ... perhaps the following substitution would be clearer: OLD All of these tests fail unconditionally if the BY SMTP MAIL FROM parameter does not exist for the current message or recipient. NEW The envelope test fails unconditionally for each of these envelope-part strings if the BY SMTP MAIL FROM parameter does not exist for the current message or recipient.
I support Alexey's DISCUSS position.
draft-ietf-pce-pcep-p2mp-extensions
The text under figure 2 looks to be incorrect, the length in the IPv6 case is
surely n*16 + 4, and not n*16 bytes.
The following text ==== Four values are possible for the leaf type field: 1. New leaves to add; 2. Old leaves to remove; 3. Old leaves whose path can be modified/reoptimized; 4. Old leaves whose path must be left unchanged. ==== Is almost identical to the text two lines above, and the list entry numbers are I think the values, but this is not a clear way to show it. If the authors think there will ever be more than 4 operations, they should consider using a registry.
1) section 3.1.1 discusses advertising P2MP by setting bit 10 (TBA by IANA), but
this request is not made in the IANA section. Later text
2) cut and paste error in section 3.5
s/PCReq/PCResp/
3) in 3.7, if a PCE ... understands the P2MP flag, but the PCE is not capable
..., it must send a PCErr ...". The P2MP flag can be set to mean "this is not a
PCReq/PCRep for P2MP" (section 3.3.1). So if the PCE understands this is not a
request for P2MP and the PCE cannot do P2MP, why is that an error?
4) in 3.7, if teh PCE does not understand the P2MP flah, it is required to send
a new error type. If, say, an existing implementation doesn't understand the
P2MP flah because it doesn't support P2MP, why do we think it supports the new
error type defined in the P2MP spec?
5) in 3.8, is the current behavior (in implementations that have not implemented
the P2MP spec) to reject the request?
6) in 3.10, "it SHOULD be possible", does this mean "implementations SHOULD
support the optimization functionality defined in this document"? or is
implementation of the optimization functionality defined in this document
REQUIRED for compliance? Can you make sure the document is clear on that point?
7) throughout 3.10, the word "must" is used; shoudl this be MUST in an RFC2119
sense?
8) "To remove old leaves the user must ..." - is it possible to get an error
because there are no leaves that can be removed? I note that error 17 value=1 is
for "no END-POINTS with leaf type 2". I am not quite sure when that error
occurs.
9) in 3.10, "The PCC must also provide the list of old leaves and indicate if
they should be reoptimized or not ..." What if the PCC knows that the PCE does
not support reoptimization? Is it still required? What if the PCC doesn't care
whether it gets reoptimized or not? Why is it required that the PCC provide
this?
10) In 3.10, what error code is returned if the PCC does NOT provide any type 3
or type 4? Should it return an error 17 value=2, or error 17 value=3?
11) in a pruning operation, what error is returned if a leaf is specified in
both the END-POINTS type 2 and END-POINTS type 4?
(or type 2 and type 3)?
12) in an add operation, what error is returned if a leaf specified in type 1
already exists?
13) in 3.12, "This specification also defines two new flags to the SVEC object".
Where? I didn't find any mention of SVEC or P and D flags in the IANA section.
The sections says it is in 6.2, but 6.2 defines the F,N,E flags in the RP
Object.
14) in 3.13.2 Response Fragmentation, a couple cut and paste errors:
"If the
response is too large ... the PCE will split the request ..."
"Each message sent
to the PCE ... to signify the response has been fragmented ..."
15) in 3.13.3, I think the example text is ambiguous
"RP2 with Req-ID1 and P2MP flag and F bit cleared."
Does this mean the P2MP flag is cleared as well as the F bit?
You might be clearer if you used something like:
RP2 with ReqID=1, P2MP=1, Fbit=0.
16) in 3.13.3, "To handle the scenario ... it should send an error message to
the sender ..." What error message should it send?
17) in 3.14, why is the list of unreachable destinations optional?
18) in 3.14, it is not obvious to me where this body goes inside the PCRep
message format. This might be my lack of understanding of other standard PCEP
objects, but PCRep is defined in 3.5. Where does the class and type associated
with the body get specified in PCRep?
19) "This object can be present in PCRep messages. There can be up to one such
object per RP." Maybe I just haven't found this yet. Can I have more than 1 RP
in a PCRep?
20) in 4.1 "MAY be required" - I don't know what that means in terms of RFC2119
compliance.
Could the requirements list be made of sentences? I don't know how
to interpret these non-sentences - both, although the first I think I can figure
out. The second I definitely do not understand:
21) "Advertisement of P2MP path computation capability enabled or disabled" -
does this mean I must be able to enable/disable the advertisement of the
information, or that I must advertise whether the capability is
enabled/disabled?
22) in 4.2, "MIB objects MUST be supported" - what MIB objects? Are these
standardized? Where are they specified? Is there a reason to not include the
relevant MIB objects in this document?
23) in 4.4, how does on everify correct operation of P2MP calculation?
24) in 4.5, "A new flag (value=10) could be defined ..." But this document does
not do so, and I think this is the same flag mentioned in 3.1.1 (TBA by IANA)
that isn't defined here.
25) in 5, "... and the implementer utilize ..." - is this the operator that
needs to utilize, or the implementer?
I found the document difficult to read and review.
The requirements section 2 doesn't use sentences, so it is difficult to
understand what the requirements actually are without going to the REQS
document; if you need to do that anyway, why bother summarizing here?
I expected that the summary was provided because the following text would refer
to speciifc requirements that were being met, but it doesn't. So I am not sure
of the value of having the summary here.
The document contains quite a lot of redundancy (some from cut-and-paste
operations). For example, the first sentences of 3.4 and 3.5 say the same thing
in different words:
"The PCReq message is encoded as follows ..."
"Below is the
message format for the request message:"
The document uses inconsistent terminology. I was looking to verify the IANA
requests, and the text in 3.1.2 describes "The TLV Type number (TBA by IANA)
...". In the IANA section, "TLV Type numbers" are not discussed. You need to
look in the "P2MP Capability TLV" section, where the "PCEP TLV Type Indicators"
registry is discussed. This type of inconsistency just makes it hardedr to read
and understand the document.
3.1.2 discusses a TLV, and then decribes the type and value; where's the label?
/Note that/ is almost never needed.
Purely a style issue, but in 3.3.1, I would have put the description of the
F-bit ("The F bit is added") with the description fo the enumarted values of the
F bit. Ditto, the N and E bits.
F bit enumeration (1) "... the receiver needs to wait until it receives an RF
with the same RP-ID and with the F bit is set to 0." Should it also wait for
possible additional fragments until is does receive one with an f bit of 0?
in 3.4, the last sentence says "must be present in this definition." In the
definition or in messages?
in 3.5, where is <end-point-pair-list> defined? I see <end-point-rro-pair-list>
and <end-point-path-pair-list>, but not <end-point-pair-list>.
in 3.7 (and elsewhere), "... computation request must then be cancelled." How
does one cancel a P2MP request? Is there a reference?
in 3.8, "if a PCC inadvertently sends a P2MP request ..." - what happens if a
PCC maliciously and deliebrately sends a P2MP request? I think it would be
better to reword this so it is not about the PCC, but just about the PCE. "If a
PCE receives a P2MP request, and the PCE does not support P2MP ... extensions,
then it should reject the request." But even better yet, shouldn't it already
reject requests it doesn't understand? So this section shouldn't even be needed,
right?
section 3.9 discusses a reoptimization request expressing a cost-benefit
reoptimzation threshold. But that functionality is not defined here and "may be
addressed in a future document." Is there soemthing specific about such a
function that MUST be discussed here to ensure that implementations do not
preclude such a future functions? If not, then why bring it up in this document?
Let the future document discuss this possible new function.
in 3.10, there is no case 4.
I recommend you use case#s OR figure #s, but not
both. Having both is redundant and potentially confusing to readers.
in 3.12, pleae provide a reference for SVEC.
in 3.12, consistency would be nice: Diversity bit, or Diverse bit?
in 3.13, s/thousands of leaves. Then/thousands of leaves, then/
in multiple places s/indentify/identify/
some of the text in 3.13, 3.13.1, and 3.13.2 is redundant. It might be best to
just have it in 3.13. If you want it in 3.13.1 and 3.13.2, then you don't need
it in 3.13.
in 3.13.3 "The assumption is that ..." - would that be better as "The assumption
used for this example is that ...". I assume that is the reason for the
assumption; otherwise please explain why this assumption is made.
in 6.1, I recommend s/P2MP Capability TLV/PCEP TLV Type Indicators/
in 6.5, for some reason, the HTML bold formatting is lost.
In the document
text, this is sometimes called Objects and Values rather than PCEP objects. I
would be helpful to be consistent.
The security considerations state:
As described in [PCE-P2MP-REQ], P2MP path computation requests are
more CPU-intensive and also use more link bandwidth. Therefore, it
may be more vulnerable to denial of service attacks. Therefore it is
more important that implementations conform to security requirements
of [RFC5440], and the implementer utilize those security features.
I agree with this summary entirely, with one exception: my reading of the
security considerations in 5440 indicates that these mechanisms are all
optional with the sole exception of TCP-MD5, so "conform[ing] to the
security requirements of [RFC5440]" isn't as productive as it sounds.
I think that this section should call out the mechanisms in 5440 that are
most important for addressing the attacks noted in the current text. I would
expect the new text to be brief since 5440 already provides a nice overview
of the mechanisms.
The DISCUSS is partially based on issues raised initially by Fred Baker in the
OPS-DIR review.
> 4.2. Information and Data Models
> As described in [PCE-P2MP-REQ], MIB objects MUST be supported for
> PCEP extensions specified in this document.
As the existing PCEP MIB document
(http://tools.ietf.org/html/draft-ietf-pce-
pcep-mib-01) does not support P2PM, it was agreed by the WG at IETF77, to create
a new PCEP MIB module specifically to support PCEP P2MP. If such a MIB document
already existed it would be good to be included as an Informative Reference.
Otherwise some text should be added to 4.2 on this respect.
> 4.6. Impact on Network Operation > It is expected that use of PCEP extensions specified in this document > does not have significant impact on network operations. While the addition of PCEP-P2MP extensions may have minimal impact on the level of traffic and operations, the applications that are enabled by activating these extensions may result in increased traffic and operational complexity.
PCEP requires use of TCP-MD5 with recognition of its failings, specifically
mentioning that TCP-AO was not yet complete. But as TCP-AO has now passed the
IESG, should there be some recognition of that change?
This is DISCUSS-DISCUSS (i.e, nothing for the authors to do at this time):
This doc does not seem the proper place to change the PCEP recommendation, but a
change in the MUST requirement in PCEP (RFC5440) seems to be something to
consider somehow.
I support Tim's DISCUSS position too. Some new comments based on Russ Mundy's SECDIR review: 1) RFC4875 Security Considerations requires that the ingress LSR of a P2MP TE LSP the leaves for the P2MP LSP for use in multi-vendor deployments. Although it's not clear that this document needs to provide this requirement, I wanted to flag the requirement in case that it had been overlooked.
draft-ietf-avt-register-srtp
I could not figure out what SRTP meant until I found it in the table of references at the bottom of the document, nor was it completely clear until that point that it was defined by RFC3711
Section 7.1., paragraph 4: > [SDESC] IANA, "SDP Security Descriptions: SRTP Crypto Suite > Registrations", December 2009, <http://www.iana.org/ > assignments/sdp-security-descriptions>. Not sure if an IANA URL can be a normative reference. Cite the RFC that created it, maybe?
Some minor points if you have the document open for revision... -- There are two assertions in Section 1 that I would prefer to see backed up with references... It is desirable to extend SRTP and its keying mechanisms to support country-specific cryptographic transforms. existing documents require extensions to SRTP and extensions to SRTP keying to be published as Standards-Track RFCs I think Dan caught the second of these. --- Call me a pedant, but Section 2 says... This document updates Section 6 and Section 12 of [RFC3711], which currently require a standards track RFC to define a new SRTP transform. I have written many standards tracj RFCs that did not define SRTP transforms. I think you mean... This document updates Section 6 and Section 12 of [RFC3711], which currently require a standards track RFC be used to define a new SRTP transform. --- Please decide whether "informaitonal RFC" and "standards track RFC" are capitalised or not, and then be consistent. ---
section 3 - why not just eliminate this section, and move the security considerations section to be numbered section 3? I don't think there is any rule that says security consideration must follow the ian considerations section. section 4 s/transforms is/transforms are/ s/this specifications/this specification/
I think that the same approach used in CMS, TLS, and IPsec should be
used here too. That is, algorith specifications are published as
Informational RFCs or published by some other standards body that can
be referenced (such as NIST FIPS Publications). Then, a standards
track RFC specifies the conventions for using of the algorithm in a
the particular security protocol.
I provide two examples below for the Camellia Encryption Algorithm and
the SEED Encryption Algorithm. For SRTP to support these algorithms,
I would envision a standards-track RFC being written that specifies
the conventions for using the algorithm and makes any necessary IANA
registry additions. This standards-track RFC would normatively
reference the informational RFC that is already published using the
procedures specified in RFC 3967.
CAMELLIA EXAMPLE:
RFC 3713 (INFORMATIONAL): A Description of the Camellia Encryption
Algorithm.
RFC 3657 (PROPOSED STANDARD): Use of the Camellia Encryption
Algorithm in Cryptographic Message Syntax (CMS).
RFC 4132 (PROPOSED STANDARD): Addition of Camellia Cipher Suites
to Transport Layer Security (TLS).
RFC 4312 (PROPOSED STANDARD): The Camellia Cipher Algorithm and Its
Use With IPsec.
RFC 5581 (INFORMATIONAL): The Camellia Cipher in OpenPGP.
SEED EXAMPLE:
RFC 4009 (INFORMATIONAL): The SEED Encryption Algorithm.
(Obsoleted by RFC4269)
RFC 4269 (INFORMATIONAL): The SEED Encryption Algorithm.
RFC 4010 (PROPOSED STANDARD): Use of the SEED Encryption Algorithm
in Cryptographic Message Syntax (CMS).
RFC 4162 (PROPOSED STANDARD): Addition of SEED Cipher Suites to
Transport Layer Security (TLS).
RFC 4196 (PROPOSED STANDARD): The SEED Cipher Algorithm and Its Use
with IPsec.
2. Update to RFC3711 This document updates Section 6 and Section 12 of [RFC3711], which currently require a standards track RFC to define a new SRTP transform. After publication of this document, new SRTP transforms can be defined using either an informational or standards track RFC. I think it would be good to clarify that that means an AD sponsored Informational RFC. I.e. an Independent Submission via RFC Editor doesn't count. (I know that that is clear in the IANA Consoderations section.)
> However, existing documents require extensions to SRTP and extensions to SRTP keying to be published as Standards-Track RFCs. For clarity and consistency with the previous phrase where [RFC2026] is explicitely mentioned, it would be better to specify here what documents are referred ([RFC3711] and [RFC4568] ).
This is a discuss-discuss (i.e., nothing for the authors to do - at this time):
Doesn't RFC 3967 | BCP 97 explain how standards track documents can normatively
point to (i.e., use) informational track documents? In other words, I'm not
entirely sure why this ID is needed at all because I think the text in RFC 3967
| BCP 97 trumps whatever text is in RFC 3711. If the WG wants to allow
SRTP/SCRTP to use an informational track algorithm RFC, then the WG publishes an
RFC that says STRP can use said informational RFC, calls out this DOWNREF in a
WG LC (and possibly again in an IETF LC), and they're done. Is there some other
background I'm missing?
I'd really like to see the set of OLD/NEW text for the sentences that you want changed. It's pretty clear in section 6 what you want to change, but I don't see where there's a MUST in section 12 for algorithm documents to be standards track.
draft-ietf-mip4-rfc3344bis
Jari tells me that the Erratum has now been rejected based on WG consensus. I will clear my Discuss.
The Gen-ART Review by Miguel Garcia on 2010-03-08 raised a few
editorial issues. Please consider them. I would really like to
see the comments about Appendix G addressed, so it is repeated
here for convenience:
- The structure of Appendix G is a bit confusing. Section G.1 lists
the changes made since RFC 3344. Sections G.2 and G.3 list the Major
and Minor Changes, respectively, but it is not clear to me if these
are changes since RFC 3344 or they include earlier changes as well.
To add more confusion, Section G4 lists the changes since RFC 3344,
but wasn't this what Section G.1 is all about?
Two comments: 1) Sec 1.6: It's a little ODD that there's a requirement in the terminology section (see SPI paragraph). Can this be moved to somewhere else in the document? 2) Sec 1.9: r/it is recommended that new Mobile IP extensions follow one of the two new extension/it is RECOMMENDED that new Mobile IP extensions follow one of the two new extension ?
draft-nottingham-http-link-header
[TBD]@ietf.org and [TBD-2]@ietf.org mailing lists need to be created and an RFC Editor Note needs to ask them to substitute the final names.
This is a discuss-discuss. To be clear, I am not asking for any change in the
document at this
time.
Is there any precedent for the following text?:
Within at most 14 days of the request, the Designated Expert(s) will
either approve or deny the registration request, communicating this
decision to the review list. Denials should include an explanation
and, if applicable, suggestions as to how to make the request
successful. Registration requests that are undetermined for a period
longer than 21 days can be brought to the IESG's attention (using the
iesg@iesg.org mailing list) for resolution.
It sounds like the IESG could be fielding a lot of registration requests.
The reference for the "hub" relation type in the initial registration is
"<http://pubsubhubbub.googlecode.com/>", however referencing a website does not
appear to be consistent with "Specification Required" as mentioned in Section
6.2.1 and defined in RFC 5226. For consistency, it would be best for the person
who requested this relation type to submit a brief Internet-Draft defining the
relation, and for the initial registry contents to exclude the "hub" relation
type pending submission of that Internet-Draft.
I concur with Tim Polk's concern regarding increased load on the IESG resulting from the (seemingly novel) 14-day rule for review of registration requests.
Should there be additional guidance to the expert reviewer on what to check for
in the specification required by "Specification Required"? Is it sufficient for
registration to have a document that contains only the template, or is that
document expected to have more semantic content?
The answer to that may affect "first", "last", and "payment" in this document.
In either case, "hub" needs a more stable reference than googlecode.
draft-reschke-rfc2231-in-http
A fine document, but there are three small things I don't understand...
Why isn't RFC 2231 a normative reference?
Why does the text say...
RFC 2231 (Appendix of [RFC2231]) defines an
escaping mechanism for use in MIME headers.
...I can't find an Appendix in RFC 2231.
RFC 2231 doesn't actually use the term "escape" or "escaling". It might be nice
to harmonise on the terms used by theat RFC.
In section 3.2: > > Producers MUST NOT use character sets other than "UTF-8" ([RFC3629]) > or "ISO-8859-1" ([ISO-8859-1]). > Better to say: > > Producers MUST use either the "UTF-8" ([RFC3629]) or the > "ISO-8859-1" ([ISO-8859-1]) character set.
In section 3.2: Producers MUST NOT use character sets other than "UTF-8" ([RFC3629]) or "ISO-8859-1" ([ISO-8859-1]). Extension character sets (ext- charset) are reserved for future use. ext-charset does not appear in the ABNF. Should it?
In Section 3.2, there appears to be confusion between the terms "mime-charset" and "ext-charset". Section 4.1 of this I-D states: Section 4.2 of [RFC2277] requires that protocol elements containing text are able to carry language information. Thus, the ext-value production should always be used when the parameter value is of textual nature and its language is known. In fact RFC 2277 states that "[a]ll human-readable text has a language" and appears to emphasize human-readable text. Although it's not truly clear if RFC 2277 makes a distinction between "text" and "human-readable text", it might be useful to incorporate that distinction here because many textual strings included in protocol elements are not intended for human consumption.
Sec 3.3, Is the link to the WG ticket stable enough for a standards track document? Sec 4.1, r/should/SHOULD X2 Sec 4.2, r/recommended/RECOMMENDED
draft-turner-asymmetrickeyformat
I tried to compile the ASN.1 and got errors. First, 'Attribute' is
being imported from module 'PKIX-CommonTypes-2009' but is not
exported by module 'PKIX-CommonTypes-2009'. Second, this line
contains a syntax error:
Version ::= INTEGER {v1(0), v2(1)} (v1, ..., v2, ...)
Please consider the media-subtype-related comment from the Gen-ART Review by Roni Even: In section 7 what you are registering is a media subtype and not a media type. The media type is application. So "defines a new media type" should be "defines a new media subtype" and "Registration of media type" should be "Registration of media subtype".
I second Alexey's discuss.
draft-turner-asymmetrickeyformat-algs
I second Alexey's discuss.
draft-haberman-rpsl-reachable-test
I like this document and idea, and I fully support it going forward.
For what it is worth, I do not believe the document needs to be any
clearer with respect to the security implications or what protocols
are being offered for test. However, I did have one practical concern:
The presence of one or more pingable attributes signals to network
operators that the maintainer of the referenced network is providing
the address(es) for external diagnostic testing. Tests involving the
advertised address(es) SHOULD be rate limited to no more than ten
probes in a five minute window unless prior arrangements are made
with the maintainer of the attribute.
I think this is overly cautious, and could perhaps apply to some
automatic probing by everyone. But written as above, I would not be
able to launch a regular ping with default options to towards the
site, unless I aborted it within ten seconds. And even then, that would
be it for that five minute period.
I would suggest that the text explictly calls out a conservative
limit (e.g., the above one) on any automatic probing, while allowing
manual testing without any hard limits. The text could perhaps say
something about normal courtesy in tests, such as alerting the
destination before any resource consuming tests are done (flood pings
and the like)
The acronym RPSL should be expanded in the Title.
section 2: "can advertise" - should this be a MAY or SHOULD? section 3: "maintaner of the attribute" - would this be better stated as "operator fo the target network"?
The Gen-ART Review by Vijay Gurbani raised a point that deserves
a response:
Is the intent to have the specific IP address be used solely for
diagnostic tests? That is, can someone probe for other services on
this IP address (http, sip, etc.)? The description is not very clear
on that, and in fact, if the intent is for the latter to happen, then
some manner of Security Consideration section should be put in to
alert of any ramifications.
+1 Sean's and Peter's discuss...
The missing security considerations section should address any controls that are
needed
on intermediate systems (e.g., gateways, routers or firewalls) as well as
the advertised
reachable host.
The document lacks the required security considerations section.
From an operational perspective, the NIC Handle system is no longer supported as
widely as it once was; therefore inclusion of the <nic-handle> does not
necessarily or even reliably "provide a link to contact information" as claimed
in the specification. Is there a reason why the "ping-hdl" attribute does not
have a value-type of <email-address> (as for the "notify" attribute in RFCs 2622
and 4012)?
Please demarcate the rows of the table in Section 2 -- it is confusing to read. There are no references for the value-types <ipv6-address> and <ipv4-address>, which are apparently meant to be definitional for the "pingable" attribute; these are defined in RFC 4012 and RFC 2622 respectively but references would be helpful. Similarly there is no reference for the value-type <nic-handle>, which is apparently meant to be definitional for the "ping-hdl" attribute; this is defined in RFC 2622 but a reference would be helpful.
This ID needs a security considerations section. This section is required as
per (http://www.ietf.org/id-info/checklist.html) and noted in the nits checker.
draft-ietf-nsis-nslp-natfw
This document is defined as Experimental but there is nothing inside that
describes the criteria of the experiment and the limitations in deployment which
have been subject of extensive discussion. I believe that we need to include a
reference to draft-ietf-nsis-ext-07.txt and text that points to that I-D for the
status of the document and deployment limitations.
draft-ietf-nsis-rmd
The promises in the IPR Statement apply only if this document is published on the standards track, which is not happening at this time.
This document is defined as Experimental but there is nothing inside that
describes the criteria of the experiment and the limitations in deployment which
have been subject of extensive discussion. I believe that we need to include a
reference to draft-ietf-nsis-ext-07.txt and text that points to that I-D for the
status of the document and deployment limitations.
Should not the title reflect the fact that we deal with an NSIS QoS Model? for example by adding (using NSIS) or saying NSIS QoS Model.
This is DISCUSS placeholder.
The SECDIR review included a number suggestions for the security considerations
section. The authors noted that the suggestions were useful, but due to the
cloud computing disaster in Iceland their travel plans have been disrupted
resulting in them not being able to address the comments until after the May 6th
telechat.
draft-ietf-nsis-ext
The descriptions of the various allocation policies in ietf-nsis-ntlp don't seem
to match what's in the actual document. Most of those break the values into
ranges with policies of "standards action", "expert review", "private
experimental use", and "reserved". The corresponding descriptions in this
document say "IETF review of a specification" or "expert review". In the section
on Object Type ID, this document says "IETF review of a specification or through
another acceptable published specification", which doesn't match what's in nsis-
ntlp-20.
draft-ietf-radext-status-server
The document says: The "hop by hop" functionality of Status-Server packets is useful to RADIUS clients attempting to determine the status of elements on the path between the client and a server. This should read: ... determine the status of the first element on the path between ... (because you are not forwarding from the proxy and there are no security associations from a client to proxies beyond the first one, there is no way to test proxies 2 and onwards) The document notes on the discussion of codes and port numbers: However, as the category of [RFC2866] is Informational, this conflict is acceptable. This is merely a statement about the status of various RFCs. Personally, the substantive change is that this new RFC would allow a new code to be used on port 1813. I think it should do an "Updates: RFC 2866" and get it over with.
Section 4.1., paragraph 2:
> The client SHOULD also have a configurable global timer (Tw) that is
> used when sending periodic Status-Server queries during server fail-
> over. The default value SHOULD be 30 seconds, and the value MUST NOT
> be permitted to be set below 6 seconds. If a response has not been
> received within the timeout period, the Status-Server packet is
> deemed to have received no corresponding Response packet, and MUST be
> discarded.
DISCUSS: I would like to discuss two issues with this design. First,
since it is only RECOMMENDED to implement Tw and not REQUIRED, clients
need not do so. How do clients without Tw decide that a server has not
responded?
Second, there is no discussion on what rate clients should
be using when *issuing* Status-Server queries. The current text allows
a client to send Status-Server queries to the server at high rates,
and does not require the client to reduce its sending rate when it
receives no responses. In other words, there currently isn't any sort
of congestion control. Has this been discussed by the working group?
It seems like all the pieces are already there to implement a simple
congestion control scheme: have clients issue at most one request per
Tw (already implied by Section 4.3 text but not clearly stated
anywhere), double Tw up to some conservative maximum when the server
does not respond, restore the initial Tw when it does (Section 4.3
again has some text that goes into that direction).
Section 1812., paragraph 4: > The server MAY prioritize the handling of Status-Server packets over > the handling of other requests, subject to the rate limiting > described above. Without congestion control, implementing this MAY guarantees that the minimum amount of useful (= non-Status-Server) work will be done. Section 4.3., paragraph 3: > If no response is received to Status-Server packets, the RADIUS > client can initiate failover to another proxy. By continuing to send > Status-Server packets to the original proxy at an interval of Tw, the > RADIUS client can determine when the original proxy becomes > responsive again. This uses Status-Server messages as an overload detection mechanism. They need to be sent in a way that will back off the rate under overload, because otherwise the scheme can turn into an overload *generation* mechanism. Section 4.5., paragraph 17: > It is RECOMMENDED, therefore, that implementations desiring the most > benefit from Status-Server also implement server failover. The > combination of these two practices will maximize network reliability > and stability. If Status-Server messages are being sent in a way that is congestion controlled (i.e., the rate is reduced under overload).
Please consider the comments from the Gen-ART Review by Francis Dupont: - Abstract page 2: there is an explicit reference to a RFC, this is in general forbidden but IMHO we are here in the allowed exception case. - 2.1.1 page 8: a servers policy -> a server policy - 3 page 10 (twice): etc. -> etc., ??? - 4.2 page 13: adminstrators -> administrators - 4.2 page 15 (twice): e.g. -> e.g., - 4.3 page 16: modelled -> modeled - 4.3 page 16: usually the hysteresis against flapping tries to keep the connection (i.e., failover after 3 missed responses), here it is the opposite. IMHO it is very aggressive but it is how RFC 3539 works so I have no concern about it. - 4.5 page 16: Proxyhas -> Proxy has - 4.5 page 17: cannot, -> cannot - 4.5 page 18: i.e. -> i.e., - 5 page 19: EAP-MEssage -> EAP-Message - 8 page 23: synthesise -> synthesize - 8 page 23: in "the suggestion of [RFC5080] Section 2.2.2, which suggests" suggests -> proposes - 8 page 23: configurably is not in my dict? - 9.2 page 23: IMHO the RFC2119 reference should be moved to normative references section (perhaps others too?) - Authors' Addresses -> Author's Address
I support Lars' and Peter's discuss positions.
Is the use of MD5 in generating the Response Authenticator subject to collision
attacks? If not, it would be helpful to describe why not, and provide a
reference to RFC 4270. If so, then the security considerations need to be
updated.
Given that the Request Authenticator should be unpredictable and unique, a reference to RFC 4086 would be appropriate. Please add a reference to RFC 1321 for the definition of MD5.
Support Lars' discuss re: limiting message rates If there is a reason to perform a major edit on this document, please consider splitting the "documenting what was deployed" and "recommending fixes" into clearly separate sections (if not documents).
I support Peter's discuss. Additionally, I noted the same thing Peter did wrt to random numbers. Section 3: In the Request Authenticator description the two paragraphs repeat that Request Authentication SHOULD be unpredictable and then says why. Maybe the second paragraph should be tweaked: The Request Authenticator value in a Status-Server packet SHOULD also be unpredictable **because** an attacker **could** trick a server into responding to a predicted future request, and then use the response to masquerade as that server to a future Status-Server request from a client.
draft-wallace-using-ta-constraints
DISCUSS DISCUSS: I would like to understand the scope (applicability statement)
for this document and also why it is Informational (as opposed to PS).
7.2. Informative References
[I-D.draft-ietf-pkix-ta-format]
Housley, R., Wallace, C., and S. Ashmore, "Trust Anchor
Format", draft-ietf-pkix-ta-format (work in progress).
I think this reference is Normative, considering that the document is using some
ASN.1 structures defined in it.
I concur with the DISCUSSes lodged by Alexey Melnikov.
In addition, the security considerations do not document what attacks are made
possible if implementations do not enforce trust anchor constraints and if trust
anchor information is not securely stored. The authors might refer to RFC 3552
in drafting appropriate text.
I support Alexey's DISCUSS position. I think this ought to be standards track.
draft-simpson-tcpct
I support the IESG Writeup