IESG Narrative Minutes
Narrative Minutes of the IESG Teleconference on 2017-10-12. These are not an official record of the meeting.
Narrative scribe: John Leslie and Ignas Bagdonas (The scribe was sometimes uncertain who was speaking.)
Corrections from: Mirja
1 Administrivia
2. Protocol actions
2.1 WG submissions
2.1.1 New items
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
Telechat:
2.1.2 Returning items
Telechat:
2.2 Individual submissions
2.2.1 New items
2.2.2 Returning items
2.3 Status changes
2.3.1 New items
2.3.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
3.2.2 Returning items
3.3 Status changes
3.3.1 New items
3.3.2 Returning items
3.4 IRTF and Independent Submission stream documents
3.4.1 New items
Telechat:
3.4.2 Returning items
4 Working Group Actions
4.1 WG Creation
4.1.1 Proposed for IETF Review
4.1.2 Proposed for Approval
Telechat::
4.2 WG Rechartering
4.2.1 Under evaluation for IETF Review
4.2.2 Proposed for Approval
5. IAB News We can use
6. Management Issues
Telechat::
Telechat::
Telechat::
Telechat::
Telechat::
Telechat::
7. Working Group News
7a. Other Business
1122 EDT started Conflict-Review (scribe left telechat
(at 2017-10-12 06:00:03 PDT)
draft-ietf-ccamp-ospf-availability-extension
I support Adam's DISCUSS. It seems odd to find the terminology section before section 1. Also, please consider using the boilerplate from 8174, especially since there are lower case instances of at least "should". I think the reference to RFC5920 needs to be normative, since reading that document seems necessary to understand the security considerations.
(1) Please include draft file names in the references, not just abbreviations. That will make it easier to track the relationship and dependencies. For example, the draft uses the generalized format defined in draft-ietf-teas-gmpls-scsi, but the name of that draft (draft-ietf-teas-gmpls-scsi) doesn’t appear anywhere. Also, the “References” and “Referenced by” tools in the datatracker don’t seem to work properly — in this case this document doesn’t appear to reference draft-ietf-teas-gmpls-scsi at all [A]. [A] https://datatracker.ietf.org/doc/draft-ietf-ccamp-ospf-availability-extension/references/ (2) Section 3.2. (Processing Procedures): “This information MAY be used for path calculation by the node(s).” I think that the “MAY” is out of place because this document already indicated that the use of the information is out of scope: s/MAY/may (3) Also from 3.2: The Availability SCSI-TLV MUST NOT be sent in ISCDs with Switching Capability field values that have not been defined to support the Availability SCSI-TLV. Non-supporting nodes would see such as a malformed ISCD/LSA. Where is this signaling defined? How does a node know that others support the Availability ISCD/LSA? (4) Section 4. (Security Considerations): “This document does not introduce security issues beyond those discussed in [RFC4203]…the extensions specified here have no direct effect on IP routing.” But that is not true! Even if out of scope of this document, the intent has already been established that the information can be used for route computation. I think you should then expand on the impact that tampering/changing the LSAs could have.
This could lead to random outcomes "If multiple are present, only the first Availability SCSI-TLV for an availability level carried in the same ISCD SHALL be processed. " I would suggest the following instead: "If multiple are present, the Availability SCSI-TLV with the lowest bandwidth value SHALL be processed. " Nit: In section 3.1 you may actually specify the actual length value as done for the type: OLD "Length: A 16 bits field that expresses the length of the TLV in bytes. " NEW "Length: 4 (bytes), 16 bits."
draft-ietf-teas-gmpls-scsi creates an IANA table "Generalized SCSI (Switching Capability Specific Information) TLVs Types" with a registration policy of "Specification Required." This document adds a value to this registry, and goes on to claim: The registration procedure for this registry is Standards Action as defined in [RFC8126]. "Standards Action" is not the same as "Specification Required." Since *this* document is not defining the registry, it should not reiterate the policy -- in particular because the policy can get out of sync if specified in multiple locations, as in this case.
Section 3.1 defines two fields as being "32-bit IEEE floaing point", which runs the risk of becoming ambiguous in the future (e.g., while no 32-bit decimal representations are currently defined, IEEE did define new, smaller formats in the most recent revision of IEEE 754). Additionally, byte ordering is important here. Recommend changing as: "This field is a binary32-format floating point number as defined by [IEEE754-2008]. The bytes are transmitted in network order; that is, the byte containing the sign bit is transmitted first." -- and, of course, add a citation for IEEE 754-2008 to the normative reference section. Additionally, while recipient behavior is described for the error of sending multiple TLVs with the same availability (yay!), I think you also want text around handling of TLVs that contain unexpected values (e.g., Availability >= 1.0, and handling of values like INF, -INF, and NaN). Options would include ignoring the TLV, or rejecting the entire ICSD. I'm not sure which is more consistent with typical OSCF handling. The reference for [GSCSI] is out of date. This is complicated by the fact that the title doesn't match, so finding the correct document is quite difficult. Please update to use "I-D.ietf-teas-gmpls-scsi-04" or something similar. The IANA section is pretty confusing at the moment, as it claims "IANA has created...", even though the table in question is requested by draft-ietf-teas-gmpls-scsi. It's probably worth adding a note (with a "remove before publication") indicating that the registry will be created by draft-ietf-teas-gmpls-scsi, and that the requested value should be added to it when it is created. ____ Nits: Please expand "TE" in the title. Section 3.1: Type: 0x01, 16 bits. As this is 16 bits, I recommend changing to: "0x0001, 16 bits"
This document should list the document that defines 32-bit IEEE floating point number as a Normative Reference, as it is required to implement the draft.
draft-ietf-curdle-cms-eddsa-signatures
I am in no way a subject matter expert in this field, but the bits I did understand were all easily understandable :-)
Thank you for your work on this draft and for addressing the SecDir review comments. https://mailarchive.ietf.org/arch/msg/secdir/FIm8MqdrQSOwXAsRkfJ27VFUF2k
Section 1.2: CMS values are generated using ASN.1 [X680], which uses the Basic Encoding Rules (BER) and the Distinguished Encoding Rules (DER) [X690]. Recommend: CMS values are generated using ASN.1 [X680], using the Basic Encoding Rules (BER) and the Distinguished Encoding Rules (DER) [X690]. (Rationale: ASN.1 has many more encodings than this, and the original phrasing implies that these are the only two.) I'm a little surprised that there are no citations for Curve25519, Curve488, and "Schnorr's signature system." If it is realistic add citations for these, I believe it would be an improvement.
draft-ietf-curdle-rsa-sha2
[EXT-INFO] needs to be a normative reference, since it's part of a SHOULD level normative requirement.
Thanks for addressing the SecDir review comments. https://mailarchive.ietf.org/arch/msg/secdir/ObNBH1VK1aPmdid3StYKLooa4Ls
Section 3.2: The signature field, if present, encodes a signature using an algorithm name that MUST match the SSH authentication request - either "rsa-sha2-256", or "rsa-sha2-512". It might be that I'm not familiar enough with SSH to know what recipients do when receiving unexpected values and the the proper behavior here would be obvious to implementors. If that's not the case, I would think that additional text here telling recipients what to do in the case of a mismatch would be helpful. The reference [EXT-INFO] needs to be normative rather than informative, as it is part of a normative behavior described in this document. Both section 1 and Section 5.1 describe NIST recommendations regarding key length, while not endorsing them (normatively or otherwise). This strikes me as notable, given that the NIST recommendations regarding SHA-1 seem to form part of the rationale for its replacement. Is the lack of endorsing NIST-recommended key lengths intentional? Nits: RFC6979 is in the references section, but does not appear to be referenced. One of the lines in the Acknowledgements section is too long.
There are a few outstanding comments from the Gen-ART review: https://datatracker.ietf.org/doc/review-ietf-curdle-rsa-sha2-10-genart-lc-housley-2017-09-01/ I personally do not have strong feelings about the title and the text in Section 3.1 but the review comments should be resolved by the author/WG.
draft-ietf-lamps-rfc5280-i18n-update
You folks would know best what's actually clear to your intended audience, but the use of "provide clarity on the handling of" in the Abstract, These updates to RFC 5280 provide clarity on the handling of Internationalized Domain Names (IDNs) and Internationalized Email Addresses in X.509 Certificates. and in the first paragraph of the Introduction, This document updates RFC 5280 [RFC5280]. The Introduction in Section 1, the Name Constraints certificate extension discussion in Section 4.2.1.10, and the Processing Rules for Internationalized Names in Section 7 are updated to provide clarity on the handling of Internationalized Domain Names (IDNs) and Internationalized Email Addresses in X.509 Certificates. wasn't particularly helpful to me. Are there a few words that would describe (at a high level) what the problem with RFC 5280 was, that required this document (I'm suggesting saying "so if you implemented RFC 5280, you can expect problems A and B, so you probably want to implement this specification as well", but in different words)?
I had the same question as Spencer -- I'd be interested to know what lack of clarity was (so that people who were unclear, and read this will know what they might have guessed at!). I'm really not knowledgable in this field, so feel free to ignore if this would have been obvious to anyone reading 5280...
-1.1: Please consider using the boilerplate from 8174. There's at least at least one use of a lower-case "should" (in 7.5.1, last paragraph).
The final paragraph in Section 2.4 reads: Implementations should convert the local-part and the host-part of internationalized email addresses placed in these extensions to Unicode before display. The mention of converting "local-part" to "Unicode" has a very strong implication that the local-part of internationalized email addresses can be (should be?) ACE-encoded (or otherwise converted to some non-Unicode encoding). Unless my understanding of internationalized email addresses is wildly wrong (and that may be the case), this isn't how they work: the local-part *is* in Unicode, and so conversion to Unicode doesn't make sense. This seems highly likely to lead developers down the path of ACE-encoding the local-part component of email addresses, which would cause incompatibilities.
The document has several instances of (lower-case) "should" where talking about implementation behavior. These look like they should be normative to me -- if that's the intention, please make them uppercase. If not, please update to RFC 8174 boilerplate. The document contains the following normative requirement: Note: Implementations MUST allow for increased space requirements for IDNs. It's hard to determine what an implementation needs to do in order to satisfy this normative requirement. Presumably, "increased" is relative to previous buffer allocations for domain names? Also, the statement can be satisfied as stated by simply increasing such buffers by a single byte. Surely that's not what's intended, is it? (Aside: I find the use of "Note:" preceding normative text to be confusing, so you might want to remove it)
draft-ietf-mboned-interdomain-peering-bcp
Minor questions/comments: 1) Section 3.4 also says: "Highly efficient use of bandwidth in AD-1." But aren't packets eventually duplicated in this case in AD-1? I guess it's more efficient than replicating them at the network border but might be still less efficient than native multicast in the whole network, no? 2) section 4.3.3 says: "The two AD's may supply additional security logs..." This seems to be a general action not specific to multicast or the scenarios described in this doc. 3) I don't think the conclusion section (8) is helpful or needed. If you want to keep it at all, this text could be moved into the introduction.
(This is related to Alissa's DISCUSS about logging of privacy-sensitive data. But since it's a little different, I'm entering my own DISCUSS.) In section 4.4 (operations) the bullet on problem notification states that AD2 will inform AD1 of, among other things, the locations of users. Is that intended to be geolocation, or network location? If the former, that's extremely sensitive information, and needs privacy guidelines.
Substantive Comments:
- I support Alissa's and Kathleen's DISCUSS positions.
- There seem to be quite a few implied assumptions about business models. I
will call out some specifically, but I'm sure I didn't catch them all. These
assumptions should either be removed or made explicit.
- The lists of guidelines seem to mix guidelines with observations of fact.
This makes it difficult to tell which parts are "best practices" (that is,
recommendations) vs which parts simply state fact.
-2: Is the assumption that the source is a service provider and the consumer is
an end-user relevant? This seems to perpetuate the (often false) assumption
that end users only consume content, but never produce it. It would be better
to state this in the form of whatever assumptions are implied by the idea of
SPs and EUs. For example, do you assume there is a one to many relationship
between SPs and EUs?
-3.2: Why does this section not rate a figure? I think it would be helpful to
show the GRE tunnel as distinct from the native multicast.
-3.5, paragraph after Figure 4: The large number of tunnels implies some
assumptions about the cardinality between SPs and EUs that should be stated
explicitly. (It would help to show this in the figures.)
- 4.3.2: The idea that that AD1 has a need to identify users in AD2 seems to be
based on some implied business model assumptions. Please state those
explicitly. (Or if I missed where they are stated, please point out the text.)
-4.3.3: This states that logging is necessary for delivery. Why is that? Again,
this seems to make some implicit business model assumptions. This section also
needs explicit privacy considerations.
-4.4: The choice of monitoring, etc, seems to be up to the network operators to
decide. Why does this document need to "expect" that? It might be helpful to
describe how monitoring specific information could be useful (perhaps for
troubleshooting), but the document does not go into that. The statements about
compensation should be out of scope for an IETF document.
-5: Can you define, or reference a definition for, "Looking-Glass style".
-6: Please include a discussion of threat models. When might one choose to
encrypt or not encrypt? What risks exist if you don't encrypt?
-- : "DRM and Application Accounting, Authorization and Authentication should
be the responsibility of the multicast application source" Why? This seems to
imply some business model assumptions.
Editorial Comments:
- General: I find the heavy use of nested bullet lists hard to read. Much of
the information in the lists would be better suited to paragraph form,
especially when list entries span several sentences. Likewise, the
inconsistent use of full sentences vs fragments makes it hard to read. (Maybe
this is just me)
-2: Please explain (s,g) before using, or even better spell it out. You do, in
fact, explain it in 4.2.3, but it's used quite a bit before you get to there.
-3.2, third bullet: "Ability to support only partial IP multicast
deployments..." Does this mean "only able to support partial..." or "able to
support partial..."?
- 3.3, figure:
The figures that involve tunnels would be easier to understand if you visually
distinguished tunnels from non-tunneled links.
- 3.3, e: "AMT tunnels will then configure dynamically"
s/configure/"be configured"
-3.4, d: " It is recommended that proper procedures are implemented such
that the AMT Gateway at the End User device is able to find the
correct AMT Relay..."
Is that a recommendation or a requirement necessary to work at all? (Same
construction appears in at least 3.5).
-4.1: Please expand SLA on first use.
-4.2.3: AMT Gateway: "The Gateway will reside on an End-Point - this
may be a Personal Computer (PC) or a Set Top Box (STB)."
Is that meant to be exhaustive? Surely there are endpoints that do not resemble
PCs or STBs.
-4.2.3, example procedures for gateway selection:
The heavy use of passive voice in this section obscures the actors. (This is
true to some degree throughout the document, but it seems more confusing here.)
-4.3.2, 2nd bullet: Please don't use "/" as shorthand for conjunctions.
(Pattern repeats throughout the rest of the draft.)
-4.3.3, first paragraph: The first sentence is hard to parse.
-6: Please expand DRM and CDN on first mention.
Thanks for your work on this draft. I'd like to see some text clarifications on security recommendations that should not be difficult to resolve. Section 4.4 - the exchange of supporting information could be sensitive, are there security requirements on the exchange? I don’t see them in this section. Section 6 - For the following text, it would be helpful to see some recommendations: “DRM and Application Accounting, Authorization and Authentication should be the responsibility of the multicast application source provider and/or AD-1. AD-1 needs to work out the appropriate agreements with the source provider.”
I agree with and support Alissa's Discuss and comments. Since she already holds a discuss on this point, here are my comments: Section 4.3.3 clearly refers to different types of logs, some have well known methods of delivery (syslog) and authentication, but setting a minimum requirement for secure exchange including encryption and authentication should be included in this section. The protocols and options may vary between the log types.
Thanks for doing this work.
I have comments, but they're all editorial.
In this text,
o AD-1 and AD-2 are assumed to adopt compatible protocols. The
use of different protocols is beyond the scope of this
document.
"compatible protocols" isn't helpful without some context. Is this talking
about "compatible multicast protocols", or complete protocol stacks from IP on
up, or something else?
I'm also noticing that the terms "should" and "recommended" appear a few times
in this document. This is a BCP and doesn't reference BCP 14, which is all
fine, but the wording is likely to lead readers in one direction. I wonder if
it's helpful to say these things differently, so that (for instance)
Hence, in the case of inter-domain peering, it is
recommended to use only SSM protocols; the setup of inter-
domain peering for ASM (Any-Source Multicast) is not in scope
for this document.
might become
Hence, this document assumes that in the case of inter-domain
peering, only SSM protocols are used; the setup of inter-
domain peering for ASM (Any-Source Multicast) is not in scope
for this document.
Nit: "out of cope"
This text,
packet streams will be part of a suitable
multicast transport protocol.
didn't parse for me - was it saying
packet streams will be carried by a suitable
multicast transport protocol.
or something else?
In this text,
Note that domain 2 may be an independent network domain (e.g., Tier
1 network operator domain). Alternately, domain 2 could also be an
Enterprise network domain operated by a single customer. The peering
point architecture and requirements may have some unique aspects
associated with the Enterprise case.
The Use Cases describing various architectural configurations for
the multicast distribution along with associated requirements is
described in section 3. Unique aspects related to the Enterprise
network possibility will be described in this section. Section 4
contains a comprehensive list of pertinent information that needs to
be exchanged between the two domains in order to support functions
to enable the application transport.
it wasn't easy for me to tie "some unique aspects" in the first paragraph to
"will be described in this section" in the second - if the last sentence in the
first paragraph was moved to be the second paragraph, so the text was
Note that domain 2 may be an independent network domain (e.g., Tier
1 network operator domain). Alternately, domain 2 could also be an
Enterprise network domain operated by a single customer.
The Use Cases describing various architectural configurations for
the multicast distribution along with associated requirements is
described in section 3. The peering
point architecture and requirements may have some unique aspects
associated with the Enterprise case. These unique aspects will be
described in this section. Section 4
contains a comprehensive list of pertinent information that needs to
be exchanged between the two domains in order to support functions
to enable the application transport.
that would have been easier for me to follow. It's also worth mentioning that
I'm guessing that "section 3" is "this section" in that text, and I'm pretty
sure "this section" isn't "section 2", which is actually where the sentence
appears, but it might be easier for the reader to say "will also be described
in section 3".
The first sentence in
e. The interconnection of AD-1 and AD-2 should, at a minimum,
follow guidelines for traffic filtering between autonomous
systems [BCP38]. Filtering guidelines specific to the multicast
control-plane and data-plane are described in section 6.
just seems odd ("this BCP says you should do that BCP"). ISTM that if there are
multicast-specific reasons to do BCP38 in addition to the usual reasons, that
would be a fine thing to say here, of course.
If your audience doesn't already know
o The GRE tunnel is often left pinned up.
(and if they don't, thank you for telling them), you might want to add a few
words explaining why that's a disadvantage.
In this text,
The advantage for such a chained set of AMT tunnels is that the
total number of unicast streams across AD-2 is significantly
reduced, thus freeing up bandwidth. Additionally, there will be a
single unicast stream across the peering point instead of possibly,
an unacceptably large number of such streams per Use Case 3.4.
However, this implies that several AMT tunnels will need to be
dynamically configured by the various AMT Gateways based solely on
the (S,G) information received from the application client at the EU
device. A suitable mechanism for such dynamic configurations is
therefore critical.
is there a good reference for "suitable mechanism(s)"?
I support Kathleen's and Alissa's discusses I'm concerned about whether the practices described adequately capture the notion of user consent to receive the data. Specifically, we're talking about sending large streams of data to people. Do the protocols in question adequately ensure that the addresses in question wish to receive the data. Specifically, the issue I am concerned with is whether I can cause you to get a large video stream. I'm filing this as a Comment rather than a Discuss because it doesn't seem like an issue for this BCP but rather for the protocols it documents. Please define S,G at first use.
I support Alissa's and Kathleen's DISCUSSes; and (as a separate concern), I
support Ben's DISCUSS.
Most of the comments I noted in my review of this document have been made by
other reviewers, and I will not reiterate most of them. I would, however, like
to draw particular attention to Ben's comments regarding charging, billing, and
settlement -- I believe these issues should either be fleshed out in
significantly more detail, or removed (with a simple statement in the
introduction that such issues are generally out of scope for the entire
document).
___
Section 4.2.3 contains the following text:
(Note
that in IPv6 there is a specific Anycast format and Anycast is
inherent in IPv6 routing, whereas in IPv4 Anycast is handled via
provisioning in the network. Details are out of scope for this
document.)
It would be helpful to the reader if the "out of scope" statement were
accompanied by a pointer to BCP 126/RFC 4786.
___
Section 5 contains the following text:
It is expected that multicast diagnostics will be collected
according to currently established practices [MDH-04].
I believe this statement makes [MDH-04] normative, as it is required to
understand its contents to implement the recommendations in this BCP.
Section 4.3.3 recommends that ADs generate and exchange extensive logging information, but the document says nothing about securing these logs or limiting the exchange of private or confidential information between the peers. This seems like it needs to be addressed in the BCP.
(1) Why does this document contain the copyright disclaimer for pre-RFC5378
work?
(2) Section 4.4 says:
"In the event of performance degradation (SLA violation), AD-1
may have to compensate the multicast application source per SLA
agreement. As appropriate, AD-1 may seek compensation from AD-2
if the cause of the degradation is in AD-2's network."
and
"Faults in service could lead to SLA violation for which the
multicast application source provider may have to be
compensated by AD-1. Subsequently, AD-1 may have to be
compensated by AD-2 based on the contract."
These bullets seem out of scope for this BCP. I would recommend deleting them.
(3) Section 6 says:
"DRM and Application Accounting, Authorization and Authentication
should be the responsibility of the multicast application source
provider and/or AD-1. AD-1 needs to work out the appropriate
agreements with the source provider.
Network has no DRM responsibilities, but might have authentication
and authorization obligations. These though are consistent with
normal operations of a CDN to insure end user reliability, security
and network security."
I find these two paragraphs somewhat contradictory and vague. The first
paragraph makes it sound like DRM could be the responsibility of AD-1. The
second paragraph makes it sound like AD-1 (assuming it counts as "network")
would never be responsible for DRM. Then later on the text says:
"Authentication and authorization of EU to receive multicast content
is done at the application layer between the client application and
the source. This may involve some kind of token authentication and
is done at the application layer independently of the two AD's."
Is this differentiating authentication and authorization of the application
source from that of the end user? It's not clear. I would suggest revising this
whole section to be clear about which security functions are the responsibility
of which parties.
draft-ietf-rtgwg-uloop-delay
Section 1. Introduction: "That means that all non-D neighbors of S on the topology will send to S any traffic destined to D if a neighbor did not, then that neighbor would be loop-free." -- I was unable to parse the above. I may just be overtired, but it feels like there are some missing words. Nits: " When S-D fails, a transient forwarding loop may appear between S and B if S updates its forwarding entry to D before B." -- Perhaps "... entry to D before B does." or "... before B updates its forwarding entry"? Section 2.1. Fast reroute inefficiency "On the router C, the nexthop to D is the tunnel T thanks to the IGP shortcut." s/the// "On C, the tail-end of the TE tunnel (router B) is no more on the shortest-path tree (SPT) to D, ..." s/is no more on/is no longer on/ (related) "... so C does not encapsulate anymore the traffic to D..." s/does not encapsulate anymore/no longer encapsulates/ Section 3. Overview of the solution "This ordered convergence, is similar to the ordered FIB ..." s/,/ (superfluous).
(Oops, sorry, I entered the bit about addressing my comments for the wrong draft. The following comments still apply.) - General: Do I undertand correctly that this is a black-box implementation detail? I note that section 4 explicitly says that it is a local-only feature that does not require interoperability. If so, then standards track seems inappropriate. BCP or informational seems to make more sense. Since there are recommendations here, I think BCP is the right choice. (I note Adam made a similar comment.) -11: Do you expect this section to stay in the RFC? It is likely to become outdated rather quickly. Editorial Comments: - General: Please number the tables. - sections 2 and 3 and their child sections have quite a few grammar errors. Please proofread it again. I mention a few specifics below, but doubt I caught everything. - 2, first paragraph: " That means that all non-D neighbors of S on the topology will send to S any traffic destined to D if a neighbor did not, then that neighbor would be loop-free." I can't parse that sentence. Is it a run-on sentence, or are there missing words? -- S / "can be work" / "can work" -3: " may cause high damages for a network." I suggest " may cause significant network damage". -4, last paragraph: "This benefit comes at the expense of eliminating transient forwarding loops involving the local router. " How is that an "expense"? Isn't it the whole point? -5.3, first paragraph and paragraph before figure 4: The MUST is stated twice. Please avoid redundant normative statements. Even if they agree now, they can cause maintenance issues down the road.
Section 5.1. (Definitions) refers to a couple of “existing IGP timers”. I understand the concepts, but can you please reference the IGP documents where these timers are defined? I quickly checked rfc2328 and couldn’t find a specific place that talked about LSP_GEN_TIMER (or LSA, of course!), or a similar concept. SPF_DELAY seems to be introduced by I-D.ietf-rtgwg-backoff-algo. Given that the rest of Section 5. (Specification) is built on these “existing IGP timers”, I think that the references should be Normative. Note also that the description in Section 5.2. (Current IGP reactions) is described (in 5.3) as the “standard IP convergence” and carries a “MUST” associated with it. It was mentioned (in 5.1) that the timers in question are “often associated with a damping mechanism”, which is not part of the base IGP specifications. I’m putting this comment in as a DISCUSS given that understanding the definitions (and having then Normative references) is necessary for the implementation of the mechanism described. I think it should be easy to resolve by just adding the appropriate references.
(1) Where do the numbers in the “Route computation event time scale” table come from? Please put a reference or at least some guidance to the origin of the information. If it's just for informational purposes, then please say so. BTW, please also put a number on the table. [I have the same question for the tables in Section 9.] (2) Section 5.4. (Local delay for link down) specifies that “update of the RIB and the FIB SHOULD be delayed for ULOOP_DELAY_DOWN_TIMER msecs. Otherwise, the RIB and FIB SHOULD be updated immediately.” When would ULOOP_DELAY_DOWN_TIMER not be applied? Along the same lines, if there’s no delay mentioned in Step 5 of 5.3, when would the RIB/FIB not be updated immediately? IOW, why are these “SHOULDs” not “MUSTs”? (3) What should be the default setting for ULOOP_DELAY_DOWN_TIMER? Section 9. (Examples) shows a couple of manually configured (?) scenarios, but no guidance is present in the document. Please include guidance (maybe based on the local network convergence, or even a default that manufacturers can use) in the Deployment Considerations section. (4) Section 11. (Existing implementations). Please take a look at RFC7942. Nits: s/any traffic destined to D if a neighbor did not/any traffic destined to D; if a neighbor did not s/can be work/can work “IGP shortcut feature”: a reference would be nice
Nit in section 9: You should probably not talk about 'our' solution or mechanism in an RFC: s/our/this/ or s/our X/the X described in this document/ This appears multiple times in section 9.
Thanks for addressing the SecDir review comments: https://mailarchive.ietf.org/arch/msg/secdir/tnRc2LPp6FqfDeyqd2cJExEtdXA
Line 115
Consider the case in Figure 1 where S does not have an LFA to protect
its traffic to D. That means that all non-D neighbors of S on the
You need to define LFA.
Line 118
topology will send to S any traffic destined to D if a neighbor did
not, then that neighbor would be loop-free. Regardless of the
advanced fast-reroute (FRR) technique used, when S converges to the
This is not a grammatical sentence.
Line 132
S ------ B
1
Figure 1
What do the numbers in this box mean? I assume they are route metrics, but you
need to say so.
Line 136
When S-D fails, a transient forwarding loop may appear between S and
B if S updates its forwarding entry to D before B.
Something seems to have gone badly wrong with this paragraph. Are these lines
supposed to be in the previous paragraph.
Line 326
unstable. As an example, [I-D.ietf-rtgwg-backoff-algo] defines a
standard SPF delay algorithm.
You need to define SPF here.
Line 338
1. The Up/Down event is notified to the IGP.
Usually, one would say that the IGP is notified of...
Line 552
S
Figure 7
Is this the same as the previous figure with T running CEAB?
This document doesn't really define any new on-the-wire protocol. Was publication as a BCP rather than a standards track document considered? The Introduction contains the following text: That means that all non-D neighbors of S on the topology will send to S any traffic destined to D if a neighbor did not, then that neighbor would be loop-free. I can't parse this sentence. Is there supposed to be a sentence break somewhere in there? The introduction starts talking about post-failure events (e.g., "when S converges to the new topology") before mentioning a failure of the S-D link. This makes it very hard to follow. Would suggest mentioning the failure being considered before talking about the ensuing events. Section 4 begins: This document defines a two-step convergence initiated by the router detecting a failure and advertising the topological changes in the IGP. This introduces a delay between the convergence of the local router and the network wide convergence. This reads backwards to me. With this technique, the network converges first, followed by an introduced delay, followed by router convergence. Right? Further on in that section: This benefit comes at the expense of eliminating transient forwarding loops involving the local router. I can't make sense of this. Eliminating transient forwarding loops is a good thing, right? Not an expense? I agree with Alvaro that the lack of a recommended default for ULOOP_DELAY_DOWN_TIMER is an issue, especially as the values configured in the examples seem to change arbitrarily from 1 second to 2 seconds.
draft-ietf-mpls-spring-lsp-ping
Authors have identified corrections: - 5.1 requires reference to ietf-spring-segment-routing for definition - 5.2 requires reference to ietf-spring-segment-routing for definition - 5.3 need to remove reference to section 3.5 and only reference ietf-spring-segment-routing (as section in document is being renumbered, best not to reference) - change ietf-spring-segment-routing from normative reference to informative reference for consistency with RFC8029 and other MPLS Ping documents which do as informative reference to definitions (will consult with SPRING AD (Alvaro) before making change)
Agree with Adam's DISCUSS. I had the same concerns as well.
(1) I’m surprised that there’s not even a passing reference to draft-ietf-spring-oam-usecase, given that it points to this draft in several places, among other things as “adding functionality to the use cases described by this document”. I'm not advocating for a web of references, just surprised. (2) The definition of a field with the name “Protocol” in Section 5. (Segment ID sub-TLV) got me a little confused when I went looking for a registry and found the values corresponding to the Downstream Detailed Mapping TLV (Section 6). The name is ok, but I was wondering: Can you reuse the existing registry for the values used on the Segment ID sub-TLV? If so, then the values for OSPF/ISIS would change. If not, then please have IANA set one up. (3) What happens if there’s any error (invalid length, unknown protocol, etc.) in the sub-TLVs defined in Section 5? I’m assuming that the action is specific to the TLV that contains them, or that there is something already specified in rfc8029 — please include a pointer, or specifics if needed. I see that Section 7.4. (Segment ID Check) says that other values (for Protocol) “MUST be treated as Protocol value of 0” — that’s ok for now, but when/if other values are used this document would have to be Updated. It may be better to say “any other unassigned value” (or maybe unrecognized, or something along those lines). (4) I would really like to see a registry definition for Adj. Type (in 5.3).
I share Kathleen's and Ekr's question about using this for reconnaissance.
I don't see mention of the possibility of the new LSP Ping and traceroute being used for reconnaissance. Is there a reason that i snot applicable or should it be added as a consideration? Thanks. Thanks for addressing the SecDir review: https://mailarchive.ietf.org/arch/msg/secdir/HhRollkdh9Y581j7HlQys8kP4nE
I can't emphasize strongly enough that my understanding of segment routing is neophyte-level on a good day, but I do have a question about Section 8. I'm understanding that on a network path where some network elements support segment routing while others do not, what you can measure is a ping or traceroute to the first network element that doesn't support segment routing (or is it to the last network element that does support segment routing?), but you don't have any visibility along the path beyond that - do I have that right? Assuming so ... I didn't see anything about this topic before Section 8/page 16. Perhaps it's worth mentioning whether this works earlier in the document, perhaps in the Introduction? My last point might not be in scope for this document, or even the SPRING working group, but if this is a limitation, any suggestions you could make to network operators with mixed networks (which I could imagine would be the rule, rather than the exception, as the technology is deployed) about what they can do to benefit most from this technology might be appreciated.
I share Kathleen's concern. A related issue is the trust model: this allows one endpoint to potentially learn a lot about the MPLS topology. Is that an issue?
Section 5.3 indicates that "Advertising Node Identifier" and "Receiving Node Identifier" are "4 or 6 octets." There are two issues that arise with the way this is currently specified, both of which can lead to a lack of interoperability: 1. While implementors might infer that "Protocol=1" results in a 4-byte value, and that "Protocol=2" results in a 6-byte value, it's a bit unclear what length is to be used here for "Protocol=0." 2. The descriptions for both of these fields include: "When Protocol is set to 1, then the 32 rightmost bits represent OSPF Router ID." This implies that the field is *wider* than 32 bits when Protocol=1, which leaves deep ambiguity about the circumstances under which the field is allowed to be 4 octets. I would strongly recommend that this section add clear language that unambiguously spells out how implementations are expected to select the field width for the four variable-width fields in this Sub-TLV (the two I cite above as well as the interface ID fields).
Sections 5.1, 5.2, and 5.3 define "Reserved" fields without indication of how these fields should be treated. Recommend each of these be defined to "MUST be set to 0 on send, MUST be ignored on receipt" -- this is the scheme that maximizes the ability to use them in the future. Section 5.3 sefines three values for "Adj Type": 0, 4, and 6. Please either state that all other values are and will always be an error, or create an IANA registry for this field. Section 5.3 sefines three values for "Protocol": 0, 1, and 2. Please either state that all other values are and will always be an error, or create an IANA registry for this field.
draft-ietf-grow-bgp-session-culling
draft-ietf-rtgwg-routing-types
I agree with Kathleen's comment about calling out or labeling elements likely to have privacy or security implications.
It would be good to call out the elements that are identifiers in the security considerations section as the ones that might have an impact on security and privacy. The text in 7950 is good, but just adding something to list the identifiers or state that identifiers may be of concern would be an improvement. Thanks.
Section 2:
Are these types in any particular order? If not, you might consider
alphabetizing them to make thing easier to find.
uint24
This type defines a 24-bit unsigned integer. It is used by
target="I-D.ietf-ospf-yang"/>.
There appears to be some XML damage here.
____
There are several patterns in the YANG definition that perform significant
restriction of numbers (e.g., to ensure they don't fall outside the range that
can be stored in 16 or 32 bits). In many cases, these patterns include the
ability to zero-prefix some (but not all) decimal values. For example, the
production for route-origin would allow leading zeros in "2:0100:0555" but not
in "2:04294967295:065535" (even though "2:4294967295:65535" is okay). I don't
know offhand whether it makes sense to allow leading zeros in these fields, but
I would argue that the production should be consistent in allowing or
disallowing them. This issue arises in various forms in route-target,
ipv6-route-target, route-origin, and ipv6-route-origin.
The definition of bandwidth-ieee-float32 includes the following text:
The encoding format is the external hexadecimal-significant
character sequences specified in IEEE 754 and C99. The
format is restricted to be normalized, non-negative, and
non-fraction: 0x1.hhhhhhp{+}d or 0X1.HHHHHHP{+}D
where 'h' and 'H' are hexadecimal digits, 'd' and 'D' are
integers in the range of [0..127].
Notably, this prose clearly says that values can start with "0x1" and "0X1",
but not "0x0" or "0X0" -- while the pattern production does allow 0x0, and the
examples even include values starting with 0x0. The quoted prose above should
be re-worked so it also allows values starting with 0x0 and 0X0.
draft-ietf-v6ops-unique-ipv6-prefix-per-host
Thanks for addressing my previous comments.
To me this seems approriate for BCP; I'm saying this because this was mentioned in the shepherd-write-up as it was brought up by the gen-art review. Please also consider the following comment from the gen-art review (Thanks Joel!): "The issue of status for the document (BCP vs Informational) is for the IESG to conclude. However, even if it is a BCP, as I understand the purpose, this document is intended to describe the practices to be used when a provider has decided to deploy a /64 per host. The wording that is chosen throughout the document makes it appear that the underlying decision about such a deployment is also a recommended practice." I agree that wording could be made clearer here!
Thanks for addressing my DISCUSS and COMMENTs.
Thank you for addressing the SecDir review: https://mailarchive.ietf.org/arch/msg/secdir/wWp_0vlmsz7Ss-nowjhehYImOeg
One nit: Please consider moving Benefits of unique IPv6 prefix over a unique IPv6 address from the service provider include improved subscriber isolation and enhanced subscriber management. to the first paragraph of the Abstract. I’m assuming that this explains the “needs that have arisen” in the first sentence of the Abstract, of course.
Document: draft-ietf-v6ops-unique-ipv6-prefix-per-host-07.txt
I found the discussion of the shared network medium a bit
confusing. As I understand it, the idea is that if we are
on a shared network and we have the same prefix, I might
try to send to you directly. What you want to do is make
that not happen by having each node have a separate prefix.
Correct? If so, perhaps promote this bullet, and also have
it describe the problem and why this provides a solution:
o Two devices (subscriber/hosts), both attached to the same provider
managed shared network should only be able to communicate through
the provider managed First Hop Router
It's a bit unclear to me how much you are saying that
something is current practice versus how much you are
recommending it. For instance, the abstract reads more
like what you would expect for PS.
This document outlines an approach utilising existing IPv6 protocols
to allow hosts to be assigned a unique IPv6 prefix (instead of a
unique IPv6 address from a shared IPv6 prefix). Benefits of unique
IPv6 prefix over a unique IPv6 address from the service provider
include improved subscriber isolation and enhanced subscriber
management.
But then S 4 seems to be documenting:
The IPv6 RA flags used for best common practice in IPv6 SLAAC based
Provider managed shared networks are:
The use of a unique IPv6 prefix per UE adds an additional level of
protection and efficiency as it relates to how IPv6 Neighbor
Discovery and Router Discovery processing. Since the UE has a unique
IPv6 prefix all traffic by default will be directed to the First Hop
provider router. Further, the flag combinations documented above
maximise the IPv6 configurations that are available by hosts
including the use of privacy IPv6 addressing.
It's not quite clear to me why unique prefixs are needed here if
people set L=0. Is it that people ignore L=0?
Finally, I'm a bit confused about how to read this text about the
L=0 bit in cases where I have multiple devices rather than just one
at the customer prem. Say I have a topology with a home router
and devices behind it. I.e.,
Service Provider
|
|
Customer
Router
|
+-----------+-----------+
| | |
Host 1 Host 2 Host 3
I assume what happens here is that the router gets prefix X, assigns
itself XY, and then the Hosts get XA, XB, XC, etc, a la 7278. Is that
right? If so, my question is about packets coming into the Router from
the SP, which have (say) XA. The text about the L-flag suggests that
the router should send them back to the gateway, but that's clearly
not right. What am I missing?
Radius should have an informative reference on first use.
draft-ietf-nvo3-mcast-framework
Firstly, thanks to Tianran Zhou for the OpsDir review -- please address his nits. I have an additional nit: Section 3. Multicast mechanisms in networks that use NVO3 "What makes NVO3 different from any other network is that some NVEs, especially the NVE implemented on server, ..." s/server/servers/ ?
I agree with Mirja's Discuss, but I've been watching the conversation with the TSV-ART reviewer and I'm sure the right things will happen. Thanks for putting this document together. It seems helpful.
Based on the feedback provided by the tsv-art review (Thanks Colin!) I would like to see a paragraph or short section that discusses how replication as used in section 3.2 and 3.3 can impact multicast congestion control and also provides a pointer to draft-ietf-tsvwg-ecn-encap-guidelines-09 in case ECN is supported in the NVO network which can likely be the case in data center scenarios.
draft-ietf-opsawg-service-model-explained
Please consider comments from the Routing Area Directorate review. I think this document is useful as there are many "service definitions" in the industry. As the document says, the distinction is dependent on the definer, and that is ok. This document scopes IETF's use of the term. It would help clarify the document's intent if repeated this more than the one sentence in section 6.4. As the Routing Area Directorate reviewer (Dave) noted, there are multiple places which could be improved and it is why I'm a "no objection" vs. a "yes" as these may seem small, but they do change the tone of the document, especially as this document will hopefully be used by other SDOs to understand our work, e.g.: - Section 5 on Possible causes of confusion: "The confusion arises not only because of the use of the word "service" in both cases, but also because network operators may offer both types of service to their customers." This sentence is very confusing:-) It infers confusion is caused by the operator on the use of their term for a service "but ..because network operators may offer both". But as the document itself says - service depends on the context. As Dave says, don't confuse the reader further. Just delete this sentence and say these are different types of services, it's not the use of the term "service" which is confusing:-) - Section 6.4 on MEF Architecture "Thus, it may be impractical to fit IETF service models into the MEF Forum LSO architecture." Why are you pre-judging the applicability? Dave noted this also. Suggest delete this sentence. And previous sentence - IETF's work..typically smaller offering/s/IETF's work .. is a different scope. I don't think IETF's work is a "smaller offering", it's just different. The sentence infers don't use IETF's work, use MEF Forum's if want a complete package. - And many more examples in Dave's careful review.
Please consider the comments from the rtg-dir review: https://mailarchive.ietf.org/arch/msg/opsawg/HSmtr7a1fK4LDDHYyiDhlNQ_ccU/?qid=86e48faaab41ffc8b1d3e45802b85d0b
Thanks for addressing the SecDir review: https://mailarchive.ietf.org/arch/msg/secdir/IQlNrjC7dr_J2jtdFkuidcvLTLs
draft-ietf-tcpm-cubic
I'm a confused by the fact that this draft claims to specify CUBIC, but also cites another document for CUBIC. Which is the authoritative definition? If the answer is "that other document", then some words to clarify that would be helpful. I gather CUBIC is not an acronym? If correct, why spell it in all-caps?
Some minor issues from Qin Wu's OPS DIR review needs to be taken care of (as agreed by Mirja)
I'm really glad to see this specification entering IESG Evaluation. I have a few comments, but most are editorial or (at most) about improving clarity. In this text, In a smaller BDP network where Standard TCP flows are working well, the absolute amount of the window decrease at a loss event is always smaller because of the multiplicative decrease. I got lost on "always smaller" than what - than Standard TCP? Or CUBIC? Or something else? Nit: Is "weithed" "weighted", or is it something else? In 4.7. Timeout In case of timeout, CUBIC follows the standard TCP to reduce cwnd, but sets ssthresh using beta_cubic (same as in Section 4.5). should "standard TCP" be "Standard TCP"? I wasn't watching for other occurrences of "standard TCP", but I noticed a bunch of them. In this text, CUBIC MUST employ a slow start algorithm, when the cwnd is no more than ssthresh. Among the slow start algorithms, CUBIC MAY choose the standard TCP slow start [RFC5681] in general networks, or the limited slow start [RFC3742] or hybrid slow start [HR08] for high-bandwidth and long-distance networks. is there any guidance you can give implementers about when to choose specific slow start algorithms? In 5.10. Incremental Deployment CUBIC requires only the change of TCP senders, and does not require any assistant of routers. I'm not parsing the sentence. Is it saying CUBIC requires only changes to TCP senders, and does not require any changes to routers. ? Either way, it might be worth pointing out here that no changes to TCP receivers are required, either.
conflict-review-harkins-tls-dragonfly
The TLS WG reviewed this draft a long time ago and decided they didn't want to work on it, and asked that the CFRG look at the underlying dragonfly Password Authenticated Key Exchange (PAKE). That draft was controversial, but ultimately got through the CFRG supported by a security proof. After the security proof had been completed, the TLS WG was no longer interested in this draft that uses the dragonfly PAKE. The Cipher Suite registration rules have been relaxed and with that, it's fine to publish with the ISE.