IESG Narrative Minutes
Narrative Minutes of the IESG Teleconference on 2010-10-28. These are not an official record of the meeting.
Narrative scribes: Susan Hares and Linda Dunbar (The scribe was sometimes uncertain who was speaking.)
Corrections from:
1 Administrivia
2. Protocol Actions
2.1 WG Submissions
2.1.1 New Items
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
2.1.2 Returning Items
2.2 Individual Submissions
2.2.1 New Items
2.2.2 Returning Items
3. Document Actions
3.1 WG Submissions
3.1.1 New Items
3.1.2 Returning Items
3.2 Individual Submissions Via AD
3.2.1 New Items
Telechat:
3.2.2 Returning Items
Telechat:
3.3 Independent Submissions Via RFC Editor
3.3.1 New Items
Telechat:
Telechat:
3.3.2 Returning Items
3.3.3 For Action
Telechat:
1303 EDT break
1308 EDT back
4 Working Group Actions
4.1 WG Creation
4.1.1 Proposed for IETF Review
Telechat:
Telechat:
4.1.2 Proposed for Approval
4.2 WG Rechartering
4.2.1 Under evaluation for IETF Review
4.2.2 Proposed for Approval
Telechat:
5. IAB News We can use
6. Management Issues
Telechat:
Telechat:
Telechat:
Telechat:
7. Agenda Working Group News
1425 EDT Adjourned
(at 2010-10-28 07:28:12 PDT)
draft-ietf-ccamp-lsp-hierarchy-bis
Thank you for doing this spec. It is very well written and technically solid. I would have otherwise voted Yes but that would have required a bit too much crosschecking and reading other RFCs than I had time for today.
I am generally Ok with this document and I was about to ballot No Objection, but
I found something I would like to quickly discuss:
3.1.2. Unnumbered Links with Action Identification
TLVs
Zero, one, or more TLVs may be present. Each TLV is encoded as
follows:
Type (16 bits)
The identifier of the TLV. Two type values are defined in
this document:
1 IGP Instance Identifier TLV
2 Component Link Identifier TLV
Does this need to use an IANA registry?
Length (16 bits)
Indicates the total length of the TLV in octets. I.e.,
4 + the length of the value field in octets. A value field
whose length is not a multiple of four MUST be zero-padded
so that the TLV is four-octet aligned.
Value
The data for the TLV padded as described above.
3.3.1. Unnumbered Component Link Identification
If the component link is to be unnumbered, the Unnumbered Component
Link Identifier TLV is used. The TLV is formatted as described in
Section 3.1.2. The Type field has the value 2, and the Value field
So this seems to be pointing to the Type value quoted above, but ...
has the following content:
3.3.2. IPv4 Numbered Component Link Identification
If the component link is identified with an IPv4 address, the IPv4
Numbered Component Link Identifier TLV is used. The TLV is formatted
as described in Section 3.1.2. The Type field has the value 3, and
... this is using a type not listed in 3.1.2.
What am I missing?
(Same comment about 3.3.3)
the Value field has the following content:
draft-ietf-isis-bfd-tlv
Agree with the discusses though, in particular with the graceful restart interaction issue.
Section 5., paragraph 1:
> It is worth considering what if anything should be done when IS-IS is
> gracefully restarting [RFC5306].
DISCUSS: Since RFC5306 is already published, it is up to this document
to specify how the proposed mechanism intersects with
graceful-restart. The text in the remainder of this section seems to
boil down to "we don't know", in which case I think you should
actually say that this mechanism MUST NOT be used together with
RFC5306 (until someone writes an ID that sorts this out in detail). It
would probably also be good to discuss the pros and cons of when to
use RFC5306 and when to use the proposed mechanism.
Section 3., paragraph 1: > A simple solution to this problem is for an IS-IS router to advertise > that it has BFD enabled on a given interface. It can do this through > the inclusion of a TLV in its IIHs, and indeed that is our proposal. Since this isn't at the proposal stage anymore, please rephrase for RFC publication.
I believe [I-D.ietf-bfd-base] and [I-D.ietf-bfd-generic] (which are now RFCs) should be normative references for this work. The note in section 8: Note to RFC Editor: this section may be removed on publication as an RFC. should be removed since it is normal for non-null IANA sections to remain in place in published RFCs. Can the responsible AD please confirm with IANA that expert review for the codepoint allocation has happened.
It looks like [I-D.ietf-bfd-base] is actually a Normative reference, as a reader is expected to understand it in order to implement this extension.
(1) This is a minor discuss, but section 3.1 includes the following:
For each locally supported MTID/NLPID pair, an ISIS_TOPO_NLPID_STATE
variable is assigned. If ISIS_TOPO_NLPID_BFD_REQUIRED is TRUE, this
variable follows the BFD session state for that MTID/NLPID (UP ==
TRUE). Otherwise the variable is set to TRUE.
Somehow, the last sentence feels wrong. I was expecting FALSE if
ISIS_TOPO_NLPID_BFD_REQUIRED was not TRUE. Please double-check
and let me know you verified or changed the value). I will clear regardless of
the decision!
(2) The authors have proposed text for the security considerations section in
response
to the secdir review back on 7/27. The text is not in the document or
an RFC Editor Note,
so I am afraid it has been lost. The proposed text was:
The TLV defined within this document describes an addition to the IS-IS
Hello protocol. Inappropriate use of this TLV could prevent an IS-IS
adjacency from forming or lead to failure to detect bidirectional
forwarding failures - each of which is a form of denial of service.
However, a party who can
manipulate the contents of this TLV is already in a position to create
such a denial of service by disrupting IS-IS routing in other ways.
I support Lars' discuss with respect to graceful restart. It would have been helpful if the goal of each state definition was explained in section 3.1. (It probably would have avoided my discuss!) Three of the six state variables defined in 3.1 are never mention in sections 3.2, 3.3, or 4. Apparently, these variables were only needed to compute the three state variables: ISIS_BFD_REQUIRED; ISIS_NEIGHBOR_USEABLE; and ISIS_TOPO_USEABLE. Differentiating the interim values from the values that impact adjacency establishment/maintenance, topology advertisement, and transition might also enhance clarity. Please consider expanding IIH, MTID, and NLPID.
1. Please expand acronyms on first use ("IIH", "TLV", "MITD", "NLPID", "PDU",
etc.) or add a section on Terminology that points to the appropriate
specifications.
2. Section 3.3. has the sentence: "If ISIS_TOPO_USEABLE is FALSE then the
topology specific neighbor is NOT advertised." The capitalized term "NOT" is
decidedly not an RFC2119 keyword, so please lowercase it. (The capitalized
logical terms and system states "TRUE", "FALSE", "AND", "OR", "UP", and "DOWN"
are slightly less confusing, although they could be put in scare quotes for
improved readability.)
3. Removing the IANA Considerations section on publication is not standard
practice.
I support Tim and Lars discuss positions.
draft-ietf-avt-rapid-acquisition-for-rtp
A well written document. Just one comments: What does this sentence mean when it talks about "spare" and is this an equipment resource or a network resource we are considering? "If there is spare bandwidth, the retransmission server might burst the Reference Information faster than its natural rate."
(CC'ing Magnus Westerlund, whose tsv-dir review touched on the points I am
raising as well.)
Section 1., paragraph 11:
> A reasonable effort has been made in this specification to design a
> solution that reliably works in both engineered and best-effort
> networks. However, a proper congestion control combined with the
> desired behavior of this solution is difficult to achieve. Rather,
> this solution has been designed based on an assumption that the
> retransmission server and the RTP receivers have some knowledge about
> where the bottleneck between them is. This assumption may not hold
> unless both the retransmission server and the RTP receiver are in the
> same edge network. This solution is not designed to be used across
> any best-effort path of the Internet. Thus, a careful consideration
> should be given when deploying this solution in best-effort networks.
DISCUSS: This applicability statement is too weak. I really believe
you need to restrict the applicability of this mechanism to
managed/engineered networks. RTP streams already give us the huge
headache of not being congestion controlled. But at least they don't
consume unlimited amounts of bandwidth, because there is an upper
bound on the number of bits per time interval they'll result in, since
were talking realtime playback here. This extension makes it
potentially MUCH worse - every time a receiver tunes in, this will
result in a traffic burst of potentially much higher bandwidth than
the base RTP stream. Folks will want "rapid" to be "as rapid as
possible", meaning they'll blast at the maximum rate that they can.
That burst isn't being congestion controlled or rate controlled at
all, as far as I can see from the document. The only environments we
can be sure that this won't cause harm to other traffic is
environments where bandwidth has been provisioned so that these bursts
can be absorbed. This is not a technology we can recommend for the
general Internet.
Section 5., paragraph 4:
> o Second, providing the rapid acquisition optimizations must not
> cause collateral damage to either the multicast session being
> joined, or other multicast sessions sharing resources with the
> rapid acquisition operation. In particular, the rapid acquisition
> operation must avoid interference with the multicast session that
> might be simultaneously being received by other hosts. In
> addition, it must also avoid interference with other multicast
> sessions sharing the same network resources. These properties are
> possible, but are usually difficult to achieve.
DISCUSS: Unless you limit the applicability of this technology to
engineered networks, where the only other traffic is other multicast
sessions, you absolutely also need to minimize (ideally, eliminate)
the impact on other (i.e., non-multicast) flows.
Section 5., paragraph 5:
> One challenge is the existence of multiple bandwidth bottlenecks
> between the receiver and the server(s) in the network providing the
> rapid acquisition service. In commercial IPTV deployments, for
> example, bottlenecks are often present in the aggregation network
> connecting the IPTV servers to the network edge, the access links
> (e.g., DSL, DOCSIS) and in the home network of the subscribers. Some
> of these links might serve only a single subscriber, limiting
> congestion impact to the traffic of only that subscriber, but others
> can be shared links carrying multicast sessions of many subscribers.
> Also note that the state of these links can vary over time. The
> receiver might have knowledge of a portion of this network, or might
> have partial knowledge of the entire network. The methods employed
> by the devices to acquire this network state information is out of
> scope for this document. The receiver should be able to signal the
> server with the bandwidth that it believes it can handle. The server
> also needs to be able to rate limit the flow in order to stay within
> the performance envelope that it knows about. Both the server and
> receiver need to be able to inform the other of changes in the
> requested and delivered rates. However, the protocol must be robust
> in the presence of packet loss, so this signaling must include the
> appropriate default behaviors.
DISCUSS: This comes back to the first part of my DISCUSS: Unless we
can specify such a mechanism for the general Internet - and I think we
all agree that we can't - we cannot permit deployment of this
extension there. In other words, we need to limit it to engineered
walled-garden networks (such as intra-ISP IPTV rollouts) where such a
mechanism can be cobbled together with OAM information.
Section 6.4., paragraph 1:
> This section provides informative guidelines about how the BRS can
> shape the transmission of the unicast burst and how congestion can be
> dealt within the RAMS process. When the RTP_Rx detects that the
> unicast burst is causing severe congestion, it can prefer to send a
> RAMS-T message immediately to stop the unicast burst.
DISCUSS: Why is this section only informative? It describes techniques
that I'd consider essential (or at least, very, very useful), such as
requiring to monitor packet loss and react to it (and it uses RFC2119
language to do so...)
Section 5., paragraph 6: > A second challenge is that for some uses (e.g., high-bitrate video) > the unicast burst bitrate is high while the flow duration of the > unicast burst is short. This is because the purpose of the unicast > burst is to allow the RTP receiver to join the multicast quickly and > thereby limit the overall resources consumed by the burst. Such > high-bitrate, short-duration flows are not amenable to conventional > admission control techniques. You should investigate the work of the PCN working group. Section 6.4., paragraph 12: > o When using RAMS in environments as described in (g), the BRS MUST > transmit the burst packets at an initial bitrate higher than the > nominal bitrate, but within the engineered or reserved bandwidth > limit. Right. This is feasible in engineered networks. Section 6.4., paragraph 13: > o When the BRS cannot determine a reliable bitrate value for the > unicast burst (using a through g), it is desirable that the BRS > chooses an appropriate initial bitrate not above the nominal > bitrate and increases it gradually unless a congestion is > detected. This is what we'd need to allow use on the general Internet. I note that you're halfway down the path of using TFRC here...
idnits reports...
-- The document has a disclaimer for pre-RFC5378 work, but was first
submitted on or after 10 November 2008. Does it really need the
disclaimer?
In the Adbstract:
However, the proposed method...
Don't be so timid! This is about to become an RFC.
This is a fine document, but I have a small list of issues I would like to
discuss before recommending approval of this document:
For the purpose of gathering detailed information about RTP_Rx's
rapid acquisition experience, [I-D.ietf-avt-multicast-acq-rtcp-xr]
defines an RTCP Extended Report (XR) Block. This report is designed
to be payload-independent, thus, it can be used by any multicast
application that supports rapid acquisition. Support for this XR
report is, however, OPTIONAL.
The reference looks Normative to me.
7.3. RAMS Information
o Message Sequence Number (8 bits) : Mandatory field that denotes
the sequence number of the RAMS-I message for the particular media
sender SSRC specified in the message header. The MSN value SHALL
be set to zero only when a new RAMS request is received. During
rapid acquisition, the same RAMS-I message MAY be repeated for
redundancy purposes without incrementing the MSN value. If an
updated RAMS-I message will be sent (either with a new information
or an updated information), the MSN value SHALL be incremented by
one. In the MSN field, the regular wrapping rules apply.
When the MSN overflows, is the next one going to have the value 0 or 1?
7.1.2. Private Extensions
The structure that MUST be used for the private extensions is
depicted in Figure 6. Here, the enterprise numbers are used from
http://www.iana.org/assignments/enterprise-numbers. This will ensure
the uniqueness of the private extensions and avoid any collision.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Reserved | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Enterprise Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Value :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Pedantic remark: I don't believe that Enterprise Numbers are limited to 32bits,
although I don't think IANA will bypass the 32bit mark any time soon.
I support the issues raised by Lars in his DISCUSS.
1. I concur with Lars's DISCUSS: what will prevent people from using this technology for purposes other than rapid acquisition (e.g., as a way to bypass normal restrictions)? 2. Section 1 states that "Acquisition Delay" is "the difference between the time an RTP receiver joins the multicast session and the time the RTP receiver acquires all the necessary Reference Information". Section 4 states that three different elements contribute to "overall acquisition delay": multicast switching delay, Reference Information latency, and buffering delays. Which is it? This seems to have an impact on the problem statement and solution space.
draft-ietf-l3vpn-mvpn-spmsi-joins
INTRODUCTION, paragraph 6:
> The specification for Multicast Virtual Private Networks (MVPN)
> contains an option that allows the use of PIM as the control protocol
> between provider edge routers. It also contains an option that
> allows UDP-based messages (known as "S-PMSI Join" messages) to be
> used to bind particular customer multicast flows to particular
> tunnels through a service provider's network. This document extends
> the MVPN specification so that these options can be used when the
> customer multicast flows are IPv6 flows.
DISCUSS: I have one quick clarification question regarding the
applicability of this extension: Does this document update MVPN, i.e.,
is the intent here to specify a mandatory-to-implement extension to
MVPN, or is this an optional extension? If the latter, how is the use
negotiated?
Please consider the Gen-ART Review by James Polk on 27-Oct-2010.
The document title is: MVPN: Customer IPv6 Using PIM Control Plane and S-PMSI Join Messages Is this missing "multicast flows" after IPv6?
Given that join messages are sent in UDP datagrams, a normative reference to RFC 768 seems appropriate.
draft-ietf-netconf-with-defaults
In a Discuss related to Alexey's, I am not clear about the "requirements" placed
on servers and clients in this specification. Is the intention to say that
"implementations conforming to this sepcification" should/must do stuff. Or, as
the language of the I-D implies, "[new] implementations of Netconf" should/must
do things?
The former case really needs a little clarification in the text.
The latter case implies that this I-D updates the Netconf spec.
For example:
4.3. Conformance
Every NETCONF server SHOULD implement this capability.
which seems to conflict in tone from...
4.1...
A NETCONF server implementing the :with-defaults capability:
o MUST indicate its basic mode behavior by including the 'basic-
mode' parameter in the capability URI, as defined in Section 4.4.
o MUST support the YANG module defined in Section 5.
o SHOULD support the 'report-all' or 'report-all-tagged' defaults
handling mode.
o MAY support additional defaults handling modes.
I don't think this is a big deal, but you need to work out exactly what you are
requiring, and then make a few tweaks accordingly.
The Gen-ART Review by Richard Barnes on 25-Oct-2010 raises a concern
with Section 4 that needs to be addressed. Richard said:
I'm confused by the existence of Section 4 in light of the fact that
Sections 2.1.2, 2.2.2, and 2.3.2 say that a server MUST support a
<with-defaults> value for each of the basic modes. If there are
cases where a server doesn't support a given mode, what does it mean
for it to "support the <with-defaults> parameter" with a given value?
The Gen-ART Review by Richard Barnes on 25-Oct-2010 raises several concerns and a question. Please consider them.
While I was initially skeptical about usability of this extension, I think the
document is making a compelling argument for having this extension.
However, there is one question I would like to discuss:
A NETCONF server implementing the :with-defaults capability:
o MUST indicate its basic mode behavior by including the 'basic-
mode' parameter in the capability URI, as defined in Section 4.4.
o MUST support the YANG module defined in Section 5.
o SHOULD support the 'report-all' or 'report-all-tagged' defaults
handling mode.
o MAY support additional defaults handling modes.
DISCUSS DISCUSS (this might result in no changes to the document):
Is the goal
here to allow servers to advertise what they support, but pushing complexity of
dealing with multiple modes to clients? My personal experience with other
protocols suggest that simpler operations for clients would result in more
widespread deployment of extensions.
So to translate this into something actionable: I am a bit concerned that
various things are optional for compliant servers to support. I would feel more
comfortable changing the SHOULD/MAY to MUSTs (at least for the SHOULD).
Is this
something that was discussed in the WG?
I think XSD needs a Normative reference.
I could not understand the meaning of Section 2.3.1. I suggest revising it for symmetry with sections 2.1.1 and 2.2.1, which I thought were very clear. I have proposed text which is probably wrong (since I had trouble with the current text) but at least illustrates what I am suggesting... OLD If a client sets a data node to its schema default value, it MUST always be reported. If the server sets a data node to its schema default value, it MUST NOT be reported. Non-configuration data nodes containing the schema default value MUST be reported. NEW When data is retrieved from a server using the 'explicit' basic mode, and the <with-defaults> parameter is not present, data nodes MUST be reported if explicitly set by the client, even if they contain the schema default value. Non-configuration data nodes containing the schema default value MUST NOT be reported.
1. I would like to echo Alexey's "discuss-discuss". 2. It's not clear why the 'default' attribute qualified by the "urn:ietf:params:xml:ns:netconf:default:1.0" namespace is called "the 'wd:default' attribute"; does this assume that the attribute will always be prefixed with "wd:"? If so, why? 3. The text mentions that a server will check if default="true", but the boolean datatype in XML Schema Part 2 has two lexical representations for logical TRUE (both "true" and "1" are valid). An implementation note might be appropriate, such as: In accordance with Section 3.2.2.1 of XML Schema Part 2: Datatypes, the allowable lexical representations for the xs:boolean datatype are the strings "0" and "false" for the concept of false and the strings "1" and "true" for the concept of true; implementations MUST support both styles of lexical representation.
1) Building on Alexey's discuss - as written, this document requires any
client that cares about how defaults are handled to implement all three
(four?) modes. It would help to explicitly call that out in the text. Did the
group consider making one of the modes mandatory to implement at the
server (for instance, making the SHOULD in the third bullet of 4.1 a MUST)?
If so, could the reasons for not doing so be better captured in the document?
2) The phrasing of 2.1.2, 2.2.2, and 2.3.2 is ambiguous. During a conversation
with Dan, I was convinced that the intent was to make them subordinate to
the requirement at the top of section 2 that a server must pick one of the
three basic modes, and that 2.1.2 should be read as
"If the server supports the 'report-all' mode for handling default data,
and the client has requested it by specifying 'report-all' when using
<with-defaults>, then the server MUST behave as specified in section 3.1"
and not as
"The server MUST support the 'report-all' mode.
If that's correct, please adjust the text to make it less likely that
someone will misinterpret the requirement. (I thought 2.1.2 and the
third bullet of 4.1 were in conflict before the conversation with
Dan mentioned above).
3) Section 4.3 as written is updating the base NETCONF spec. Was the intent is
to add a requirement to the base protocol, affecting conformance of existing
implementations, or only to promote adoption of this extension? If the former,
the document needs an "Updates" header. If the latter, please remove or rephrase
this section.
There is a bug in 2.2.2 - it points to 3.1 instead of 3.2
draft-lundberg-app-tei-xml
I found the following text a little worryingly vague...
In general, a [TEI] file usually contains either of the strings
<TEI
<teiCorpus
near the beginning, and usually after an XML declaration on the first
line
It seems to me that this doesn't provide a rule for identifying a [TEI] file, so
I wondered:
- is there a more definitive way to identify such files?
- is it
necessary/useful to include this text?
In the discussion after the Gen-ART Review by Kathleen Moriarty, it was pointed out that Section 4 has a few acronyms that have not been spelled out earlier in the document.
It's always good to register media types. Before I can ballot in favor of this
registration, I'd like to discuss the following issues. (UPDATED to include item
#5.)
1. Because this document registers an XML media type, I suggest adding a
normative reference to the fifth edition http://www.w3.org/TR/2008/REC-
xml-20081126/ of the XML specification (e.g., in the Introduction on the first
use of the acronym "XML", which should be expanded).
2. The description of TEI files in terms of string matching (i.e., the strings
"<TEI" or "<teiCorpus" to be found "near the beginning" of the file) is
quite strange, and at odds with the XML specification. I suggest changing this
terminology to refer to the document entity http://www.w3.org/TR/2008/REC-
xml-20081126/#dt-docent or root element http://www.w3.org/TR/2008/REC-
xml-20081126/#dt-root (also, I think it is unnecessary to talk about the fact
that the root element might be preceded by the XML declaration, since that point
is handled by the XML specification).
3. It is strange that the IRI spec (RFC 3987) is referenced on first use of the
acronym IRI, but the URI specification is not referenced on first use of the
acronym URI. I suggest adding such a reference. Also, is there a reason why the
IRI spec is an informative reference and the URI spec is a normative reference?
4. Some of the security considerations are covered already by RFC 3470
("Guidelines for the Use of Extensible Markup Language (XML) within IETF
Protocols"). I suggest reviewing that document and referencing it instead of
substantially repeating its recommendations.
5. The required review on the ietf-types mailing list began on October 20, so
the two-week review period has not yet completed.
This is a discuss point for a conversation on the telechat - no action is
requested from the document editors at this time.
What are the stability requirements for the Published Specification in media
type registrations?
Is this particular specification published in any form other than the website?
(Could those be referred to instead?)
draft-ietf-netlmm-mip-interactions
I found the document very difficult to read for the reasons cited in point 1 of
the GENART review.
This issue needs to be addressed before publication.
Please consider the comments from the Gen-ART Review by Enrico
Marocco on 12 May 2010. The review can be found at:
http://www.softarmor.com/rai/temp-gen-art/
draft-ietf-netlmm-mip-interactions-06-marocco.txt
There is one typo in the RFC Editor Note. The change introduced by the following text is in section 3.2, not section 2. Still in section 2, in the last bullet of list item 5: I suspect the RFC Editor would work it out from the context, but suggest making the fix just to be sure.
The OPS-DIR review by Jouni Korhonen raised a number of non-blocking issues,
most of them of editorial nature, which should be considered if a new revision
of the document is spun out:
The document mentions that there are system specific issues that need to be
taken into account; see Sections 4.2.1 and 4.3. Those are merely bypassed
stating being "out of scope". While this is true, from operational and
management perspective it would be nice to see even references here for further
reading if any of those "out of scope" things have been solved or discussed
somewhere. For example Section 4.2.1 depends on LMA discovery to work properly
within the same administrative domain. There are solutions for this documented
in IETF in PMIPv6 context. Another related nit to point out is that the document
could actually mention that the separate HA/LMA functions actually would benefit
from a shared subscriber database (e.g. AAA
server) to work properly. The text
seems to hint that anyway.
Few editorial comments:
o Section 2 should also say that it uses acronyms from RFC5213 and RFC3775.
o Section 3 add a reference to HMIPv6-MIPv6.
o Sequence number based ordering is possible (optional) for PMIPv6 in
RFC5213
unlike stated in Section 3.2, step 1) first bullet. Not that it would help to
solve the issue described here, but using sequence numbers in
PMIPv6 is possible
in general as an option.
o Section 3.2 step 4) last bullet I do not understand why it mentions "both
host-based and network-based security associations are used to update the same
binding cache entry at the HA/LMA" as earlier the scenario has been scoped so
that HA & LMA binding caches are separate.
o Section 3.2 -> s/(or binging cache)./(or binding cache).
-> s/RFC4832, section 2.2/RFC4832, Section 2.2
-> add a reference to IKEv2 [RFC5996]
o Section 3.3 says the ".. advertising the home link prefix to the MN in a
unicast Router Advertisement message." While it makes sense and is typical
behavior when a MAG receives a Router Solicitation, it is not necessarily the
case always. The MAG can send multicast Router Advertisements when it so decides
or send it before receiving a Router Solicitation.
o Section 4.2.1 -> s/MN-HoA.For/MN-HoA. For
o Section 4.2.2 -> s/MAG. the/MAG. The
o Section 4.2.2 could reference to draft-ietf-netlmm-lma-discovery when it
discusses about LMA discovery and it not being defined in RFC5213.
o Section 5 reference [pmipv6-draft] should be [RFC5213].
o The document uses both (P)MIPv6 and (Proxy) Mobile IPv6 interchangeably.
It should stick with one style.
o The document uses both BCE and binding cache entry interchangeably. It should
stick with one style.
o The document uses both HA and Home Agent interchangeably. It should stick with
one style.
o The document uses both HA/LMA and LMA/HA interchangeably. It should stick with
one style.
o Most of the acronyms are not expanded on the first use.
I support Tim's DISCUSS positions.
Some nits:
Section 3, second sentence:
OLD
This document does not
^^^^
only focus on scenarios where the two protocols are used by the same
mobile node to manage local and global mobility, but it investigates
^^
also more complex scenarios where the protocols are more tightly
^^^^
NEW
This document not
only focuses on scenarios where the two protocols are used by the same
mobile node to manage local and global mobility, but also investigates
more complex scenarios where the protocols are more tightly
Section 3, page 9, line 4:
OLD
depicted in the figure. However, the LMA and HA can be also
^^^^^^^
NEW
depicted in the figure. However, the LMA and HA can also be
draft-katagi-clefia
draft-irtf-rrg-recommendation
draft-irtf-mobopts-mpa-framework