IESG Narrative Minutes
Narrative Minutes of the IESG Teleconference on 2012-05-24. These are not an official record of the meeting.
Narrative scribe: John Leslie and Richard Barnes (The scribe was sometimes uncertain who was speaking.)
Corrections from: Barry, Richard, Russ
1 Administrivia
2. Protocol Actions
2.1 WG Submissions
2.1.1 New Items
Telechat:
Telechat:
Telechat:
2.1.2 Returning Items
2.2 Individual Submissions
2.2.1 New Items
2.2.2 Returning Items
Telechat:
3. Document Actions
3.1 WG Submissions
3.1.1 New Items
Telechat:
Telechat:
Telechat:
3.1.2 Returning Items
3.2 Individual Submissions Via AD
3.2.1 New Items
3.2.2 Returning Items
3.3 IRTF and Independent Submission Stream Documents
3.3.1 New Items
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
3.3.2 Returning Items
1302 EDT break
1307 EDT back
4 Working Group Actions
4.1 WG Creation
4.1.1 Proposed for IETF Review
Telechat:
4.1.2 Proposed for Approval
4.2 WG Rechartering
4.2.1 Under evaluation for IETF Review
Telechat:
4.2.2 Proposed for Approval
Telechat:
Telechat:
Telechat:
5. IAB News We can use
6. Management Issues
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
7. Agenda Working Group News
Amy: secretariat issue, CDNI scheduled Interim without message to us, thus announced only on CDNI list
Several: should cancel
Russ: one of them should do it
Amy: two three-hour virtual meetings, May 29 and 30, both virtual (no travel issues to consider)
Russ: we need to find out from WGCs what went wrong; bottom-line is there wasn't the announcement... I will send them a note, cc to Secretariat
Robert: Wes is on jabber; I'll have him get in touch with you
1402 EDT Adjourned
(at 2012-05-24 07:30:06 PDT)
draft-ietf-pwe3-redundancy-bit
1.
In the section 10, you wrote:
This document makes the following update to
the PwOperStatusTC
textual convention in RFC 5542 [9]:
You can't simply
update a Textual Convention (TC) like this, but putting a new TC, out of
context.
A TC belongs to a MIB module. You need a new revision of that MIB
module: RFC5542bis.
Note: you could cut/paste the new revision of the MIB module
in this document, and obsolete RFC5542, but that would be misleading from the
document title.
Also, having a new RFC5542bis will cause some problems: there
are many TCs in there, so surely, many references to RFC5542... which in turn
will need to be updated.
Now, looking more closely at your proposed change.
- dormant(4): The PW
is not in a condition to pass
packets but is in a
'pending' state,
waiting for some external event. For
example, the
PW Preferential Forwarding status state
machine as defined in [RFC
XXXX (this document)] is in
state "STANDBY".
The only change that you require is the addition of "For example, the PW
Preferential Forwarding status state machine as defined in [RFC XXXX (this
document)] is in state "STANDBY" in dormant(4).
IMHO (and I double-checked with Dan Romascanu, just to be sure), it doesn't
require the extra work to produce RFC5542bis. Indeed, you don't change the TC
semantic.
What I believe you should be doing is:
- a sentence such as (I trust
you on the exact wording): this document illustrates how the dormant value of
the PwOperStatusTC TC can be used to ..." and you include the meaning of your
initial extra sentence
- you remove "update: RFC 5542"
2.
- Section 5.1 "independent mode".
What do you mean by "management indication" in:
In steady state with consistent configuration, a PE will always find
an active PW. However, it is possible that such a PW is not found due
to a mis-configuration. In the event that an active PW is not found,
a management indication SHOULD be generated. If a management
indication for failure to find an active PW was generated and an
active PW is subsequently found, a management indication SHOULD be
generated, so clearing the previous failure indication. Additionally,
a PE MAY use the optional request switchover procedures described in
Section 6.3. to have both PE nodes switch to a common PW.
A syslog message, a SNMP notification, something else, or this is left
completely open... in other words:
"please do a little bit of management to
please the OPS people ;-)"
Can you justify why you don't even mention "management indication" in the second
mode, i.e. section 5.2 "master/slave mode"
note: I never seen the term
management "indication". Do you want to say "management notification"?
3.
Here is another point, reported by Dan Romascanu, which I cut/pasted here:
I did not have the time for a full OPS-DIR review, but I had a look at
draft-ietf-pwe3-redundancy-bit which is on the IESG agenda tomorrow.
Benoit entered a DISCUSS on a specific issue related to a proposed
modification of the PwOperStatusTC from RFC 5542, which I support, but I
think that the manageability problems with this I-D are broader. From an
operator perspective I believe that there needs to be clear indication
of the modes of operation (Independent, Master/Slave) besides the active
/ standby status of the PW, otherwise there will be no way to understand
the status and configuration in different network situations. This may
lead to changes to RFC 5542, but I think that mentioning just the MIB
changes is not sufficient, as implementing the MIB modules is not
mandatory for all PW devices, so the need to expose the modes and
forwarding states needs to operators needs to be made in a
protocol-independent manner.
- Section 12 "Major Contributing Authors" Not sure if it's a good idea to have this new section title. Knowing how sensitive this authors/contributors topic is, I wouldn't like to see a precedent with this future RFC ,i.e. "I see a Major Contributing Authors, so can we have Minor Contributing Authors section now?" So I would prefer "contributors" and "authors" sections. - Section 5.1 1. For FEC128 PW, the PW with the lowest pw-id value is selected. 2. For FEC129 PW, each PW in a redundant set is uniquely identified No idea what FEC128 and FEC129 were. I had to search and found http://tools.ietf.org/html/rfc4379#section-3.2.8, where by the way, they're spelled "FEC 128" and "FEC 129". So please add a reference.
[Discuss updated 5/23 to cross-reference the requirements document for non-
reversion and detection of misconfiguration, and to make observations about the
failure of a Master in master/slave mode.]
I have a long and rather rambling Discuss on this document. I think
that it is important to address the requirements of management and
control of end-to-end service protection as provided by PWs, so I am
in no way rejecting the concept of this document. On the other hand, I
found quite a number of issues that caused me concern. I have split
these across this Discuss (where I hope changes to the text, or
conversations in email, will resolve the issues) and Comments where I
am less bothered by how or whether you address the issues.
---
Section 1
In order to support AC or spoke PW redundancy, at least one of the
PEs on which a PW terminates MUST be different from that on which the
primary PW terminates, as described in [6].
This is not true, is it? Well, it may be true that the reference says
this, but in that case the reference is wrong.
AC redundancy can be provided using a pair of parallel ACs between the
same CE and PE pair (although this seems to be explicitly excluded by
figure 4-1). What you are describing is PE protection.
I think some of the confusion here is because of the terminology
inconsistency. RFC 3985 is quite clear that the AC does not form part
of the PW. So, this document is all about protecting the emulated
service.
This does appear to be noticed earlier in the section where it says:
Scenarios, such as those above, therefore rely on a set of two or
more pseudowires to protect a given VPWS or VPLS.
I believe that the document should be clear up front that two protection
mechanisms are being described in this document. The first is end-to-end
service protection (where AC and T-PE failure are protected) and end-to-
end PW protection (where the working and protection PWs run between the
same pair of T-PEs). The document also needs to note clearly that PW
segment protection (i.e. working and protection [multi-] segment
protection between a pair of S-PEs) is out of scope.
>> Ah, I found this in the last paragraph of Section 2. A bit lost in
the morass of other text.
Note that an excellent way to handle this discuss will be the wholesale
deletion of text and replacement with a simple reference to [6].
---
Looks to me that [6] is used normatively.
---
It is not clear to me why you don't support 1+1 protection. But section
2 clearly rules it out.
In the absence of faults, all PWs are UP both locally and remotely
and a PE node needs to select a single PW to forward user packets to.
This is referred to as the active PW. All other PWs will be in
standby and MUST NOT be used to forward user packets.
Perhaps this restriction should be stated. Or is there the possibility
that a future protocol extension will be made to add 1+1 support?
---
Section 2
In order for both ends of the service to select the same PW for
forwarding user packets, this document defines a new status bit, the
'Preferential Forwarding' status bit, to allow a PE node to indicate
the preferential forwarding state of a PW to its peer PE node.
I may have missed something here, but in 1:1 end-to-end *service*
protection, the choice of which PW to use has to be made at the CE not
the T-PE. But the signaling (LDP) is between PEs. How does the CE learn
the settings of the status code bits?
---
I think there is some confusion about when bits are set and cleared in
the status code. Some of this is textual.
Section 11.1 has...
0x00000020 When the bit is set, it indicates "PW forwarding
standby".
When the bit is cleared, it indicates "PW forwarding
active".
Which is good and means that the text should probably refer to this as
the "PW forwarding standby bit" rather than "PW Preferential Forwarding"
as currently in section 6. (Note that IANA will need a name for the bit
in the registry - they seem to have dug the names out of section 6, but
this should be explicit in the IANA section of the document).
Then the bit used for requesting switchover gives me a problem. While I
understand the issues (selection from a pool that may be larger than 1,
need to synchronize, etc.), the explanation of the status code field in
RFC 4447 is clear that setting a bit represents a "fault". Thus, it
would be reasonable to handle a set bit as "cannot send traffic on this
PW" whereas you are asking for it to mean "please send traffic on this
PW". (Again, IANA will need a name for this bit in the registry.)
I do wonder whether, given the existence of OAM and fault status bits,
and the definition of precedence, you need this bit. It even seems to
allow conflict with the precedence.
---
What happens when a T-PE that supports this I-D sends a switchover
request to a T-PE that foes not support this I-D? Presumably it will
register the request as a fault (as above) and will not send traffic.
---
In section 2
a. A MANDATORY 1:1 PW protection with a single active PW and one
standby PW. An active PW can forward data traffic and control
plane traffic, such as Operations, Administration, and
Maintenance (OAM) packets. A standby PW does not carry data
traffic.
This does not say whether OAM packets and be carried on a standby PW.
Later, in section 3, I find:
Standby PW: An UP PW that is not used for forwarding user traffic,
but MAY forward OAM and specific control plane traffic.
And so on (e.g. Section 6.1)
When a PW is in Standby state, the PEs MUST NOT forward user packets
over the PW but MAY forward PW OAM packets and specific control plane
packets.
Perhaps, rather than listing types of message, you should note that all
ACH packets are allowed.
---
Section 2
b. Multi-homing of a PE node to two or more PE nodes.
What does this mean? A PE is multi-homed to multiple PEs? I suppose you
are trying to talk about parallel PWs between two T-PEs, and a PE that
is at the far end of a relationship with a CE that is multi-homed to
more than one T-PE?
---
Section 3
The designation of Primary is performed by local
configuration for the PW at the PE and is only required when
revertive behavior is used.
But all of the text (for example, in 5.1 and 5.2) uses MUST for
reversion, so there appears to be no option.
Which is odd because the second requiremen of Section 4.1 of draft-ietf-
pwe3-redundancy says that non-revertive behavior MUST be supported.
---
Section 5
I think that you need to clarify which mode of operation would be used
in the case of figure 15-2. I think that master/slave mode cannot be
used, and that independent mode only works with configuration. There is
a degenerate case of this topology where there is absolutely no LDP
communication between the PEs on the active PW and those on the standby
PW.
---
Section 5.1 first point 2
"we propose"
please restate this protocol specification in terms of absolute
statements of required behavior.
---
Section 5.2.
Note that the behavior
described in this section assumes correct configuration of the Master
and Slave endpoints. This document does not define a mechanism to
detect errors in the configuration.
I suggest this is broken. You should at least be able to detect the
error (not necessary to be able to resolve it) and report it. Also to
not get into an unresolvable protocol breakdown when there are two T-PEs
that think they are Masters.
Actually, requirements 2 and 3 of Section 4.2 of draft-ietf-pwe3-redundancy seem
to speak against this text.
---
The timers need to have recommended defaults, and should be called out
as configurable.
---
Section 7
[5] is used normatively.
[8] is used normatively.
---
Section 7
The procedures for determining and mapping PW and AC states MUST
follow the rules in [8] with the following modifications.
Does that mean this document updates [8]?
---
Section 7.1
When a PE enters the AC receive (or transmit) defect state for a PW,
it MUST send a forward (reverse) defect indication to the remote
peers over all PWs in the redundancy set when required by the PW type
in [8] .
I think this is subtly incorrect. It applies only to PWs in the
redundancy set that terminate at the PE and that are connected to the
AC.
---
Section 8
A PE implementation compliant to RFC 4447 [2], and which does not
support the generation or processing of the 'Preferential Forwarding'
status bit or of the 'request switchover' status bit, will ignore
these status bits if they are received from a peer PE.
I struggled to find this behavior defined in RFC 4447. While I believe
that many implementations might take this approach, I also think many
might view the text in 4447 that indicates that the bits represent
"faults" to mean that even unknown status code bits should be
interpreted as PW failures. (Hence my burbling earlier about flipping
the sense of the bits.)
If you can point me at the text in 4447, I will back off this issue.
---
Section 9
I don't think this section should be so banal.
You are introducing a feature that allows the compromise of signaling
for one PW between one pair of PEs, to change the behavior (disruptively)
on a PW between another pair of PEs. That seems to be a new and
interesting attack vector.
Therefore, you should at least flag this point and note that security on
a redundant set is only as good as the weakest security on any member
of that group.
---
On re-reading Section 5.2 I cannot work out what happens if the Master
node is the PE that fails. It looks like this is not covered and would
provide a problem.
In case anyone is hunting, I can find just 4 out of the 12 authors
confirming on the PWE3 list that they are not aware of any IPR
disclosures that need to be made.
---
I continue to be disappointed by the piecemeal invention of bolt-on
signaling features for PW management. It really seems that the working
group needs to work on a functional architecture for pseudowires to
work out all of the bits and pieces that are needed for redundancy,
bandwidth, multi-segment routing, etc., etc. I wish this would happen
before we incrementally munge the protocol too much, but I
understand that this is not directly actionable for the authors of this
document.
---
You need to remove the citation from the Abstract.
---
The document was pretty hard to review because there are repetitions
and overlap between sections. Do you need all the text?
---
Please clean up "redundant set" or "redundancy set"
---
There's a lot of terminology in the Introduction that need clarifying.
I found...
SS-PW
PW
MS-PW
T-PE
PE-rs
PE
PWE3
---
Section 1
Only one of these
pseudowires is used by the PEs to forward user traffic on at any
given time.
delete "on"
---
Figure 1-1
s/Pseudowire/Pseudowires/
---
Please decide "pseudowire" or "pseudo wire".
Cf. RFC 3985 figure 2 and draft-ietf-pwe3-redundancy figure 2
---
Section 1
In
this case, multiple MS-PWs are configured between a pair of T-PE
nodes, as described in Figure 2 of [6].
Figure 2 of [6] would appear to be identical to figure 1-1. Why do
you reference it?
---
Section 1
This document specifies a new PW status bit to indicate the
preferential forwarding status of the PW for the purpose of notifying
the remote PE of the preferential forwarding state of each PW in the
redundancy set i.e. Active or Standby.
Please say "remote T-PE".
---
Section 2
The PWE3 control protocol [2] defines the following status codes in
the PW status TLV to indicate the state for an AC and a PW:
0x00000000 - Pseudowire forwarding (clear all failures)
0x00000001 - Pseudowire Not Forwarding
0x00000002 - Local Attachment Circuit (ingress) Receive Fault
0x00000004 - Local Attachment Circuit (egress) Transmit Fault
0x00000008 - Local PSN-facing PW (ingress) Receive Fault
0x00000010 - Local PSN-facing PW (egress) Transmit Fault
Firstly, I think these values are defined in RFC 4446 not RFC 4447.
Then, I think there is actually no need to list the values here.
You could, if you like, point to the registry.
But reading this section, I am not sure that this quoted text is
pertinent.
---
Section 2
You have put some terms in upper case that are not from RFC 2119.
Anyway, I am not convinced that RFC 2119 usage is helpful in this
early and descriptive section. Lowercase would be just fine.
---
Figure 4-1 caption
s/Architecure/Architecture/
---
Section 2 point d.
s/qualify/qualifies/
---
Section 3
I think you could prune this section quite heavily. For example, it is
probably not necessary to define a pseudowire or a PE.
---
Section 5.1
The PW which corresponds to the
minimum of the compared values across all PWs in the redundant is
selected.
s/redundant/redundant set/ ?
---
Section 5.2
One endpoint node of the redundant set of PWs is designated the
Master and is responsible for selecting which PW both endpoints MUST
use to forward user traffic.
I think...
s/MUST//
---
Section 7.2
A PE enters the PW receive (or transmit) defect state for a PW
service when one or more of the conditions specified in Section 8.2.1
(Section 8.2.2) in [8] are met for all PWs in the redundancy set.
For the avoidance of doubt, I think you should
s/for all/for each of the/
(It is not necessary that the same defect state should exist on each PW)
---
Section 10
I completely support Benoit's Discuss on this section. You cannot revise
a MIB module like this.
However, it really looks like you don't want to make a revision at all.
Changing one Description clause by adding "for example" is really not
worth the effort.
Why don't you just write an applicability note saying how the TC is used
to support the function described in this I-D?
---
Author's Addresses
s/Author's/Authors'/
The security considerations say that this is the same as for 4447, which is arguably correct, but 4447 really defers to 3036, which a) doesn't consider switching over to a "less good" PW as a potential DoS (is it?) and b) only has TCP-MD5 based security which even in 2001 attracted an IESG note, repeated in 3036 from rfc 2385 (from 1998!). Any chance of getting some 21st century security stuff done in PW-land? (Sorry, but that's hard to resist:-) This is probably not the place to fix that, but it'd be good to know if there's a plan. Is there? Nits: - PE-rs is used without expansion (on p2) - FEC128 and FEC129 are used without definition on p11 (As as AGI::SAII:TAII) - What is the "system IP address"? (on p11) Could be fairly obvious, but then again if a node has many addresses, maybe not.
Please consider the issues raised in the Gen-ART Review by Miguel Garcia on 23-May-2012. I tend to agree with his points on RFC 2119 language in Sections 5 and 15. Please find the review at: http://www.ietf.org/mail-archive/web/gen-art/current/msg07447.html.
Section 2:
MANDATORY
OPTIONAL
OPTIONALLY
Neither MANDATORY nor OPTIONALLY are 2119 terms. I suspect that the capitalized
words in this section are a new magical usage of which I am unaware. Perhaps you
might like to define terms?
5.1
The PW endpoints MAY also implement the following optional active PW
selection mechanism.
1. If the PW endpoint is configured with the precedence parameter on
each PW in the redundant set, it MUST select the PW with the
lowest configured precedence value.
So you MAY do something that you MUST do? I am confused.
a management indication SHOULD be generated
I may not understand what is meant by a "management indication" here, but it
sounds like an implementation choice, not something that is required for
interoperation. Did I get that wrong?
Please check the idnits:
Checking nits according to http://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
** There are 19 instances of too long lines in the document, the longest
one being 4 characters in excess of 72.
== The 'Updates: ' line in the draft header should list only the _numbers_
of the RFCs which will be updated by this document (if approved); it
should not include the word 'RFC' in the list.
-- The draft header indicates that this document updates RFC5542, but the
abstract doesn't seem to directly say this. It does mention RFC5542
though, so this could be OK.
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the IETF Trust and authors Copyright Line does not
match the current year
== The document seems to lack a disclaimer for pre-RFC5378 work, but was
first submitted before 10 November 2008. Should you add the disclaimer?
(See the Legal Provisions document at
http://trustee.ietf.org/license-info for more information.) -- however,
there's a paragraph with a matching beginning. Boilerplate error?
IETF Trust Legal Provisions of 28-dec-2009, Section 6.c(iii):
"This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s)
controlling the copyright in such materials, this document may not
be modified outside the IETF Standards Process, and derivative
works of it may not be created outside the IETF Standards Process,
except to format it for publication as an RFC or to translate it
into languages other than English."
... text found in draft:
"Code Components extracted from this document must include Simplified BSD
......^
License text as described in Section 4.e of the Trust Legal
Provisions and are provided without warranty as described in the
Simplified BSD License."
-- The document date (May 1, 2012) is 20 days in the past. Is this
intentional?
Checking references for intended status: Proposed Standard
----------------------------------------------------------------------------
(See RFCs 3967 and 4897 for information about using normative references
to lower-maturity documents in RFCs)
== Outdated reference: A later version (-08) exists of
draft-ietf-pwe3-redundancy-07
Note these comments are the same for both draft-ietf-pwe3-redundancy and draft- ietf-pwe3-redundancy-bit. Much of the Terminology is repeated in draft-ietf-pwe3-redundancy and draft- ietf-pwe3-redundancy-bit. Can't you just point from on to the other? This uses the TCP MD5 "signature" option [RFC5036]. KARP's hopefully going to get this fixed sooner rather than later. So there's nothing for the authors to do about this otherwise recurring gripe. I'd like to suggest some tweaks to the security considerations section, assuming of course that I've not totally missed the mark: 1st - I think the "LDP extensions" are referred to as options in both RFC 4447 and 5036? 2nd - I think there's only one of them? 3rd - I think you mean control plane not control protocol? How about the following tweaks to the security considerations section: This document uses the TCP MD5 Signature option, as specified in [2], to protect pseudowires. This document has the same security considerations as in the PWE3 control-plane [2]. If you want to future proof the text more maybe: LDP extensions/options that protect pseudowires must be implemented because the security considerations for the bits defined in this document have the same security considerations as the PWE3 control-plane [2].
draft-ietf-pkix-cmp-transport-protocols
There is significant confusion in terminology in this document, with "transport" used in cases where we would normally use "transfer" to be more clear and consistent with the existing body of RFCs. HTTP is a transfer protocol; TCP is a transport protocol. If the document was scrubbed to fix this terminology, I would have no problem with it going forward.
(1) Today, using HTTP/TLS is not hard. If CMP messages are visible over a public network, then there may be a number of high-level DoS-type attacks possible, e.g. bad-guy sees a certification request for example.com and knows that that will take ~1 day to process so bad-guy goes to another (not so careful) CA and get a cert for example.com denying service to the correct example.com and damaging the CA to whom the original certification request was directed. On this basis, I think this document really needs to make use of HTTP/TLS a MUST-use messages go over any untrusted network, and hence TLS would need to be mandatory-to-implement. I'd also say that IPsec isn't really very relevant here (but would work fine), so I'd suggest that the spec be changed along the lines of: OLD: "Therefore users of the HTTP transport for CMP might want to consider using HTTP over TLS according to [RFC2818] or virtual private networks created e.g. by utilizing Internet Protocol Security according to [RFC4301]." NEW: "HTTP over TLS [RFC2818] MUST be supported by all nodes implementing this protocol. TLS with strong confidentiality SHOULD be used in all cases, with the only exception being when CMP messages are sent over fully trusted networks, which doesn't happen very often." (2) How is RFC 1945 a MUST but not a normative reference and is that then a downref? Is http/1.0 *really* needed as a MUST these days? I'd say s/MUST support/might support/ for http/1.0 and leave 1945 as an informative reference and avoid the messing with new last calls etc.
3.3 - is the 200 vs 201/202 point here consistent, seems like not. 3.5 also seems to say what's needed and better, so I'd suggest deleting 3.3 entirely 3.3 - what are the 3xx "security implications"? Either 4210 is ok or not, so I'm really not sure what's meant here.
I have no issues with the publication of this document. I only have some non- blocking comments: 1. Part of the Introduction sounds more like a history lesson and does not bolster the content of the document. I would suggest paring it down and focusing on introducing the functionality. 2. Terms like "PKIMessage" and "DER-encoded" are not defined anywhere before they are used. 3. The 2nd paragraph of section 3.3 seems incomplete. It would be useful if some example security implications were discussed. 4. What purpose does section 4 serve? Are there interoperability functions that could be described? I would suggest providing guidance on how the potential interactions can be handled. 5. While I appreciate the impact of having unresponsive authors, I don't think the explanatory text in section 7 (paragraph 1) is needed. Simply list those people as previously contributing authors.
Substantive comments; these are non-blocking, but please consider them seriously, and feel free to chat with me about them: I agree with Brian Haberman's comments #3 and #4. On #3: there is a short note in the Security Considerations about using 301 Moved Permanently, but, in general, this should say more about the security implications of using HTTP redirection. Otherwise, "careful consideration of possible security implications" isn't likely. On #4, I think you either need to remove the section or explain it quite a bit better. ======== Other comments; no need to respond to these: A note to the doc shepherd: Thank you for being clear about the low level of WG interest in the document and the reasons for publishing it despite that. Too often, shepherd writeups try to give what they think are "the right answers", rather than the true and accurate ones. A note on Brian Haberman's comment #1: In contrast, I think the "history" in the introduction is useful. After reading Brian's comment I considered each paragraph for removal or abridgment, and found that each one was useful in explaining why the document is making the choices it's making and going in the direction it's going.
In 3.8: While implementations MAY make use of all defined features of the HTTP protocol, they SHOULD keep the protocol utilization as simple as possible. I find this potentially confusing. If the directive to implementers is that they are allowed to use (and therefore the other side needs to be aware of) all defined HTTP features, the MAY should be uppercased and the SHOULD should not. If the directive to implementers is that they SHOULD keep the protocol use simple, then the first part of the sentence is at best confusing. If the latter is the intent, try: While all defined features of the HTTP protocol are available to implementations, they SHOULD keep the protocol utilization as simple as possible.
Section 1., paragraph 4: > Before this document was published as an RFC, the draft version > underwent drastic changes during the long-lasting work process. The > "TCP-Based Management Protocol" was enhanced and a TCP-Messages-over- > HTTP transport specification appeared. As both proved to be needless > and cumbersome, implementers preferred to use plain HTTP transport > following [RFC1945] or [RFC2616]. This document now reflects that by > exclusively describing HTTP as transport protocol for CMP. The sentence "TCP-Based Management Protocol" was enhanced and a TCP-Messages- over-HTTP transport specification appeared." hit my eye as Transport AD. Is there any meat to have this sentence in here? I would suggest to remove it, in order to not give a wrong impression that the IETF has worked at any time on a TCP over HTTP protocol. The "TCP-Based Management Protocol" is also sort of unknown to me. Section 3.7., paragraph 1: > A CMP server may create event-triggered announcements or generate > them on a regular basis. It MAY utilize HTTP transport to convey > them to a suitable recipient. As no request messages are specified > for those announcements they can only be pushed to the recipient. How can a HTTP server push data to the client with HTTP? HTTP is a request/response protocol where the client is sending out the requests. I assume that the CMP server is located at the HTTP server. However, the draft isn't completely clear about whether the CMP server is necessarily located at the HTTP server. Section 3.7., paragraph 7: > CMP Announcement messages do not require any CMP response. However, > the recipient MUST acknowledge receipt with a HTTP response having an > appropriate status code and an empty body. When not receiving such > response it MUST be assumed that the delivery was not successful and > if applicable the sending side may retry sending the Announcement > after waiting for an appropriate time span. What is this time span? Replace "may" with "MAY"? Section 3.7., paragraph 10: > A receiver MUST answer with a suitable 4xx or 5xx HTTP error code > when a problem occurs. This MUST here contradicts this statement "All applicable "Client Error 4xx" or "Server Error 5xx" status codes may be used to inform the client about errors." out of Section 3.3, as 4xx/5xx codes may be support, but this requires that they are supported.
Section 3.3., paragraph 2: > While "Redirection 3xx" status codes MAY be supported by > implementations, clients should only be enabled to automatically > follow them after careful consideration of possible security > implications. It would be good to link to your security section about the the discussion of this. Section 3.4., paragraph 0: > All applicable "Client Error 4xx" or "Server Error 5xx" status codes > may be used to inform the client about errors. Replace "may" with "MAY"? But see also my DISUCSS about 4xx/5xx codes. Section 3.4., paragraph 1: > The Internet Media Type "application/pkixcmp" MUST be set in the HTTP > header when conveying a PKIMessage. to be precise: MUST be set in the Content-Type header. - Section 4: In support of Brian's comment, i.e., what is the purpose of this section?
draft-ietf-netext-access-network-option
-The term "vendor" is confusing
Vendor ID
The Vendor ID is the SMI Network Management Private Enterprise
Code of the IANA-maintained Private Enterprise Numbers registry
[SMI].
The example in figure 1 speaks about: "Operator-Id: provider2.example.com"
Vendor Id, in the network management world is the manufacturer id, while you're
after the Operator-Id
I see what you want to do, but this is confusing. Also, do
we expect that all operators will have Private Enterprise Number?
Maybe you want to redefine this with something such as (I trust you on the right
wording)
Operator PEN ID
SMI Network Management Private Enterprise
Code of the IANA-
maintained Private Enterprise Numbers registry
[SMI] for the operator
running ... [actually running what, that's another
required clarification
in the draft] ... the respective interface on mobile access gateway?
In section 3.1.3 (and some other places such as IANA), change "Vendor ID" by
"Operator PEN ID"
And also add a few sentences about
- whether all operators should or must now
register new PENs for this spec.
I checked for a couple of my local ISPs, and
not all of them had a PEN.
- if there is no PEN Operator ID, then ANI type= 3,
Op-ID=2 MUST NOT/SHOULD NOT be used
if "SHOULD NOT", what should be default?
Operator PEN ID=8653? (not even sure if this is the right thing to do) or 0?
You want to discuss with the authors of draft-liang-iana-pen-00, be in synch
with them.
- Part of the OPS-DIR review, this one was reported by Juergen Quittek:
Section 3.1.1, description of ANI Length:
ANI Length: The description states
"The value can be in the range of 2 to 32 octets."
I think this is wrong. A value of 2 would only include
the E-bit, the reserved field and a (zero valued) Net-Name-Len
field. The description implies that a (zero-valued) AP-Name Length
Field is also mandatory. Then you need at least 3 octets, not just 2.
- I was wondering about the relationship between the Access Technology Type
option and this new Access Network Identifier option. Both of the required at
the same time? I finally discovered the answer in RFC5213: the Access Technology
Type is mandatory. That would help to stress this in the document, just in case
the readers are not that familiar with RFC5213 (like myself)
-OLD:
The
Access Network Identifier mobility option MUST contains one or more
Access Network Identifier Sub-options.
NEW:
The
Access Network Identifier mobility option MUST contain one or more
Access Network Identifier Sub-options.
- Part of the OPS-DIR review, the following editorial comments were reported by
Juergen Quittek:
Section 3.1.1, description of Net-Name length:
Following up on the technical issue above: It is not clear,
if the Network Name may be of length zero. The description
of the AP-Name Length explicitly states
"If the access point name is not included, then this length
MUST be set to a value of zero."
There is no such statement for the Net-Name Length. Please add
A statement, that the Network name MUST NOT be of length zero,
Or add a statement like the cited one from AP-Name length.
Section 3, description of field "Type" under Figure 2:
"(IANA-1)" is highly ambiguous. Please replace
OLD
Type: (IANA-1)
NEW
It MUST be set to value of (to be defined by IANA),
indicating that its a Network-Identifier option.
Section 3.1.2, description of N and E flag:
OLD
N: When the flag (N) is set to a value of (1), it means North, else
its South
NEW
N: When the flag (N) is set to a value of (1), it means North, else
it means South
The same applies accordingly to the E flag.
I have a concern about tying the interpretation of the "Network Name" field in the Network-Identifier Sub-option to the Access Technology type in the Access Technology Type option. Why not put a "Network Name Type" field - there's a handy set of Reserved bits available - that explicitly identifies the type of the Network Name? Without a "Network Name Type" field, the definition of a new Access Technology type will have to include the definition of the interpretation of the "Network Name" field.
This is a not-quite-Discuss Comment I think a number of references listed as Informative need to be moved to Normative. Specifically: SMI RFC 3629 RFC 1035 RFC 6275 I am in two mindsabout RFC2460. Happy to discuss why/whether this would be appropriate, but it looks like the uses are explicit "do encode this thing you need to read this reference" type of statements.
(1) Why doesn't this use geopriv? (2) Why is it ok to send the MN location (3.1.2) without asking the user? (3) Why is it ok to send SSID and AP name without asking the user? Many of those are pretty revealing as to MN location. (4) I looked at 6275 and 5213 and its not clear to me that these sensitive values, if sent, MUST be protected using IPsec with strong confidentiality and mutual authentication. The authentication part may be ok according to the documents, but I'm not sure if that's the deployed reality. Is it? But even if so, there's nothing much that I can see to ensure confidentiality for this information. Where's all that (clearly) specified?
IANA Considerations rant:
o Action-1: This specification defines a new Mobility Header option,
the Access Network Identifier. This mobility option is described
in Section 3. The Type value for this option needs to be assigned
from the same numbering space as allocated for the other mobility
options, as defined in [RFC6275].
I noticed the same problem that confused IANA, and was going to kick in a
DISCUSS to get it fixed: the registry is called "Mobility Options", and
referring to it as a "Mobility Header option" confused it with the "Mobility
Header Types" registry. No need for the DISCUSS, though, because the author
noticed the error in Pearl's proposed IANA actions, and sorted it out by email.
So this comment will just serve to beat people up about this, and to rant a bit.
You can otherwise ignore it:
Folks, it's just not that hard to go to
http://www.iana.org/protocols/ and actually *look up* the correct name of the
registry you aim to use... and then to use the *exact* name. Please be specific
and accurate; it's important.
3.1.1
'E'-bit: 1-bit flag for representing the encoding of the following
name field. MUST be set to zero (0) if the network name is
encoded using 8-bit octets or to one (1) if the network name is
encoded using UTF-8 [RFC3629].
So, I want to understand the semantics of the below network name field if the
'E'-bit is 0. What does it mean to be 8-bit octets that are not UTF-8? What is
it then? And I'm not sure this is even correct, since further down in the
definition of Network Name you say, "Encoding MUST be UTF-8." Something is funky
here. Please explain.
(BTW: RFC3629 is a normative reference, not informative. Please correct that in
section 9. I think there are probably several things you've got in the wrong
place.)
Net-Name Length: 8-bit field for representing the length of the
network name to be followed.
I think you want to specifically say "in octets", since if it's UTF-8,
characters is probably *not* what you mean.
3.1.3
2 - Realm of the operator. Realm names are required to be
unique, and are piggybacked on the administration of the DNS
namespace. Realms are encoded using a domain name encoding
defined in [RFC1035].
Operator Identifier: Up to 253 octets of the operator identifier.
The encoding of the identifier depends on the used Operator-ID
Type. Numeric values are encoded in network byte order and
strings are in UTF-8 representation and have no terminating '\0'
mark.
So the first part above says that the domain names are encoded to RFC 1035. Are
you talking there about the letter-digit-hyphen rules of 2.3.1 of 1035? If so,
you should say that. However, if that's what you mean, then clearly those are
all US-ASCII. The second part says that "strings are in UTF-8 representation".
Now I'm confused. Are you intending to allow things outside of US-ASCII, e.g.
unencoded UTF-8 U-labels for IDNs? Something is not right about the above. I
also have no idea why you have the note about the terminating '\0'. Please
explain.
Now, all that said, I'm a bit worried about the lack of information on how to
compare these things that appears in section 4. Comparing network names you seem
to leave to DHCP, but others you don't talk about. If you have to compare these
things, are you going to (and do you have to) deal with comparing UTF-8 strings
which have different normalizations? Perhaps the answer is "no" and these are
not things that need to compare if one contains "latin small 'o' followed by
combining diaeresis" and the other contains "latin small 'o' with diaeresis".
But if these two *do* have to compare as identical, you're going to need to say
more about how those comparisons (and normalizations) happen.
( no change - just reformatting to make this easier to read in the tracker ) Can the document provide more clarity on what kinds of things the LMA is expecting to use the information carried by this extension for? Specifically, how is geolocation going to be used? Is there normative text in some other document that constrains what the LMA can do with this information? Could it be used, for instance, for dispatching emergency services? The document is inconsistent in describing what the location represents. Some sections say it is the location of the MAG. Other sections say it is the location of the network (which is very unclear). The security considerations section says it is the location of the mobile node. What this location represents needs to be very clearly stated. If the security consideration text is correct, and this location is intended to represent (even as coarsely as which AP a user is attached to) the location of the MN, and thus the MN's user, then the considerations in RFC6280 do come into play, and the document needs to account for them. What is the expected relationship/trust model between the APs and the MAGs in Figure 1? Are they required to be part of the same administrative domain? What are the consequences if incorrect data is provided when the information is "dynamically obtained through some of out-of-band means". The geolocation format proposed in this document doesn't allow specifying details like the coordinate reference system. Was reusing an existing format (such as the geo-uri in RFC5870) considered? Is there a need to express precision or uncertainty?
I'm piling on with Stephen and Robert.
draft-snell-atompub-tombstones
I don't think I have seen a reply to the Chris' review below, part of the OPS- DIR review. -------- Original Message -------- Subject: Re: [OPS-DIR] Ops directorate review of draft-snell-atompub-tombstones-14.txt Date: Tue, 7 Feb 2012 05:21:14 -0800 From: Christopher LILJENSTOLPE <ietf@cdl.asgaard.org> To: ops- dir@ietf.org CC: draft-snell-atompub-tombstones@tools.ietf.org > Greetings, > > I have performed an Operations Directorate review of draft- snell-atompub-tombstones-14.txt > > Operations directorate reviews are solicited primarily to help > the area directors improve their efficiency, particularly when > preparing for IESG telechats, and allowing them to focus on > documents requiring their attention and spend less time on the > trouble-free ones. Improving the documents is important, but > clearly a secondary purpose. A third purpose is to broaden the > OpsDir reviewers' exposure to work going on in other parts of > the IETF. > > Reviews from OpsDir members do not in and of themselves cause > the IESG to raise issue with a document. The reviews may, > however, convince individual IESG members to raise concern over > a particular document requiring further discussion. The reviews, > particularly those conducted in last call and earlier, may also > help the document editors improve their documents. > > ---- > > Review result: > > I believe there is an operational impact in this document, or, at lest a technical issue that may result in operational confusion. > > Section 5 discusses digital signatures of a atom removal message. Specifically, the paragraph: > > Section 4.4.2 of [W3C .REC-xmldsig-core-20020212] requires support for > DSA signatures and recommends support for RSA signatures. However, > because of the much greater popularity in the market of RSA versus > DSA, Atom Processors that verify signed Atom Documents MUST be able > to verify RSA signatures, but do not need be able to verify DSA > signatures. Due to security issues that can arise if the keying > material for message authentication code (MAC) authentication is not > handled properly, Atom Documents SHOULD NOT use MACs for signatures. > > Is where I have my issue. By reading this document, it seems as if we are suggesting an exactly opposite selection of mandatory digital signature algorithms as the W3C does for XML. W3C MUST's DSA, and SHOULD's RSA, and this draft is suggesting a MUST for RSA and a MAY for DSA. I would suggest that the authors either consider harmonizing with W3C, or requiring both RSA and DSA. If not, toolchains created to validate XML signatures may not work in this application. > > I also believe that the authors should outline the expected behavior if a processor can validate an XML message signature, and that validation proves that the message is invalid. There is NO mention that that should be a MUST NOT or SHOULD NOT for further processing of the message. > > These could lead to operational behavior issues and should, in my opinion, be addressed before the document is published. > > Regards, > Chris > >
I have the same comment as Adrian Farrel: the 3 lines introduction is very very light, and doesn't give much background and references.
My Comment raised on -14 persists in -15. I have no objection to the publicaiton of this document. I think that the Introduction could have been more extensive - a good place for citations and explanations.
1. I didn't really get what's meant by " When an at:deleted-entry element appears in a Feed document other than it's source Feed or when an at:deleted-entry element that has a source Feed document is used in the context of a Deleted Entry Document, it MUST contain an atom:source element." But I guess Atom developers probably do so that's ok. 2. Last para of section 6: I guess that if someone did MAC and then symmetrically encrypt one of these (is that as unlikely as I think?) then it might be useful to tell them not to use the same key for both. 3. Digital signatures by themselves do not provide non-repudiation. Please delete that term.
I intend to move to Yes, but I've got a couple of concerns with text in section 3: An Atom feed MAY contain atom:entry elements and at:deleted-entry elements sharing the same atom:id value. Atom processors SHOULD ignore any at:deleted-entry elements sharing an atom:id value with an atom:entry whose atom:updated element specifies a date and time more recent than or equal to the at:deleted-entry element's when value. What exactly are the semantics associated with a feed that has both an atom- entry and at:deleted-entry for the same atom:id? Is it something like "marked for delete before purged"? How might this situation come up? I'm worried that there is not enough information in here (and the SHOULD is making me more worried) to be able to implement this in an interoperable fashion. Please explain. Implementors should note that the at:deleted-entry element is informative in nature only and may be ignored by Atom processors. I'm not sure what the above means. What is it informative of? Do you really mean "advisory" instead of "informative"? Or do you mean "probabilistic" (which would concern me)? Are you saying that an Atom processor can't rely on an at:deleted- entry? The presence of an at:deleted-entry element does not guarantee that the atom:entry to which it is referring will no longer be available. Again, I'm not sure what the above means in practice. If it doesn't guarantee it, does it probabilistically indicate it? Again, what are the semantics of the thing?
Most of s5 and s6 are copied from RFC 4287 can't you just point to RFC 4287 for the text? In both s5 and s6, it's the last 3 paragraphs. Was the last paragraph of s6 supposed to be titled signing and encrypting like it was in 4287? I guess this made sense to the atom folks but those blurbs only talk about the processors of the feed, but where is the requirement for the generator of the feed? It's great to require that only RSA be supported instead of DSA and that AES-128 CBC be the only choice for the processor, but if the generator uses one of the other allowed W3C allowed algs how do you get interop? Assuming you import the text from RFC 4287 this is probably moot but ... in the following: Section 5.1 of [W3C.REC-xmlenc-core-20021210] requires support of TripleDES, AES-128, and AES-256. Processors that decrypt Deleted Entry Documents MUST be able to decrypt with AES-128 in Cipher Block Chaining (CBC) mode. What does the second sentence add? Was it trying to say that processors only have to support AES 128 CBC because it's the only thing that's going to be used? Nothing to do on this one: I really hate MACs being characterized as signatures.
draft-ietf-ledbat-congestion
There are a lot of timing assumptions and many specific references to NTP. The draft should go to the TICTOC and NTP WGs with a request for their review of these aspects of the draft. Detailed comments below: Applications. Thus the extra delay induced by LEDBAT must be below 150 ms to reduce impact on delay-sentive applications. SB> I find this a suprising comment given that earlier in the document SB> you state that LEDBAT is not aimed at this class of application. SB> Please can the authors provide clarity. ===== A.2. Clock skew The clock skew manifests in a linearly changing error in the time estimate. For a given pair of clocks, the difference in skews is the skew of the one-way delay estimate. Unlike the offset, this no longer cancels in the computation of the queuing delay estimate. On the other hand, while the offset could be huge, with some clocks off by minutes or even hours or more, the skew is typically small. For example, NTP is designed to work with most clocks, yet it gives up when the skew is more than 500 parts per million (PPM). Typical skews of clocks that have never been trained seem to often be around 100-200 PPM. SB> This needs evidence and qualification Previously trained clocks could have 10-20 PPM skew due to temperature changes. SB> This also needs evidence and qualification A 100-PPM skew means accumulating 6 milliseconds of error per minute. The base delay updates mostly takes care of clock skew unless the skew is unusually high or extreme values have been chosen for TARGET and BASE_HISTORY so that the clock skew in BASE_DELAY minutes is larger than the TARGET. SB> This needs to be reviewed by some NTP experts.
Given that the base delay is constant, SB> It's not completely constant in the face of routing changes ====== implementation as a reference: o Skew correction with faster virtual clock: SB> This is the first time you have introduced the reader to a virtual SB> clock.
1. Since "LEDBAT is an experimental delay-based congestion control mechanism", I was wondering when the LEDBAT is not appropriate. And I was very surprised not to see a reference to RFC 6297. Specifically http://tools.ietf.org/html/rfc6297#section-2.2, "Potential Issues with Delay- Based Congestion Control for LBE Transport". A sentence such as the following, from RFC 6297, is particularly important to mention: "this makes such protocols highly sensitive to eventual changes in the end-to-end route during the lifetime of the flow [Mo99]." 2. Then I was wondering: what about ECMPs with different delays? Is LEDBAT appropriate or not? I could not deduced from the document if you keep the list of delay per host, or per transport. If per transport, LEDBAT is appropriate If per host IP address, LEDBAT might have some issues in case of significant different delays in the ECMPs A new section about LEDBAT applicability would be welcome 3. how can I monitor that LEDBAT doesn't do any harm or does actually the job? I understand that LEDBAT is experimental, but also deployed, but how do we monitor the impact? What if LEDBAT misbehaves: how do we notice? And I don't see in the charter that you're going to address the manageability and operational aspect in a different document.
OLD: The International Telecommunication Union's (ITU's) Recommendation G.114 defines a delay of 150 ms to be acceptable for most user voice applications. NEW: The International Telecommunication Union's (ITU's) Recommendation G.114 defines a one way delay of 150 ms to be acceptable for most user voice applications.
I would be somewhat more comfortable with a "warning label", perhaps as a new section 2.3, that explicitly describes safe deployment scenarios, identifies and specifies crucial parameters for safe operation, and explains what experimental results will be produced. Before requiring any new text, I have a few questions that do not require any immediate action on the part of the authors. These questions may result in an actionable Discuss position. 1. As this document suggests an ongoing experiment that will be run on the Internet, I'd like to know if the WG chairs and the document authors see any situation in which deployment of this experimental protocol could be harmful to the operation of the Internet. 2. Are there specific operational parameters that are crucial to the safe operation of this protocol? 3. Is there a plan for explicit experimentation to gather results that will allow this protocol to be published on the Standards Track?
Minor editorial issue: I don't understand this sentence at the end of section 4.2.1: As closer the extra delay gets to the TARGET value, as slower LEDBAT will increase the window.
One security/2119 question and a bunch of nits on what's a good document. section 7 - you say a protocol using LEDBAD "should" authentiate timestamp and delay fields. Is that a 2119 SHOULD? If so, then someone who turns up with an I-D that uses LEDBAT but has no MTI authentication might get DISCUSS comments on that basis. Is that what you want? If not, then perhaps s/should/ought/ will reduce the scope for possible future confusion. You could also mean that if using (D)TLS then the timestamp and acks SHOULD be protected, but that its ok for a protocol that has no MTI security (heaven forbid:-) to use LEDBAT. (See also the recent endless discussion on case for 2119 keywords on ietf-discuss if you've time to spare:-) I don't mind how you choose to handle this, since its really an issue to be handled when LEDBAT is used, but think that this could usefully be clarified here. nits: - list in 2.1 ends with a comma - just checking that a point 4 wasn't dropped off the end of the list - 2.2 uses "tail-drop" and "non-drop-tail" - would "non-tail-drop" be better there? - p8, there's no mandatory-to-implement FILTER() - is that ok? You give a bunch of options, but don't say that one of them MUST be implemented. - p9, says a maximum value MAY be placed on CTO, then gives a MUST about that value. Just checking that its intended to be ok to implement with no maximum CTO at all. - 4.2.2, a reference to the limited experimented with BT nodes would be nice (I've a few such comments, the added references would be good I think if someone's reading this in 10 years time, which they may do.) - 4.3 a reference to the G.114 doc would be nice (incl. the version since that can change and the 150ms recommendation might also) - 4.3, references to the DNA and uTorrent implementations would be nice - 5.3, typo s/worse case/worst case/ - p16, a reference for NTP would be nice in Appendix A - p17, typo "condersiderations" - A.3, earlier you mentioned two BT implementations but here you talk about *the* BT implementation - which do you mean? And a reference would be nice.
I am happy to see this document being published. I only have a minor, non- blocking, comment. In several places within the document, it says that LEDBAT is "no more aggressive than TCP". Given the wide range of TCP congestion control algorithms, I think it would be good to indicate which ones are being compared to LEDBAT. I assume the document is referring to those congestion control algorithms that conform to RFC 5681.
A nit: -- Section 2 -- The second sentence looks like it needs to be split in two after "however", perhaps with a colon. Mail to Stanislav Shalunov is bouncing. If you can't get a current address, you should probably remove him from the front-page authors list, and move him to a "Contributors" section to avoid delays during AUTH48. ==================================================== My original DISCUSS, now recorded as a comment for posterity: I understand that the shepherd says that the algorithm "requires further experimentation and targeted deployments before it is ready for standards track." But the shepherd also says that there are "several independent implementations" that include a product deployment, that there's been a lot of experimentation and that "parameterization and associated tradeoffs are well understood and documented," that "we got enough (independent) experimental data that guided the design decisions," and that it's been reviewed by experts from TCPM and ICCRG (who I presume are happy with it). All this over a development period of a year and a half. It makes me wonder what experimentation is still needed, such that this can't be sent out a Proposed Standard. In general, have we really gotten to where "Proposed Standard" means "final and perfect"? For this specific document, is there really not enough data at this point to recommend greatly expanded deployment? Does this really still have to be carefully rolled out here and there in controlled experiments? Is it intended that this will eventually become a Proposed Standard? What data will you collect from limited experimentation at this point, that you haven't already gotten? How will we know when the experiment is ready to be turned into a Proposed Standard (or declared a failure), how far from that point are we now, and how will be make sure the experiment progresses? -------- Response from Rolf Winter: We have seen a large deployment by a single company. While this means that there indeed is massive deployment, it doesn't mean we have (enough) independent data to say it is always safe, efficient, reliable etc. The company in question says they have deployed it with "good results" (no other indicators or data really). I personally feel that this is not enough and (as far as I am concerned) not enough independent experimental results. In particular, the WG made decisions that changed the initial design that was brought to the IETF which is what has been run in the wild I believe. Generally, I know what you mean when you say that this smells like Proposed Standard rather than Experimental. We should aim to bring good proposals faster to standards track, however this is congestion control and the IETF was always cautious when it came to congestion control (you could argue this as being positive or negative of course). So I think experimental here is the right way to go for now. We have just seen implementations from other people and I would like them to experiment as well (hopefully sharing more real data with the community). Once we decide to go standards track we would also need to define a framing format. I'd say we should do these two things at the same time. The experiment I believe is over, once people that have implemented the congestion control part are actually asking for a framing format. This hasn't happened as of now. -------- Further response from Wes Eddy: One of the open questions that I think would warrant further understanding before going Standards Track is discussed in the Applicability Section 2.2, and summarized at the end: Further study is required to fully understand the behaviour of LEDBAT with non-drop-tail, non-FIFO queues. In my opinion, that's one of the important unknowns. It's related to the question of what happens when queues are very small. Another question that has received a lot of discussion lately is whether the LEDBAT target delay is really low enough that the people doing competing real- time media flows are totally happy with it, how to know whether we've got this balance right, and how low it can really go without suffering from other issues. I think Rolf explained well that we tend to be pretty conservative about advancing CC specifications, traditionally. Look at the progression of 2001 (PS) in 1997 to 5681 (DS) in 2009 as an example! (and of course SS and CA predate RFC 2001 by quite a bit as well).
Had the same security question Stephen had.
draft-ietf-pwe3-redundancy
Thanks for the section 4.2. Operational Requirements, but I believe that you
miss the monitoring part.
Only configuration is mentioned at
o (T-)PEs
participating in PW redundancy MUST support the
configuration of revertive
or non-revertive protection switching
modes if both modes are supported.
Please add a bullet point about the monitoring of the protection switching mode,
along with the configuration.
Always imagine the situation of two NMS changing
the configuration....
I've been confused by the section 3.2.1 title "Single Multi-Homed CE".
When I
looked at the first sentence in that section, "The following figure illustrates
an application of single segment pseudowire redundancy", I thought: ok, "single"
in the title means SS-PW. The figure 2 was in line with that assumption.
Following the same logic, "3.2.2. Multiple Multi-Homed CEs" was targeting MS-PW.
However, the figure 3 was not representing MS-PW
Ok, I got now, thanks to Stewart Bryant's explanation, but my point remains:
please change the 3.2.* section titles to something more meaningful.
For
example:
[Single-Homed | dual-Homed] CE With [ MS-PW SS-PW] Redundancy
Note: I always start reading a document by analyzing the table of content!
Along the same lines, section 3.2 is only for SS-PW, right? So be consistent
with the sentence from 3.2.1 "The following figure illustrates an application of
single segment pseudowire redundancy.": either copy it or remove it (if you have
the title right)
Part of the OPS-DIR review done by Nevil Brownlee, a few typos:
1. Intro: "ensuring that only one active path ..." needs to end in
something like "is active at any one time."
2. Terminology: You need to be consistent in capitalising UP.
You define "Up PW," but mostly refer to it as "UP PW."
s 1: s/describes framework/describes a framework/
s 3.2.1 s/are not be propagated/are not propagated/
s.3.2.4 "one of the PE to forward the traffic and the
other to standby status." seems odd. How about
"one of the PE to forward the traffic, while the
other remains in standby status" ?
s 4.1 s/MUST besupported./MUST be supported./
s 4.2 empty bullet at end of list
Thanks for this document. It is quite readable and explains the
scenarios well.
Unfortunately, the document does not cover all possible scenarios and
it is hard to tell whether some key ones are left out on purpose (because
they are not needed), on purpose (because they are hard to solve), or by
mistake (but are still important). Maybe section 3.2 can help by
explaining whether the reference scenarios are examples or a closed set.
I have a specific case in mind that can be captured by the following
figure.
|<-------------- Emulated Service ---------------->|
| |
| |<------- Pseudo Wire ------>| |
| | | |
| | |<-- PSN Tunnels-->| | |
| V V V V |
V AC +----+ +----+ AC V
+-----+ | | PE1|==================|PE2 | | +-----+
| |----------|....|...PW1.(active)...|....|----------| |
| | | |==================| | | |
| CE1 | +----+ +----+ | CE2 |
| | +----+ +----+ | |
| | | |==================| | | |
| |----------|....|...PW2.(standby)..|....|----------| |
+-----+ | | PE3|==================|PE4 | | +-----+
AC +----+ +----+ AC
In this figure, it is unclear to me whether coordination between the
active and standby PWs is possible without a "vertical" control
protocol. But I am also not sure whether this is needed given that the
PWs could be permanently provisioned and the switching could be
performed in the CEs based on service-level OAM.
But the answer to this question begs a big question about the solutions
proposed for a number of the other scenarios. The issue can be summed
up by asking: what is the difference between service-level protection
and PW protection?
Note that the figure is a developed case of figure 2, or a degenerate
case of figure 3.
---
There seem to be some unstated assumptions about how CEs detect and
act on failures. For example, in 3.2.1 it is not clear whether
both ACs from CE1 are intended to be sending traffic all the time
(so that the PEs make the switching choices) or whether CE1 is
expected to detect failure and switch over to the other AC.
For the reverse direction traffic, this is an interesting problem
because unless the CE is running continuity OAM in the active
emulated service, it may not know that it needs to start receiving
on the other AC.
But, if there is an assumption that ACs are live-live, or that the
emulated service runs OAM, then the PW protection requirements are
quite a bit simpler.
---
I think your references to RFC 4447 should often be to RFC 4446. For
example, in Section 2:
o Up PW: A PW which has been configured (label mapping exchanged
between PEs) and is not in any of the PW defect states specified
in [RFC4447]. Such a PW is is available for forwarding traffic.
But, maybe you would also want this to be future-proof. When *any* PW
fault is reported by the status code field, doesn't that make a Down PW?
---
The exclusion of 1+1 is, I suppose, OK if it has WG support. But the
presentation in Section 4.1 is a bit abrubpt: "you might be able to do
1+1 is you like, but it is out of scope."
Can you do two things:
- indicate that 1+1 is out of scope near the top of the document so
that readers get the picture
- give some reason why it is out of scope
There is quite a slection of unexplained acronyms that you should sort
out.
---
I don't think you should make such a big thing of the difference between
SS-PW and MS-PW protection. You are doing end-to-end PW protection and if
you call it that, you don't have to go through any hoops.
As a counterpoint to this, I don't think that you can claim that
protection mechanisms in the PSN necessarily provide everything that is
needed for SS-PW protection. Consider a PE that is homed to two
networks. It is likely that when switching from one network to another
we will switch to a separate PW in its own tunnel, rather than switch
the PW to a new tunnel. (Note also that the figure in my Discuss could
easliy apply to SS-PWs, and AC/PE protection would be wanted and not
available from the PSN.)
But the bottom line is to have a lighter touch wrt PSN protection
techniques. What you are defining here supplements those techniques. It
may be run instead of or as well as PSN techniques and (obviously) is
very useful when those techniques are not available.
You certainly should not be worried about creating multiple layers of
protection. This is normal, and an important part of network operation
is to decise which layers to enable, and how to prioritise between the
layers.
---
I do think it is a shame that you do not consider segment protection as
part of this work.
---
It is disappointing that this document describes the solution. Surely
you could make this document more abstract and leave the description of
the solution to draft-ietf-pwe3-redundancy-bit.
---
The terminology here seems to be very subtly different from that in
draft-ietf-pwe3-redundancy-bit. For example "Up PW" or "UP PW". It would
make sense to have just one terminology section between the two docs
(probably here), and avoid any ambiguity.
(Actually, there is some internal inconsistency in this I-D, as well.)
---
In Section 2
o Revertive protection switching: Traffic will be carried by the
primary PW if it is UP and a wait-to-restore timer expires and the
primary PW is made the active PW.
I think there is something missing. At least punctuation, but probably
words.
---
In section 2 there is a contradiction between the definition of Primary
PW:
When the primary PW comes back up
after a failure and qualifies for the active state, the PW
endpoint always reverts to it.
And the existence of a definition for non-revertive switching.
---
By the way, did you look at RFC 4427?
I find some of the terminology here a little loose and not in step with
normal usage for protection switching.
---
In Section 4.1 you have:
o Protection switchover can be initiated from a PE e.g. using a
manual lockout/force switchover, or it may be triggered by a
signal failure i.e. a defect in the PW or PSN. Manual switchover
may be necessary if it is required to disable one PW in a
redundant set. Both methods MUST be supported and signal failure
triggers MUST be treated with a higher priority than any local or
far-end manual trigger.
This is very unusual and I am surprised that the operators in the WG
have bought in to it. What it says is that if an operator takes a PW
out of service (using a lockout) or forces the traffic onto a particular
PW, then a network failure may override what the operator said. This
would be pretty bad news in an optical network (because you might blind
an engineer), but in a packet network it is only a problem because it
would be a surprise to the operator and might reuslt in a traffic hit.
---
In section 4.1 it seems you have a somewhat underspecified requirement.
o Note that a PE MAY be able to forward packets received from a PW
with a standby status in order to avoid black holing of in-flight
packets during switchover. However, in the case of use of VPLS,
all VPLS application packets received from standby PWs MUST be
dropped, except for OAM packets.
Probably...
s/Note that a PE MAY be able to forward/A PE MAY forward/
But also, how long does it go on doing this for?
And in the VPLS case, what about control plane packets? Do you really
mean s/OAM/ACH/ ?
---
Please sort out "redundant set" vs. "redundancy set"
Matthew, thank you: the -08 version is clear, and a pleasure to read. It has fixed all my concerns about the language. Good work.
Note these comments are the same for both draft-ietf-pwe3-redundancy and draft- ietf-pwe3-redundancy-bit. Much of the Terminology is repeated in draft-ietf-pwe3-redundancy and draft- ietf-pwe3-redundancy-bit. Can't you just point from on to the other? This uses the TCP MD5 "signature" option [RFC5036]. KARP's hopefully going to get this fixed sooner rather than later. So there's nothing for the authors to do about this otherwise recurring gripe. I'd like to suggest some tweaks to the security considerations section, assuming of course that I've not totally missed the mark: 1st - I think the "LDP extensions" are referred to as options in both RFC 4447 and 5036? 2nd - I think there's only one of them? 3rd - I think you mean control plane not control protocol? How about the following tweaks to the security considerations section: This document uses the TCP MD5 Signature option, as specified in [2], to protect pseudowires. This document has the same security considerations as in the PWE3 control-plane [2]. If you want to future proof the text more maybe: LDP extensions/options that protect pseudowires must be implemented because the security considerations for the bits defined in this document have the same security considerations as the PWE3 control-plane [2].
draft-ietf-ccamp-assoc-info
I have no objection to the publication of this document. I do have a comment/suggestion though... 1. I believe that the 2nd paragraph of the intro can be substantially re-worded or deleted altogether. The thrust of the draft is to provide additional detail on the use of association information. That does not require referencing Adrian's e-mail to the list. 2. If the text in the intro that references Adrian's e-mail is removed, the Acknowledgments section can be re-worded to drop the reference as well.
draft-irtf-rrg-ilnp-v4opts
I respectfully disagree with the evaluation of the IESG shepherd WRT this document not being in conflict with existing IETF work. The IETF is working to phase out IPv4, and yet the proposal here seems to be to extend the capabilities of IPv4, which is contra to that goal. If this draft is to be published it should surely go straight to historic status. I do not think that we should be authorizing the assignment of IPv4 options to this protocol. The purpose of the protocol is to run an experiment and as such it should preferably be run on one of the existing experimental options. If the existing experimental options are not of a suitable type, a new experimental option could be considered.
Re the para starting: Currently deployed IPv4 routers from multiple router vendors use packet forwarding silicon that is able to parse past IPv4 options to examine the upper-layer protocol header at wire-speed on reasonably fast (e.g. 1 Gbps or better) network interfaces. I am not sure what routers designs the authors have evaluated, but I would have anticipated that a significant number of deployed routers will either drop or punt any packet that does not start with 45 in the first octet.
I agree with Stewart's Discuss stating that there is no need to allocate IPv4 options for this experiment since it can be run on existing experimental options. The authors give a reason why using the existing values would not meet their requirements. I dispute the reason as follows: > In order to experiment with a new protocol, an experimental value may > be needed that won't collide with an existing or future usage. It is precisely the nature of experiments that they may colide if they are run in overlapping networks. There are sufficient code points available that this can be coordinated if there are multiple experiments. There are no existing experiments that immediately spring to mind. Future experiments will be less likely as IPv4 is sunsetted. --- The LISP documents (currently in the RFC Editor Queue for publication as Experimental RFCs in the IETF Stream) have clear and unambiguous text to caution the user about the unknown side-effects of conducting the experiment on the Internet. For example, draft-ietf-lisp-23 says: This experimental specification has areas that require additional experience and measurement. It is NOT RECOMMENDED for deployment beyond experimental situations. Results of experimentation may lead to modifications and enhancements of protocol mechanisms defined in this document. See Section 15 for specific, known issues that are in need of further work during development, implementation, and experimentation. An examination of the implications of LISP on Internet traffic, applications, routers, and security is for future study. This analysis will explain what role LISP can play in scalable routing and will also look at scalability and levels of state required for encapsulation, decapsulation, liveness, and so on. It seems to me highly desirable that similar caveats be applied to this work and added to the front of all ILNP documents. I strongly urge the authors and IRSG to apply such text.
draft-irtf-rrg-ilnp-noncev6
I respectfully disagree with the evaluation of the IESG shepherd WRT this document not being in conflict with existing IETF work. The IETF is conducting experimental work in this area (LISP & HIP) and this needs to be referenced.
draft-irtf-rrg-ilnp-icmpv6
I respectfully disagree with the evaluation of the IESG shepherd WRT this document not being in conflict with existing IETF work. The IETF is conducting experimental work in this area (LISP & HIP) and this needs to be referenced. Additionally, when the author of draft-templin-aero wanted to do experimental work using ICMPv6 we directed them to using an experimental identifier. For consistency we should do the same in the case of the ILNP experiment. If a new experimental type is needed we should create that and make it available to all experiments.
Agreeing with Stewart, I cannot see (from this document or from discussions in email threads) why ILNP cannot make use of Experimental code points to conduct this experiment. Indeed, the Abstract says: This note specifies an experimental ICMPv6 message type used with the Identifier-Locator Network Protocol (ILNP). ...which seems to be in direct contradiction with the IANA considerations section. I propose that the IESG refuse this request for a code point and refer the authors and IRSG to the existing experimental code points. --- I think the 5742 review should note that this work is related to the work conducted in the LISP and HIP working groups. Presumably, if it is using ICMP, it is also related to work in 6man.
The LISP documents (currently in the RFC Editor Queue for publication as Experimental RFCs in the IETF Stream) have clear and unambiguous text to caution the user about the unknown side-effects of conducting the experiment on the Internet. For example, draft-ietf-lisp-23 says: This experimental specification has areas that require additional experience and measurement. It is NOT RECOMMENDED for deployment beyond experimental situations. Results of experimentation may lead to modifications and enhancements of protocol mechanisms defined in this document. See Section 15 for specific, known issues that are in need of further work during development, implementation, and experimentation. An examination of the implications of LISP on Internet traffic, applications, routers, and security is for future study. This analysis will explain what role LISP can play in scalable routing and will also look at scalability and levels of state required for encapsulation, decapsulation, liveness, and so on. It seems to me highly desirable that similar caveats be applied to this work and added to the front of all ILNP documents. I strongly urge the authors and IRSG to apply such text.
draft-irtf-rrg-ilnp-icmpv4
I respectfully disagree with the evaluation of the IESG shepherd WRT this document not being in conflict with existing IETF work. The IETF is conducting experimental work in this area (LISP & HIP) and this needs to be referenced. The IETF is working to phase out IPv4, and yet the proposal here seems to be to extend the capabilities of IPv4, which is contra to that goal. If this draft is to be published it should surely go straight to historic status. I do not think that we should be authorizing the assignment of ICMPv4 codepoints to this protocol. The purpose of the protocol is to run an experiment and as such it should preferably be run on one of the existing experimental codepoints. If the existing experimental codepoints are not of a suitable type, a new experimental option could be considered. This is consistent with the advice given to the author of draft-templin-aero wanted to do experimental work using ICMPv6 we directed them to using an experimental identifier.
[Updated Discuss to reflect new discoveries in the IANA registries] I think that the IESG's 5742 response on this document should note that this is related to the work in LISP and HIP. I wonder whether it should also note that it is related to Sunset4. --- I am very uneasy about allocating a new code point for ILNP from the ICMP message type registry. This seems incompatible with reducing the work on extensions that keep IPv4 viable and detract from moving to IPv6. It seems that (as with LISP) the bulk of the research work should be focussed on IPv6, and the IPv4 work should be archival not experimental. Thus, I do not think the IESG should grant the request for a code point in this case. Two ICMP messages types (253 and 254) are provided for experimentationand could be used in this case. The authors also note in this document: there is no architectural difference between using ICMP and using some different framing, for example UDP. therefore I believe that our refusal of a code point would not prevent experimentation from being done.
The LISP documents (currently in the RFC Editor Queue for publication as Experimental RFCs in the IETF Stream) have clear and unambiguous text to caution the user about the unknown side-effects of conducting the experiment on the Internet. For example, draft-ietf-lisp-23 says: This experimental specification has areas that require additional experience and measurement. It is NOT RECOMMENDED for deployment beyond experimental situations. Results of experimentation may lead to modifications and enhancements of protocol mechanisms defined in this document. See Section 15 for specific, known issues that are in need of further work during development, implementation, and experimentation. An examination of the implications of LISP on Internet traffic, applications, routers, and security is for future study. This analysis will explain what role LISP can play in scalable routing and will also look at scalability and levels of state required for encapsulation, decapsulation, liveness, and so on. It seems to me highly desirable that similar caveats be applied to this work and added to the front of all ILNP documents. I strongly urge the authors and IRSG to apply such text.
draft-irtf-rrg-ilnp-eng
This is a discuss discuss and is entered for IESG procedural reasons. This document needs an IESG response that is consistent with the responses for the other documents in this set.
Section 10.4 calls up problems that are better described as access router problems and not end-system changes. These are quite serious issues and probably need greater prominence.
draft-irtf-rrg-ilnp-dns
I agree with the Discuss and Comments entered by Adrian
I think the IESG 5742 review should mention that this work is related to work done in LISP and HIP. Presumably, the suggested additions to DNS make it related to DNSEXT as well.
The LISP documents (currently in the RFC Editor Queue for publication as Experimental RFCs in the IETF Stream) have clear and unambiguous text to caution the user about the unknown side-effects of conducting the experiment on the Internet. For example, draft-ietf-lisp-23 says: This experimental specification has areas that require additional experience and measurement. It is NOT RECOMMENDED for deployment beyond experimental situations. Results of experimentation may lead to modifications and enhancements of protocol mechanisms defined in this document. See Section 15 for specific, known issues that are in need of further work during development, implementation, and experimentation. An examination of the implications of LISP on Internet traffic, applications, routers, and security is for future study. This analysis will explain what role LISP can play in scalable routing and will also look at scalability and levels of state required for encapsulation, decapsulation, liveness, and so on. It seems to me highly desirable that similar caveats be applied to this work and added to the front of all ILNP documents. I strongly urge the authors and IRSG to apply such text.
draft-irtf-rrg-ilnp-arch
I think that we need to go with at least the statement concerning LISP and HIP as these are experimental protocols being run by IETF WGs. Additionally the document needs to include either a reference to to RFC 6115, or equivalent reservation text so that it is treated with parity WRT to the LISP documents. The document also needs to provide a reference to the LISP work. The IPv4 text in the draft implies that we are continuing to develop IPv4 functionality and should be changed to make it clear that IPv4 is entering the end of its life.
be mapped and then tunnelled through the inter-domain core of the
Internet. Another class being considered is sometimes known as
"Identifier/Locator Split". This document relates to a proposal
that is in the latter class of evolutionary approaches.
SB> Given that LISP is an IETF WG which seems to be operating in
SB> this area, why is there no reference to this work?
when designing the TCP/IP protocol suite. Unfortunately, that
separation did not occur, so the deployed IPv4 and IPv6 Internet
entangles upper-layer protocols (e.g. TCP, UDP) with
network-layer routing and topology information (e.g. IP
addresses) [IEN1] [RFC768] [RFC793].
SB> You can have ID/Loc splitting below the transport layer and there are many
ways to design it.
The key idea proposed for ILNP is to directly and specifically
change the overloaded semantics of the IP address. The Internet
community has indicated explicitly, several times, that this use
of overloaded semantics is a significant problem with the use of
the Internet protocol today [RFC1498] [RFC2101] [RFC2956]
[RFC4984].
SB> Please be aware that there are a number of competing proposal to encode
information in an IPv6 address.
Layer | IP | ILNP
---------------+----------------------+---------------
Application | FQDN or IP address | FQDN
Transport | IP address | Identifier
Network | IP address | Locator
Physical i/f | IP address | MAC address
---------------+----------------------+---------------
SB> What if the physical interface is not a LAN?
SB> Surely IP resolves an IP
address to a physical interface or indeed a virtual interface. This is
particularly
SB> necessary with an unnumbered interface.
SB>
SB> You might
consider borrowing the notation used by the Transport Network(sic) engineers
and use a client
SB> server model when you go below IP.
SB>
SB> Hopefully you
later consider recursive newtwork designs.
Where, today, IP packets have:
- source IP address, destination IP address
instead ILNP packets have:
- source I-LV, destination I-LV
However, it must be emphasised that the I-LV and the IP address
are *not* equivalent.
With these naming enhancements, we will improve the Internet
architecture by adding explicit harmonised support for many
functions, such as multi-homing, mobility and IP Security.
SB> This is a view of the network based on the concept of a
SB> classic global IP layer.
SB> There are many new applications emerging that don't think that
SB> way and want multiple instances. In other words they have
SB> addresses that exist outside the network - sort of Godel addresses.
Specifically in response to [RFC4984], ILNP improves routing
scalability by helping multi-homed sites operate effectively with
provider-aggregatable (PA) address prefixes. Many multi-homed
sites today request provider-independent (PI) address prefixes so
they can provide session survivability despite the failure of one
or more access links or Internet Service Providers (ISPs). ILNP
provides this session survivability by having a
provider-independent node Identifier value that is free of any
topological semantics. This I value can be bound dynamically to a
provider-aggregatable L value, the latter being a topological
SB> I may have missed it, but I do not see a definition or "I" or "L"
3. ARCHITECTURAL CHANGES INTRODUCED BY ILNP
3.1 Identifiers
In normal operation, a node will not change its set of valid
Identifier values frequently. However, a node MAY change its set
SB>You do not define frequently.
of valid Identifier values over time, for example in an effort to
provide identity obfuscation, while remaining subject to the
architectural rule of the preceding paragraph.
SB> Surely there are less arcane reasons to change identity besides
SB> security by obscurity, for example there are business reasons
SB> such as restructuring the business or re-purposing of the
SB> equipment.
3.1.2 Syntax
ILNP Identifiers have the same syntax as IPv6 Interface
Identifiers [RFC4291], based on the EUI-64 format [IEEE-EUI],
which helps with backwards compatibility.
SB> IFF the requirement is to solve the problem with a single
SB> layer of encapsulation.
There is no semantic
equivalent to an ILNP Identifier in IPv4 or IPv6 today.
SB> Is this true? You could regard the problem as solved
SB> by updating DNS, thus the issue is not semantics
SB> but performance in today's networks.
The Modified EUI-64 syntax used by both ILNP Identifiers and IPv6
Interface Identifiers contains a bit indicating whether the value
has global-scope or local-scope [IEEE-EUI] [RFC4219]. ILNP
Identifiers have either global-scope or local-scope. If they have
global scope, they SHOULD be globally unique.
SB> Why are global (and you need to define global) identifiers
SB> not REQUIRED to be unique?
Regardless of whether an Identifier is global-scope or
local-scope, an Identifier MUST be unique within the scope of a
given Locator value to which it is bound for a given session or
packet flow.
SB> For that network instance.
As an example, with ILNPv6, the ordinary IPv6
Neighbour Discovery (ND) processes ensure that this is true, just
as ND ensures that no two IPv6 nodes on the same IPv6 subnetwork
have the same IPv6 address at the same time.
SB> Is that true, or do mean that no more than two are concurrently
SB> operational in that network instance?
3.4 Notation
3.5 Transport-layer state and transport pseudo-headers
In ILNP, protocols above the network-layer do not use the Locator
values. Thus, the transport-layer uses only the I values for the
transport-layer state (e.g. TCP checksum, UDP checksum), as is
shown, for example, in expression (6) above.
SB> I have not seen you note to the reader that the code to calculate the
SB> transport checksums needs to change.
SB>
SB> Also surely NATs need to change as a result of this?
3.7 ILNP Multicasting
Multicast forwarding and routing are unchanged, in order to avoid
requiring changes in deployed IP routers and routing protocols.
ILNPv4 multicasting is the same as IETF standards-track IPv4
multicasting.
SB> What does this mean?
SB> You used the IPv4 address as a locator, so either ILNP does
SB> not support IPv4 m/c or you only support m/c to the loc.
5.1 Host Multi-Homing (H-MH)
At present, host multi-homing is not common in the deployed
Internet.
SB> Ah, what about all of the laptops that are connected
SB> to both Ethernet and WiFi? A number of these have
SB> one or more virtual network connections in addition.
8. BACKWARDS COMPATIBILITY & INCREMENTAL DEPLOYMENT
ILNPv4 is backwards compatible with existing IPv4. As the IPv4
address fields are used as 32-bit Locators, using only the
address prefix bits of the the 32-bit space, IPv4 routers also
would not require changes. An IPv4 router would be unaware
whether the packet being forwarded were classic IPv4 or the
proposed enhancement in ILNPv4 [ILNP-V4OPTS].
SB> Most IPv4 routers are aware that they are being presented
SB> with IPv4 packets carrying options
I found one typo: Section 3.3: "thought it" -> "though it" In section 5.2, MP-TCP is actually being defined by the MPTCP working group (not TCPM). You could cite RFC 6182 for the MPTCP architecture.
The LISP documents (currently in the RFC Editor Queue for publication as Experimental RFCs in the IETF Stream) have clear and unambiguous text to caution the user about the unknown side-effects of conducting the experiment on the Internet. For example, draft-ietf-lisp-23 says: This experimental specification has areas that require additional experience and measurement. It is NOT RECOMMENDED for deployment beyond experimental situations. Results of experimentation may lead to modifications and enhancements of protocol mechanisms defined in this document. See Section 15 for specific, known issues that are in need of further work during development, implementation, and experimentation. An examination of the implications of LISP on Internet traffic, applications, routers, and security is for future study. This analysis will explain what role LISP can play in scalable routing and will also look at scalability and levels of state required for encapsulation, decapsulation, liveness, and so on. It seems to me highly desirable that similar caveats be applied to this work and added to the front of all ILNP documents. I strongly urge the authors and IRSG to apply such text. This is particularly important in this document as it is the cornerstone of the ILNP project. I believe it would also be really good to do more analysis in this document of what type of further experimentation is welcomed, and how it should be carried out. Without that, this document is little more than a hostoric record. --- A reference in the Introduction to RFC 6115 would be highly appropriate.
I am fine with either 5742 IESG note, but if we go with the latter one about LISP and HIP, it should probably apply to all of the documents. I don't know what Lars would do differently based on the IESG note, so it is probably moot.
draft-irtf-rrg-ilnp-adv
This is a discuss discuss and is entered for IESG procedural reasons. This document needs an IESG response that is consistent with the responses for the other documents in this set.