IESG Narrative Minutes
Narrative Minutes of the IESG Teleconference on 2010-08-26. These are not an official record of the meeting.
Narrative scribe: Barry Leiba (The scribe was sometimes uncertain who was speaking.)
Corrections from: NONE
Changes: Addition of appendix with snapshot of discusses/comments
1 Administrivia
2. Protocol Actions
2.1 WG Submissions
2.1.1 New Items
Telechat:
Telechat:
Telechat:
Telechat:
2.1.2 Returning Items
2.2 Individual Submissions
2.2.1 New Items
Telechat:
2.2.2 Returning Items
3. Document Actions
3.1 WG Submissions
3.1.1 New Items
Telechat:
Telechat:
Insert discussion of response to Morfin appeal:
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
3.1.2 Returning Items
3.2 Individual Submissions Via AD
3.2.1 New Items
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
3.2.2 Returning Items
3.3 Independent Submissions Via RFC Editor
3.3.1 New Items
3.3.2 Returning Items
4 Working Group Actions
4.1 WG Creation
4.1.1 Proposed for IETF Review
4.1.2 Proposed for Approval
4.2 WG Rechartering
4.2.1 Under evaluation for IETF Review
4.2.2 Proposed for Approval
Telechat:
Telechat:
Telechat:
5. IAB News We can use
6. Management Issues
Telechat:
Telechat:
Telechat:
Telechat:
7. Agenda Working Group News
1435 EDT Adjourned
(at 2010-08-26 08:29:44 PDT)
draft-ietf-msec-ipsec-group-counter-modes
A review by Ari Keränen:
4. Group Key Management Conventions
o When a GKMS determines that a particular group member is no longer
a part of the group, then it MAY re-allocate any sender identifier
associated with that group member for use with new group member.
In this case, the GKMS MUST first delete and replace any active AH
or ESP SAs with which the SID may have been used.
How does the "delete and replace" happen in practice if the GKMS is a
different entity than the one with the active AH or SA?
A GKMS MUST support a group member notifying the GCKS that its IV
space will soon be exhausted and requires a new SA to be distributed.
A group member SHOULD notify the GCKS in advance of its IV space
being exhausted. A GCKS MAY choose to ignore this notification based
on policy (e.g., if the group member appears to be asking for new SAs
so frequent as to negatively affect group communications).
Ignoring the IV space exhaustion notifications probably has some
security implications worth noting in the security considerations sections.
I support Alexey's DISCUSS. "MUST support" is ambiguous. and the following SHOULD/MAY combination is so loose, it is unclear what a compliant implementation MUST support.
This is a fine document, but I have one question:
4. Group Key Management Conventions
A GKMS MUST support a group member notifying the GCKS that its IV
space will soon be exhausted and requires a new SA to be distributed.
Excuse my ignorance of the subject, but I would like to understand how this MUST
can be achieved and whether any protocol extensions are needed to implement this
requirement.
A group member SHOULD notify the GCKS in advance of its IV space
being exhausted. A GCKS MAY choose to ignore this notification based
on policy (e.g., if the group member appears to be asking for new SAs
so frequent as to negatively affect group communications).
This one is a DISCUSS-DISCUSS (i.e., no action required for authors).
I'd like to understand why this counter mode ID is on standards track when the
last one (draft-ietf-ipsecme-aes-ctr-ikev2) had to go through as informational.
These are regular DISCUSSes:
#2: From SECDIR review:
Please add a normative reference to draft-ietf-msec-gdoi-update-06 that
references how to distribute the SIDs.
#3: Section 4:
If the entire set of sender identifiers has been
exhausted, the GKMS MUST refuse to allow new group members to
join.
If the GKMS got in this situation by using a small SID wouldn't another idea be
to switch to a bigger SID? This obviously wouldn't work for the 16 but would
for the 8 and 12 bit SIDs.
#1: Sec 2: It is the basis for several modes of operation that combine encryption, including CCM and GCM. combine with what? I assume you mean "combine authentication with encryption, including CCM and GCM."
draft-ietf-tsvwg-ecn-tunnel
A few comments from Ari Keranen: 1. Introduction Nonetheless, the latest IPsec architecture [RFC4301] considered a bandwidth limit of 2 bits per packet on a covert channel made it a manageable risk. Remove "made it"? 4. New ECN Tunnelling Rules an alternate congestion marking scheme used by a specific Diffserv PHB (see S.5 of [RFC3168] and [RFC4774]). For consistency: s/S/Section/ (also in Section 7 and Appendix B1)
> In some circumstances (e.g. pseudowires, PCN), the whole path > is divided into segments, each with its own congestion > notification and feedback loop. The above reference to PWs assumes an agreed documented MS-PW congestion architecture, whereas the most that exists is a few hints in RFC5659. The reference to PWs should be removed, or the text aligned with RFC5659.
A quick note. In the Acknowledegements... The views expressed here are those of the author only. I know what you mean with respect to your sponsor, but the views expressed here represent IETF consensus now, so this sentence is not accurate.
A fine document. I've only got some non-blocking comments:
#1 - Sometimes RFC4301 and RFC3168 is used when describing the IPsec tunnels and
non-IPsec tunnels and sometimes it is used to describe the actual document.
Could IPsec tunnels and non-IPsec tunnels be used instead when discussing the
tunnels and [RFC4301] and [RFC3168] be used when describing the document? I
think it would make it clearer.
#2 - If there's one required mode and one optional, then I suggest in Section
4.1:
OLD:
a REQUIRED `normal mode' and a `compatibility mode'
NEW:
a REQUIRED `normal mode' and an OPTIONAL `compatibility mode'
#3 - The tables include codepoints and "drop". Can you add a NOTE that indicates
"drop" in the tables is not a codepoint.
#4 - Section 4.2:
This is because the
inner Not-ECT marking is set by transports that use drop as an
replace drop with "drop" ?
indication of congestion and would not understand or respond to
any other ECN codepoint [RFC4774].
#5 - Section 5.1 & 5.2, please indicate which sections are changed in 4301/3168.
It will aid readers who are familiar with those documents.
#6 - Section 5.2:
The compatibility mode of encapsulation is identical to the
encapsulation behaviour of the limited functionality mode of an
RFC3168 ingress, except it is optional.
^^^^^^^^r/optional/OPTIONAL?
draft-ietf-tsvwg-dtls-for-sctp
Review by Ari Keränen:
3.1. Future Versions of DTLS
This document is based on [RFC4347]. If a new RFC updates or
obsoletes [RFC4347], this documents also applies to the newer
document defining DTLS unless this document also gets updated or
revised.
How do you know whether the "new DTLS" is compatible with this spec?
Support Lars' discuss
Section 3.1., paragraph 1:
> This document is based on [RFC4347]. If a new RFC updates or
> obsoletes [RFC4347], this documents also applies to the newer
> document defining DTLS unless this document also gets updated or
> revised.
DISCUSS: This section is in the wrong document. It will need to be in
the DTLS bis document, because only when we have that will we know
whether the hypothetical new version of DTLS cann support this spec or
not. If it can, the DTLS bis will Update this document and indicate
this, and if not, it will need to move this document to Historic. In
other words, I believe this section should be removed.
Section 1.1., paragraph 2: > Security features provided by DTLS over SCTP include authentication, > message integrity and privacy of user messages. Applications using > DTLS over SCTP can use almost all transport features provided by SCTP > and its extensions. Which ones can they not use? (Also, nit, I'm not a big fan of 1:1 repetition of the abstract in the introduction.) Section 3.2., paragraph 1: > DTLS limits the DTLS user message size to the current Path MTU minus > the header sizes. This limit SHOULD be increased to 2^14 Bytes for > DTLS over SCTP. The wording here is odd. You don't actually want to increase a limit of the base DTLS spec (because otherwise you'd need to Update it.) You probably want to say "for the purposes of running over SCTP, the DTLS path MTU SHOULD be considered to be 2^14." (And should this not be a MUST?) Section 4.3., paragraph 1: > Application protocols running over DTLS over SCTP SHOULD register and > use a separate payload protocol identifier (PPID) and SHOULD NOT > reuse the PPID that they registered for running directly over SCTP. Shouldn't these be MUSTs? Section 4.4., paragraph 2: > All DTLS messages of the ApplicationData protocol MAY be transported > over stream 0, but users SHOULD use other streams to avoid possible > performance problems due to head of line blocking. Suggest to change the sentence logic to "SHOULD use other streams, MAY use 0 if <condition>" and therefore say when it is OK to go against the SHOULD. Section 1.1., paragraph 17: > o The DTLS user can not perform the SCTP-AUTH key management, Nit: s/can not/cannot/ Section 4.5., paragraph 1: > This makes sure that an attacker can not modify the stream in which a Nit: s/can not/cannot/
I support Lars discuss on section 3.1 I support Sean's discuss issue #1 (restrict the DTLS cipher suites to ones that provide the required security services).
I support Lars's DISCUSS on section 3.1
I also found section 3.1 awkward
#1 - DTLS indicates that in the absence of an application specific profile that
the TLS_RSA_WITH_AES_128_CBC_SHA is the mandatory to implement cipher suite.
Assuming that's the only cipher suite you use you can get the services you
noted: authentication, message integrity and privacy of user messages. DTLS
allows other cipher suites to be negotiated that would not provide these
services. Please indicate the cipher suite you'd like support to support (or
say that the default is used) and any restrictions on the choice of other cipher
suites to ensure you get all three services.
#2 - Any chance we can get a why on the MUST NOT in 3.3-3.5? DTLS says
applications SHOULD support Anti-Replay and PMTU Discovery.
#3 - Need to specify whether you support renegotiation. The following was used
in draft-ietf-nsis-ntlp-sctp (feel free to tweak):
DTLS renegotiation [7] may cause problems for applications such that connection
security parameters can change without the application knowing it. Hence, it is
RECOMMENDED that renegotiation be disabled for GIST over DTLS.
#1 - Agree with Lars DISCUSS. A nice attempt at future proofing, but I don't think it'll fly ;) #2 - Sec 4.6: Before sending a ChangeCipherSpec message all outstanding SCTP user messages MUST have been acknowledged by the SCTP peer and MUST NOT be revoked anymore by the SCTP peer. anymore? Should it just be "revoked by"? #3 - In the security considerations, the I-D notes that "It is possible to authenticate DTLS endpoints based on IP-addresses in certificates." I went and looked in SCTP and didn't find anything about limiting endpoints with IP-address in certificates. It'd be nice to have a reference for this?
draft-ietf-isms-radius-vacm
Thanks for this I-D. I have no objection to its publication as an RFC. Section 4.1 I found the following sentence somewhat tricky. An implementation-specific identifier is needed for each AAA- authorized "session", corresponding to a communication channel, such as a transport session, for which a principal has been AAA- authenticated and which is authorized to offer SNMP service. The problem is around "implementation-specific" which implies that there is a single identifier for all communication channels from any Company-X Product-Y device. Not what you mean! If you have time to tweak this a little, that would be good. --- Section 4.2 Not sure that the two uses of "MAY" in this section really need to be upper case, but it is not very important. --- Section 5.1 Would be nice to give a reference for the TCs mentioned.
Please consider the editorial comments in the Gen-ART Review from
Francis Dupont. The review can be found at:
http://www.softarmor.com/rai/temp-gen-art/
draft-ietf-isms-radius-vacm-09-dupont.txt
Magnus Nystrom noted some confusion in the current section 7.2. After reviewing the text, I think he has a point. I would suggest deleting "or equivalent" from the second and fourth bullets and appending something along the following lines at the end of the section: As noted in section 4.2, the above text refers specifically to RADIUS attributes. Other AAA services can be substituted, but the requirements imposed on User-Name and Management-Policy-Id-Attribute MUST be satisfied using the equivalent fields for that service.
This is a very good document and I plan to enter a 'Yes' in the ballot, but
there are a number of issues that were raised in the OPS-DIR review by Joel
Jaeggli and in the MIB-Doctor review by Glenn Keeni which are under discussion
with the authors. I am holding a DISCUSS until these issues are resolved.
draft-thaler-v6ops-teredo-extensions
Roni Even raises two concerns in his Gen-ART Review. Please respond
to both of the concerns. The review can be found at:
http://www.softarmor.com/rai/temp-gen-art/
draft-thaler-v6ops-teredo-extensions-07-even.txt
Trailer type field might benefit from having an IANA registry.
draft-ietf-mipshop-transient-bce-pmipv6
Clearing my Discuss on the basis of Jari's answer: "That's a good question to ask. The answer is yes."
Please consider the editorial comments in the Gen-ART Review from Spencer dawkins on 25-Aug-2010.
6. IANA Considerations This specification also adds one status code value to the Proxy Binding Acknowledge message, the PBU_ACCEPTED_TB_IGNORED_SETTINGSMISMATCH status code. The PBU_ACCEPTED_TB_IGNORED_SETTINGSMISMATCH status code is described in Section 4.7. Its value must be assigned from the same number space used for the Mobile IPv6 Binding Acknowledgement status values, as defined in [RFC3775], and must be smaller 128. I am looking at <http://www.iana.org/assignments/mobility-parameters/mobility- parameters.xhtml> and I am not finding "Binding Acknowledgement status" sub- registry. Am I looking in a wrong place, or is it named differently?
The security considerations section needs to indicate whether there are any new
security considerations introduced in addition to those in RFC 5213.
draft-ietf-avt-srtp-not-mandatory
This is a very much needed document, well written, and makes IMO the right conclusions. I did have two issues, however, but decided to place a Yes vote as opposed to holding a discuss. I do want to talk about these topics on the IESG telechat, however. The first issue is that in Section 4 MIKEY is ruled out as mechanism for supporting situations where the SIP infrastructure is untrusted. I do not understand why this is being done. MIKEY can provide end-to-end authentication, which would seem to thwart attacks where SDES would clearly fail. Can this exclusion be elaborated and/or removed? The second issue relates to the main recommendations. The documents makes the argument that RTP applications are so diverse that they can not live under the same security solution. However, I am left wondering whether there would be mandatory-to-implement security solutions for specific applications. Do the authors for some reason believe that is not feasible or undesirable? Should there be IETF activities started on making such requirements for specific applications?
Section 3., paragraph 4: > [ETSI.TS.102.474], where one mode of operation uses ISMAcryp > (http://www.isma.tv/specs/ISMA_E&Aspec2.0.pdf) to encrypt the RTP > payload data only. Nit: It'd be better to refer to this URL as a reference. Section 4., paragraph 9: > authentication solutions that are tied into the key manangement. Nit: s/manangement./management./
I support Russ's DISCUSS
This draft seems to say that BCP 61 does not apply to RTP. BCP 61
describes the "Danvers Doctrine", which says that the IETF should
standardize on the use of the best security available, regardless of
national policies. BCP 61 also says:
> One of the continuing arguments we hear against building security
> into protocols is the argument that a given protocol is intended only
> for use in "protected" environments where security will not be an
> issue.
>
> However it is very hard to predict how a protocol will be used in the
> future. What may be intended only for a restricted environment may
> well wind up being deployed in the global Internet. We cannot wait
> until that point to "fix" security problems. By the time we realize
> this deployment, it is too late.
>
> The solution is that we MUST implement strong security in all
> protocols to provide for the all too frequent day when the protocol
> comes into widespread use in the global Internet.
I find it inappropriate for an Informational document to a BCP. If
there is consensus that RTP is a special case, then the exception to
BCP 61 ought to be documented in a BCP.
I do not believe that there is such a consensus as it would contradict
the results of the RTPSEC BOF held at IETF 68. The RTP security
requirements were eventually published as RFC 5479, and then RFC 5763
and RFC 5764 (DTLS-SRTP) published a solution to those requirements.
I recognize that DTLS-SRTP is not the solution for all environments.
However, today most RTP in deployments use no security. BCP 61 argues
for security to be implemented even if it is not turn on in every
deployment. A secuity solution for unicast point-to-point audio is
unlikely to work well for multicast IPTV. This does not argue for no
security. Rather it argues for a collection of security solutions
that accomodate the various environments that RTP supports.
Note: This is a joint discuss from both Security ADs. Given the importance of
this
document, we are both holding a discuss position so we can participate in
the
discussion that follows.
We accept the basic premise of this document: as a “framework protocol”,
applying
BCP 61 directly and mandating a single security solution is not
appropriate and
would not achieve the goal of BCP 61: ensuring that security
mechanisms are
implemented (and thus available) even if it is not turned on in
every deployment.
However, we do not believe the proposed solution (leaving the
selection to each
application of RTP) is any more likely to achieve that goal.
In most actual deployments,
RTP is basically not secured. Allowing a thousand
flowers to bloom practically
guarantees that real deployments will not include
security mechanisms (since there
is so little prospect of code re-use and many
current deployments won’t turn it on.)
To meet the spirit of BCP 61, we recommend that the working group consider the
following approach: specify a small set of solutions that cover the major
classes of
applications, and mandate implementation of the appropriate solution
for each RTP
application. RTP application standards would be required to
justify a mandatory to
implement security scheme that does not fall within this
set. We believe this solution
provides the best opportunity to achieve the
goals of BCP 61 for RTP-based applications.
This document does a good job in building the case that SRTP is not universally
fit as a security solution for all use cases of RTP. I have however a couple of
issues with two sections in the document that I would like to be discussed
before I can approve the document:
1. The last application scenario listed in Section 3 says:
> Finally, the link layer may be secure, and it may be known that the
RTP media data is constrained to that single link (for example, when
operating in a studio environment, with physical link security). An
environment like this is inherently constrained, but might avoid the
need for application, transport, or network layer media security.
I do not believe that this is relevant in a discussion about securing an IETF
protocol. BCP 61 (RFC 3365) Section 6 is very clear in that:
> One of the continuing arguments we hear against building security
into protocols is the argument that a given protocol is intended only
for use in "protected" environments where security will not be an
issue.
...
The solution is that we MUST implement strong security in all
protocols to provide for the all too frequent day when the protocol
comes into widespread use in the global Internet.
I suggest to take out this case as irrelevant
2. I am confused about what section 5 tries to say. First I do not know the term
'framework protocol' - this needs to be defined or referred to. What the section
seems to say is that for that category of protocols (where RTP belongs) the
strong security is more an application issue, where an application may be built
of several building blocks, out of which the protocol is only one of them. This
seems again to question or even justify an extemption from the requirements of
BCP 61 [RFC3365] for RTP or even a whole class of protocols.
1. In Section 1: s/Section 2 describes the scenarios in which RTP is deployed./Section 2 describes the most widely encountered scenarios in which RTP is deployed./ 2. in Section 2 - why are the conferencing scenarios listing only video conferencing and not voice and video conferencing?
Note: This is a joint discuss from both Security ADs. Given the importance of
this
document, we are both holding a discuss position so we can participate in
the
discussion that follows.
We accept the basic premise of this document: as a “framework protocol”,
applying
BCP 61 directly and mandating a single security solution is not
appropriate and
would not achieve the goal of BCP 61: ensuring that security
mechanisms are
implemented (and thus available) even if it is not turned on in
every deployment.
However, we do not believe the proposed solution (leaving the
selection to each
application of RTP) is any more likely to achieve that goal.
In most actual deployments,
RTP is basically not secured. Allowing a thousand
flowers to bloom practically
guarantees that real deployments will not include
security mechanisms (since there
is so little prospect of code re-use and many
current deployments won’t turn it on.)
To meet the spirit of BCP 61, we recommend that the working group consider the
following approach: specify a small set of solutions that cover the major
classes of
applications, and mandate implementation of the appropriate solution
for each RTP
application. RTP application standards would be required to
justify a mandatory to
implement security scheme that does not fall within this
set. We believe this solution
provides the best opportunity to achieve the
goals of BCP 61 for RTP-based applications.
draft-ietf-pkix-ta-mgmt-reqs
This is along the same line as Alexey's:
3.7.2. Rationale
There is no standardized format for trust anchors.
Is this really true now that 5914 is published?
draft-ietf-mif-problem-statement
I have a fundamental problem with the way in which this document characterizes
the problems resulting from the simultaneous use of multiple interfaces as all
resulting from receiving different configuration objects from different
administrative domains. In my opinion, some of the example problems in the
document are a result of other problems inherent with the simlutaneous use of
multiple interfaces. This distinction is important because , again in my
opinion, there are mif problems which cannot be solved by changes to the
configuration behavior in the host.
For example, in section 4.1, the symptom:
4. S1 or S2 has been used to resolve "a.private.example.com" to an
[RFC1918] address. Both N1 and N2 are [RFC1918] addressed
networks. IPv4 source address selection may face challenges, as
due address overlapping the source/destination IP addresses do
not necessarily provide enough information for making proper
address selection decisions.
is inherent in having interfaces connected to networks using overlapping address
spaces, and cannot be solved by improvements to the configuration behavior.
Similarly in section 4.1:
5. H1 has resolved an FQDN to locally valid IP address when
connected to N1. After movement from N1 to N2, the host tries to
connect to the same IP address as earlier, but as the address was
only locally valid, connection setup fails. Similarly, H1 may
have received NXDOMAIN for an FQDN when connected to N1. After
movement from N1 to N2, the host should not assume the FQDN
continues to be nonexistent.
How is this problem caused by configuration objects from different domains?
I
see two ways to address my concern: either be explicit in limiting the problem
statement and mif deliverables to those problems that can be solved with proper
handling of configuration information from multiple admin domains or extend the
scope of this document to include any problems that may result from the
disparate environments (IP reachability, DNS resolution, QoS) to which
interfaces are attached.
Some of the symptoms don't derive from the stated operational environments. For
example, in section 4.1:
3. H1 keeps only one set of DNS server addresses from the received
configuration objects and kept S2 address. H1 sends the DNS
query for a.private.example.com to S2. S2 asks its upstream DNS
and gets an IP address for a.private.example.com. However, the
IP address is not the same one S1 would have given. Therefore,
the application tries to connect to the wrong destination host,
or to the wrong interface of the latter, which may imply security
issues or result in lack of service.
seems to be in conflict with the constraint at the top of the section that 'name
"a.private.example.com" [...] is within the private namespace of S1 and only
resolvable by S1'; that is, if the constraint holds, H1 would not get a
resolution for a.private.example.com by sending a resolution query to S2.
Also in section 4.1:
5. H1 has resolved an FQDN to locally valid IP address when
connected to N1. After movement from N1 to N2, the host tries to
connect to the same IP address as earlier, but as the address was
only locally valid, connection setup fails. Similarly, H1 may
have received NXDOMAIN for an FQDN when connected to N1. After
movement from N1 to N2, the host should not assume the FQDN
continues to be nonexistent.
what does "movement from N1 to N2" mean?
Still in section 4.1:
A MIF host may also be provisioned with a Interface-specific suffix
search list ([I-D.ietf-mif-current-practices]). In this situation,
if H1 sends DNS query on I1 using the search list tied to I2, the
namespace could be not valid on I1 and the name could be not
resolved.
isn't the described host behavior clearly a bug in the host stack?
From Andrew Sullivan, dns-directorate review:
First, this is an implicit recognition that the DNS namespace is not
actually a single, unified namespace. I think that's just
acknowledging the facts in the world, but I know there are people
opposed to that.
Second, it seems to be setting up the mif WG to be trying to "solve"
the DNS split-views problem. I think this effectively means that
we're (i.e. the dns-dir crowd) will need to keep on top of MIF.
Section 3., paragraph 1:
> 2. Interfaces of a MIF host can provide different
> characteristics (e.g. round-trip time, least cost, better
> bandwidth, etc....). So, user, applications or network
> provider may wish to influence routing to take benefit of
> this heterogeneity. However, with current host
> implementations, neither the Type-of-Service nor path
> characteristics can be taken into account in the routing
> table.
DISCUSS: I don't think MIF can solve this problem. Yes, interfaces are
the first hops into *paths* of different characteristics, but what
service quality an application sees across a path depends on the
destination, the transport protocol in use and the communication
patterns of the application. There is nothing here that can be
optimized without taking these into account.
INTRODUCTION, paragraph 4: > of its provisioning domain. Some configuration objects are global to Nit: s/domain/domains/ Section 1., paragraph 1: > A multihomed host have multiple provisioning domains (via physical Nit: s/have/has/ Section 1., paragraph 4: > values from each provisioning domains, such as different DNS servers Nit: s/from/for/ Section 3.1., paragraph 1: > [RFC5113] is out of scope of this document. Moreover, lower layer Nit: s/is/are/ Section 3.2., paragraph 2: > The host maintains a route cache table where each entry contains the > local IP address, the destination IP address, Type-of-Service and > Next-hop gateway IP address. The route cache entry would have data > about the properties of the path, such as the average round-trip > delay measured by a transport protocol. Modern stacks don't store transport info in the route cache anymore. Suggest to remove the last sentence. Section 3.2., paragraph 3: > As per [RFC1122], two models are defined: > o The "Strong" host model defines a multihomed host as a set of > logical hosts within the same physical host. In this model a > packet must be sent on an interface that corresponds to the source > address of that packet. And it will only be received on that interface, too. Section 3.2., paragraph 4: > o The "Weak" host model describes a host that has some embedded > gateway functionality. In the weak host model, the host can send > and receive packets on any interface. This doesn't really make the distinction clear. A weak host can send and receive packets ***addressed to or from any of its source addresses on any of its interfaces***. Section 3.5., paragraph 2: > Some application protocols do referrals of IP addresses and port > numbers for further exchanges. A referral also includes the transport protocol to be used. Section 2., paragraph 0: > 2. For the IP1 address family, H1 has one default route (R1, R2) per > network (N1, N2). IP1 is reachable by both networks, but N2 path > has better characteristics, such as better round-trip time, least > cost, better bandwidth, etc.... These preferences could be > defined by user, by the provider, by discovery or else. H1 stack > uses R1 and tries to send through I1. IP1 is reached but the > service would be better by I2. Note that "better" here is entirely dependent on what kind of traffic is to be exchanged with the destination, i.e., it is transport protocol and application dependent. General preferences of any sort are therefore likely to be wrong. Section 11., paragraph 23: > [RFC4477] Chown, T., Venaas, S., and C. Strauf, "Dynamic Host > Configuration Protocol (DHCP): IPv4 and IPv6 Dual-Stack > Issues", RFC 4477, May 2006. Nit: Unused Reference: 'RFC4477'
I have not seen any discussion of the Routing Area Directorate review performed
by Joel Halpern. I should like to see the issues raised debated and resolved
before this document goes forward.
===
This is a Routing Area Review. Please consult with your document
shepherd before making any changes. Consult the Routing Area
Directorate page for information on the review process
(http://www.ietf.org/iesg/directorate/routing.html)
Document file: draft-ietf-mif-problem-statement-07.txt
Document Name: Multiple Interfaces Problem Statement
Reviewer: Joel M. Halpern
Review Date: 15-August-2010
Last Call End Date: 2010-08-23
Telechat Date: 2010-08-26
Summary: This document is nearly ready for publication as an
informational RFC.
However, there are some items that should be attended do.
Comments:
Moderate:
Section 5, item 3 on routing, sub-bullet 2 describes an underlying
problem attributed to routing. As routing is sued by this section, it
seems to apply to host interface selection, first hop router selection,
and general path selection. As written, the text seems an invitation
for the MIF working group to delve into the issues of host control over
routing path selection. Please do not go there. I sould suggest
tightening the text up to make it clear that what is meant is policy
based itnerface and first-hop router selection, where policy may reflect
the many things listed in sub-bullet 2.
Minor:
Section 2: MIF Characgteristics:
It is a bit odd to list the characteristics of a MIG host in the
Terminology section. It seems like a section on its own.
In the thrid bullet in the characteristics, the English usage is a bit
misleading. The text says "A MIF host can attach to more than one
provisioning domains." I suspect that "can" here means "may be", that
is that the document recognizes the possibility of such attachment. As
written, the text almost seems to be requiring special logic for
handling multiple domaisn, which while it may be a conclusion of the MIF
group is clearly not a requirement for the problem statement. (The
following item uses "may be" in exactly the way I would recommend for
item 3.)
The last item in the list of characteristics refers to a MIF host as
potentially forwarding packets. While the document is clear that such
behavior is out of scope (which is good), I wonder if it would be better
to note the IPv6 terminology and say that such devices are not hosts?
(they are nodes, but they are not hosts.) The reason I raise this is
that the host-like logic in a router is probably also out of scope for
MIF, isn't it?
Section 3.5 on Finding and Sharing IP Addresses with Peers contains
clear, and to the best of my knowledge accurate, information. However,
I can note determine what the relationship of this topic is to MIF. I
suspect that the intention is to say that MIF will not be working on NAT
traversal of referral issues. But the text does not seem to say that.
Similarly, for section 3.6 on APIs and connection managers, the text
talks about the issues, but is unclear as to whether they are in or out
of scope for MIF.
Yours,
Joel M. Halpern
My concern is already captured in DISCUSS posiotns held by Ralph, so I am not going to pile on. However, I do want to make it known that I also have the same concern. (Note the same concern was raiseed by Roni Even in his Gen-ART Review dated 24-Aug-2010.)
This is an useful document. The comments below are not blocking, but in case they are considered they could improve readability: 1. In section 3.1 the following statement is made: > Network discovery and selection on lower layers as defined by [RFC5113] is out of scope of this document. Moreover, lower layer interaction such as IEEE 802.21 is also out of scope. It would be good to be more exact about what is IEEE 802.21 - for example s/lower layer interaction such as IEEE 802.21/handover and interoperability between lower layer networks such as the mechanisms defined in IEEE 802.21/ An informative reference to IEEE 802.21 would also be in place. 2. Expanding acronyms at their first occurance would be useful. 3. The OPS-DIR review performed by Menachem Dodge also included a number of useful editorial comments which I suggest to consider.
Some very minor editorial suggestions: Is there a missing word (I think "may" at "may have") in the first sentence of the introduction? Should the first sentence of 3.6 start with "An Application"?
An updated DISCUSS that includes a reference to the SECDIR review.
This is a placeholder DISCUSS while the authors, AD, and SECDIR reviewer work on
some expanded text for the security considerations section. See the thread:
http://www.ietf.org/mail-archive/web/secdir/current/msg01963.html
draft-ietf-netmod-yang-usage
Section 4., paragraph 0:
> 3.7. Intellectual Property Section
DISCUSS: The current ID format does not have an Intellectual Property
Section anymore.
Section 3., paragraph 3: > The following sections MUST be present in an Internet-Draft > containing a module: > o Narrative sections > o Definitions section > o Security Considerations section > o IANA Considerations section > o References section I think it makes sense here to separate this into sections that this memo requires for YANG modules (the first two), and into sections that the general ID template requires (the final three), because the latter can change and obviously YANG IDs need new sections if they become required to submit an ID. For the latter, you should rephrase the sections that describe their content in a way that makes it clear that they are currently required, but that new ones may be added and just maybe some of the listed ones will dissappear. Section 3.1., paragraph 3: > Each YANG module or submodule contained within an Internet-Draft or > RFC is considered to be a code component. The strings '<CODE > BEGINS>' and '<CODE ENDS>' MUST be used to identify each code > component. I note that YANG is listed in http://trustee.ietf.org/license-info/archive/Code-Components-List-4-23-09.txt, so you actually do not need to require the use of <CODE BEGINS> and <CODE ENDS>. Section 4., paragraph 1: > In general, modules in IETF standards-track specifications MUST > comply with all syntactic and semantic requirements of YANG. > [I-D.ietf-netmod-yang]. The guidelines in this section are intended > to supplement the YANG specification, which is intended to define a > minimum set of conformance requirements. You may want to recommend that authors verify the syntax of their YANG module with an automated checker every time before submitting a new revision. (I see that Section 4.8 talks about that - maybe add a forward reference?) Section 4.5., paragraph 2: > The 'attribute' and 'namespace' axes are not supported in YANG, and > MAY be empty in a NETCONF server implementation. s/MAY/may/ (I don't think the idea is to make requirements on NETCONF servers here) > The 'position' and 'last' functions MAY be used with caution. I don't know what "MAY be used with caution" means. Does it mean "SHOULD NOT, but if you do consider <this>"? Or does it mean "MUST be used in <this way>"? (The "with caution" phrasing appears elsewhere, and I have the same question about all occurrences.) Section 6.1., paragraph 1: > transport is SSH [RFC4742]. Reference missing: RFC4742
Thanks for this document. I think it will be useful. --- Support Enrico's point in Russ's Discuss. It is not appropriate to keep the boilerplate outside the IETF domain. http://trac.tools.ietf.org/wg/netconf/trac/wiki may be an appropriate location. --- I wonder if there is scope for some common framework text like that held at http://www.ops.ietf.org/mib-boilerplate.html --- I am a bit worried that this document covers advice that is more general than just the Yang-related work in an I-D. This risks setting up contradictory advice in a number of places. (For example, discussing how the References should be split is generic advice for authors of I-Ds that could be changed at any time.)
The Gen-ART Review by Enrico Marocco on 9-Jul-2010 leads me to ask a
question about Section 3.4.
Section 3.4 says:
>
> Each specification that defines one or more modules MUST contain a
> section that discusses security considerations relevant to those
> modules. This section MUST be patterned after the latest approved
> template (available at
> http://www.ops.ietf.org/netconf/yang-security-considerations.txt).
>
This seems like an odd place for a normative reference to point.
I'd be much happier with a place that required some form of review
and consensus call to be updated.
I am generally glad that this document is written. Some comments/questions below: 3.6. Reference Sections For every normative reference statement which appears in a module contained in the specification, which identifies a separate document, a corresponding normative reference to that document SHOULD appear in the Normative References section. Why only a SHOULD (and not a MUST)? 4.1. Module Naming Conventions Modules contained in standards track documents SHOULD be named according to the guidelines in the IANA considerations section of [I-D.ietf-netmod-yang]. Why only a SHOULD? A distinctive word or acronym (e.g., protocol name or working group acronym) SHOULD be used in the module name. If new definitions are being defined to extend one or more existing modules, then the same word or acronym should be reused, instead of creating a new one. s/should/SHOULD ? 4.7. Module Header, Meta, and Revision Statements It is acceptable to reuse the same revision statement within unpublished versions (i.e., Internet-Drafts), but the revision date MUST be updated to a higher value each time the Internet-Draft is re- published. I tend to think that this MUST will be ignored in practice. I think making authors update a revision date with every uncompatible change would be more sensible.
Support Russ' discuss.
Is there a yang doctors set up yet (like there was MIB doctors) where people send their modules to get reviewed?
draft-ietf-pkix-asn1-translation
draft-ietf-tcpm-tcp-lcd
Thank you for this work and for proposing it as Experimental. My first Comment is very close to being a Discuss, and I hope you feel able to add some text (perhaps to the Introduction) to give the reader (and future generations) some guidance. For experimental documents, I think it is important to give some parameters of the nature of the experiment. - What constraints will be placed on the experimental work to prevent the experiment spilling out into the Internet (walled garden)? - What are the risks if the experiment is released? (perhaps a forward pointer to section 7) - How will you judge whether the work is stable and successful? - Do you have plans / proposals to return and revise the work for the Standards Track? --- Section 2 Tiny nit, sorry This document improves TCP's behavior in case of "long connectivity disruptions". Well, the document doesn't do that of itself :-)
Please consider the editorial comments in the Gen-ART Review from Enrico Marocco on 25-Aug-2010.
This is a placeholder DISCUSS.
There has been no response to the SECDIR review comments from Catherine Meadows
(http://www.ietf.org/mail-archive/web/secdir/current/msg01965.html).
draft-sheffer-emu-eap-eke
I couldn't work out which range of EAP Method Types should be used for the allocation described at the head of Section 7 for "EAP-EKE Version 1". I presume you are headed for 1-191 or 256-... The difference at this stage is whether expert review needs to be invoked.
Please respond to the comments from Dan Harkins on 18-Aug-2010.
[This is a preliminary DISCUSS and I might add a few extra items before the IESG
telechat.]
This is a well written document and in general I have no objections to its
publication. However I have several points I would like to discuss before
recommending approval of this document:
3)
7.5. Identity Type Registry
In addition, an identity type registry is defined:
+-----------+---------+---------------------------------------------+
| Name | Value | Definition |
+-----------+---------+---------------------------------------------+
| Reserved | 0 | |
| ID_OPAQUE | 1 | An opaque octet string |
DISCUSS DISCUSS: Is this value ever entered by a human? If the answer is yes,
then this need some common user friendly input format for management of such
identities.
It would have been nice to be able to piggyback on one of existing
MAC/PRF/Encryption algorithm registries.
4.2.3. The EAP-EKE-Confirm Payload
PNonce_PS/PNonce_S:
This field ("proptected nonce") contains the encrypted and
typo: protected
integrity-protected response to the other party's challenge, see
Section 5.3 and Section 5.4. Similarly to the PNonce_P field,
this field's size is determined by the encryption and MAC
algorithms.
This is a placeholder discuss. Issues raised in Brian Weis' secdir review have
not been addressed yet. Please
involve Brian in the discussion as you address
these issues!
I support Russ and Tim's DISCUSS positions.
draft-juskevicius-datatracker-wgdocstate-reqts
I have a couple of minor comments. Is "WG I-D" a synonym for "I-D associated with an IETF WG"? I don't understand this requirement: WG document status tracking SHOULD be implemented per-document, not per-WG. (R-012) What would "per-WG WG document status tracking be?
Section 4.2., paragraph 1:
> When an IETF WG Chair needs to input or update the WG status of an
> I-D in one of his or her WGs, the WG Chair SHALL be required to log-
> on to the Datatracker using a personal user-id and password (e.g.,
> an IETF tools password) in order to gain 'write' access. (R-015)
DISCUSS: This is redundant with R-014.
Section 4.2., paragraph 3:
> - SHALL be given full 'read' and 'write' privileges to input and
> update WG status information for all of the I-Ds associated with
> their WGs, one WG at a time; (R-016)
DISCUSS: This is redundant with R-014 and R-015, and it's unclear what
the "one WG at a time" bit means.
Section 4.2., paragraph 7:
> - SHALL be able to designate one or more people to act as delegates
> to input and update the WG status of the I-Ds associated with their
> WGs; (R-020) The identifier for each delegate should be the
> person's e-mail address; (R-021)
> - SHALL be able to designate different people to act as delegates for
> them in different WGs when the WG Chairs are also responsible for
> the different IETF WGs; (R-022)
DISCUSS: This sounds like the delegates are personal delegates of the
chair; in reality they are WG secretaries.
Section 4.2., paragraph 9:
> - SHALL be able to assign people to be Document Shepherds for one or
> more WG I-Ds if this role will not be performed by a WG Chair or a
> designated delegate; (R-024) The identifier for each Document
> Shepherd should be the person's e-mail address. (R-025)
DISCUSS: The shepherd must always be a chair or secretary, this cannot
be delegated to others. (If all chairs and secretaries are
disqualified from being shepherds, this role falls back to the AD.)
Section 4.2., paragraph 11:
> - SHALL be able to review and change the people assigned to be
> Document Shepherds in their WGs, one WG at a time. (R-027)
DISCUSS: No. See above.
Section 4.3., paragraph 0:
> 4.3. For Delegates of IETF WG Chairs
DISCUSS: The "delegates" stuff is too complex and not in light with
how WG secretaries work. For the purposes of the tracker, secretaries
for a WG are just like chairs except they cannot appoint and remove
secretaries.
Section 4.4., paragraph 0:
> 4.4. For IETF WG Document Shepherds
DISCUSS: The document is confused about what shepherds are. According
to RFC4858, shepherds are chairs, and if the chairs are conflicted,
they are secretaries, otherwise this role falls back to the AD. The
shepherding role cannot be otherwise delegated.
Section 6.1., paragraph 0:
> 6.1. Candidate WG Document
DISCUSS: This entire process for handling documents that may be
candidates in multiple WGs is super complex and mostly useless,
because such cases almost never exist, esp. not concurrently. Plus, it
invents a new process with deadlines, timers and notifications where
we currently have none, and I don't think that's the purpose of this
document.
Section 3., paragraph 1: > The Datatracker SHALL be enhanced to provide IETF WG Chairs and the > people they designate to act as their delegates with the flexibility > to input and update the WG status of some, all, or none of the I-Ds > associated with their WGs using the WG document states and status > annotation tags defined in [WGDRAFTS]. (R-001) Can we s/the people they designate to act as their delegates/secretaries/? AFAIK there are no other delegates allowed by the process. (Also elsewhere in the doc.) Section 3., paragraph 2: > The following two examples clarify Requirement R-001: > - the Chairs (and their delegates) of a newly chartered IETF WG may > choose to input the WG status of all of the I-Ds associated with > their WG to provide maximum transparency to the IETF community and > to manage the progression of the I-Ds; > - the Chairs (and delegates) of a mature WG (e.g. a WG that is > nearing the completion of its charter milestones) may decide not to > manually input the status of their WG I-Ds into the Datatracker. These examples don't clarify much. What they do is instead to make it sound OK for chairs of old WGs to not bother with these new functions, which I don't think is the message we want to send. Section 3., paragraph 8: The look and feel for R-005 and R-006 is somewhat important, but it is also maybe more important that the style sheets and javascript UI code be shared, so that when the IESG tracker is updated, the WG tracker benefits and vice versa. Section 7, paragraph 1: > The Datatracker SHOULD date and timestamp every update to the WG > status of an IETF Stream I-D and use that information when it needs > to display the WG status change history of that I-D. (R-007) I think this needs to be a MUST, for transparency. Section 7, paragraph 2: > The WG > status change history for each I-D SHOULD also identify the person > or entity that updated the WG status of the I-D (e.g. one of the > WG's Chairs, a delegate, an AD, the System, the IETF Secretariat) > and describe the change in the WG status of the I-D (e.g. "WG State > changed from 'a' to 'b'", "Document Annotation Tag 'x' Set (or > Reset)", "Document Availability status changed from 'j' to 'k'"). > (R-008) I think this needs to be a MUST, for transparency. Section 7, paragraph 4: > WG document status tracking SHOULD be implemented using a new WG > state machine that is separate from Datatracker's existing IESG > document status tracking state machine. (R-010) This is an implementation detail we don't care about, as long as the externally visible behavior is such. Section 7, paragraph 6: > WG document status tracking SHOULD be implemented per-document, not > per-WG. (R-012) This is clearly a MUST. Otherwise, we don't *have* document tracking. Section 4.4., paragraph 2: > The requirements in this Section describe the access privileges to > be granted to a WG Document Shepherd who is not a WG Chair or a > delegate of a WG Chair with the privileges described in Section 4.3. There are no such shepherds. See above. Section 6., paragraph 0: > 6. Special requirements for some WG I-D states and conditions Many of the issues I raised for draft-ietf-proto-wgdocument-states-08 apply here, too. If they result in any changes to that document, this document will need to be carefully brought in line. Section 6.2., paragraph 3: > adopted by another IETG WG. (R-073) If a WG Chair or delegate moves Nit: s/IETG/IETF/ Section 7., paragraph 3: > associated with an IETG WG: Nit: s/IETG/IETF/
Thank you for undertaking this work which I see as very important for
the stability of the IETF as it continues to be under a lot of
pressure caused by increasing workloads and decreasing resources.
I will move to a "Yes" ballot after we have addressed my small issues,
below. I also have one point for discussion with the rest of the IESG.
(A large number of issues reflects the importance of the work and the
readability of the work; it does not indicate any quality issues.)
===
Discuss-Discuss (i.e. author need take no action)
It seems to me that some of the sections of this document are
constraining on the way that the WG chairs operate their WGs. For
example, in section 6.1
The "Candidate WG Document" state may be used to describe:
- an I-D that someone has asked to be considered by a WG, if the WG
Chair has agreed with the request;
- an I-D that the WG Chair asked an author to write; or
- an I-D listed as a 'candidate draft' in the WG charter.
And similarly, in section 6.1
The first WG Chair (or delegate) to move an I-D into the "Candidate
WG Document" state SHALL be required to specify the maximum length
of time that the I-D may remain in this state. (R-056) The maximum
length of time that an I-D may remain in the "Candidate WG Document"
state SHOULD be specified as a number of weeks. (R-057)
Don't we want to be careful to not create WG operational process as a
side effect of this document? Shouldn't this document be limited to
the behavior of the tool? Noting, in particular, that
draft-ietf-proto-wgdocument-states is Informational and not a BCP.
For example, in the second case, this would change to "SHALL be able to"
===
Discuss
1. Requirement 2
(e.g. other WG Chairs)
This is ambiguous. It could be taken to mean chairs of other WGs.
Suggest you use
(e.g. another chair of the WG)
---
2. Requirement 3
The WG status of every IETF Stream I-D SHALL be tracked using the WG
document states, WG document status annotation tags, and intended
document maturity levels specified in [WGDRAFTS]. (R-003)
Appears to read like a requirement on the IETF or the WG chairs, not a
requirement on the Datatracker.
Do you mean:
It SHALL be possible to track the WG status of...
---
3. Requirements 7 and 8
Requirement 8 is a MUST. We cannot have documents changing state without
accountability.
I feel that requirement 7 is very close to a MUST because it is very
important to be able to see how long a document has been "stuck" in a
state.
Pretty sure that R-042 is a MUST at the same time.
---
4. A really useful feature of the datatracker is that a Comment can be
inserted at any time to add context. This could be when there is a
state change (or, indeed, when there isn't a state change when one
might reasonably be expected).
I think this should be called out explicitly as a feature and all of
- WG chairs
- delegates
- shepherds
MUST be able to add comments which MUST be date stamped and tracked
against the user.
(This sort of shows up partially in R-037.)
---
5. Requirement 18
- SHALL NOT be allowed to create ad hoc WG document states or state
names; (R-018)
It is not explained what an "ad hoc WG document state or state name" is.
- ad hoc WG?
- ad hoc document in a WG?
- ad hoc state?
I suspect that the text would read as well by deleting "ad hoc".
---
6. Requirements 37 and 38
After displaying the information required by R-036, the Datatracker
SHALL prompt the WG Chair or delegate to select a next state for the
I-D and to enter some text to explain the state change for the I-D's
status change history. (R-037) The Datatracker SHOULD always prompt
the person who updates or changes the WG state of an I-D to input
some text for the I-D's status change history. (R-038)
37 seems to say SHALL {prompt next state, prompt text}
38 says SHOULD {prompt text}
So 37 and 38 overlap / conflict
---
7. Section 5.3
This section appears to say that the write-up is a single entity that
can be eddited, and some form of change log. I'm not oppsed to this,
but i want to check that you are aware that this is different from the
current system where any changes to the write-up are represented by a
complete upload of a new copy of the write-up.
---
8. Timer pops
(This may be a joint issue with draft-ietf-proto-wgdocument-states
There is inconsistency in how timer pops are handled.
For example, when in CANDIDATE WG DOCUMENT and the timer expires, the
state changes automatically; but when in IN WG LAST CALL and the timer
expires, the state does not change.
Inconsistency is not good!
In fact, states that have a timer should have a "follow-up state" so
that it is clear what the state is and what the next action actually
is.
---
9. Section 7
Requirement R-001 provides each IETF WG Chair with the freedom to
decide to use all or just some of the WG document states defined in
[WGDRAFTS] to indicate the status and progression of documents in
his or her working group.
This is not how I read R-001! It reads...
The Datatracker SHALL be enhanced to provide IETF WG Chairs and the
people they designate to act as their delegates with the flexibility
to input and update the WG status of some, all, or none of the I-Ds
associated with their WGs using the WG document states and status
annotation tags defined in [WGDRAFTS]. (R-001)
I.e., the requirement talks about the optionality applying to the
drafts (one at a time). It does not talk about the optionality of
some of the states. What is more, a number of the other requirements
show some rules about state transitions that appear to indicate a
lack of optionality.
Section 7 goes on to say:
The same requirement also allows each
IETF WG Chair to decide to *not* log-on to the Datatracker to
manually input or update the status of drafts in her/his WG.
This could be read two ways. One reading implies that the states
can be changed in some way other than by logging on.
10. Could you mention WG Secretaries explicitly somewhere. Perhaps
as an example when you mention delegates the first time?
---
11. Minor inconsistency that "WG chair" and "IETF WG chair" are both
used.
---
12. Section 2
- I-Ds that are being considered for adoption by one or more WGs.
Maybe an unnecessary nit, but "are being considered" is passive voice
and I know a number of document authors who do nothing but consider
their I-Ds for adoption by a WG. Would you mind changing to...
- I-Ds that are being considered under the guidance of a WG chair for
adoption by one or more WGs.
---
13. Section 2
An I-D having a filename that includes the author's name and a WG
acronym but not the string "-ietf-" may be a candidate for adoption
by a WG and is also to be interpreted as being an "I-D associated
with an IETF WG" for the purposes of this document.
Sorry to be a pedantic lawyer, but... :-)
"is also to be interpreted" should be scoped to within the two bullets
at the top of the section, I think. So perhaps...
An I-D having a filename that includes the author's name and a WG
acronym but not the string "-ietf-" may be a candidate for adoption
by a WG and, if so, is also to be interpreted as being an "I-D
associated with an IETF WG" for the purposes of this document.
---
14. Requirement 10
I don't feel it is correct to place requirements on the implementation
that do not affect:
- the blackbox behavior
- the cost
- the maintainability
It is possible that you feel that this requirement falls into the third
category, but it seems a bit out of scope to me.
Alternatively, it may be that you simply meant that the implementation
should use the state machines documented in [WGDRAFTS] to determine
the valid state transitions.
---
15. Requirement 40
Very pedantic. Sorry!
The Datatracker SHALL allow WG Chairs and their delegates to set and
reset all of the WG I-D status annotation tags defined in Section
3.5 of [WGDRAFTS] for every I-D associated with their WGs. (R-040)
s/all of the/each of the/
(The subtly being that you have implied that they can set/reset "all at
once" - a button that often exists on GUIs, but not what you mean.)
---
16. Requirement 86
Pretty petty, but...
The WG Chair (or delegate) who moves an I-D into the "In WG Last
Call" state SHALL be required to specify the number of weeks that
the document may remain in this state.
Why is the granularity required to be in weeks?
Can we have a "date and time for end of last call"?
Very often I have started a WG last call on a Friday and wanted to let
it run two weeks and until first thing Monday morning.
I am largely happy with this document. However there are a couple of issues I
would like to discuss before recommending approval of this document:
1) 3. General requirements
The Datatracker SHOULD date and timestamp every update to the WG
status of an IETF Stream I-D and use that information when it needs
to display the WG status change history of that I-D. (R-007) The WG
status change history for each I-D SHOULD also identify the person
or entity that updated the WG status of the I-D (e.g. one of the
WG's Chairs, a delegate, an AD, the System, the IETF Secretariat)
and describe the change in the WG status of the I-D (e.g. "WG State
changed from 'a' to 'b'", "Document Annotation Tag 'x' Set (or
Reset)", "Document Availability status changed from 'j' to 'k'").
(R-008)
Why only SHOULDs (twice)?
2) 6.1. Candidate WG Document
The Datatracker SHALL also remove the name of the IETF WG from its
WG status display (of other WGs (per Requirement R-061) in which the
I-D is still being considered for adoption), and remove the Chairs
(and delegates) of the WG from the distribution list for the e-mails
that may be generated per Requirements R-063, and R-065 to R-069
inclusive. (R-072)
Should this also result in an email to Chairs/delegates of other WGs?
3) 6.5. In WG Last Call
It is possible that a WGLC may lead directly back into another WGLC
for the same document. For example, an I-D that completed a WGLC as
an "Informational" document may need another WGLC if a decision is
taken to convert the I-D into a standards track document. The
Datatracker SHOULD allow this to occur. (R-090)
I believe this must be a MUST level requirement. Not allowing multiple WGLCs
would
be a serious deficiency in the tool.
4) DISCUSS DISCUSS:
6.8. Revised I-D Needed (annotation tag)
A document that needs revision may be identified when the WG Chair,
delegate, or the Responsible AD logs-on to the Datatracker to append
one of the "Issue Raised - Revision Needed" annotation tags to the
status of the document. The Datatracker SHALL require the person
who attaches one of these annotation tags to a document to indicate
the number of weeks that it should take for the revised document to
be produced (R-096). The Datatracker should also prompt the user to
consider changing the WG state of the I-D from "Submitted to IESG
for Publication" to something else (e.g., Parked WG Document, WG
Document, Waiting for WG Chair Go-Ahead). (R-097)
As an AD I would hate to be forced to use another interface to make a document
as needing a new revision once the document is in IESG processing.
Can this be
clarified?
5) 6.8. Revised I-D Needed (annotation tag)
The Datatracker should be programmed to send an e-mail to the WG's
Chairs and delegates after the number of weeks specified in R-087 to
remind or 'nudge' the WG Chairs and delegates to follow-up on the
revisions to the document, unless a revised document is submitted
before the time elapses. (R-098)
Does posting of a new revision automatically clear the "Revised I-D Needed"
annotation tag?
6) 8. WG document status change reporting requirements
Everyone with 'write' access to WG document status information
SHOULD be able to obtain a summary display of all status changes
made to the WG documents they are responsible for, from the present
time backwards, split by pages, after successfully logging-on to the
Datatracker. (R-101)
Is there any reason why this information is only accessible to people with
"write" access? One great advantage of the existing datatracker is that
information about a document is visible to everyone (including all history),
although there is a way to mark certain things as "private" (not visible to
others).
1) 4.2. For IETF Working Group Chairs
When an IETF WG Chair needs to input or update the WG status of an
I-D in one of his or her WGs, the WG Chair SHALL be required to log-
on to the Datatracker using a personal user-id and password (e.g.,
an IETF tools password) in order to gain 'write' access. (R-015)
[...]
- SHALL be able to designate one or more people to act as delegates
to input and update the WG status of the I-Ds associated with their
WGs; (R-020) The identifier for each delegate should be the
person's e-mail address; (R-021)
I think it would be a good idea to clearify the relationship between a user-id
and an email address. Currently each user-id is an email address, but the text
above seem to be implying that some kind of mapping might be possible.
This also
affects other sections (e.g. 4.3).
2) 4.3. For Delegates of IETF WG Chairs
The Datatracker SHOULD alert the WG Chairs, the IETF Secretariat,
and the newly designated delegate via e-mail if a person who is
newly designated to be a delegate of a WG Chair does not have a
personal user-id and password to log-on to the Datatracker. (R-029)
What about showing this information to the WG chair when he/she adds a delegate
in the datatracker's web interface?
3) 5.1. WG Document States
The Datatracker SHALL allow WG Chairs and their delegates to select
the next state for an I-D from one of the 'most likely' next states
described in Requirement R-035, or from any of the other WG document
states (per Requirement R-017) if needed. (R-039)
Why not just say that any state transitions are allowed.
If the intent of the
wording is to show that there should be an easy way to select one of the 'most
likely' states, then that should be stated explicitly.
4) 5.3. WG Document Protocol Write-ups
IETF WG Chairs and delegates may designate themselves to act as the
Document Shepherds for some or all of the I-Ds in their own WGs. In
the WGs where this happens, the Datatracker SHOULD ask the WG Chairs
and delegates which role they are playing when the log in, in order
to display the most appropriate user-interface for that role.
(R-053)
Speaking as an individual, I would dislike an interface that is forcing me to
act in a particular role without allowing me to change the role. In particular I
am hoping that once a role is selected, it can be changed without the need to
logout and login again.
5) 6.1. Candidate WG Document
The Datatracker SHALL allow an IETF WG Chair or delegate to identify
an I-D as a "Candidate WG Document" in her or his WG if the I-D has
not yet been adopted by any IETF WG, is not expired and has not been
withdrawn or replaced by another I-D. (R-054) The Datatracker
should not allow a document that is expired, withdrawn, replaced or
already adopted by an IETF WG to be moved into the "Candidate WG
Document" state.
I am slightly concerned about not allowing a replaced document to be used as a
"Candidate WG Document". Sometimes documents get forked, or a document which was
once replaced by another one might be abandonned by the WG. It should be
possible to use such documents elsewhere.
6) 6.1. Candidate WG Document
When Requirements R-056 and R-057 are met, the Datatracker SHALL
display the WG status of the I-D as follows: "Candidate WG Document
in (name of IETF WG)". (R-058)
I hope you didn't mean that the status should be presented exactly in the form
shown above.
7) 6.3. Not Adopted by a WG
Notwithstanding the aforementioned, a different IETF WG may decide
I think the same WG should also be allowed to adopt the document later on.
I suggest dropping the word "different" above.
to adopt an I-D after it has entered the "Not Adopted by a WG"
state. The Datatracker SHALL allow a WG Chair or delegate to move
an I-D that is in the "Not Adopted by a WG" state into the "Adopted
by a WG" state if the I-D has not expired, been withdrawn, or been
replaced by another I-D. (R-075)
8) 6.4. WG Document
The Datatracker SHALL allow WG Chairs and their delegates to move an
I-D into the "WG Document" state from a different document state as
defined in Section 3.3 of [WGDRAFTS] if the I-D has not expired,
been withdrawn or replaced by another I-D. (R-079)
Just to double check: this would allow to adopt a draft as a WG document,
without renaming it?
I think that would be useful.
(Consistent with Robert's issue #1)
The processing described in the Candidate WG Document state adds a lot of
formality that are not currently
practiced by most IETF working groups, and
don't seem to be supported by 2026. Is a datatracker requirements
draft the
place to institute new process requirements?
[WGDRAFTS] does not define withdrawn. I share Lars' concerns regarding 4.2, paragraph 7, 9 , and 11. I am not sure I agree with his analysis, but this text deserves some discussion!
1) Where this document is capturing requirements to facilitate WG tracking
using
processes that WG chairs are already exercising I think it's on track.
I believe
it and it's companion state document are going going further than
that in
with the definition of the Candidate WG document and Not Adopted by
a WG states
and the behavior required not just of the tool but of the chairs
by this document.
Attempting to define a new process and codify it into a
tool at the same time seems
risky. I would prefer to see the requirements
around tracking a document before WG
adoption split into a separate effort,
both in determining requirements and implementing
the tool. (It would be even
better if there was experience with the suggested process -
an interested
chair and cooperative AD could do this now with the comments field in the
existing tracker.) Our initial effort should be scoped to helping WG chairs and
other
stakeholders track what they already do.
2) R-003 can be read to mean that every IETF Stream document SHALL be tracked
using this tool,
contradicting R-001. I suggest that the first part of the
requirement be rephrased thus:
When the WG status of an IETF Stream I-D is tracked, the Datatracker SHALL use
the
WG document states ...
3) Why is R-012 SHOULD and not MUST?
4) There are a couple of places (For instance R-021) where a design decision is
being
made (probably the right decision, but I'm not sure this is the tool to
make that
decision with)- there are people now with exising datatracker/tools
logins whose login name
does not look like an email address. This decision will
force delegation to them to be through
an email address _associated_ with the
login. MANY people with datatracker logins have more than
one email address.
Could we remove this bit of design? If not, can we acknowledge that
people may
have more than one email identifier?
5) The delegation requirements in 4.2 seem to be written from the viewpoint of a
chair
delegating authority for all of the documents in the working group. Why
are they not
written so that delegation is done on a per-document basis (in the
spirit of R-012)?
6) R-054 (also touched in Alexey's comments) imply that someone must logout to
change
roles. If that was the intent, it should be made explicit. I hope that
was NOT the
intent and I think we need an additional requirement that a login
that can serve
multiple roles be allowed to change roles on demand without
logging out.
Early in the conventions section: There are instances of individual drafts
being adopted
by working groups that don't get renamed -ietf-.
R-020 - is it worth calling out in the requirement that one of the delegates may
also have
other roles (like being the chair of another WG, or being an AD of
another area). It might
also help the implementer of these requirements if you
made a forward reference to R-033
here. (btw - R033 is showing some edititis -
it's referring to itself as if it were somewhere
else.
I have concerns with the process being proposed around the pre-WG adoption
states and the
mechanics associated with them. I'm capturing a couple of them
here as a comment, but in
general I think the proposal needs additional
discussion before codifying it into a tool.
- Many working groups consider
all documents that fall within their scope candidates
for adoption. Is the
goal here to focus attention on documents a chair plans to
issue a call for
adoption on? If so, a chair can do that with email, and I don't
see the
benefit tracking this state brings. I _can_ see this introducing pressure
on chairs to "bless" documents ahead of time, and becoming a breeding ground for
process confusion (similar to the must-bar-bof-twice misconception that has been
recently raised)
- What is the point of the "Not adopted by a WG state"? If
it was to help push back
against proposal replay attacks? If so, I think
just having a way to capture that
a group was asked to adopt a document and
declined would be just as powerful and
would be far less complex to
implement. (The tool could present the chair with
a button that put a chunk
of well-known, searchable, text into a comment for example).
Updated to remove #3, but I retained the numbering.
Great document. Just a couple of things I'd like to clear up:
#1) R-008: Why isn't the time-stamp and identification of the person who made
the change a MUST? On a tangential note, maybe we should be tracking exactly
who it is who did the submission. This information might be useful.
#2) R-20: Should we limit the number of delegations allowed per-WG? Can we pick
an upper bound of say 3 people per WG that aren't WG chairs?
#3) Resolved.
#4) R-035: When would the datatracker not show the state etc after logging on?
#1) R -019 r/(e.g., IANA status, RFC-Editor status, IESG status;/(e.g., IANA status, RFC-Editor status, IESG status); #2) R-020/025 Should the should be SHOULD: The identifier for each delegate should #3) R-022 r/for the different/the different #4) R-033: each IETF AD SHALL have the privileges specified in Requirement R-033 for every WG in his or her Area (R-033) I'm having trouble parsing this one. Is it meant to be recursive? #5) Page 12: The "a" is extra perhaps: for adoption in a their IETF WG without #6) R-073/094: Should the shall be SHALL? #7) Sec 6.3 last para: r/draft-IETF-/draft-ietf- #8) Sec 6.5: Should we add a default value for the length of the WG LC?
draft-ietf-proto-wgdocument-states
DISCUSS-DISCUSS: The title and abstract claim this document describes
datatracker states. Reading the text, it's clear that the document
also describes transitions between states, and this is where my rub is
with the document: it's neither complete in describing these
transitions, nor does it IMO necessarily characterize the possible or
even typical transitions very accurately. (For example, starting
Section 3.2.3 by saying that "IESG Evaluation is another state that
may cause an I-D to be sent back to an IETF WG for revision" really
paints an incorrect picture of the common case.)
DISCUSS: It seems that the model here is that three state machines
exist: one for document availability (active/expired/replaced), one
for the IESG, and one for the WG. The result is that a given document
is in a specific state in all of these three state machines. This is
not at all clearly explained in the document, it talks about the
states of all three state machines interchangeably, which is really
confusing. A clear overview with some diagrams would help a lot.
(Section 3.4 has some of this, but much too late.)
Section 3.3.1., paragraph 4:
> b) an I-D that the WG Chair asked an author to write;
DISCUSS: I disagree that this makes an ID a candidate WG document.
Section 3.3.2., paragraph 0:
> 3.3.2. Adopted by a WG
DISCUSS: We don't need this state. It's equivalent to applying "WG
Document" to an individual ID.
Section 3.3.4., paragraph 0:
> 3.3.4. Adopted for WG Info Only
DISCUSS: I don't think we need this state, it's equivalent to "WG
Document" that never progress (or eventually progress to "Withdrawn".)
Section 3.3.5., paragraph 0:
> 3.3.5. Not Adopted by a WG
DISCUSS: What purpose does this state serve other than to shame
authors?
Section 3.5.4., paragraph 0:
> 3.5.4. Awaiting External Review / Resolution of Issues Raised
DISCUSS: Because "external" really means "external to the WG", this
state subsumes states 3.5.1, 3.5.2 and 3.5.3. Review-team specific
states are not a good idea; for example, you'd immediately need to add
"MIME Types Review", "URL Team Review", "TSV Directorate Review", etc.
etc.
Appendix A:, paragraph 1:
> This Appendix describes the status information currently stored in
> the IETF Datatracker tool for every I-D submitted to the IESG for
> publication. Most of the terms and definitions herein are as in
> [IESGSTAT].
DISCUSS: These definitions should be identical to [IESGSTAT], because
it is not the purpose of this document to redefine what those states
mean. If the descriptions in [IESGSTAT] can be improved, let's make
the changes there, please.
Section 2., paragraph 1: > The phrase "working group document" is to be interpreted as being > synonymous with "working group I-D". The same is true for the > plural case of each phrase. You probably want to add that a "working group I-D" is an I-D that has gotten consensus for adoption as a work item by a WG (compared to individual ones, that have not or not yet). Section 3.1.3., paragraph 3: > - The filename of an individual I-D that is being considered for > adoption by an IETF WG will typically include the name of its > author (e.g. 'draft-author-wgname-topic-nn'). If the I-D is > adopted by a WG, its filename will change to 'draft-ietf- > wgname-topic-00', and the Datatracker will describe the older > individual I-D as having been "Replaced by" a newer WG I-D. It may be useful to add that "replacing" an ID in this form currently requires an explicit request by the WG chair. Without that request, the IDs will coexist and the individual one will eventually expire. Section 3.2., paragraph 0: > 3.2. IESG Document States The state definitions below are sightly different in wording than in [IESGSTAT] and in Appendix A. This is confusing. Section 3.2.3., paragraph 0: > 3.2.3. IESG Evaluation Suggest to swap the order of the two paragraphs. Section 3.3., paragraph 0: > 3.3. Working Group Document States It would be good to make this a new top-level section, because unlike Sections 3.1 and 3.2, which were replicated for information and not new, this *is* the new stuff. Section 3.3., paragraph 1: > This section describes new states to be added to the Datatracker to > make it possible for IETF WG Chairs and/or their delegates to > indicate the status of I-Ds associated with their working groups. What delegates? Secretaries? Section 3.3., paragraph 2: > WG Chairs will have the option to use some, all or none of these WG > document states to describe the status of some, all or none of the > I-Ds associated with their WGs. Don't we want to recommend that they should use them for all of their documents though? Section 3.3.1., paragraph 6: > Note that a document author may "shop" an I-D to multiple working > groups hoping to get the I-D adopted somewhere. In order to track > this, the Datatracker will be enhanced to enable an I-D to be in > the "Candidate WG Document" state in more than one WG at a time. This sounds like we want to encourage shopping. Shouldn't the focus here be on adding functions that alert us to cases where shopping happens? Section 3.3.3., paragraph 3: > Every "WG Document" should have an "intended maturity level" (e.g. > Informational, Proposed Standard, Experimental) associated with it > as described in Section 3.6. This information is often requested > by IETF participants and it is now required by the IESG for every > I-D that is submitted to the IESG for publication. Not relevant for the purposes of this document. Section 3.3.6., paragraph 0: > 3.3.6. Parked WG Document Not clear if we need this state. Also, what it exactly means is unclear - does "parking" prevent a document from becoming expired? Section 3.3.7., paragraph 0: > 3.3.7. Dead WG Document How is this different from a "WG Document" that is "Expired"? Section 3.4., paragraph 0: > 3.4. Working Group Document State Diagram This section/diagram should really come before the detailed state descriptions earlier in Section 3. Section 3.6., paragraph 0: > 3.6. Intended Maturity Level of WG Documents Sure, but this document is supposed to be on ID states.
Many thanks for taking on this important work. Just a few Comments
that you might consider as the I-D goes forward.
I feel there is some confusion between "state" and "status" (for
example, in the Abstract). This is handled in
draft-juskevicius-datatracker-wgdocstate-reqts which says:
The phase "WG status of an I-D" is to be interpreted as referring to
the WG document state that an I-D is in, as defined in Section 3.3
of [WGDRAFTS]. This phrase does not refer to an I-D's availability
status (e.g. "Expired", "Active") as described in Section 3.1 of
[WGDRAFTS], or the IESG state used by IETF Area Directors (ADs) to
describe the status of an I-D they may be evaluating.
I feel it would be helpful to use the same language in both documents.
---
Section 3.1.2
An "Active" I-D is a document that is not expired.
In fact, an I-D that is an RFC, is not "Active". Ditto other states.
---
Some inconsistency of "WG" and "IETF WG" that implies a difference of
meaning that does not exst.
---
Section 3.2
Not quite sure of the purpose of this section.
It seems to me that "In Last Call"and "Waiting for AD Go-ahead" are
also key states for interaction with the document authors.
"AD is Watching" and "Dead" also seem to be pretty closely related to
the authors.
---
Figure 1
I know this is showing common transitions only, but I suspect you should
show the arrow between "Candidate WG Document" and "Not Adopted be a WG"
as double-headed.
I am in favor of publishing this document, as it would help to be transparent in
WG processes.
I am agreeing with Sean's comments. Additionally, I have some comments of my
own:
1) 3.3.3. WG Document
Every "WG Document" should have an "intended maturity level" (e.g.
Informational, Proposed Standard, Experimental) associated with it
as described in Section 3.6. This information is often requested
by IETF participants and it is now required by the IESG for every
I-D that is submitted to the IESG for publication.
I would like to point out that frequently the "intended maturity level" is
decided quite late in the WG process. So I want to make sure that this
information is not required early on.
2) 3.3.8. In WG Last Call
A document in this state should remain "In WG Last Call" until the
WG Chair moves it to another state. The WG Chair may configure
the Datatracker to send an e-mail after a specified period of time
to remind or 'nudge' the Chair to conclude the WGLC and to
determine the next state for the document.
Personally I prefer the way how IETF LCs work: IETF LC lasts for a specified
period of time, after which the document automatically moves to "Waiting for AD
Go-Ahead" state. I think the same should happen to documents in WGLCs.
3) 3.3.10. WG Consensus: Waiting for Write-Up
A document in the "WG Consensus: Waiting for Write-Up" state has
essentially completed its development within the working group,
and is nearly ready to be sent to the IESG for publication. The
last thing to be done is the preparation of a protocol write-up by
a document shepherd. The IESG requires that a document shepherd
write-up be completed before publication of the I-D is requested.
This might be an abuse of process, but I don't think write-up is always required
when publication is requested. I sent several documents to IETF LC without a
write-up, I think this should be allowed.
4) A.1.2. Publication Requested
A formal request has been made to advance/publish the document,
following the procedures in Section 7.5 of RFC 2418 [RFC2418]; the
request could be from a WG Chair, or from an individual. Note: the
Secretariat (iesg-secretary@ietf.org) is copied on these requests to
ensure that the request makes it into the Datatracker.
I don't think sending this to Secretariat is a requirement. All documents I've
sponsored I entered into datatracker myself. So I suggest inserting the word
"typically" before "copied".
A document
in this state has not (yet) been reviewed by an Area Director nor
has any official action been taken yet, other than to note that its
publication has been requested.
(a) Section 3.1
The document state withdrawn is listed but is not defined and no reference is
given. "Withdrawn" is not supported
in the old tracker, so I have no idea what
is intended.
(b) 3.1.3. Replaced
I have seen a number of cases where a single document was replaced by three or
four documents. I suspect that
the reverse situation (where multiple documents
are replaced by one) also exists. The text in this section implies
that the
replacement is always one-for-one.
(c) This one is a discuss-discuss. I am not requesting any change, but do want
to see some discussion of this
concept
3.6. "Intended Maturity Level of WG Documents" suggest that every wg document
should indicate the intended
maturity level. This is a decision that the wg
often makes at a later stage in the process (before or during WG LC).
Making the
decision early may not be a good idea - the editor may regard that as a
contract. Was the idea of an
"undecided"maturity level considered?
(a) In 3.3.1
OLD
b) an I-D that the WG Chair asked an author to write;
NEW
b) an I-D that the WG Chair asked an author to write specifically
for consideration as a WG draft;
(b) I support Lars' discuss on section 3.3.5. Not Adopted by a WG
(c) Figure 1
There should be a line from WG LAST CALL to WG document. A chair
may decide that Last Call failed, and
send the document back to the working for
extensive discussions. As drawn, any document that goes into Last Call
has to
go to the IESG before it can then be returned to the working group.
I think the proposal for a process to track documents before WG adoption should
be split
into a separate effort. This is coupled to a discuss point on the
tracker requirements document
copied here for convenience:
Where this document is capturing requirements to facilitate WG tracking using
processes that WG chairs are already exercising I think it's on track. I believe
it and it's companion state document are going going further than that in
with the definition of the Candidate WG document and Not Adopted by a WG states
and the behavior required not just of the tool but of the chairs by this
document.
Attempting to define a new process and codify it into a tool at the
same time seems
risky. I would prefer to see the requirements around tracking
a document before WG
adoption split into a separate effort, both in
determining requirements and implementing
the tool. (It would be even better
if there was experience with the suggested process -
an interested chair and
cooperative AD could do this now with the comments field in the
existing
tracker.) Our initial effort should be scoped to helping WG chairs and other
stakeholders track what they already do.
#1) Sec 3.3.7 and Figure 1: If a document is dead to the WG, then can the author take it to another WG and begin the shopping process all over again? #2) Sec 3.5: Should we add "Awaiting Media-Type Review / Resolution of Issues Raised" or more generally "Awaiting Expert Review" for any I-D that affects an IANA registry? #3) Sec 3.6: Is it "Standard" or "Internet Standard"? The title of section 4.1.3 of 2026 is the later. 2026 also uses the phrase when describing STDXXX.
draft-turner-suiteb-cmc
5.1. RA Processing of Requests RAs conforming to this document MUST ensure that only the permitted signature, hash, and MAC algorithms described throughout this profile are used in requests; if they are not, the CA MUST reject those s/CA/RA ? requests. The RA SHOULD return a CMCFailInfo with the value of badAlg [RFC5272]. 6.1. CA Processing of PKI Requests When processing end-entity generated SignedData objects, RAs MUST NOT s/RAs/CAs ? perform Cryptographic Message Syntax (CMS) Content Constraints (CCC) certificate extension [CCC] processing.
draft-livingood-woundy-congestion-mgmt
A review by Ari Keranen: There's some repetition especially in section 7. For example, the following sentence is there twice: As a result, the congestion management system measures the traffic conditions as observed by each CMTS, and applies any policy actions to traffic on a specific interface of a CMTS (rather than some other, more distant segment of the network). The described approach may have at least one problem: given that there is a "fixed" limit (e.g., 70% utilization for 15 minutes) after which user enters the Extended High Consumption State (EHCS), it gives users incentives to linger just below the limit (e.g., 100% utilization for 14.5 minutes and 60% for 30 seconds). Even if the limits would be unknown to subscribers, the user could try to probe them and try to stay just below the probed limit and thus get a bigger share of the congested link than users not doing that. Instead, if the user could be partially in ECHS, depending on the utilization after some threshold, there would not be such incentives. For example, after using 80% of the link for 15 minutes (or 100% for 5 minutes), one third of the packets would be marked BE, or for 90% utilization for 15 minutes, two thirds of the packets would be BE, etc. This approach would also prevent the oscillation problem. In section 7.3 it is mentioned that (in theory) BE traffic might not be delivered at all in case of high link utilization. Wouldn't it be better to deliver BE packets just with (much) lower probability?
in 3.7, any device controlled by Comast? or any device?
draft-azinger-additional-private-ipv4-space-issues
This is a very much needed document. The document is on the right track,
but falls short on a couple of aspects. I would like to recommend
revising the document once before we approve it.
My main concern is that in my recollection the IETF made a very clear
decision. All the discussion pointed to saying "no" for any new
address space allocation for private addressing. There were numerous
arguments why this is the right course of action. However, the document
falls short of actually stating this. The document needs to say clearly
that the IETF recommends against new private address space allocations.
A couple of other issues:
It is not always
possible to rely on CPE devices using any particular range, however.
In some cases this means that CPE devices can use unallocated address
space or address space allocated to other network operators.
I have heard of operators running on unallocated address space, but
never of CPEs. CPEs may default to different values with the RFC 1918
range of course. (Though when we talked about this in OPSAREA a couple
of IETFs ago Dave Tahler pointed out that majority if not all new
equipment defaults to 192.168/16.) But CPE that defaults to unallocated
or someone's address space? Really? Do we have evidence of this from the
field?
In any case, the document does not describe what is the key problem
for the CPE: having a *different* address range than the service provider
network has.
Using unique, globally scoped IPv6 unicast addresses is the preferred
option as it removes any concerns about address scarcity. In some
cases implementing a new network protocol on a very large network
takes more time than is available, based on network growth and the
proportion of private space that has already been used.
It would be good to mention already here that some ways of allocating
new address space on the IPv4 side would result in equivalent
implementation/deployment issues (such as updating all routers and
hosts across the Internet to not drop 240/4).
I would also like to see Thomas Narten's comment on peer-to-peer
addressed (see below for a copy of his review).
Finally, I think the section that talks about address sharing
across multiple subscribes is probably a little too simplified.
Note that the IETF already has ongoing work about such mechanisms
(e.g., dual stack lite which implements a CGN to share addresses).
I think the true driver behind new private address space is that
the service providers do not want "new" solutions (such as IPv6,
dual stack lite) but rather want to keep existing customer NATs
and add one of their own.
Thomas Narten's review:
Overall, I think the document is useful, but another pass would be
good. My review comments below.
Thomas
> > any Internet registry. Very large networks can find that they need
> > to connect more interfaces than the number of addresses available in
> > these three ranges. It has occasionally been suggested that
better:
Very large networks can find that they need to number more device
interfaces than there are available addresses in these three
ranges.
> > these three ranges. It has occasionally been suggested that
> > additional private IPv4 address space should be reserved for use by
> > these networks. Although such an action might address some of the
> > needs for these very large network operators it is not without
> > consequences, particularly as we near the date when the IANA free
> > pool will be fully allocated.
This document should (probably) say that the question of reserving
more private space is out of scope and not adddressed by this
document.
> > The address space set aside in [RFC1918] is a finite resource which
> > can be used to provide limited Internet access via Network Address
> > Translation (NAT). A discussion of the advantages and disadvantages
> > of NATs is outside the scope of this document. Nonetheless, it must
But at least provide references to some of the documents that do
discuss that... I think the IAB has authored 2..
> > others. For instance, it is often technically feasible to use NAT or
> > even multiple layers of NAT within the networks operated by
> > residential users or corporations where peer to peer communication is
> > not needed. Where true peer to peer communication is needed or where
This is too simplistic. Its not just peer-to-peer. More like if only
clients (and no servers) are behind the NAT. This document is likely
to have problems trying to summarize the pros/cons of NAT. Can't you
just point to some other document and move on?
I particularly object to the word "often" above. It all depends on
what you are doing, and "often" suggests it mostly works.
> > In many cases it is possible to use multiple layers of NAT to re-use
> > parts of the address space defined in [RFC1918]. It is not always
Again, "in many cases" sets the wrong tone, IMO.
> > In some cases this means that CPE devices can use unallocated address
> > space or address space allocated to other network operators. In
"can use" is a very positive tone and suggests this is a good idea or
acceptable. Please rephrase.
> > Another option is to share one address across multiple interfaces and
> > in some cases, subscribers. This model breaks the classical model
> > used for logging address assignments and creates some risks
> > [CLAYTON]. This concept is more fully explored in [FORD].
how can using the same address by multiple susbcribers work? How do
you make routing work?
> > 4.1. Unique Globally Scoped IPv6 Unicast Addresses
> >
> > Using unique, globally scoped IPv6 unicast addresses is the preferred
> > option as it removes any concerns about address scarcity. In some
> > cases implementing a new network protocol on a very large network
> > takes more time than is available, based on network growth and the
> > proportion of private space that has already been used. In these
> > cases, there is a call for additional private address space that can
> > be shared by all network operators. [DAVIES] makes one such case.
> >
This section needs work. Deploying IPv6 is not a simple solution for
someone running out of IPv4 space. What about providing backwards
compatability with IPv4?
What might be best is to just say that moving to IPv6 is the best long
term solution, but in the short term having IPv4 is probably still a
requirement. And that this document just focusses on IPv4.
Making it sound like you can just move to IPv6 as a solution is silly
and not helpful.
Also, I'd put 4.1 and 4.2 into their own section that focusses on IPv6
issues. These are the only 2 subsections that talk about IPv6, I
believe.
> > cost. However, it is unlikely to become available in large
> > contiguous blocks and this would add to the network managment burden
> > for the operator.
You might want to explain what the increased burden is. ALso, you
don't say how much of a burdon this would be. Presumably, running out
of usable space is a bigger burden to have to deal with...
> > For these reasons, address transfers will not be
> > an attractive proposition to many large network operators.
This is just the author's opinion. Better to say something more like:
For these reasons, address transfers will likely provide only
limited help to many large network operators.
And, BTW, what is "large"?
> > Leases
> > might not be attractive to some organizations if both parties cannot
> > agree a suitable length of time. Also, the lessor might worry about
> > its own unanticipated needs for additional IPv4 address space.
I think the above can be dropped. There are many issues that would
impact the viability of such an approach. You only mention a couple,
and I'm not sure they are even the important ones.
> > 4.4. Using Unannounced Address Space Allocated to Another Organization
> >
> > Some network operators have considered using IP address space which
> > is allocated to another organization but is not publicly visible in
> > BGP routing tables. This option is very strongly discouraged as the
> > fact that an address block is not visible from one view does not mean
Just "strongly discouraged?" Shame on you! This should not be
recommended at all, as it can lead to interoperability problems to
sites that legitimately own that space. (You start to mention them
later.)
> > queries, traceroute output and other ways. The ambiguity this causes
> > is problematic for multiple organizations. This issue is addressed
> > in [RFC3879], section 2.3.
"is addressed" is wrong wording. I think you mean to say that this
issue is discussed in more detail on that section....
> > It is also possible that the registrant of the address block might
> > want to increase its visibility to other networks in the future,
> > causing problems for anyone using it unofficially. In some cases
> > there might also be legal risks involved in using address space
> > officially allocated to another organization.
It's not just if it is announced publically, also happens if the
network interconnect privately...
> > 4.5. Unique IPv4 Space Registered by an RIR
> >
> > The policy framework shared by the RIRs does not discriminate based
> > on what an address is used to do, just on how efficiently the
> > assigned addresses are used.
Please just say: RIR policies allow organizations to get public space
even if the addresses will only be used for internal purposes.
> > Unique IPv4 addresses registered by an
> > RIR are potentially available to organizations whose networks have
> > used all the addresses set aside in [RFC1918].
This makes it sound like you have to first use up your addresses
before going to an RIR. That is not true and should be made more
clear.
> > Nonetheless, network
> > operators are naturally disinclined to request unique IPv4 addresses
> > for a purpose that could be met with private addresses were it not
> > for the size of the network because addresses assigned in this way
> > are not available for anyone else to use and so their registration
> > denies them to new entrants, including potential customers.
I don't quite understand what this is trying to say...
> > It is be possible to re-designate a portion of the current global
s/be///
> > When considering re-designating a portion of the current global
> > unicast IPv4 address space as private unicast address space it is
> > important to consider how much space would be used and for how long
> > it would be sufficient. Not all of the large networks making full
> > use of the space defined in [RFC1918] would have their needs met with
> > a single /8. In 2005, [HAIN] suggested reserving three /8s for this
> > purpose while in 2009 [DAVIES] suggested a single /10 would be
> > sufficient. There does not seem to be a consensus for a particular
> > prefix length nor an agreed basis for deciding what is sufficient.
> > The problem is exacerbated by the continually changing needs of ever
> > expanding networks.
Actually, there has not been consensus to reserver *any* additional
space. The above should say that clearly. Saying we just haven't
agreed on the size is misleading.
Hmm. this document just ends without a summery or recommendation. That
doesn't seem right...
This position is mostly a discuss-discuss; I'd like to discuss some of the basic
premises from which the doc is written.
I don't see any acknowledgments of review by or input from other stakeholders
like service providers, wireless operators, etc. I've asked John Brzozowski
(Comcast) for his comments, which he expects to send to me by Sep 3.
In my opinion, the document is not clear on the distinction between RFC 1918
addresses used to number "internal" interfaces, which are only used for internal
communication, and addresses used to number "subscriber" interfaces, which need
global access. So, for example, in section 3:
The address space set aside in [RFC1918] is a finite resource which
can be used to provide limited Internet access via Network Address
Translation (NAT). A discussion of the advantages and disadvantages
of NATs is outside the scope of this document. Nonetheless, it must
be acknowledged that NAT is adequate in some situations and not in
others. For instance, it is often technically feasible to use NAT or
even multiple layers of NAT within the networks operated by
residential users or corporations where peer to peer communication is
not needed.
unless the operator is using RFC 1918 address space for subscriber devices
(e.g., HGW, host, mobile device), I don't see how this text is relevant to RFC
1918 address space exhaustion.
A little farther along in section 3:
Another option is to share one address across multiple interfaces and
in some cases, subscribers. This model breaks the classical model
used for logging address assignments and creates some risks
[CLAYTON]. This concept is more fully explored in [FORD].
This text, if I understand it correctly, talks about sharing a global address
(not RFC 1918 space) among multiple subscribers, and isn't germane to the
discussion of RFC 1918 address space exhaustion.
Regarding section 4.2: if the addresses in question are truly site-scoped and
not routed outside the operator's domain, how is the (probabilistically
unlikely) prefix clash a problem? Is the use of IPv6 ULAs any more difficult
than the use of IPv6 GUAs; I don't undertstand the different descriptions for
the problems listed in sections 4.1 and 4.2.
In section 4.3, are the global addresses in question for use in supplementing
internal addressing for which RFC 1918 is insufficient? Is it feasible to
obtain enough addresses in this way to make significantly more address space
available than is in 10/8?
In section 5.3:
If additional private address space is not defined and the large
network operators affected by this problem are not able to solve
their problems with IPv6 address space or by segmenting their
networks into multiple routing domains, those networks will need
unique IPv4 addresses. It is possible and even likely that a single
network could consume a whole IPv4 /8 in a year.
Is this projected rate of consumption based on global addresses required for
subscriber equipment accessing the Internet and (potentially) private addresses
for numbering internal interfaces? Do the authors have any data to support
their claim?
INTRODUCTION, paragraph 2: > Additional Private IPv4 Space Issues Nit: Title can be misunderstood (as in "this doc talks about additional issues with regards to private address space.") Maybe: "Issues with Assigning Additional IPv4 Private Address Space"? Section 3., paragraph 0: > 3. Network Address Translation I wish this section were more clear about the significant downsides that multiple levels of NAT have compared to a single level of NAT. Section 8.1., paragraph 2: > [RFC2860] Carpenter, B., Baker, F., and M. Roberts, "Memorandum of > Understanding Concerning the Technical Work of the > Internet Assigned Numbers Authority", RFC 2860, June 2000. Nit: Unused Reference: 'RFC2860'
I support this document as a really helpful anchor for discussing an
important problem space.
My Discuss is around the scope of the problem as expressed in the
document.
1. I got snarled up with some of the language around "interfaces". My
initial reaction was to assume that you were talking about interfaces
as links between routers. These are indentified for use in routing
protocols, but do not need to be routable entities. Thus, I was
surprised not to find any mention of unnumbered interfaces.
But I suspect you are intending to scope to "interfaces to the
network" since the text seems to focus on addressable points of
attachment.
Could we discuss this and, if I am right in my suspiscions, perhaps
you could look at how to clrify this in the text.
2. I found the example of VPNs a little uncomfortable (section 2). I
believe that the VPN technologies developed in the IETF have included
good precautions to avoid "address clashes" and, while I can believe
that folk feel uneasy knowing that customer spaces have overlapping
address spaces, this is not actually a significant risk.
s/It is be/It is/
Some of the references are Internet-Drafts. These need to be marked as work-in-progress.