IESG Narrative Minutes
Narrative Minutes of the IESG Teleconference on 2010-10-07. These are not an official record of the meeting.
Narrative scribes: John Leslie (The scribe was sometimes uncertain who was speaking.)
Corrections from: (none)
1 Administrivia
2. Protocol Actions
2.1 WG Submissions
2.1.1 New Items
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
2.1.2 Returning Items
2.2 Individual Submissions
2.2.1 New Items
Telechat:
2.2.2 Returning Items
3. Document Actions
3.1 WG Submissions
3.1.1 New Items
Telechat:
Telechat:
Telechat:
3.1.2 Returning Items
3.2 Individual Submissions Via AD
3.2.1 New Items
Telechat:
Telechat:
3.2.2 Returning Items
3.3 Independent Submissions Via RFC Editor
3.3.1 New Items
Telechat:
3.3.2 Returning Items
3.3.3 For Action
Telechat:
4 Working Group Actions
4.1 WG Creation
4.1.1 Proposed for IETF Review
4.1.2 Proposed for Approval
Telechat:
Telechat:
4.2 WG Rechartering
4.2.1 Under evaluation for IETF Review
Telechat:
Telechat:
Telechat:
4.2.2 Proposed for Approval
Telechat:
1231 EDT break
1236 EDT back
5. IAB News We can use
6. Management Issues
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
7. Agenda Working Group News
1312 EDT Adjourned
(at 2010-10-07 07:29:02 PDT)
draft-ietf-krb-wg-anon
Section 4.2: The TGS SHOULD NOT populate identity-based authorization data into an anonymous ticket in that such authorization data typically reveals the client's identity. MUST? Or, under what conditions can the TGS violate the SHOULD NOT? Section 7: The padata-value field of the PA-PKINIT-KX type padata contains the DER [X680] [X690] encoding of the Abstract Syntax Notation One (ASN.1) type PA-PKINIT-KX. Are [X680] and [X690] citations? There are no matching references in the References section.
idnits (http://tools.ietf.org/tools/idnits/) notes a few issues with references that other ADs have noted, and one problem with format. It would be good to sort these out. --- I like the acknowledgement... Sam Hartman and Nicolas Williams were great champions of this work. It is so often the case that document authors do not champion their work :-)
Please consider the comments made by Elwyn Davies in the Gen-ART
Review posted on 10 September 2010. The review can be found here:
http://www.softarmor.com/rai/temp-gen-art/
draft-krb-wg-ananon-12-davies.txt
The Security Considerations note that "Because there are plaintext parts of the tickets that are exposed on the wire, such matching by a third party observer is relatively straightforward." Presumably the use of transport layer security would minimize the attack surface here, so at least an informative reference to draft-josefsson-kerberos5-starttls might be appropriate.
1) Refer to RFC 5652 vice RFC 3852. 2) Sec 4.1.1: This is pretty nit-noid, but the certificates field is OPTIONAL in the ASN so it might be better to say absent as opposed to empty. The signerInfos field isn't OPTIONAL so empty is correct. It's up to you whether you should change this.
draft-ietf-krb-wg-naming
Section 3.1: If a well-known principal name is used as the client principal name or the server principal name but not supported, the Authentication Service (AS) [RFC4120] and the application server MUST reject the authentication attempt. What does "not supported" mean here? How does this behavior compare with the behavior of currently deployed ASs; i.e., will an AS implemented before this document was written reject the authentication attempt?
In section 3.1: is the string "WELLKNOWN" case sensitive? 6. IANA Considerations This document provides the framework for defining well-known Kerberos names and Kerberos realms. A new IANA registry should be created to contain well-known Kerberos names and Kerberos realms that are defined based on this document. The evaluation policy is "Specification Required". This needs (at least) an Informative reference to RFC 5226.
1. Please expand KDC at first occurence. 2. In the Security Considerations section: > It is possible to have name collision with well-known names because Kerberos as defined in [RFC4120] does not reserve names that have special meanings, consequently care MUST be taken to avoid accidental reuse of names. s/care MUST be taken to avoid accidental reuse of names/accidental reuse of names MUST be avoided/
I would like to echo Ralph's comment: given that RFC 4120 does not have the concept of reserved names, this specification cannot legislate the behavior of applications that currently conform to RFC 4120 but not this specification. Furthermore, it would be helpful to describe the recommended behavior of a client that supports reserved names when it interacts with an authentication service or ticket granting service that does not support reserved names; for example, does the client need to discard the ticket it receives?
1) Sec 1: It's odd that there's a 2119 requirement in the intro (before the requirements terminology). Could this be reworked? 2) Sec 1: r/is to remedy/remedies 3) Sec 1: It would be nice to have some text that indicates say which parts of 4120 you're updating. Section 6.1, 6.2, 7.5.7, and 7.5.8 right? Side note: Interesting that in 4120 Section 6.2 uses NT-TYPENAME while 7.5.8 uses the prefix KRB and underscores instead of dashes (KRB_NT_TYPENAME). Should KRB_NT_WELLKNOWN also be NT-WELLKNOWN? 4) Sec 3.1, 2nd para, 2nd sentence: r/must/MUST
draft-ietf-isis-genapp
I support the publication of this document and I think it is a good
and proper addition to the ISIS protocol.
However, I have a specific technical concern. Section 6 says:
The IS-IS WG of the IETF acts as the authority to determine whether
information proposed to be advertised in IS-IS LSPs falls under this
definition.
But then Section 8 says:
Registration procedure is "Specification Required" as defined
in [RFC5226]
If we are expecting to verify that the information falls under the
right category, then Specification Required does not appear to be
the right IANA rule. Or am I missing something?
Abstracts should not have normative language. This has been pointed out at the
COMMENT level but I think this is a DISCUSS-level concern.
I'm missing a crystal clear statement in a very visible spot that the content
exchanged in GENINFO TLVs MUST NOT alter the behavior or operation of the IS-IS
protocol and/or state machine. In other words, GENINFO is not a tool for a
vendor to extended IS-IS in non-interoperable ways. The document does hint that
this is the intent in a few places; I'm simply asking for making this very, very
clear.
(Non-actionable comment: I will likely abstain on this document even when the above change is made. The reason is that I'm allergic against the current trend of adding kitchen-sink options that turn all kinds of formerly purpose-built protocols info generic "information exchange" mechanisms.)
Thank you for this draft, it is a necessary addition to the IS-IS family. I look
forward to moving to a "Yes" ballot when we have cleared up a number of minor
points.
Discuss updated after emails with the authors.
---
Section 2
In order to minimize the impact advertisement of GENINFO may have on
the operation of routing, such advertisements MUST occur in the
context of a non-zero instance of the IS-IS protocol as defined in
[I-D.ietf-isis-mi]. Exceptions to this restriction MAY be allowed
subject to restrictions discussed later in this document.
In Section 5, this is presented as:
Advertisement of GENINFO therefore MUST occur in the context of a
non-zero instance of the IS-IS protocol as defined in
[I-D.ietf-isis-mi]. Exceptions to this policy MAY be allowed only
when there exists a standards track RFC which defines the
application.
If you say "MUST" I don't think you can allow a variation using "MAY".
Suggest...
Section 2
OLD
In order to minimize the impact advertisement of GENINFO may have on
the operation of routing, such advertisements MUST occur in the
context of a non-zero instance of the IS-IS protocol as defined in
[I-D.ietf-isis-mi]. Exceptions to this restriction MAY be allowed
subject to restrictions discussed later in this document.
NEW
In order to minimize the impact advertisement of GENINFO may have on
the operation of routing, such advertisements MUST occur in the
context of a non-zero instance of the IS-IS protocol as defined in
[I-D.ietf-isis-mi] except where the rules for the use of the zero
instance set out later in this document are followed.
END
Section 5
OLD
Advertisement of GENINFO therefore MUST occur in the context of a
non-zero instance of the IS-IS protocol as defined in
[I-D.ietf-isis-mi]. Exceptions to this policy MAY be allowed only
when there exists a standards track RFC which defines the
application.
NEW
Advertisement of GENINFO MUST occur in the context of a non-zero
instance of the IS-IS protocol as defined in [I-D.ietf-isis-mi]
except when the use in the zero instance is defined in a Standards
Track RFC.
END
---
3.3. Standardization Requirements
GENINFO is intended to advertise information on behalf of
applications whose operations have been defined in public documents.
GENINFO is NOT intended to be used for proprietary or experimental
purposes.
The public document MUST include a description of the subTLV
allocation policy.
I support the intent of this text, but I don't think it is clear.
For example, an experimental RFC is a public document. A proprietary
use may be documented in a public document.
Since the rgeistration rules are "Specification Required", I suggest
you refer to this directly, and re-state what "Specification
Required" means.
---
I feel a bit of a lack discusion of backwards compatibility.
You need to cover how a legacy implementation will react to seeing the
new GENINFO TLV (a reference to an existing RFC will do), and then
consider how this will apply to the utility of the extension (for
example, if all speakers participating in the IS-IS instance must be
upgraded - I think they will because otherwise they will not see the
flags fields in the new TLV).
It would be helpful to add a brief statement in Section 4 along the lines of:
"According to the rules of [RFC4971] a legacy implementation receiving a GENINFO
TLV will ..."
---
Section 10.2
[I-D.ietf-isis-mi] looks like it is used as a normative reference in
Section 2.
I don't think it is helpful to use RFC 2119 language in the Abstract.
---
I think that the RFC Editor will ask you to jiggle the content/section-
headings slightly. They have a preference for seeing Section 1 named
"Introduction".
---
A few acronyms need to be expanded on first use:
- TLV
- PDU
---
Section 3.1
Application ID
An identifier assigned to this application via the
GENINFO-REG.
What is the "GENINFO-REG"?
How about:
Application ID
An identifier assigned to this application via the
registration procedures described in Section 8.
---
Section 3.2
The scope of the codepoints used in such subTLVs is defined by the
GENINFO TLV codepoint AND the Application ID i.e. the subTLV
codepoints are private to the application.
The uppercase word "AND" has not definition.
Suggest
The scope of the codepoints used in such subTLVs is defined by the
combincation of the GENINFO TLV codepoint and the Application ID,
i.e. the subTLV codepoints are private to the application.
The sole statement in the security considerations:
This document raises no new security issues for IS-IS.
I don't think that is quite true, albeit in a rather cyclic manner.
First, I believe that the use of IS-IS as a transport does have security
implications that need to be considered
when specifying a new geninfo
application ID. It would be helpful to describe the limitations implied by this
transport,
and when additional security mechanisms can be employed to extend the
scope. For example, the standard IS-IS
cleartext password might be
insufficient for some types of data, requiring deployment of RFC 5304 or 5310
authentication mechanisms.
Second, deployment of advanced IS-IS security mechanisms (e.g., RFC 5310
authentication) is something I
personally advocate. However, if an IS-IS
deployment were to deploy these mechanisms solely to support
advertisement of
some generic information this may exacerbate any performance implications for
the IS-IS
deployment and could be used to launch denial of service attacks.
That is, deploying IS-IS security mechanisms
*because* of the generic
information would be costly for the IS-IS implementation and would violate the
usual
precept of "security commensurate with need".
I think a paragraph or two (total) in the security considerations that addresses
both these issues would be appropriate.
I support Lars' discuss,
1. I dislike overloading protocols with exchanges of information that do not
relate to the protocol functionality. However, at this phase, if the working
group was chartered to do this work, I can accept such an extention as the
GENINFO advertising of generic information. However, in this specific case I do
not see anything in the IS-IS WG charter that indicates that this work is within
the WG goals. On the contrary the phrase
'The IS-IS Working Group is chartered
to document current protocol implementation practices and
improvements,
as well as to propose further extensions to be used within the scope
of
IS-IS and IP routing.'
may be read as saying the generic information advertising is not within the
scope.
I do not even see the document on the Goals and Milestones list. Does it hide
under another name?
Is there any other record about this item being reviewed and approved by the
IESG as a chartered item?
2. I am confused by the recommendation in 3.2:
> The use of additional levels of subTLVs is discouraged due to the
inherent inefficiency in encoding introduced because the parent
subTLV must encode the nested subTLV length. While this inefficiency
is small (one additional octet), it may be sufficient to extend the
total information about a single application object beyond the
carrying capacity of a single GENINFO TLV. Given that each
Application ID can utilize the full range of subTLV codepoints (0 to
255) without conflict with any other application, the need to be
frugal in the use of APPSUBTLV codepoints is greatly reduced.
The last phrase confuses me, as it seems to go against the rest of the
paragraph. I would suggest a clear explanation at this point.
3. In section 3.3 - it would be useful to explain what a 'public document' is.
Is this the same as what RFC 5226 considers a 'public specification' or is this
something else?
4. In Section 6:
> The applicability statement above is expected to cover some
information currently being advertised by IS-IS in previously defined
TLVs. It is expected and seen as desirable that an effort be made to
migrate the advertisement of such information to utilize the
procedures defined in this document.
Are there any examples? From an operational deployment point of view how would
the exchange of information be migrated from advertising in exiting previoulsy
defined TLVs to an Application ID in the new General Info TLV?
5. I disgree with the claim made in the Security Considerations section that
'This document raises no new security issues for IS-IS'. I believe that when
defining new applications that exchange generic information using IS-IS there is
a risk that the basic protocol exchange be impacted and this needs to be
mentioned.
6. The process required in the IANA Consideration section is not fully in tune
with the statement made in section 6:
> The IS-IS WG of the IETF acts as the authority to determine whether
information proposed to be advertised in IS-IS LSPs falls under this
definition.
Is it supposed that the IS-IS WG will stay active for a long period of time to
make determination whether new requests fall or not within the categories
covered by IS-IS Decision process? What process will the WG follow - ask for an
RFC to be writte for each request?
To me the process defined in Section 8 seems to be sufficient - the
"Specification Required" procedure as defined in [RFC5226] implies the
nomination of a Designated Expert, and while writing an RFC is the best
specification the procedure can expect, documents published outside of the RFC
path can also serve the purpose.
Section 5 states that "flooding of information not directly related to the use
of the IS-IS protocol in support of routing degrades the operation of the
protocol." Therefore I think the Security Considerations section needs to
discuss the possibility of denial of service attacks, preferably with reference
to RFC 4732.
The abstract says "SHOULD be advertised" and "SHOULD be used", but conformance language does not belong in the abstract. Please unpack acronyms on first use (TLV, PDU, LSP, etc.).
What is the current status of isis-mi? How stable is it? (Specifically, how
likely is it that changes there would cause this document to have to return to
the working group later?). I agree with other's suggestion that isis-mi should
be a normative reference.
I support Dan's discuss points. The document could better motivate the need for a generic container. Could it explicitly call out the existing messages that would have been candidates for the use of this mechanism if it existed at the time? Would it make sense to add text reinforcing that elements not understanding this TLV would ignore-but-flood?
1) Never seen 2119 language in Abstract. Is this allowed by the RFC editor? 2) Spell out LSP on first occurrence. 3) Sec 2: It's odd that there are requirements in the overview section. Could this be reworked? 4) Sec 3 (and the rest of the document): RFC 5305 refers to sub-TLV not subTLV. This document should align with 5305. 5) Sec 3.1: It would be nice if you assigned a word for the Flags: S (Scope), D (Down), I, and V. It would be nice to assign a word to for "I" and "V" too. How about Ipv4 for "I" and ipV6 for "V". 6) Sec 3.2: RFC 5035 has to following text about ignoring unknown sub-TLVs: "Unknown sub-TLVs are to be ignored and skipped upon receipt." Does this draft want to use 2119 language to in fact require they be ignored? 7) Sec 3.2: r/AND/and 8) Sec 3.3: r/NOT/not 9) Sec 7: r/IS-IS/IS-IS [RFC1195].
draft-ietf-ccamp-gmpls-ethernet-pbb-te
Why is there a question over this suggested value? "(suggested value: 35?)"
I am fine with approving this document, but there is one detail that needs to be
fixed, and can easily be fixed in the document. Section 5.2 defines normative
behavior in the case of Invalid MAC addresses (actually the functional IEEE
802.1 functional address range) but does not explicitely specify this range, but
rather refers to [IEEE 802.1Q] which is an Informational Reference. I think that
for clarity either the reference must be moved to Normative, or the range of the
functional addresses needs to be shown here.
1) Sec 4.1, 2nd para: Having a 2119 requirements in a note seems odd. This should be reworded. Maybe just remove "Note however that"? 2) Sec 4.1.1: r/Eth LSP/Eth-LSP 3) Sec 6: Expand UNI, NNI, and DOS.
draft-ietf-grow-mrt
"All MRT format messages have a common header which includes a timestamp, Type, Subtype, and length field. The header is followed by a message field. The MRT common header is illustrated below." s/includes/consists of/ since includes implies it has other information, or the scope for other information in the future. also the what you illustrate is the MRT format, not just the common header. ============= It would have been clearer to have described the microsecond extended common header in it's own right and then call it up in each of the *_ET cases, rather than to have described the IGP _ET modes in terms of the BGP _ET mode.
The rule is that acronyms need to be expanded on their first use in the title, abstract, and body of the document.
Just a couple of small things to consider... --- A couple of places say things like: A number of MRT message types have been documented in some references It would be nice to state the references (informational). --- Section 5.1 Should Remote IP address and Local IP address fields be explained?
The DISCUSS and COMMENT is based upon the OPS-DIR review performed by Lionel
Morand. I would like to have them answered before I can approve this document.
1. The requested status is "Standard Track" and the wording in the introduction
seems not to be appropriate, more relevant for an Informational RFC.
"This memo serves to document the MRT format as currently implemented
in publicly available software."
If Standard Track is the right intended status (I believe it is) the language in
the introduction should reflect that the document defines a protocol extension
for standards track, not just documents existing implementations.
Moreover the original format is extended. Should we have rather something like:
"this memo standardize the MRT format as it shall be used..."?
2. The introduction mentions that some type values are deprecated and are given
in Appendix for information. But, after that, section by section describing the
types and in the IANA section, there is nothing about the deprecated values.
Should we mark theses values are reserved? Whatever the decision, something
should indicated each time it is required.
As Sean Turner noted, please add a normative reference to RFC 3629 for UTF-8 (in Sections 4 and 5.3).
Support Sean's point 4 (re: privacy considerations). I also suggest the Security Considerations section explore the ramifications of protecting the transport of data in this format (and perhaps even the timing of its availability) to avoid informing an eavesdropper that wishes to mount an attack on one of the protocols being reported on. Pointing to the potential attacks in the security considerations sections of the protocol documents would help.
This is an updated DISCUSS that picks up Robert's comment (#5 is new the others
are unchanged).
1) Sec 4 (If the Apps ADs have already said this): Need a normative reference to
UTF-8.
2) Sec 5.2: Need a normative reference to IPv4 and IPv6 for their address
formats.
3) Sec 5.5: Is there some format for this field?
4) As noted in the Richard Barnes' SECDIR review (http://www.ietf.org/mail-
archive/web/secdir/current/msg02007.html), some of the information in an MRT
object could be considered private, especially given that MRT is commonly used
to publish router dumps (e.g., through RouteViews [1]). For example, BGP
neighbors that advertise paths to their peers might not expect these paths to be
published in an MRT dump. There is also a proposed extension to MRT that would
add geolocation information about the router and its peers [2]. I would suggest
that the document add a brief note that some information contained in MRT dumps
might be considered private. Suggested text based on the above:
"
Some
information contained in an MRT data structure might be considered sensitive or
private. For example, a BGP peer that sends a message to an MRT-enabled router
might not expect that message to be shared beyond the AS to which it is sent.
The proposed geolocation extension to MRT could reveal the location of an MRT
router's peers [I-D.ietf-grow-geomrt]. An organization that intends to use the
MRT structure to export routing information beyond the domain where it normally
accessible (e.g., publishing MRT dumps for use by researchers) should verify
with any peers whose information might be included, and possibly remove
sensitive fields.
"
5) The Security Considerations section explore the ramifications of protecting
the transport of data in this format (and perhaps even the timing of its
availability) to avoid informing an eavesdropper that wishes to mount an attack
on one of the protocols being reported on. Pointing to the potential attacks in
the security considerations sections of the protocol documents would help.
1) Sec 2.4.1: Expand: FSM. 2) Sec 5.1: Isn't it "OSPFv2 Protocol"? No need to change the type name but (I think) the text referencing 2328 should say OSPFv2. 3) Sec 5.2, para after Figure 3: Should the "may"s and "should" be upper case? 4) Sec 5.2, penultimate paragraph: must or MUST? 5) Sec 5.3: Expand: ASN, NLRI, AS. 6) Sec 5.3, 2nd para: Please reword so that 2119 requirement is not in a "Note". 7) Sec 5.3, 3rd para: r/optional/OPTIONAL
draft-ietf-tsvwg-sctp-chunk-flags
This document is doing exactly the right thing and its good that
we update the IANA rules on Chunk Flags.
However -- and I feel a bit silly raising this -- the motivation
at the beginning just seems wrong. The document says:
Without publication
of this document, the only way to have done this would have been to
obsolete [RFC4960], which is not appropriate.
I do not think obsoleting RFC 4960 would have been necessary at all.
As an example, even this draft just does an Updates: RFC 4960, not
Obsoletes: RFC 4960.
As this is a small issue I do not plan to block the publication because
of this matter, but I did want to raise a Discuss so that we can talk
about it on the IESG telechat and hopefully the responsible AD will
place an RFC Editor note to correct this.
Suresh Krishnan posted a Gen-ART Review on 5 October 2010, and the
authors responded to the review immediately. However, I do not think
that the concerns with the IANA Considerations have been resolved.
I think a simple update to Section 3 will resolve the issue.
Suresh Krishnan said:
>
> Even though this is under the IANA considerations section, the
> instructions seem to be aimed not at IANA but at protocol extension
> designers. Where does the required documentation need to be? In the
> relevant draft or in an IANA registry. The only IANA instruction I
> can see is the sentence beginning with "IANA creates for each new
> chunk type a registration table for the chunk flags for this type."
The authors said in reply:
>
> Section 3.1 is the updated section 14.1 of RFC 4960. This is
> explained in Section 3:
>
> Section 3.1 describes the updated procedure for chunk type
> registration and replaces Section 14.1 of [RFC4960]. Section 3.2
> adds a new procedure for chunk flag registration to the updated
> section 14.1 of [RFC4960].
>
> IANA is requested to create an SCTP Chunk Flag registry. The
> initial contents of the registry should be assigned using the
> values specified in Section 3.3.
>
> So what we expect from IANA when this ID is approved is specified
> in section 3.3.
I suggest that Section 3 should say:
Section 3.1 provides the updated procedure for SCTP Chunk Type
registration; it replaces Section 14.1 of [RFC4960].
Section 3.2 provides a new procedure for SCTP Chunk Flag registration.
A registry entry must be created for each SCTP Chunk Type.
Section 3.3 provides the SCTP Chunk Flag registry values for the
SCTP Chunk Types specified in [RFC4960].
This document is fine, and I support its approval, provided that the issues
raised in the Jari's DISCUSS and the issue here are considered for edits (RFC
Editor note would be fine).
Section 3.2, point b) seems to me incomplete when it describes the behavior of
implementations that do not support a new flag only as a receiver and not as a
sender.
A small edit on the lines of the one suggested below would clarify the issue:
s/It MUST be considered that implementations not supporting the flag will just
ignore it/It MUST be considered that implementations not supporting the flag
will send '0' on transmit and just ignore it on receipt.
I support Jari's DISCUSS.
draft-gundavelli-v6ops-l2-unicast
"It is inconsequential for the network layer protocols or the IP stack to go across the layers and check the semantics of message delivery." Does the author mean "It is inappropriate....."? ==========================
Related to Lars' DISCUSS, this text in section 3 needs to be expanded
to be specific about how to handle the case when there are multiple target
nodes in the multicast group:
o An IPv6 sender node in some special cases and specifically when
the link-layer address of the target node is known, MAY choose to
transmit an IPv6 multicast message as a link-layer unicast message
to that node.
Introduction: It is inconsequential for the network layer protocols or the IP stack to go across the layers and check the semantics of message delivery. Not sure what "inconsequential" means here...
Bernard Aboba's tsv-dir review raises the following point:
> This document, while making a valid point, needs additional refinement so as
> to ensure that IP multicast packets are sent to all potential subscribers on
> a LAN. In its current form, this document provides too much wiggle room for
> implementers and is could potentially result in
> Interoperability problems.
Please see his detailed review for the specific instances where he recommends
improvements to the document.
I think that RFC 2464 is surely a normative reference.
I support the DISCUSSes from Lars and Adrian.
The Introduction states:
... if there is only one
receiver and its link-layer address is known it is legal to send the
IP multicast to the unicast link-layer address of that system.
Section 3 states:
An IPv6 sender node in some special cases and specifically when
the link-layer address of the target node is known, MAY choose to
transmit an IPv6 multicast message as a link-layer unicast message
to that node.
These are not consistent. Specifically, the Introduction makes it sound as if it
is legal to send the IPv6 multicast message to the unicast link-layer address
only if there is but one link-layer receiver, whereas Section 3 removes this
restriction and states only that the sender of the IPv6 multicast message needs
to know the address of the target node. Please harmonize the text between these
two sections.
draft-ietf-pce-manageability-requirements
draft-ietf-v6ops-cpe-simple-security
Section 3.1: REC-9: Inbound DHCPv6 discovery packets [RFC3315] received on exterior interfaces MUST NOT be processed by any integrated DHCPv6 server. Did you consider processing by an integrated DHCPv6 relay agent? I would suggest "server and/or relay agent".
Please note that RFC 4306 has been obsoleted by RFC 5996
Two comments: (1) REC-25 seems out of place. REC-25 specifies default mode for handling Host Identity Protocol (hip) packets, but is in section 3.2.4 "IPsec and Internet Key Exchange (IKE)". (2) Shouldn't REC-21 cover WESP packets as well as ESP packets? It would seem the same rules would apply.
draft-ietf-grow-bgp-graceful-shutdown-requirements
Section 5., paragraph 2: > As a result, provided an alternate path is available in the AS, the > packets are rerouted before the BGP session termination and fewer > packets (possibly none) are lost during the BGP convergence process > since at any time, all routers have a valid path. There is obviously the unstated assumption here that the available capacity on the new path can sustain the current load on the old path. Otherwise, there will definitely be packet loss. This isn't something that BGP can necessarily guarantee. Section 5., paragraph 5: > a) A mechanism to advertise the maintenance action to all affected > routers is REQUIRED. Such mechanism may be either implicit or > explicit. Note that affected routers can be located both in the local > AS and in neighboring ASes. Note also that the maintenance action can > either be the shutdown of a BGP session or the establishment of a BGP > session. > The mechanism SHOULD minimize packet loss when a path is removed or > advertised. In particular, it SHOULD be ensured that the old path is > not removed from the routing tables of the affected routers before > the new path is known. A "mechanism to advertise" can't really "minimize packet loss". It's the *reaction* to that advertisement that you need to make this requirement for.
Discuss updated to include comments from my review
I think this is a useful document and it is encouraging to see requirements like
this developed in the Ops Area for use within the Routing Area. Thank you.
---
Section 4
Please add "g-shut" and "g-noshut" to the terminology section
---
Section 5 Requirement a)
The mechanism SHOULD minimize packet loss when a path is removed or
advertised. In particular, it SHOULD be ensured that the old path is
not removed from the routing tables of the affected routers before
the new path is known.
Now, I may be a bit pednatic here, but I have two questions:
1. Is it the mechanisms that minimises packet loss, or does the
mechanism enable an implementation to minimise packet loss?
2. Why is this "SHOULD" not "MUST"? What use would this mechanism be if
it does not minimise packet loss? You might as well not have it!
OTOH, if you believe that "SHOULD" is correct, you will need to
give at least an example (using "MAY") of how the non-minimisation
of packet loss is acceptable.
---
Section 5 Requirement c)
This is out of scope of this
document, but comprehensive graceful shutdown procedures should take
this into account.
If it is out of scope, how can you say that the GS should do? I know you
are trying to say that a wider scope GS procedure should take this into
account, but that is clearly out of scope. I suggest you change to:
This is out of scope of this
document.
---
Section 7
I think you should require that solutions should specifically address
the issue of bogus g-shut messages and the impact they would have on
the n/w. Also the impact of hiding a g-shut message so that g-shut is
not performed.
=====
Enke Chen performed a Routing Directorate review on October 1st. I would like to
see discussion or action on the following points he raised.
---
I suggest that "BGP graceful bringup" related text be removed from the document
for the following reasons:
- To reduce packet loss during BGP bringup, several techniques have been
developed and are well known, including setting the "overload bit" in
IS-IS, and using large metrics in OSPF; and also also postponing the
bringup of external links until the IGPs and IBGPs have converged.
- When a primary path is added (such as in the case of BGP bringup),
routing needs to reconverge. IMO there is not much more that can be
done or needs to be done than what is already known.
- It is not clear from the document if there is a new requirement.
---
Section 2, Introduction
The draft says:
Currently, BGP [BGP-4] and MP-BGP [MP-BGP] do not include any
operation to gracefully withdraw a prefix while traffic toward that
prefix could still be correctly forwarded. When a BGP session is
taken down, BGP behaves as if it was a sudden link or router failure
and withdraws the prefixes learnt over that session, which may
trigger traffic loss. There is no mechanism to advertise to its BGP
peers that the prefix will soon be unreachable, while still being
reachable. When applicable, such mechanism would reduce or prevent
traffic loss.
This paragraph seems to suggest a particular enhancement ("graceful
prefix withdraw") in the protocol might be needed. This is a bit
misleading, and may not be the intention.
First, such an enhancement is not really required as there are a number
of parameters (in particular LOCAL-PREF) in BGP that can be used to
influence the degree of preference in route selection, and thus
influence the traffic flow.
Second, this is a requirement document, and is not about a specific
solution to satisfy the requirement.
So I suggest that the text be removed, or expanded to include the
possible re-use of existing protocol machinery.
Section 2 The Border Gateway Protocol(BGP) is heavily used in Service Provider Add citation of RFC 4271 [BGP-4] networks both for Internet and BGP/MPLS VPN services. For resiliency Add citation of RFC 4364 [VPN] --- Section 6 OLD The solution drafts should state its applicability for each of these possible topologies. NEW The solution documents should state the applicability of the solutions for each of these possible topologies.
I don't object to this document moving forward if the working group and sponsoring AD believe it will be useful in informing future protocol work, but I worry about its utility. The document has 16 SHOULDs and 2 SHOULD NOTs, and only 2 MUSTs (one of which really doesn't add anything): In the end, once the planned maintenance is finished the nominal BGP routing **MUST** be reestablished. Security Considerations Security considerations **MUST** be addressed by the proposed solutions. Are there really no other hard requirements the group could come to consensus on? The document talks about only covering "a subset of the cases". Does it mean "these requirements" when it says "the cases"? If not, what cases is it referring to?
draft-rosen-urn-nena
Like Lars, I was bothered a bit by some of the style in the Introduction section. Not quite RFC style, IMHO.
Section 1., paragraph 1: > NENA is the "Voice of 9-1-1" in North America. NENA's mission is to > foster the technological advancement, availability and implementation > of a universal emergency telephone number system (9-1-1). In > carrying out its mission, NENA promotes research, planning, training > and education. The protection of human life, the preservation of > property, and the maintenance of general community security are among > NENA's objectives. NENA serves as a link in the delivery of > emergency services. 9-1-1 has, throughout its evolution, become > recognized as an asset of the North American public. I feel like I am reading an advertisement for NENA here...
You have to love it when people have nothing better to do than pick trivial nits :-) Abstract... "URN name model" Should that be "URN model"? --- Abstract... Management activities for these and other resource types are provided by the National Emergency Number Association (NENA) Registry System (NRS). You have already defined "NENA" so... Management activities for these and other resource types are provided by the NENA Registry System (NRS). --- Introduction... Should expand "NENA" on first usage. --- Section 2... TNRS will maintain a website at a stable address which provides XML and text renderings of the urn:nena registry. Is this a typo? s/TNRS/NRS/ ?
Please consider the comments made by Suresh Krishnan in the Gen-ART
Review posted on 31 August 2010. The review can be found here:
http://www.softarmor.com/rai/temp-gen-art/
draft-rosen-urn-nena-02-krishnan.txt
[NENA08-003] reference might be Normative.
1) Just nit picking here, but in the 1st paragraph of the introduction it says that NENA's mission is .... universal .... but then it's goes on to say it's just for N.A. Is NENA really shooting for universal 9-1-1 or just in N.A.? 2) RFC 2141 requires US-ASCII so you could change: The "NENAclass" is a US-ASCII string that conforms to the URN syntax ... to The "NENAclass" conforms to the URN syntax ...
draft-iana-rfc2754-to-historic
The introduction says: In practice, this was never done in the public Internet. During a detailed review of IANA's protocol registration activities in support of the IETF, this request for IANA action was identified. The last sentence seems disconnected from the rest. Can it be deleted or reformulated? Right now, the sentence sounds like we had identified a need to do something. As I understand it, we identified an old RFC that suggested IANA activities that are no longer relevant.
The OPS-DIR review byLionel Morand raised the following issue which would be worth being explained: In the section 2, it is stated: During a review of RFCs in 2009 it became apparent that the IANA actions requested in RFC 2754 were never done. In the intervening time, another technology appears to be taking the role once envisioned for Distributed RPSL. It may be helpful for the reader to know what is this alternative solution. A simple reference can be useful.
draft-livingood-web-notification
draft-katagi-clefia