[Gen-art] Genart last call review of draft-ietf-6man-comp-rtg-hdr-05
Reviewer: Elwyn Davies Review result: Ready with Nits I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at <https://wiki.ietf.org/en/group/gen/GenArtFAQ>. Document: draft-ietf-6man-comp-rtg-hdr-05 Reviewer: Elwyn Davies Review Date: 2024-04-30 IETF LC End Date: 2024-04-29 IESG Telechat date: Not scheduled for a telechat Summary: Ready with a couple of nits. A thought occurred to me - the experiment is written as assuming that the routing will be in single managed domain. However, once the Segments Left has been reduced to zero, the CRH remains fixed and it would, in principle, be possible to send the packet out into the wider network to be routed by conventional means. I would also note that the header could also act as a back channel by sending information in SIDs with indexes greater than the intial value of segments left that are never actually used by the CRH mechanism. Major issues: None Minor issues: In the Abstract and Introduction, the abbreviation CRH is expanded to Compact Routing Header(s) but s3 and the draft headers refer to them as Compressed Routing Headers. I take Compact is the current preferred version. Nits/editorial comments: s5.1, notes at end: It would be desirable to call them Note 1 and Note 2. The comment in the 'submit the packet' bullet should refer to Note 1. Note 2 is a general note applying to the previous bullets. ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Genart last call review of draft-ietf-extra-imap-uidonly-06
Reviewer: Elwyn Davies Review result: Almost Ready I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at <https://wiki.ietf.org/en/group/gen/GenArtFAQ>. Document: draft-ietf-extra-imap-uidonly-06 Reviewer: Elwyn Davies Review Date: 2024-03-08 IETF LC End Date: 2024-03-15 IESG Telechat date: Not scheduled for a telechat Summary: The docment is almost ready for approval as an RFC. It has a number of nits, in particular there are a number of missing definite and indefinite articles. One minor issue which I have flagged is that the total suppression of the UIDNOTSTICKY response, even if the client has not enabled the UIDONLY response format, may possibly be inappropriate. Major issues: None Minor issues: s3.6: This states that "a server that advertises UIDONLY extension MUST NOT return UIDNOTSTICKY response code." Should this only be the case if the client has enabled UIDONLY? It seems to me that a client that does not use UIDONLY and indeed maybe an old client that does not implement UIDONLY might be confused or broken if it does not receive UIDNOTSTICKY responses when it was expecting them, but my knowledge of IMAP is limited so this might not be the case. Nits/editorial comments: Abstract and s1: UID is not a well-known abbreviation in the context of the RFC Editors list and needs to be expanded on first usage in the Abstract and in s1. Abstract: It would be good to mention that this proposal is experimental. s3, para 2: s/MUST return tagged BAD response/MUST return a tagged BAD response/ s3, para 4: s/The server returns UIDREQUIRED/The server returns the UIDREQUIRED/ Also this line is too long (flagged by idnits). s3, last para: s/details./detail./ s3.3, para 2: OLD: The UID is always returned at the beginning of a UIDFETCH response, and it can also appear in UID response data item, if requested by the client. While UID response data item is redundant when requested, NEW: The UID is always returned at the beginning of a UIDFETCH response, and it can also appear in the UID response data item, if requested by the client. While the UID response data item is redundant when requested, END s3.5: s/in tagged BAD response/in a tagged BAD response/ s.3.6, para 4:s/SHOULD return COPYUID response/SHOULD return the COPYUID response/ s3.6, para 5: OLD: Use of UIDNOTSTICKY response code (see [RFC4315]) is not compatible with the UIDONLY extension. I.e. a server that advertises UIDONLY extension MUST NOT return UIDNOTSTICKY response code. NEW: Use of the UIDNOTSTICKY response code (see [RFC4315]) is not compatible with the UIDONLY extension, i.e. a server that advertises the UIDONLY extension MUST NOT return UIDNOTSTICKY response code. END s3.7: s/CONDSTORE/The CONDSTORE/; s/QRESYNC/The QRESYNC/; s/such parameter/such a parameter/ s3.8: Add a reference to Section 9 of [RFC 9051] associated with "sequence-set". s3.8: s/server MUST reject/the server MUST reject/ s4: Add a note that this syntax is intended to update the Formal Syntax in Section 9 pf [RFC9051]. s4: Note that redefining SP is inappropriate as it duplicates the definition in RFC 9051. Removing this will also partially suppress a warning from idnits regarding referencing an obsolete RFC. s4, uidfetch-resp: The second line (;; The uniqueid is the UID of the corresponding) is too long (flagged by idnits) s4: I am unclear why 'capability' is explicitly extended. The definition in RFC 9051 implies that the possible values come from the IANA database and the UIDONLY attribute is added to that database by s6.1. s6/s6.1: RFC document structure prefers that all document sections contain substantive text. Currently there is no text in s6 and only one subsection - the text in s6.1 should be used for s6. ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Genart last call review of draft-ietf-netconf-ssh-client-server-37
Reviewer: Elwyn Davies
Review result: Almost Ready
I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair. Please treat these comments just
like any other last call comments.
For more information, please see the FAQ at
<https://wiki.ietf.org/en/group/gen/GenArtFAQ>.
Document: draft-ietf-netconf-ssh-client-server-37
Reviewer: Elwyn Davies
Review Date: 2024-02-14
IETF LC End Date: 2024-02-12
IESG Telechat date: 2024-02-29
Summary:Almost ready. The majority of points are editorial nits, however the
proposed mechanism for generating YANG modules to provide automated access to
certain sets of options defined in IANA registries is not explained at all in
the introduction and needs to be. I also feel that the authors need to consider
(and may have already done this) whether they should supply automation scripts
that will assist IANA in creating and checking the updated YANG modules that
they are to be asked to generate when the relevant registry entries are
updated. I have not attempted to check that the IETF YANG modules are correct
or complete as I do not have the SSH knowledge at my fingertips. I wonder if
the mechanism needs a designated expert to deal with naming queries and help
with any issues in creating the IANA YANG modules rather than passing this
burden to the NETCONF WG chair - which rather assumes the NETCONF WG will be
around for ever.
Major issues:
None
Minor issues:
General: The document contains a number of references to the NETCONF WG chairs
and the NETCONF WG mailing list. Is this adequately future proof?
General: Although this is not directly relevant to the draft, it occurs to me
that since IANA is being requested to edit YANG modules in response to registry
changes and the resulting modules would be expected to be read by protocol
implementations, it would be desirable if IANA was supplied with scripts that
could be used to automatically update the IANA modules and run the YANG checker
script to ensure the syntactical correctness of the updates. The changes
resulting from these updates should be automatically backwards compatible so
updating the modules should not be problematic. S2.1.1: The last paragraph of
this section reads:
The diagram above uses syntax that is similar to but not defined in
[RFC8340].
In that case had the syntax better be defined in this document?
Nits/editorial comments:
Abstract, para 2: I suggest s/enabling/supporting/ since the YANG modules
provide a standardised framework rather than actually providing the only way of
configuration of SSH entities.
Abstract, para 3: Similarly, s/for an IANA-maintained/providing support for an
IANA-maintained/.
Introduction, s1: This section is very bald. In particular, the introduction
is silent about the purpose of the IANA modules. It should, in the way of
convention, contain similar words to paragraphs 2 and 3 of the abstract to
explain the purpose of the document.
The section should also contain a subsection similar to s1.1 to explain the
purposes of the IANA modules and how they are created and maintained since the
draft only defines the format and not the exact contents of the YANG modules.
s1.1, para 1: s/more so than/rather than/, s/advance/extended/
s1.2, para 1: as with the Abstract s/enable/support/
Table 1: This table should have a RFC Editor note to clarify that the right
hand column needs to be updated with the references to the RFCs that will
hopefully result from the approval of the referenced I-Ds. For convenience of
readers, I hope that the keys will be of the form RFC to reduce reader
effort in working out what documents are reference.
s1.4: The jargon should be replaced by 'operational state
datastore' with a reference to Section 5.3 of RFC 8342.
s2.3:
OLD:
rpc generate-asymmetric-key-pair {
if-feature "asymmetric-key-pair-generation";
description
"Requests the device to generate an public key using
the specified key algorithm.";
NEW:
rpc generate-asymmetric-key-pair {
if-feature "asymmetric-key-pair-generation";
description
"Requests the device to generate a public key using
the specified key algorithm.";
END
ss6.3-6.6: In the 5th para of the boilerplate text in each of these 4 sections:
s/is a invalid for a YANG identity/is not a lexically valid name for a YANG
identity/
Also 4 paragraphs from the end of each section:
s/that points to the where the module was published./that points to the
document defining the registry update that resulted in this change./
Appendix A: I think the intention of the instruction to remove Appendix A
before publication only applies to the program in the header section rather
than the whole Appendix which contains the initial creations of the IANA
modules. I take it that the program will be rerun if neces
[Gen-art] Genart last call review of draft-ietf-opsawg-rfc7125-update-05
Reviewer: Elwyn Davies
Review result: Almost Ready
I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair. Please treat these comments just
like any other last call comments.
For more information, please see the FAQ at
<https://wiki.ietf.org/en/group/gen/GenArtFAQ>.
Document: draft-ietf-opsawg-rfc7125-update-??
Reviewer: Elwyn Davies
Review Date: 2023-10-27
IETF LC End Date: 2023-10-26
IESG Telechat date: 2023-11-30
Summary:
The data specification is good to go, but there are some difficulties (in my
view) with status and the nature of some text that is intended to be a data
description but actually provides normative rules for a protocol using the
data. Looking at the IPFIX IANA record, it may be worth checking that there
are not additional entries that could be vulnerable in a similar way to the
Control Flags. I also noted that there are some references to RFCs in the
record that could do with added RFC numbers.
Major issues:
Status of documents: I note that this is intended to be a standards track
document that obsoletes an informational document (RFC 7125) which in turn
updated a standards track document (RFC 5102) which has in turn been sort of
'obsoleted' by RFC 7012. Since RFC 5102 remains as a historic reference and
is mentioned in RFC 7012, I think this draft should specify that it updates RFC
7012 since someone using the IPFIX data structures etc should be aware of this.
Also I would say that this draft goes further than making RFC 7125 obsolete -
RFC 7125 should become Historic. I take it this could be specifed in this
document.
S3: In essence this document contains a data description intended to update a
part of the data description in the IANA record of "IP Flow Information Export
(IPFIX) Entities". However, the four paragraphs of Description in S3 starting
at para 4 ("As the most significant...") contain prescriptive normative
language that purports to affect the behaviour of the protocol that is
intending to use this data description (e.g., para 5 says
All TCP control bits (including those unassigned) MUST be exported
as observed in the TCP headers of the packets of this Flow. )
Is this a legitimate usage? I note that this language is (I think) the
'stronger requirement language' mentioned in s5, para 1. This issue is closely
tied to the document status issue above.
Minor issues: None
Nits/Editorial comments:
s1, para 3
OLD:
However, that update is still problematic for interoperability
because a value was deprecated since then (Section 7 of [RFC8311])
and, therefore, [RFC7125] risks to deviate from the authoritative TCP
registry [TCP-FLAGS].
NEW:
However, that update may still be problematic for interoperability
because a flag value was added prior to the release of [RFC9293] for
experimental purposes but has since been deprecated (see Section 7 of
[RFC8311]). [RFC7125] pre-dates this deprecation and explicitly mentions the
deprecated flag hence deviating from the authoritative TCP registry
[TCP-FLAGS]. Any future changes to the control flags would risk additional
deviations unless [RFC7125] were updated in the same way.
END
s4: IANA should also add a reference to this document.
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Genart last call review of draft-ietf-lamps-nf-eku-02
Reviewer: Elwyn Davies Review result: Ready with Nits I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at <https://wiki.ietf.org/en/group/gen/GenArtFAQ>. Document: draft-ietf-lamps-nf-eku-02 Reviewer: Elwyn Davies Review Date: 2023-09-10 IETF LC End Date: 2023-09-08 IESG Telechat date: 2023-09-21 Summary: Ready with a number of nits. Major issues: None Minor issues: None Nits/editorial comments: Abstract and s1: It would be useful to provide a reference to 3GPP document TS 23.501 with a pointer to Section 6 which defines what the Network Functions are both at the end of the Abstract and in the first para of s1. s1, 1st bullet: Should '5GC Service Based Architecture' be '5G Core Service Based Architecture'? s1, 2nd bullet: I suggest s/is JSON Web Tokens and is/uses JSON Web Tokens which are/ s1. para 6 after bullets: This starts > [RFC5280] specifies several extended key purpose identifiers (EKU), >defined via KeyPurposeIds, for X.509 certificates. Using the abbreviation EKU at this point is premature (it is defined in para 8) and IMO confusing. I suggest: > [RFC5280] specifies several key usage extensions, >defined via KeyPurposeIds, for X.509 certificates. Key usage extensions added to a certificate are > meant to express intent as to the purpose of the named usage, for humans and for complying libraries. s1, para 7: s/a NF who generates/a NF which generates/ [It's a function not a person.] s1, para 8: s/However, there is currently no KeyPurposeIds/However, there are currently no KeyPurposeIds/ s3, para 2: s/EKU extention/EKU extension/, s/require the keyUsage extension/require the KeyUsage extension/ s4, para after bullet 3 and s5: The abbreviation KU on its own has not been defined and is not used elsewhere: s/KU/KeyUsage/ (two places) s7: s/ The inclusion of EKU/The inclusion of the EKU/ s8, para 1: s/This OID/These OIDs/ s8: You could add references linking to the two registries referred to in this section. ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Genart last call review of draft-ietf-httpapi-yaml-mediatypes-04
Reviewer: Elwyn Davies Review result: Not Ready I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. Document: draft-ietf-httpapi-yaml-mediatypes-04 Reviewer: Elwyn Davies Review Date: 2023-04-09 IETF LC End Date: 2023-04-10 IESG Telechat date: Not scheduled for a telechat Summary: The document is not ready for approval mainly because the registry specifications are not in a form where IANA can simply cut and paste them into the resistry database. IANA have called this out during their review. Major issues: As noted in the IANA review, the text for the registry updates is not in a state where it can simply be cut and pasted into the registry entries by IANA. It contains references to sections in the document that are not in the notional registry entry section. This requires major reworking. Minor issues: The figures in the document consist of plain text and it is not easy to see where the figure text starts in the text or htmlized versions. I am not quite sure how this can best be resolved but some delineator at the start of the figure would be helpful. Maybe a YAML comment at the start of the figure text. Nits/editorial comments: General: s/e.g./e.g.,/ (6 instances) Abstract: Suggest adding "intended to be used to identify document components formatted according to the YAML Ain’t Markup Language (YAML™) specification" to te end of the abstract. s1, para 1: s/the relevant/a corresponding/, s/previously had not/had not previously/ s1, para 1: Add a reference to BCP13/RFC 6838 i.e.. [MEDIATYPE] after "suffix". s1.2, para 2: s/section1.2.1/(see Section 1.2.1)/ s1.2.1, para 2: s/while percent-encoding those characters not allowed/but percent-encoding of those characters is not allowed/ s1.2.1, first bullet: the term 'serialization detail' ought to be in the list of YAML terms in s1.1. s4.2. para 1: s/can infinite-loop traversing the YAML representation graph at some point, for example:/can result in an infinite-loop when traversing the YAML representation graph at some point, for example:/ s4.2, first bullet: s/serialize it JSON/serialize it as JSON/ s4.2, para after Fig 4: s/representaion graph/representation graph/ s4.2, para after Fig 4: Suggest: s/"billion laughs" problem/"billion laughs" or "Exponential Entity Expansion" problem/ s5: IANA has not yet updated the registries. This section should be worded as requests for IANA to perform the updates. As mentioned above, the text in sections 2.1 and 2.2 is not in a state where IANA can use it to update the registries. s6: I personally find the mix of reference tag formats for RFCs, where some use the RFC format and others are relevant text strings irritating. I would prefer for all RFC references to be named RFC. Appendix B: Acknowledgements and Authors' Addresses should be provided as sections within the body of the document rather than in an Appendix. ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Genart last call review of draft-ietf-cellar-matroska-15
Reviewer: Elwyn Davies Review result: Almost Ready I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. Document: draft-ietf-cellar-matroska-15 Reviewer: Elwyn Davies Review Date: 2023-03-02 IETF LC End Date: 2023-02-28 IESG Telechat date: Not scheduled for a telechat Summary: Almost ready. Thre is a good deal of discussion of earlir versions of the structure and associated parsers together dicussion of future proofing and potential future versions of the structure and associated parsers. I am concerned that it is not possible to automatically know which components are associated with a given version. At the least, this would assist implementers to ensure that their parsers are working on the right ietms and ignoring irrelevant items. Major issues: Versions of Matroska: According to Section 2, this document covers versions 1, 2, 3 and 4 of Matroska. The implication is that not all elements were defined in lower numbered versions but that older parsers should potentially be able to handle later versions of the format. I am unclear about this but I have a suspiscion that implementers and extenders of the format need to know which elements existed in which versions and may need to understand whether they can modify these elements in future versions. At present there is no indication which elements are defined in earlier versions and are therefore potentially not updateable. Minor issues: General: I am concerned about the long term stability of the web site referenced for the Matroska Container Format, reference [MCF]. Among other issues it is not accessed via https and it claims that it is the one true specification which is rather confusing when it is being written into a standards track RFC. s1: What is meant by the term 'old parsers'? Is this just claiming that parsers for possible future formats will be always capable of parsing old versions of the format? Nits and Editorial Comments Abstract and s1: I wonder if 'Matroska audiovisual data container structure' might be a clearer reflection of what is being described? s1: It might be more helpful if the MCF reference pointed to the descriptive introductory page of the web site (http://mukoli.free.fr/mcf/). s1, para 1: s/differentiates from it/diverges from it/ s1, para 1: s/enables/provides/ s1, 2nd bullet: s/for which/in which/ s1, para after 2nd bullet: s/features like/features such as/ s4.3: I suspect that the use and format of Hexadecimal Floating-Point Constants is not sufficiently generally understood to not require explanation in an RFC. I suggest duplicating the reference to [ISO9899] used in Section 11.1.18 of RFC 8794 would be desirable. s5: A reference to Section 11 of [RFC8794] referring to the structure of element definitions would be useful. s5.1: The details of the elements in this section are outside my competence and I haven't looked at them with any exactitude. Nothing jumped out at me. s6.1, para 2: I was unable to parse the second sentence: "In that case the Segment containing in these Chapters do no required a Track Element or a Cluster Element." s20.5.2: s/contain/contains/ s23.3.3, para 1: s/want to seek/wants to seek/; s/to have these/to access these/ s27.1: Should an Element ID registry entry contain the Matroska version at which it was introduced? s28, para 2: s/if there is no more/if there are no more/ ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Genart last call review of draft-ietf-lpwan-schc-over-sigfox-20
Reviewer: Elwyn Davies Review result: Not Ready I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. Document: draft-ietf-lpwan-schc-over-sigfox-20 Reviewer: Elwyn Davies Review Date: 2023-01-04 IETF LC End Date: 2022-12-20 IESG Telechat date: 2023-01-05 Summary: Not ready. I notice that major edits have been done to this document since the IESG reviews raised some serious Discuss points. Aside from some serious points about the scope of the profile(s) in this review and whether there are multiple profiles involved, I think that the scope of the changes made deserve working group level review to ensure that the changes are technically accurate. I apologize for the late delivery of this review. I contracted Covid during the Last Call period and it has taken me some time to recover. Major issues: s1, para 4: It should be made explicit whether the document sets out a single set of parameters, etc., forming a single profile or whether variations are available so that more than one profile is possible. The word 'recommended' implies that there could be variations. If so how would an implementation/user know which profile was in use. It has been noted elsewhere in reviews that there are several versions of the Sigfox specification mentioned on the web page which gives access to the [sigfox-spec]. Does this profile apply to all versions of the specification? If not how does a device know which profile is used with which specification? This comment reflects inpart a Comment point raised by Roman Danyliw s3.2: This section states: "Messages sent from the Device to the Network are delivered by the Sigfox network (NGW) to the Network SCHC C/D + F/R through a callback/API with the following information: * Device ID * Message Sequence Number * Message Payload * Message Timestamp * Device Geolocation (optional) * Received Signal Strength Indicator (RSSI) (optional) * Device Temperature (optional) * Device Battery Voltage (optional)" As far as I can see, the [sigfox-spec] makes no mention of how or where the timestamp, geolocation information, device temperature and battery voltage are encoded and the format used. I take it Message Counter and Message Sequence are related in some way. How? Minor issues: Header: More than 5 authors are listed. This may now have been approved. s1: Before embarking on descriptions that refer to elements of the Sigfox network infrastructure, the document should tell the reader where s/he can find a definitive description of the elements. Referring to the relevant section of RFC 8376 would be useful, but a reference to a Sigfox document with an overview of the system would be very useful. The Sigfox Radio Specifications document is at too detailed a level to cover this requirement. [Aside: I found this document very hard work!] s2: The reader is also expected to be familiar with the Sigfox terminology. s3.2, para 1: "The uplink message size is 12 bytes in size.". Firstly: Uplink messages are variable in size depending on the requested payload. The payload can be up to 12 bytes. Secondly: This is the application level size. Six bytes of header are added in the link layer together with authentication if used. Further bytes are added in the physical layer. s8.2: I think RFC8376 is normative as the terminology used there is required knowledge. Nits/editorial comments: s1, para 1: s/on top of all/in conjunction with any of/ s1, para 2: s/a great level of/a considerable degree of/ s1, para 2: s/on top of/in conjunction with/ s1, para 3: 'worldwide network': This is advertising speak. Try 'a very wide area network' s1, para 3: s/recovery of lost messages/including recovery of lost messages/ s1, para 3: a/fragmentation/reassembly/allowing for fragmentation/reassembly of messages/ s1, para 4: s/This set of parameters are also known as/The set of parameters forms/ s3, Figure 1: For certainty, it would be useful to show the direction in which Uplink and Downlink messages travel. s3.2, para 1: s/space diversity/spatial diversity/ s3.3, last para: s/Downlink request flag/A Downlink request flag/ s3.3.1, para 2: s/which is signal by a specific the Fragment Compressed Number (FCN)/which is signalled by a specific value of the Fragment Compressed Number (FCN)/ ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Genart last call review of draft-ietf-idr-bfd-subcode-04
Reviewer: Elwyn Davies Review result: Ready with Nits I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. Document: draft-ietf-idr-bfd-subcode-04 Reviewer: Elwyn Davies Review Date: 2022-11-18 IETF LC End Date: 2022-11-15 IESG Telechat date: 2022-12-01 Summary: Ready with nits. There are a number of places where additional refereences would be helpful and the introduction doesn't say what it is going to do to solve the identified problem. Major issues: None Minor issues: None Nits/editorial comments: Abstract: Please include references to the BFD protocol specification [RFC 5880]. Abstract, para 2: OLD: This document defines a Subcode for the BGP Cease NOTIFICATION message for when a BGP connection is being closed due to a BFD session going down. NEW: This document defines a Subcode for the BGP Cease NOTIFICATION message [RGC 4271, Section 6.7] for use when a BGP connection is being closed due to a BFD session going down. END S1, para 3: OLD: If a BGP speaker desires to have its connections terminate faster than the negotiated BGP Hold Timer can accommodate upon loss of connectivity with a neighbor, the BGP speakers can rely upon BFD is used to supply that faster detection. When the BFD session state changes to Down, the BGP speaker terminates the connection with a NOTIFICATION message sent to the neighbor, if possible, and then close the TCP connection for the connection. NEW: If a BGP speaker desires to have its connections terminate more quickly than the negotiated BGP Hold Timer can accommodate upon loss of connectivity with a neighbor, the BFD protocol can be relied upon by BGP speakers to detect the loss of connectivity more rapidly. When the BFD session state changes to Down, the BGP speaker terminates the connection with a Cease NOTIFICATION message sent to the neighbor, if possible, and may then close the TCP session for the connection. This document defines a subcode "BFD Down" to be sent with the Cease NOTIFICATION message that indicates the reason for this type of connection termination. ENDS s3, last para: s/it may not be possible/it may not have been possible/ s5: s/Reference of this document/reference to this document/ s5: It would be useful to provide a reference to the relevant IANA registry https://www.iana.org/assignments/bgp-parameters/bgp-parameters.xhtml#bgp-parameters-8 s7: Arguably I would say RFC 4482 should be a normative reference. ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Genart last call review of draft-ietf-opsawg-yang-vpn-service-pm-12
Reviewer: Elwyn Davies Review result: Ready with Nits I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. Document: draft-ietf-opsawg-yang-vpn-service-pm-12 Reviewer: Elwyn Davies Review Date: 2022-10-10 IETF LC End Date: 2022-10-04 IESG Telechat date: Not scheduled for a telechat Summary: Ready with a few minor nits. Apologies for the rather late delivery. Major issues: Minor issues: s4.4: The following text appears in the section on 'Percentile Parameters': Setting a percentile to 0.00 indicates the client is not interested in receiving particular percentile. Given the discussion of configurable items in Section 6 it would be helpful to mention that these items and other items marked 'rw' and with names ending in '?' can be configured rather than just saying 'Setting'. Nits/editorial comments: General: The document contains a lot of VPN terminology and network types using acronyms such as CE, PE etc. Some of these are defined in Sections 2/2.1 but a pointer to a document that defines the VPN technology (such as RFC 4026) would be helpful. s1: The abbreviations PE, CE and P are used here before their definitions in s2. I guess they had better be expanded on first use. s2.1: The references for definitions of MPLS, OWAMP and TWAMP introduced in s3 would be usefully noted here. s3, para 3: s/involved devices/devices involved/ s3.1, para 1: s/Some applications/Some applications,/ s4.1, para before Fig 4, sentence 1: s/VPN Network PM YANG module/the VPN Network PM YANG module/ s5: There are 3 instances of 'into 0.0' in the percentile definitions of augment "/nw:networks/nw:network/nt:link" that should be 'to 0.0'. ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Genart last call review of draft-ietf-cose-countersign-06
Reviewer: Elwyn Davies Review result: Ready with Issues I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. Document: draft-ietf-cose-countersign-06 Reviewer: Elwyn Davies Review Date: 2022-07-22 IETF LC End Date: 2022-08-10 IESG Telechat date: Not scheduled for a telechat Summary: Almost ready with one minor issue and several nits. I do not understand how it is decided what the count of bstr fields is which is needed to determine if the other_fields mechanism is invoked. Are all the standard fields included? And could other_fields be included in an example please? Constructing an example would be helpful for both author and users I think. Major issues: None Minor issues: s3.3, description of 'other_fields': I am confused as to which bstr's count towards the 'only two' condition. All the fields after 'context' are encoded as bstr so are all these involved in the count? Also I couldn't see an example which appeared to showcase how 'other_fields' is used. This might well have helped. Nits/editorial comments: Abstract: Idnits is thoroughly confused by the document claiming to update RFC 8152 when it is actually updating an RFC that hasn't been published yet. Given that rfc8152bis (RFC-to-be 9052) hasn't been published yet, I wonder if a note about countersigning could be added into that document. But in any case this document updates RFC 9052. General: Use of " rather than ' for quoted strings. [s1.3 (6 places), s3.3 (2 places)] s1.3: s/Byte is a synonym for octet./"Byte" is a synonym for "octet" in this document./ s1, para 3: I think this needs a little expansion: "the inclusion of more of values in the countersignature". At least s/of more of values/of the content of additional fields/ (if I understand correctly). s2, para 3: s/Details on version 2/Details of version 2/ s3, para 2: s/This is same structure/This is of the same structure/ s3.3, para 1: s/takes in countersignature/takes in the countersignature/ s5.2, last para: s/"(Deprecated by [[This Document]]"./"(Deprecated by [[This Document]])"./ [Missing closing bracket.] s7.1: For the record there seems to be some lack of clarity as to whether there are two or three different languages supported. The 'Languages' line says 3 languages but only mentions Java and C#. Further on in 'Testing', Java, C# and C are mentioned. Since this section will be removed before publication it is not of great importance but would be good to get it right. I couldn't see a C implementation in the cose-wg repository. ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Genart last call review of draft-ietf-ippm-rfc8321bis-02
Reviewer: Elwyn Davies Review result: Ready with Nits I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. Document: draft-ietf-ippm-rfc8321bis-02 Reviewer: Elwyn Davies Review Date: 2022-06-24 IETF LC End Date: 2022-06-21 IESG Telechat date: 2022-07-14 Summary: Ready with a number of nits. I found that the discussion of possible uses besides the core proposal to be somewhat distracting and perhaps detracts from the value of the basic proposal. Major issues: None. Minor issues: Nits/editorial comments: Abstract: s/It could be considered/According to the classification defined in RFC 7799, it could be considered/ s1.1, para 1:s/overtaking./building on/; s/in the original/that was based on the original/ s1.1, last para: Delete. The change log wil not be in the final document. s2, para 3: s/will have the same color/will have the same notional "color"/ s3.1, para 6: s/shows how a flow looks like when it is split in traffic blocks/shows how a flow appears when it is split into traffic blocks/ s3.1, second set of bullets: The problem is easier to solve for multicast traffic, where load-balancing is seldom used and static joins are frequently used to force traffic forwarding and replication. Is the term 'static joins' sufficiently well-known to not need a reference? s3.2.2, para1: s/statistic distribution/statistical distribution/ s3.2.2, para2: The term 'security time gap' didn't seem obvious in this section: Between packets with the second marking, there should be a security time gap to avoid out-of-order issues and also to have a number of measurement packets that are rate independent. I suggest 'adequate time gap'. s4.1, para2: s/ number of involved nodes/number of nodes involved/ s7, last para: This paragraph is not future proof. The two drafts referenced are not working group drafts and it is not clear if they will eventually become RFCs. I would be inclined to omit the paragraph or at least reduce it to just refer to the IEEE work. It could also be moved to an appendix. s8, para 2: Not an academic paper! s/We used/The mechanisms described in this document use/ s8, bullet 5: s/strictly related each other/strictly related to each other/ s8, bullet 7: Suggest replacing text with: Verification: the methodology has been tested and deployed experimentally in both lab and operational network scenarios performing packet loss and delay measurements on traffic patterns created by traffic generators together with precision test instruents and network emiulators. s8, bullet 11: Singleton whats s8, bullet 12: "currently, the main parameter of the method is" Once this becomes an RFC the parameters are set in stone - 'currently' is not a good way of describing that state. Also the bullet asks about 'parameters'. If there is just one parameter say that. If there are others they need to be described here. ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] [Drip] Genart last call review of draft-ietf-drip-rid-24
Hi, Bob. Sorry for the tardy reply. Thanks for the responses, and, yes, I think the changes clear up the nits I identified. Now good to go. Cheers, Elwyn On 16/05/2022 13:32, Robert Moskowitz wrote: Elwyn, I believe your comments are the only opens left. Does this response and the current drip-rid-26 address your points? Note that the question sec 8.1 was addressed by IANA and is reflected in -26. Thank you. Bob On 5/10/22 21:13, Robert Moskowitz wrote: On 5/10/22 12:25, Elwyn Davies via Datatracker wrote: Reviewer: Elwyn Davies Review result: Ready with Nits I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. Document: draft-ietf-drip-rid-24 Reviewer: Elwyn Davies Review Date: 2022-05-10 IETF LC End Date: 2022-05-11 IESG Telechat date: Not scheduled for a telechat Summary: Ready with nits. I can't speak for the robustness of the security choices but the document is well written apart from a couple of pieces of deep jargon that may need explanation for more naive readers (notably multilateration - definitely a new one on me!) Multilateration occurs once in the draft, sec 9.1. It is a main part of draft-moskowitz-crowd-sourced-rid where I have the definition: Multilateration: Multilateration (more completely, pseudo range multilateration) is a navigation and surveillance technique based on measurement of the times of arrival (TOAs) of energy waves (radio, acoustic, seismic, etc.) having a known propagation speed. Do you think it should be added here in the definitions section? I really don't want to pull it from 9.1, and I don't see adding this whole definition into 9.1. Multilateration is an important tool in aviation traffic management. Oh and this is fundamental to GPS. I do expect, at some point soon, that crowd-sourced-rid will become a wg draft... Major issues: None Minor issues: None Nits/editorial comments: Abstract/s1: The term 'self-asserting IPv6 address' is defined in Section 3 of the DRIP architecture. AFAICS 'self-asserting' is novel terminology, at least in this context, and I think it would be good to point to the architecture in the Abstract and to make it a little clearer that the term self-asserting (IPv6 address) is defined in the architecture - I missed that on first reading - as well as the idea of HHITs. para 2 of the Intro references Architecture, but what do you think of: This document describes the use of Hierarchical Host Identity Tags (HHITs) as self-asserting IPv6 addresses, as described in the DRIP Architecture, and thereby a trustable identifier for use as the Unmanned Aircraft System Remote Identification and tracking (UAS RID). s1, para 3: s/are updated, these/are updated, but these/ Fixed for -25 s3.2: Query: Is there are good reason for leaving the HIT/HHIT Suite ID value 4 unused? Because draft-moskowitz-hip-new-crypto has it as '5', and that draft (which will be needed for secure-nrid-c2) proposed 5 (and 6) because a dead draft used 4... I will see if I can move them all up. I do have to check with implementors to see if there are any issues that I am forgetting. s3.2, s3.4.2, s8.2 and s8.4: After the definition of the EdDSA/cSHAKE128 value '(RECOMMENDED)' is appended. What or who is this recommendation aimed at? The users of the specification or IANA in relation to TBD3? The registry doesn't seem to have scope for recording this recommendation. If it is aimed at users, I think there should be words to this effect in s3.2 and it is probably not relevant in s3.4.2. To implementors. This is a copy from 7401, and maybe it is no longer the style? From 7401: HIT Suite Four-bit ID Eight-bit encoding RESERVED 0 0x00 RSA,DSA/SHA-256 1 0x10 (REQUIRED) ECDSA/SHA-384 2 0x20 (RECOMMENDED) ECDSA_LOW/SHA-1 3 0x30 (RECOMMENDED) Can someone provide guidance on current style for me? s3.4.1.1 and s8.4: Similar question regarding '(RECOMMENDED)'. s3.4, para 2: s/As such the following updates HIP parameters./The subsections of this section document the required updates of HIP parameters./ Fixed. Thanks, I like this improved wording. s3.5.2.1, s3.5.3 and s3.5.4: I suggest adding a reference to the HITv2 archive where the prefix 2001:20::'28 is allocated (3 places). is it enough to put in 3.5.2.1 a reference to sec 6, RFC7343? For HIPv2, the Prefix is 2001:20::/28 (Section 6 of [RFC7343]). 'Info' is zero-length (i.e., not included), and OGA ID is 4-bit. s4, para 2: 'The 2022 forthcoming ...' is not future proof. S
[Gen-art] Genart last call review of draft-ietf-drip-rid-24
Reviewer: Elwyn Davies Review result: Ready with Nits I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. Document: draft-ietf-drip-rid-24 Reviewer: Elwyn Davies Review Date: 2022-05-10 IETF LC End Date: 2022-05-11 IESG Telechat date: Not scheduled for a telechat Summary: Ready with nits. I can't speak for the robustness of the security choices but the document is well written apart from a couple of pieces of deep jargon that may need explanation for more naive readers (notably multilateration - definitely a new one on me!) Major issues: None Minor issues: None Nits/editorial comments: Abstract/s1: The term 'self-asserting IPv6 address' is defined in Section 3 of the DRIP architecture. AFAICS 'self-asserting' is novel terminology, at least in this context, and I think it would be good to point to the architecture in the Abstract and to make it a little clearer that the term self-asserting (IPv6 address) is defined in the architecture - I missed that on first reading - as well as the idea of HHITs. s1, para 3: s/are updated, these/are updated, but these/ s3.2: Query: Is there are good reason for leaving the HIT/HHIT Suite ID value 4 unused? s3.2, s3.4.2, s8.2 and s8.4: After the definition of the EdDSA/cSHAKE128 value '(RECOMMENDED)' is appended. What or who is this recommendation aimed at? The users of the specification or IANA in relation to TBD3? The registry doesn't seem to have scope for recording this recommendation. If it is aimed at users, I think there should be words to this effect in s3.2 and it is probably not relevant in s3.4.2. s3.4.1.1 and s8.4: Similar question regarding '(RECOMMENDED)'. s3.4, para 2: s/As such the following updates HIP parameters./The subsections of this section document the required updates of HIP parameters./ s3.5.2.1, s3.5.3 and s3.5.4: I suggest adding a reference to the HITv2 archive where the prefix 2001:20::'28 is allocated (3 places). s4, para 2: 'The 2022 forthcoming ...' is not future proof. Suggest adding an RFC editor note to remove '2022 forthcoming' during editing. s5, para 1: s/does not intent/does not intend/ s5: The examples should be using the 'example' top level domain. s5, para 7: The phrase 'If we assume a prefix of 2001:30::/28,' is confusing. This prefix is the one the document is asking IANA to allocate for the HHITs so I suggest 'Using the allocated prefix for HHITs TBD6 [suggested value 2001:30::/28] (See Section 3.1)'. s8.1, last item: 'False?': A decision needs to be taken on what value should be here. s9.1, para 4: Is 'multilateration' sufficiently well understood to be used without explanation? App A, para 1: s/EU/The EU/ (2 places). ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Genart last call review of draft-ietf-tls-subcerts-12
Reviewer: Elwyn Davies Review result: Ready with Nits I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. Document: draft-ietf-tls-subcerts-?? Reviewer: Elwyn Davies Review Date: 2022-04-08 IETF LC End Date: 2022-04-08 IESG Telechat date: Not scheduled for a telechat Summary: Ready with nits.Just a few editrial level nits. Major issues: None Minor issues: None. Nits/editorial comments: Abstract: The exact form of the abbreviation (D)TLS is not in the set of well-known abbreviations. I assume it is supposed to mean DTLS or TLS - This ought to be expanded on first use. Abstract: s/mechanism to to/mechanism to/ s1, para 2: CA is used before its expansion in para 3. s1, next to last para: "this document proposes" Hopefully when it becomes an RFC it will do more than propose. Suggest "this document introduces". s1, next to last para: "to speak for names" sounds a bit anthropomorphic to me, but I can't think of a simple alternative word. s1, last para: s/We will refer/This document refers/ [Not an academic paper!] s3.1, 2nd bullet: s/provide are not necessary/provide is not necessary/ s4, definition of expected_cert_verify_algorithm: " Only signature algorithms allowed for use in CertificateVerify message are allowed." Does this need a reference to the place where the list of such algorithms is recorded? s4.1.1 and s4.1.2: In s4.1.1: "the client SHOULD ignore delegated credentials sent as extensions to any other certificate." I would have though this ought to be a MUST. There is an equivalent in s4.1.2. I am not sure what the client/server might do if it doesn't ignore the DC. s4.1.3, para 1: s/same way that is done/same way that it is done/ s4.2, para 1: s/We define/This docuent defines/ sS/s5.1: RFC conventions prefer not to have sections empty of text: Add something like: "The following operational consideration should be taken into consideration when using Delegated Certificates:" ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Genart last call review of draft-ietf-quic-manageability-14
Reviewer: Elwyn Davies Review result: Ready with Nits I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. Document: draft-ietf-quic-manageability-14 Reviewer: Elwyn Davies Review Date: 2022-02-07 IETF LC End Date: 2022-02-07 IESG Telechat date: Not scheduled for a telechat Summary: Ready with various nits. The text is extremely dense and I am not sufficiently close to tis work to determine whether the advice offered is entirely appropriate or accurate. Most of the nits are trivially correctable, but some thought needs to go into making the text in s3.1 fture prooof. Major issues: None Minor issues: None Nits/editorial comments: Nits: General: s/e.g. /e.g., / (6 places) s1: A note about the origin of terminology (e.g., Connection ID) is needed. Primarily RFC 9000, I take it. s1, para 3: s/This is achieved through integrity protection of the wire image/This is enforced through integrity protection of the wire image/ Figures 1 and 6: The terms 0-RTT and 1-RTT are shown as 0RTT and 1RTT in the figures. Please make consistent. s1, para 4: s/an QUIC/a QUIC/ s2.1, para 6: s/QUIC version 1 uses version/QUIC version 1 uses version number/; s/All deployed versions/Details of all deployed versions/ s2.3, para 1: In the last sentence s/the use of Alt-Svc/ the of the HTTP Alternative Services mechanism [RFC7838]/ s2.3, para 2 (and 4 other places): The abbreviation or term 5-tuple is not in the RFC Edito'r's list of abbreviations and is not used in RFC 9000. I think this term needs to be expanded (probably in the list of terms - see comment on s1). s2.4 and elsewhere: The term 'flights [of datagrams]' is not defined. I notice that the term was not defined in RFC 9000 where it is introduced originally. s2.4, para : s/detailed Figure 2/detailed in Figure 2/ s2.4, para 8: s/Figure4/(Figure 4)/, s/Figure 5/(Figure 5)/ s2.4, para 11: s/than in the Client/that is sent in the Client/ s2.4, para 13: "When the client uses 0-RTT connection resumption, the Client Initial flight can also include one or more 0-RTT packets, as shown in Figure 6." Where is this connection resumption defined? It isn't in RFC 9000 AFAICS. Maybe https://datatracker.ietf.org/doc/html/draft-kuhn-quic-0rtt-bdp-08? Please supply a suitable explanation/reference. s2.6, para 1 and s3.5, para 4: Be consistent between 5-tuple and five-tuple please. s3.1, para 2: I think the 'DNS' protocol deserves its full title DNS over Dedicated QUIC Connections. s3.1, para 2: The second sentence regarding implementations at the time of writing is not future proof. This needs to be rewritten to express that there is an expectation of multiple applications without tying it to somewhat hypothetical implementations that might or might not exist by the time this document is published as an RFC.s3.5, paa 4: s3.2, para 2: "Connection establishment can therefore be detected using heuristics similar to those used to detect TLS over TCP." Where would a reader find out what are hese heuritics? s3.4, last para: s/E.g./For example/ s3.8.2, para 8: s/i.e. /i.e., / s4.2, para 4: s/well- defined/well-defined/ s4.2, para 6: s/unnecessary/unnecessarily/ s4.2, para 10: s/Specially/In particular/ ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Genart last call review of draft-ietf-httpbis-targeted-cache-control-02
Reviewer: Elwyn Davies Review result: Ready with Nits I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. Document: draft-ietf-httpbis-targeted-cache-control-02 Reviewer: Elwyn Davies Review Date: 2021-12-23 IETF LC End Date: 2021-12-23 IESG Telechat date: Not scheduled for a telechat Summary: Ready except for a couple of nits and one possibe issue with an informational reference that is not freely accessible to readers of the future RFC. I also wondered if a little more emphasis on the potential interactions between multiple types of cache would be desirable. Major issues: Minor issues: s2.3, para 4: The infomational reference [AGE-PENALTY] is not a publically available document. This is not a vital reference and I expect that people trying to build a CDN cache system would be aware of this discussion but it would be useful to have a reference that is publically available to explain the issue. Nits/editorial comments: s2.1, para 1: A reference to the IANA page for the is desirable (https://www.iana.org/assignments/http-cache-directives/http-cache-directives.xhtml) s2.2, para 1: s/A cache that implement/A cache that implements/ s2.3, para 1: In the last sentence: In particular, a targeted cache might have longer freshness lifetimes available to it than other caches, causing it to serve responses that appear to be prematurely (or even immediately) stale to them, It needs to be adjusted to make it clear what the final 'them' refer to.. ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Genart last call review of draft-eggert-bcp45bis-06
Reviewer: Elwyn Davies Review result: Ready with Nits I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. Document: draft-eggert-bcp45bis-06 Reviewer: Elwyn Davies Review Date: 2021-10-31 IETF LC End Date: 2021-11-23 IESG Telechat date: Not scheduled for a telechat Summary: Ready with nits. The body of the document appears fine, but the Abstract doesn't provide much insight into the content of the document. Major issues: None Minor issues: None Nits/editorial comments: Abstract:, para 1: Suggest adding a sentence or two to explain what the document actually does., e.g.: s/... mailing list./...mailing list; this document provides guidance on the intended scope of discussions appropriate for the mailing list as currently envisaged while indicating certain types of postings that would be inappropriate. In neither case are the lists considered exhaustive. The mailing list is intended to operate with self-moderation overseen by member(s) of the Sergeants-at-Arms (SAA) team. This document sets out the processes by which SAAs monitoring this mailing list are appointed and removed together with their powers as regards control of posting to the list../ ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Genart last call review of draft-ietf-dnsop-dnssec-iana-cons-04
Reviewer: Elwyn Davies Review result: Ready with Nits I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. Document: draft-ietf-dnsop-dnssec-iana-cons-04 Reviewer: Elwyn Davies Review Date: 2021-09-20 IETF LC End Date: 2021-09-16 IESG Telechat date: Not scheduled for a telechat Summary: Ready with minor nits. Major issues: None Minor issues: None Nits/editorial comments: Abstract: The longer names of DS and NSEC3 should probably be included: Viz, delegation signer (DS) and authenticated denial of existence version 3 (NSEC3). ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] Genart last call review of draft-ietf-core-senml-versions-02
Apologies... Somewhere my memory has become garbled. You are quite right RFC Editor is relentlessly focused on double quotes. I obviously getting too old for this job.Cheers,ElwynOn 3 May 2021 21:25, Carsten Bormann wrote:On 2021-05-03, at 22:10, Elwyn Davies wrote: > > Hi, Carsten. > > My understanding is > > RFC editor position: use single quotes for everything. Wasn’t that way for my first 42 RFCs :-) > Standard US view apparently. US view is actually rather unanimously double quotes (outside any outer double quotes, see below). You can find various inflections points in 1812 and 1908, where people have briefly suggested other ways, but only the British have largely (but not universally) stuck with single quotes. > British position (my version): long passages, especially direct speech quotes to be enclosed in double quotes. Odd words and short phrases within sentences use single quotes. “Kids today” (says https://slate.com/human-interest/2014/10/single-quotes-or-double-quotes-its-really-quite-simple.html :-). That seems to be a recent invention (maybe Fowler mentions something similar in 1908 (*)). > Quotes within quotes alternate between double and single quotes. That is pretty much universal. > Generally ending punctuation goes inside the quote marks in literary works. That is very much US only. > Technical authoring tends to be rather freer! Or more correct, actually… https://www.dailywritingtips.com/punctuation-errors-american-and-british-quotation-marks/ Of course, the best quote marks are the German ones: »Mehr Licht!« I tend to use them in technical writing when the subject of the writing assigns specific meanings to single and double quote marks (as in the C language, for instance). For the historical accident that ASCII is, I can’t do that in RFCs yet... Grüße, Carsten (*) https://www.bartleby.com/116/406.html Scroll down to "There are single and double quotation marks”. The text is funny as it recommends double quotes in some places and then uses single quotes in the examples for that… ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] Genart last call review of draft-ietf-core-senml-versions-02
Hi, Carsten.My understanding isRFC editor position: use single quotes for everything. Standard US view apparently.British position (my version): long passages, especially direct speech quotes to be enclosed in double quotes. Odd words and short phrases within sentences use single quotes. Quotes within quotes alternate between double and single quotes. Generally ending punctuation goes inside the quote marks in literary works. Technical authoring tends to be rather freer!I may be out of date on RFC editor but I don't think so.Cheers,ElwynOn 3 May 2021 20:21, Carsten Bormann wrote:Hi Elwyn, thank you for this substantive review. We’ll get to the details soon, but I’m intrigued by this: > General: The RFC Editor preferes the US convention for quoting items using > exclusively singe quote rather than double quote marks. Last time I looked at this, I gained the impression that the RFC editor was open to a choice by the authors between British and (US) American English. I’m neither British nor US American, but I prefer the latter (specifically CMOS style, just like the RFC editor). Also, I was under the nearly life-long impression that the British like single quotes and the US Americans like double quotes (as I do) as the outer quotes. (There are also other differences; e.g., the British prefer to keep added punctuation outside the quotes, while the US convention is to tamper with the quote and put the punctuation inside, but then only for some of the punctuation… This is a place where a sane person cannot follow CMOS.) I’m probably simply misunderstanding what you are trying to tell us. (CCing gen-art, but not core/last-call) Grüße, Carsten ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Genart last call review of draft-ietf-core-senml-versions-02
Reviewer: Elwyn Davies
Review result: Almost Ready
I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair. Please treat these comments just
like any other last call comments.
For more information, please see the FAQ at
<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.
Document: draft-ietf-core-senml-versions-02
Reviewer: Elwyn Davies
Review Date: 2021-05-03
IETF LC End Date: 2021-05-03
IESG Telechat date: Not scheduled for a telechat
Summary: Almost ready. There is one issue that needs to be sorted out. This
document removes the ordering relationship between the values of version..
Section 4.4 of RFC 8428 relies on that ordering relationahip. Accordingly
there needs to be explicit new text for Section 4.4 in this document. Also the
concept of 'must understand' items is used in this document but is not
explicitly defined in RFC 8428. This needs to be fixed - which could happen in
the new version of Setion 4.4.
Major issues:
None
Minor issues:
The redefinition of version means that this document should contain an explicit
update of (at least) paragraph 3 of Section 4.4 of RFC 8428, That section
assumes that there is an ordering relationship between version field values
which is invalidated by this document.
Also the concept of 'must understand' fields is supposed to be explained in
that section as well as discussed in s2.1 of this document. That term is not
explicitly used in RFC 8428 but I take it that it is supposed to refer to field
names ending wth an underscore character ('_'). This should be fixed with a
rewrite of s4.4 of RFC 8428.
Nits/editorial comments:
General: The RFC Editor preferes the US convention for quoting items using
exclusively singe quote rather than double quote marks.
s1, para 2: I found this paragraph difficult to parse, especially the second
sentence. Here is an alternative suggestion. OLD: The traditional idea of
using a version number for evolving an interchange format presupposes a linear
progression of that format. A more likely form of evolution of SenML is the
addition of independently selectable _features_ that can be added to the base
version (version 10) in a fashion that these are mostly independent of each
other. A recipient of a SenML pack can check the features it implements against
those required by the pack, processing the pack only if all required features
are provided in the implementation. NEW: The traditional idea of using a
version number to indicate the evolution of an interchage format generally
assmes an incremental progression of the version number as the format develops
over time. However in the case of SenML it is expected that the likely
evolution mechanism will be for independently selectable capabiity _features_
to be added to the basic system indicated by 'version' 10. To support this
model, this document repurposes the single version number accompanying a pack
of SenML records so that it is interpreted as a bitmap indicating the set of
features a recipient would need to have implemented to be able to process the
pack. ENDS
s2: Personally I would have used the left shift operator rather then 2^fc but
that is a personal view.
s2,1, para 2: s/lower-most bit positions Section 3./least significant bit
positions for the base version as described in Section 3./
s2.1, para 2: s/Section 4/by the feature defined in Section 4/
s2.1, para 2: 'boutique' is slang: s/boutique/less generally applicable/
s3: s/already/effectively already/
s6: I am not we really care but are feature names case sensitve?
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Genart telechat review of draft-ietf-ace-oauth-params-13
Reviewer: Elwyn Davies Review result: Ready I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please wait for direction from your document shepherd or AD before posting a new version of the draft. For more information, please see the FAQ at <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. Document: draft-ietf-ace-oauth-params-13 Reviewer: Elwyn Davies Review Date: 2021-03-23 IETF LC End Date: 2019-12-13 IESG Telechat date: 2021-03-25 Summary: Ready for publication with the wxcption of one very minor nit. Thanks for responding to my previous review. Major issues: None Minor issues: None Nits/editorial comments: s5: This section cover current usage. s1 anticipates the specifications mught find other usages, so... OLD: The confirmation method parameters are used as follows: NEW: The confirmation method parameters are used in [I-D.ietf-ace-oauth-authz] as follows; it is anticipated that they may be used, potentially differently, in other profiles or protocols: END ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Genart telechat review of draft-ietf-ace-oscore-profile-17
Reviewer: Elwyn Davies
Review result: Ready with Nits
I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair. Please wait for direction from your
document shepherd or AD before posting a new version of the draft.
For more information, please see the FAQ at
<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.
Document: draft-ietf-ace-oscore-profile-17
Reviewer: Elwyn Davies
Review Date: 2021-03-23
IETF LC End Date: 2020-07-20
IESG Telechat date: 2021-03-25
Summary:
Ready with nits. A very great improvement on the previously reviewed version.
Thanks.
Major issues:
None
Minor issues:
Would it be useful to provide some advice on the length of salts and IDs to go
with the advice on length of nonces? There is some in s3.3 of RFC 8613 but
some other reference might be helpful, maybe placed in s3.2.1. and/or s4.
Nits/editorial comments:
General: The RFC Editor conforms rigorously to American practice and allows
only the use of double quote marks (") in the text when marking strings as
quotations and such like. The document makes extensive but not totally
consistent, use of single quotes to flag up field names and such like (e.g.,
'nonce1'). In practice these are unnecessary, but may be replaced by the RFC
Editor if left in place. Personally. I think most of them can be removed. NB
this does not affect CBOR items such as h'1645.
General: There are lots of usages of 'CBOR diagnostic notation without the tag
and value abbreviations'. An abbreviation would reduce the verbiage.
General: It is slightly confusing to have Nonce 1/N1/nonce1 and Nonce
2/N2/nonce2 used in the document. Am I right in thinking Nonce 1 and N1 are
the same with nonce1 being the name of the JSON/CBOR parameter used to carry
the value? A few words of clarrification would help.
Abstract/s1: It would be useful to introduce the name of the profile
(coap_oscore) up front. It rather sneaks out in s3.
s1, para 2: Need to expand CBOR on first use.
s2, end of para 3: s/as well/instead/? or s/as well/alternatively/.
s2, para 7 and s6, bullet 2: s/e.g. expiration./for example, expiration./
s3.1, para 3 and last para: s/reported/shown/
s3.1, Figure 2 and Figure 3: Appendix F.3 of draft-ietf-ace-oauth-authz reports
that req_aud was replaced by audence at version 19 of the document.
s3.2, second set of bullets: Need to expand HMAC and HKDF on first use (not
well-known in RFC Editor list). It would also be useful to put a pointer to
section 11.1 of RFC 8152 here to indicate the allowed HKDF algorithms.
s3.2, 2nd para after 2nd set of bullets: s/The applications needs/The
application needs/
s3.2, 3rd para after 2nd set of bullets: s/parameeter/parameter/
s3.2, 4th para after 2nd set of bullets: s/the use of CBOR web token/the use of
a CBOR web token/
s3.2.1:
OLD:
IANA "OSCORE Security Context Parameters" registry (Section 9.4), defined for
extensibility, and is specified below. NEW: IANA "OSCORE Security Context
Parameters" registry (Section 9.4), defined for extensibility, and the initial
set of parameters defined in this document is specified below. END
s3.2.1, below Figure 9: Expand CDDL.
s4.1, para 1 and s4.2, para 2: s/RECOMMENDS to use/RECOMMENDS using/
s4.1, para 1 and s4.2. para 2: s/as nonce's value/as the nonce's value/
s4.1, para 7: s/renew/update/ [renew implies the same identifiers are used -
which is already specified!]
s4.1, last para and s4.3, last para: Does /authz-info have some special meaning?
s4.3, para 1: s/ Once receiving the 2.01 (Created) response from the RS/ Once
the 2.01 (Created) response is received from the RS/
s4.3, Figure 12: I assume the Master Salt is supposed to be a CBOR indefinite
length string encoding (it doesn't say so) as it it consists of the
concatenated CBOR strings of its component byte strings. It would be strictly
correct to start it with 0x5f and end with (0x)ff I would have thought. Be that
as it may, I do not understand why the document is concerned with either CBOR
or JSON/base64 encodings of the master salt. It may be that I am missing
something, but I didn't think that the master salt was ever put in a protocol
message as such (deliberately), but only as one or two of its components such
that it could be privately constructed at both endpoints once the three
components had been shared, and was just the concatenation of the data bytes of
the 3 components rather than involving their lengths.
s6. last para: s/observation/observations/
s7, para 3: s/RS pass/RS passes/
s9: It is now usual to give the URLs for the various existing registries as
normative references.
s9.4: I am not aware that a single registry can have different
review/specfication requirements for portions of its parameter space. Is it
seriously expected that there will be significant numbers of requests for
values in this registry? My instinct would be t
Re: [Gen-art] Genart last call review of draft-ietf-idr-bgp-ls-registry-04
It appears that the data tracker has managed to truncate my review. The whole text should have beenI am the assigned Gen-ART reviewer for this draft. The General AreaReview Team (Gen-ART) reviews all IETF documents being processedby the IESG for the IETF Chair. Please treat these comments justlike any other last call comments.For more information, please see the FAQ at.Document: draft-ietf-idr-bgp-ls-registry-04Reviewer: Elwyn DaviesReview Date: 2021-03-05IETF LC End Date: 2021-03-16IESG Telechat date: Not scheduled for a telechatSummary: The document is fine except that I think it would be appropriate to give a brief explanation of the reason for the change and to clarify what are the limits of the discretion that is available to the expert if s/he decides to go outside the SHOULD in bullet of s2.1Major issues:NoneMinor issues:s2.1, bullet2: The Designated Experts SHOULD only consider requests that arise from I-Ds that have already been acceptedAt present under RFC 7752, the specifications of new items can be in any suitable archivally stable document, including those produced by other standards bodies. S2.1 talks only of IETF documents indicating that the reason for this change might be to give the IETF complete control of the standards for this technology. However the use of SHOULD indicates that the DE could conceivably consider requests arising by other means; I think it would be desirable to offer some guidance as to the limits of the DE's discretion here. Or alternatively to specify a MUST. Nits/editorial comments:S1: A brief explanation of the rationale for the change would be helpful.This has a bit more about the extent of discretionCheers,ElwynSent from my GalaxyOn 5 Mar 2021 16:27, Adrian Farrel wrote:Thanks Elwyn, > The document is fine except that I think it would be appropriate to > give a brief explanation of the reason for the change Ah, yes, erm I understand why you're interested. Of course, we don't normally explain why IANA policies are selected. There's been a fair amount of debate on the list, and the result was we arrived at wanting these policies. I'd prefer not try to summarise how/why the WG ended up like this. > and to clarify what > paths might be available to the expert if s/he decides to go outside the > SHOULD in bullet of s.1 I had a couple of rounds of discussion on this with Alvaro. That led us to move nearly every SHOULD to become a MUST, and just two remain. As well as being the pen-holder for the document, I'm also one of the DEs, so I want to be a bit careful discussing the text that governs how I'm supposed to act. My reading of this is: 2. The Designated Experts SHOULD only consider requests that arise from I-Ds that have already been accepted as Working Group documents or that are planned for progression as AD Sponsored documents in the absence of a suitably chartered Working Group. This allows consideration of other sources of requests. The alternate would be to say "The DE MAY consider requests that arise from I-Ds that have not been accepted by a working group, or other forms of documentation." That's not very helpful. But, I think the important point is that bullet 4 covers what would happen. 8. In the event that the document is a Working Group document or is AD Sponsored, and that document fails to progress to publication as an RFC, the Working Group chairs or AD SHOULD contact IANA to coordinate about marking the code points as deprecated. This is actually guidance to the WG chairs and not the DE. The point here is, I think, that the code points don't need to be marked as deprecated, but it would be good practice. It's not clear to me why chairs wouldn't want to mark such a code point as deprecated, but "MUST" seems a bit strong. > Minor issues: > s2.1, bullet2: I think this refers to the above? Cheers, Adrian ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Genart last call review of draft-ietf-idr-bgp-ls-registry-04
Reviewer: Elwyn Davies Review result: Ready with Issues I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. Document: draft-ietf-idr-bgp-ls-registry-04 Reviewer: Elwyn Davies Review Date: 2021-03-05 IETF LC End Date: 2021-03-16 IESG Telechat date: Not scheduled for a telechat Summary: The document is fine except that I think it would be appropriate to give a brief explanation of the reason for the change and to clarify what paths might be available to the expert if s/he decides to go outside the SHOULD in bullet of s.1 Major issues: None Minor issues: s2.1, bullet2: Nits/editorial comments: ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Genart last call review of draft-ietf-mpls-rfc6374-sfl-08
Reviewer: Elwyn Davies Review result: Not Ready I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. Document: draft-ietf-mpls-rfc6374-sfl-?? Reviewer: Elwyn Davies Review Date: 2021-02-02 IETF LC End Date: 2021-01-26 IESG Telechat date: Not scheduled for a telechat Summary: Not Ready. Apologies that this review is rather late, but I found this document extremely hard to work with. There appear to be a number of areas where the work is rather too much in progress rather than ready for publication as an RFC. I also found it very difficult, not just as someone who is not at all familiar with this area of work, but at a basic technical level to work out what the protocol was going to be able to achieve and whether a LSR would garner the information it appeared to need to deliver what was clamed. Part of this appeared to be due to multiple names being used for the same thing and being used with other than their natural meaning particulaly in sections 7.1 and 7,2. Major Issues: s7, What is being standardized?: > A number of methods are described. The expectation is that the MPLS > WG possibly with the assistance of the IPPM WG will select one or > maybe more than one of these methods for standardization. > I find this statement very confusing. This document is intended for standards track, so if it goes ahead as is, the three methods are standardised and implementors would be expected to provide support for all of them unless there are to be words to indicate that not all need to be supported. Is this the intention? Or is it that this document should only support the methods chosen by the MPLS working group? In the latter case, this document is definitely not ready for standardization; I assume the unused method(s) would be removed in this case. Otherwise the second sentence is speculative and should be removed. s7, Title, purpose and general method: Note that I have very limited knowledge of this area of performance measurement so there may be misunderstandings here. However, given that caveat, I did not find the document very helpful in enlightening me and a considerable amount of background reading was needed to try and determine what was going on. Firstly, I assume that this section covers the 'additional techniques' mentioned in the Abstract and described as 'more sophisticated measurements' in s1. [Perhaps common phraseology would be desirable between the two cases.] I suggest a sentence to make this clear would be desirable. Secondly, AFAICS these techniques are basically about measuring and communicating delay jitter in various ways. It might be helpful to link what is being offered here with RFC 5481 and the discussion of delay variation measurement in RFC 6374. Section 7.1 is, as I understand it, covering IPDV measurement using (in general) normal service packets rather than just specialised RFC 6374 packets and working primarily on one LSR. I assume that the technique in s7.2 is primarily a means for reporting measurements derived from s7.1 and/or s7.4, but given that actual delays are mentioned rather than inter-packet gaps, the s7.1: After the first sentence, the first paragraph talks about delay. Since the receiving LSR has no knowledge of the transmission time of each individual packet, it is not possible for the LSR to calculate actual delays without additional information - I take it that the packets are not intended to be RFC 6374 Delay Measurement Packets as these would require corresponding responses which would contravene the query interval setting and there does not appear to be a way for the LSR doing the measurements to be told the inter-packet transmission interval. Should this be written in terms of inter-packet gaps rather than delays throughout? Further, The first paragraph describes two methods of operation without saying which one should be standardised or AFAICS providing a selection flag to allow either to be used. It seems to me that an outline of how this facility might be used is pretty much essential. Would I be right in thinking that to measure the delay jitter between a source LSR (S) and destination LSR (D), the operator decides to send a set of packets at equally spaced intervals from S to D and decides on the interval and the number of packets. S then issues a Query setting the query interval to a time greater than that needed to send the set of packets and using the Bucket Jitter Measurement Message to set the bucket delay intervals around the sending interval according to the Operator's expectations of the network. D then sets up to measure the inter-packet delays up until the next Bucket Jitter Measurement mes
[Gen-art] Genart last call review of draft-ietf-roll-unaware-leaves-24
Reviewer: Elwyn Davies Review result: Almost Ready I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. Document: draft-ietf-roll-unaware-leaves-24 Reviewer: Elwyn Davies Review Date: 2020-12-13 IETF LC End Date: 2020-12-09 IESG Telechat date: 2020-12-17 Summary: The document is almost ready for publication. As mentioned elsewhere in reviews it is a very dense document requesting updates of several standards and as such it is a difficult read and I would not be totally sure that everything is consistent. However, I did find s9 and s10 to be pretty clear. There are a few minor issues that need resolving IMO. Most are trivial but the connection to EFFICIENT-NPDAO needs fixing - both these documents are in draft and specifying alterations or updates to a document still in draft doesn't seem sensible. Apologies for rather late delivery of this review - it took longer than expected. Major issues: None Minor issues: s6.1, para 2: I found this paragraph difficult to parse. I note also that nowhere in the document is the implementor told to set the F flag to 1 (there is one place in s9.2.2 where it has to be forced to 0). Presumably there should be an instruction somewhere in s9.2.1 that there should be a Target Option with the F flag set. I would suggest alternative text for this para as follows: OLD: The new 'F' flag is set to 1 to indicate that the Target Prefix field contains the IPv6 address of the advertising node, in which case the length of the Target Prefix field is 128 bits regardless of the value of the Prefix Length field. If the 'F' flag is set to 0, the Target Prefix field MUST be aligned to the next byte boundary after the size (expressed in bits) indicated by the Prefix Length field. Padding bits are reserved and set to 0 per section 6.7.7 of [RFC6550]. NEW: The added 'F' flag is set to 1 to indicate that the Target Prefix field contains the IPv6 address of the advertising node and will, accordingly, have the Prefix Length set to 128. The length of the Target Prefix field will be an integral number of octets, TPL, which is the smallest integer such that (TPL * 8) is greater than or equal to Prefix Length. The Target Prefix is left (high bit) justified in the field and any additional bits in the rightmost octet will be filled with padding bits. Padding bits are reserved and set to 0 as specified in section 6.7.7 of [RFC6550]. ENDS s6.2, position of P flag: As a matter of interest why is the flag in position 1 and not position 0 or 4? It might be more helpful in the event of further additional functionality being added to have 3 spare bits together if the position is of no consequence. s6.3, next to last para. s8 and s 12.2: In view of the statement in s6.3: The RPL Root MUST set the 'E' flag to 1 for all rejection and unknown status codes. The status codes in the 1-10 range [RFC8505] are all considered rejections. I think that IANA should be requested to add a column to the EARO status codes registry being modified by s12.2 to add a column that identifies a status code as a rejection or otherwise. Some words in s8 may be appropriate. s7: Given that [EFFICIENT-NPDAO] is still a draft, I think this section should be synchronized with the draft so that we don't end up with one or the other new RFC updating an RFC that doesn't yet exist. s14: Idnits notes that there is a normative reference to RFC 7102 which is informational. I note that this was not mentioned in the Last Call. However RFC 7102 has already had one accepted Downref waiver and the summary of terms is a suitable use case. Nits/editorial comments: General: s/byte/octet/g Abstract: Expand RPL on first use (currently done in s1.) Expand ND. Abstract: Idnits produces a spurious warning about RFC 8505... -- The draft header indicates that this document updates RFC8505, but the abstract doesn't seem to directly say this. It does mention RFC8505 though, so this could be OK. The abstract says This specification updates RFC6550, RFC6775, and RFC8505, which is fine by me. I will report this to the Tools team. s1, s2.2, s2.3: The term defined in [USEofRPLinfo] is RPL-Unaware-Leaf rather than RPL-Unaware Leaf: s/RPL-Unaware Leaf/RPL-Unaware Leaf/ (3 places). Similarly s/RPL-Aware Leaf/RPL-Aware-Leaf/ (1 place) and s/RPL-Aware Node/RPL-Aware-node/ (2 places). s2.3, para 3: > > The term RPL-Aware Node (RAN) is introduced to refer to a node that is either an RAL or a RPL Router. This term is already defined in [USEofRPLinfo] with, I understand, the same meaning. s3, para 1: s/detailed/summarized/ - the formal details are in [USEofRPLinfo]. s3, para 3: Add MOP to glossary. s3. para 4: s/to transport a RPL Packet Info
[Gen-art] Genart last call review of draft-ietf-emu-eaptlscert-05
Reviewer: Elwyn Davies Review result: Ready with Nits I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. Document: draft-ietf-emu-eaptlscert-05 Reviewer: Elwyn Davies Review Date: 2020-10-24 IETF LC End Date: 2020-10-28 IESG Telechat date: Not scheduled for a telechat Summary: Ready with nits. There are quite a number of references to associated work that is still in progress as drafts. Whilst this is unlikely to compromise the content of this work, it will potentially delay its publication. In particular I have suggested rewriting s4.2.7 to omit more speculative references to incomplete work in favour of a general recommendation to make use of relevant new proposals as they become available. Major Issues: None Minor Issues: None Nits and Editoral Issues: General: RFC 2119 key words: In the document there are two MUSTs and a SHOULD NOT none of which are appropriate usages in my opinion (see notes below), aside from the intended infromational status. The RFC 2119 etc boilerplate in s2 could be omitted. Abstract: Need to expand EAP-TLS and EAP on first occurrence. s1, end of para 2: Suggest s/involves significantly more octets/involves exchange of significantly more octets/ s2, definition of EAP server: Where would a reader find a definition of "backend authentication"? Uncle Google was singularly unhelpful. s3, last para: clarify the meaning of kB: suggest s/~ 60kB/approximately 60 kbytes/ (I assume). s4: The usage of the form " we look/discuss/etc." typically used in academic papers is not appropriate for standards documents. Section 4 needs to be redrafted to eliminate this usage. The following may be appropriate: OLD: This section discusses some possible alternatives for overcoming the challenge of large certificates and long certificate chains in EAP- TLS authentication. In Section 4.1 we look at recommendations that require an update of the certificates or certificate chains that are used for EAP-TLS authentication without requiring changes to the existing EAP-TLS code base. We also provide some guidelines when issuing certificates for use with EAP-TLS. In Section 4.2 we look at recommendations that rely on updates to the EAP-TLS implementations which can be deployed with existing certificates. In Section 4.3 we shortly discuss the solution to update or reconfigure authenticator which can be deployed without changes to existing certificates or EAP-TLS code. NEW: This section discusses some possible alternatives for overcoming the challenge of large certificates and long certificate chains in EAP- TLS authentication. Section 4.1 considers recommendations that require an update of the certificates or certificate chains that are used for EAP-TLS authentication without requiring changes to the existing EAP-TLS code base. The section also provides some guidelines that ahould be followed when issuing certificates for use with EAP-TLS. Section 4.2 considers recommendations that rely on updates to the EAP-TLS implementations which can be deployed with existing certificates. Finally Section 4.3 briefly discusses what could be done to update or reconfigure authenticators where it is infeasible to replace deployed components giving a solution can be deployed without changes to existing certificates or EAP-TLS code. ENDS s4.1.1, para 1: s/is as follows/are as follows/ s4.1.1, para 2 (1st bullet): s/Object Identifiers (OIDs) is ASN.1/The Object Identifier (OID) is an ASN.1/ s4.1.1, para 3 (1st bullet): Need to expand DER. Also useful to add reference to RFC5280 after X.509. s4.1.1, para 4 (1st sub-bullet n 1st bullet) 'vs' needs to be expanded - either 'versus' or (Better) 'as against'. s4.1.3, para 1: The use of capitalized SHOULD NOT here is, I think, inappropriate. This is an operational recommendation rather than a protocol requirement, so s/SHOULD NOT/should not/. s4.2.2, para 1: s/useful when, for example, when/useful when, for example,/ s4.2.4: s/can define dictionary of/can define a dictionary of/ s4.2.5: s/For a client that has all intermediates,/For a client that has all intermediate certificates in the certificate chain/ s4.2.5: The second sentence of this section needs to be rewritten as if draft-thomson-tls-sic is already an RFC. s4.2.7: This section is not 'future proof'. It should be rewritten omitting the explicit examples but exhorting implementors and operatirs to consider relevant future developments. s4.3, para 1: The second and third sentences don't read well.Suggest: OLD: Another second reason is that unlimited communication from an unauthenticated device as EAP could otherwise be use for bulk data transfer. A third reason is to prevent denial-of-s
[Gen-art] Genart last call review of draft-ietf-dnsop-dns-zone-digest-09
Reviewer: Elwyn Davies Review result: Ready with Nits I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. Document: draft-ietf-dnsop-dns-zone-digest-09 Reviewer: Elwyn Davies Review Date: 2020-09-12 IETF LC End Date: 2020-09-14 IESG Telechat date: Not scheduled for a telechat Summary: Ready with few nits. Major issues: None Minor issues: s3.3: The Nits/editorial comments: ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Genart last call review of draft-ietf-ace-oscore-profile-11
Reviewer: Elwyn Davies Review result: Almost Ready I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. Document: draft-ietf-ace-oscore-profile-11 Reviewer: Elwyn Davies Review Date: 2020-07-21 IETF LC End Date: 2020-07-20 IESG Telechat date: Not scheduled for a telechat Summary: Almost ready. There is one minor issue that needs sorting out and a fair number of nits. Overall I have to say that I found it difficult to keep clear in my mind what messages were fully encrypted and which ones were sent en clair and which are in some intermediate class. The authors might wish to go back over the document from the point of a naive reader to ensure that it is clear for implementers. Major issues: None Minor issues: s2, para 5: Where does the 'input salt' come from? The term is not used anywhere else in this document and isn't defined or mentioned in either dreft-ace-oauth-authz or RFC 8613. Nits/editorial comments: s1: Need to expand CoAP on first use. s1: Need to expand CBOR on first use. s1.2, CDDL: It would useful to mention that the predefined type names from CDDL, especially bstr for byte strings and tstr for text strings, are used extensively in the document. s2, para 1: s/overview on how/overview of how/ s2, para 1: s/as well as OSCORE setup/as well as the OSCORE setup/ s2, para 2: s/that's/that is/ s2, para 8: Need to expand AEAD on first use. s2 and Figure 1: It would be helpful to the reader if Figure 1 and its descriptive paragraph was placed closer to the beginning of s2. Otherwise things like Client C' need more explanation to point the reader at the figure. s2, para 3: This says: To determine the AS in charge of a resource hosted at the RS, the client C MAY send an initial Unauthorized Resource Request message to the RS. The RS then denies the request and sends the address of its AS back to the client C as specified in section 5.1 of [I-D.ietf-ace-oauth-authz]. The access token request and response MUST be confidentiality-protected and ensure authenticity I found the combination of the Unauthorized Requst and the confidentiality-protected etc confusing. If the last sentence does apply to the Unuthorized Request it would be helpful to make it clear that this is not just a generic statement but does apply to the Unauthorized Request as well. Figure1: For consistency the first line should say Unauthorized Rsource Request. I would also suggest explaining the mapping between what is said in the text and the terms 'Ceation Hints' and 'Access Information' used in the figure. s3.1, para after Figure 2: The term 'audience' appears in this paragraph without any context indicating what it means . Later in s3.2 it appears that audience is associated with CBOR web tokens (RFC 8392). But it may also might also be realted to draft-oauth-token exchange. The appropriate reference ahould be added and should be explained in s3.1. Figure 3: Should IdContext be ContextId? ContextId is used evrywhere else. s3.2: Expand HKDF on first use ( in second set of bullets). s3.2, para after 2nd set of bullets: I think the four instances of 'may' ought to be 'MAY'. s3.2.1: It would be helpful to provide references to the online versions of the IANA registries (3 places). s4.2, para 1: A foward reference to s5 where the comunication mechanisms needed for introspection are described. s4.1, para 2: s/from what described/from what is described/ s4.2, para 5: s/that's/that is/ s4.2, last para; s/This simplifies for the RS track/This simplies the process needed by the RS to keep track/ s8, para 6: s/tasked of/tasked with/ s9.3: I don't think the Value Type for nonce is 'IESG'! lol ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Genart last call review of draft-ietf-dots-use-cases-23
Reviewer: Elwyn Davies Review result: Ready with Nits I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. Document: draft-ietf-dots-use-cases-23 Reviewer: Elwyn Davies Review Date: 2020-06-10 IETF LC End Date: 2020-06-11 IESG Telechat date: Not scheduled for a telechat Summary: Ready wih some minor nits. Major issues: None Minor issues: None Nits/editorial comments: s1, para 1: Just a thought: might be worth adding to the end of this para: "and increase the time for deployment in a situation where speed is often of the essence". s1, last para: Suggest adding in reference to DOTS requirements doc which is referred to in s2: OLD: This document provides sample use cases that provided input for the design of the DOTS protocols [RFC8782][RFC8783]. NEW This document provides sample use cases that motivated the requirements for the DOTS protocols [RFC8612] and provided input for the design of those protocols [RFC8782][RFC8783]. ENDS s2: For more logical ordering, move the definition of DDos Mitigation Service Provider after definition of DDoS Mitigation Service. s2, DDoS Mitigation Service: OLD: Service subscriptions usually involve Service Level Agreement (SLA) that have to be met. NEW: Each service subscription usually involves a Service Level Agreement (SLA) that has to be met. ENDS s3.1, para 1: The abbreviation ITP has already been defined so you shouldn't have a redefinition here. s3.1, para 7: s/thought different/though different/ s3.1, 2nd set of bullets, that are below Fig 1: This woud be more elegant using (a), (b), etc as the bullet labels. s3.1: Comment (not being familiar with the DOTS proposals): The text indicates that the ITP mitigation effort is an all or nothing buisness. Is this always the case or could the client request or the server provide a proportional response rather than an all or nothing response? s3.2, last sentence of 2nd para after Fig 2: s/These exact/The exact/ s3.3, para 2: s/various information/various sets of information/ s3.3, para after Figure 4: s/monitor various network traffic/monitor various aspects of the network traffic/. s3.3, 2nd para after Figure 4: s/it's/it is/ s3.3, last five paras: Calling out a web interface specifically is overly specific. Suggest adding 'for example'in at least one case or changing it to 'user interface'. s3.3, first para on page 11: OLD: to infer the DDoS Mitigation to elaborate and coordinate. NEW: to infer, elaborate and coordinate the appropriate DDoS Mitigation. ENDS s3.3, 3rd and subsequent paras on page 11: The orchestrator appears to change from one DOTS server to a plurality at this point. Please make it clear whether there is one or many. If only one, then s/The orchestrator DOTS servers returns this information back/The orchestrator DOTS server returns this information/ and s/servers/server/ subsequently. s3.3, last para s/like requesting/such as requesting/ s7: This is an informational document and, as such, cannot have normative references. Please combine all references into one refererences section. ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] Genart last call review of draft-ietf-ospf-mpls-elc-13
Hi, Peter. In the light of some of your responses here, I would just like to clarify that one of the reasons for gen-art reviews is to try and make extremely complicated technical documents more accessible for those who are not as deeply embedded in the jargon and technicalities of the subject as well as making sure that readers can quickly determine whether a document is relevant to work that they are doing. Please take this into account when considering your further actions. Note that the optionality of ERLD-MSD advertisements appears on reflection to be a more serious issue than just an editorial nit. Regards, Elwyn On 07/05/2020 08:53, Peter Psenak wrote: Hi Elwyn, please see inline: On 06/05/2020 16:25, Elwyn Davies via Datatracker wrote: Reviewer: Elwyn Davies Review result: Ready with Nits I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. Document: draft-ietf-ospf-mpls-elc-13 Reviewer: Elwyn Davies Review Date: 2020-05-06 IETF LC End Date: 2020-05-05 IESG Telechat date: 2020-05-21 Summary: Ready with nits. Aside: I have to say that the convolutions and cross-referencing of doing the OSPF and IS-IS extensions plus BGP-LS added to the cross-linking with MPLS is leading to mind-blowing complexity. Sooner or later something is going to blow up here! Major issues: None Minor issues: None Nits/editorial comments: Abstract and title : The application to BGP-LS (s5) is not mentioned in the abstract or the title. Also the first use of BGP-LS needs to be expanded. Why would the BGP-LS need to be mentioned in the abstract? At present BGP-LS is the subject of a separate document and this document extends the BGP add-on called BGP-LS as well as OSPF v2 and v3. It is therefor important that implementers of BGP-LS can easily find documents that are relevant to their work. I have expanded the first use of BGP-LS Abstract: s/tunnel/LSP/ done s1: Suggest s/SR-MPLS/Segment Routing with the MPLS Data Plane/ s1: Query: As a non-expert in this area, I was wondering if the signalling capability is or will be implemented in IS-IS? A brief comment on the status wrt IS-IS would be helpful. [It turns out that you already reference the document that implements this later in this draft.] yes, it is being added to ISIS. Yes, this draft reference the ISIS draft. I see no reason to to include ISIS draft status in this document though. As has been mentioned in other reviews of this document and the corresponding IS-IS document, having two documents that cover this extension is not very desirable. As a non-expert, but who knows that OSPF and IS-IS provide closely related functionality, one gets to this point in the document and wonders why OSPF and not IS-IS. If the WG does not bite the bullet and combine the drafts, it would be highly desirable to point out that the same functionality is being proposed for all three protocols s1, last sentence: s/it's/it is/ done s3: It would be a good idea to expand 'prefix' to 'address prefix advertisement' on its first occurrence here. Thereafter 'prefix' is fine by me. "prefix" is being used in almost all OSPF and ISIS document, we never use address prefix. Really? Revisiting RFC 2328 (OSPFv2) we see that prefix is not used at all and in RFC 5340 (OSPF for IPv6) the term prefix is introduced as 'IP address prefix'. In order to make it clear of what this is a prefix, and what is going on here, expanding the initial usage is highly desirable. s3, para 3: Why would a router not advertise the ELC with all prefixes? Can you say why this ought not to be a MUST. advertising ELC property with prefix advertisement is optional. We can not mandate it. It would make all routers not advertising this data violating this spec. Er, no. Nothing is said or would be said about routers that do not support ELC at all or do not support it on all interfaces. I am assuming that it is not intended to make implementation of this capability mandatory in all OSPF deployments. I was trying to understand why a router that satisfies the previous condition so that it is legitimate for it to announce ELC with any IP address prefix might wish to only announce it with some prefixes and not others. This is an interesting question for implementers as the SHOULD implies that an implementation has to provide a configuration option on a per prefix basis s4, para 3: In that case, what does the absence signify? Should we care? the absence of ERLD-MSD advertisements only indicates that a node does not support advertisement of ERLD It can not be interpreted that ERLD is not supported. Old nodes that do not advert
[Gen-art] Genart last call review of draft-ietf-ospf-mpls-elc-13
Reviewer: Elwyn Davies Review result: Ready with Nits I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. Document: draft-ietf-ospf-mpls-elc-13 Reviewer: Elwyn Davies Review Date: 2020-05-06 IETF LC End Date: 2020-05-05 IESG Telechat date: 2020-05-21 Summary: Ready with nits. Aside: I have to say that the convolutions and cross-referencing of doing the OSPF and IS-IS extensions plus BGP-LS added to the cross-linking with MPLS is leading to mind-blowing complexity. Sooner or later something is going to blow up here! Major issues: None Minor issues: None Nits/editorial comments: Abstract and title : The application to BGP-LS (s5) is not mentioned in the abstract or the title. Also the first use of BGP-LS needs to be expanded. Abstract: s/tunnel/LSP/ s1: Suggest s/SR-MPLS/Segment Routing with the MPLS Data Plane/ s1: Query: As a non-expert in this area, I was wondering if the signalling capability is or will be implemented in IS-IS? A brief comment on the status wrt IS-IS would be helpful. [It turns out that you already reference the document that implements this later in this draft.] s1, last sentence: s/it's/it is/ s3: It would be a good idea to expand 'prefix' to 'address prefix advertisement' on its first occurrence here. Thereafter 'prefix' is fine by me. s3, para 3: Why would a router not advertise the ELC with all prefixes? Can you say why this ought not to be a MUST. s4, para 3: In that case, what does the absence signify? Should we care? s4, para 4: This needs a correction and a reference to where the Link MSD Sub-TLV is defined. As a matter of interest, is there any reason why this should be sent in an OSPF context? If not why not just prohibit sending it? If it is received should it provoke an error rather than being ignored? OLD: When the ERLD MSD-Type is received in the OSPFv2 or OSPFv3 Link MSD Sub-TLV, it MUST be ignored. NEW: When the ERLD-MSD type is received in the OSPFv2 or OSPFv3 Link MSD Sub-TLV [RFC8476], it MUST be ignored. ENDS s5: This section needs to be rewritten to be 'future proof' rather than referring to the temporary allocations. A note about the temporary allocations can be added with a RFC Editor note requesting its removal on final publication. ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Genart last call review of draft-ietf-alto-incr-update-sse-20
Reviewer: Elwyn Davies Review result: Almost Ready I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. Document: draft-ietf-alto-incr-update-sse-20 Reviewer: Elwyn Davies Review Date: 2020-03-09 IETF LC End Date: 2020-03-06 IESG Telechat date: 2020-03-12 Summary: Almost ready. There are a few editorial issues, but I am not sure that Major issues: I am unsure whether this mechanism is proof against loss of messages or reordering of messags. Although there are state tags, it does not appear to have any way to ensure that the state to which the updates will be applied in the client are identical to the state that the updates were generated from. If I am wrong, it would be useful (IMO) to explain how the proposal avoids getting updates that don't apply to the state in the client. Minor issues: Nits/editorial comments: Abstract: the abstract is too long; I would suggest deleting the second sentence of the first paragraph and the whole of the second paragraph. Ths would leave sufficient information to explain what the document proposes but omits the rationale which is not necessary for outlining the contents. The deleted text would be usefully incorporated into s1. Abstract, para 3: s/s ction/section/ s1: The key role of Server-Sent Events in this proposal is not introduced here (and isn't mentioned in the Abstract). In the process SSE needs to be expanded on first use (currently right at the end of the section) and a pointer to the document that defines SSE [SSE] s1, last para: The reference to Section 13 should come right at the end - and the last two sections are (no longer) the last sectons: s/last two sections/Sections 11 and 12/ s2 et seq: I am unsure of the rationale for defining a set of special terms and not capitalizing them on every occurrence. s2: There is quite a lot of terminology imported from RFC 7285 . This should be mentioned. s3: A pointer to the SSE document would be useful [SSE]. s3.4: It would be better to use the expanded form of SSE in the first paragraph rather than waiting till the 2nd para. s4: An explanation in advance of the format of the lines delineated by ** ** would be desirable. s5.1, next to last para: s/ So there is no ambiguous decoding/ So there is no ambiguity when decoding/ s5.1, last para: s/id/data-id/ s6.3, last para: s/will uses/will use/ s6,5, "incremental changes": s/Section Section6.3/Section 6.3/ s6.5, "remove": Stating that the client SHOULD ignore this if it present is potentially problematic. If it is there it is a syntax error - should the message be ignored and potentailly flagged as an error? s7.6, last para: s/our modular/the modular/ s13/s13.1:Empty sections are not desirable Please combine the two titles and remove s13.1 . ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Genart last call review of draft-ietf-6lo-backbone-router-14
Reviewer: Elwyn Davies Review result: Ready with Nits I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. Document: draft-ietf-6lo-backbone-router-14 Reviewer: Elwyn Davies Review Date: 2020-02-06 IETF LC End Date: 2020-02-06 IESG Telechat date: Not scheduled for a telechat Summary: Ready with nits. Major issues: None Minor issues: None Nits/editorial comments: General: s/i.e. /i.e., / (4 places), s/e.g. /e.g.,/ (2 places) Abbreviations: The definition of abbreviations in this document is inconistent. There is a list of abbreviations but it is not complete; many abbreviations are introduced in the text in the usual way and there are some that are not expanded. Please be consistent - a complete list would be helpful, especially as some are used before the abbreviations section. References to Neighbor Solicitation/Advertisement messages: The formats NS() and NA() are used to refer to various NS/NA messages. Please add an explanation of this convention and a definition of the various messages referred to. Use of Layer-2 and Layer-3: These terms are not normally hyphenated. s1: Term STA used for a 'node': Please expand this abbreviation and possibly explain why it is used (I am unclear how it is derived). s1, para 5: s/Like/In the same way as/ s1, para 5: ID is not a well-known abbreviation - please expand on first use. s1, para 9: Need to expand MAC. s2.2, "Sleeping Proxy": It might be useful to add in " which might be in a sleep state in a low power network". s2.2, "Routing Proxy": Need to expand TLLA. s3, para 1: s/The next/The following/ s3, 2nd set of bullets, bullet #2: s/This includes participating to the solicited-node multicast address/This includes responding to messages addressed tothe solicited-node multicast address/ s3, 2nd set of bullets, bullet #3: Expand NUD on first use (currently expanded twice in sss6 and 8). s3.1: Expand SLLAO on first use. s3.3, para at bottom of page 13 just before Figure 5: s/is a transmitted as a multicast/is transmitted as a multicast / s3.3, last para: s/suggests using RPL/suggests using the RPL routing protocol/ s3.4, last para: s/details/detail/ s3.5, para 1: s/as silently ignored./are silently ignored./ s4, last para: s/the MTU MUST have a same value/the MTU MUST have the same value/ s5, para 2: s/It results that a 6LBR MUST be capable of maintaining a state/Consequently a 6LBR MUST be capable of maintaining state/ s5, para 3: s/ which may be avoided of/ which may be avoided if/ s5, para 5: Expand TLLAO on first use. s9: It would be useful to add a forward ref to s12 where the value of TENTATIVE_DURATION is defined. s9.1: Remove empty second bullet. Titles of ss9.1, 9.2 and 9.3: I Think these should be "Operations on" s9.2, 1st bullet: s/small timer/timer with a short setting/. Is it possible to recommend any values here or indicate how to assign a suitable value? ss9.2, 9.3: It would be useful to add a forward ref to s12 where the value of STALE_DURATION is defined. ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Genart last call review of draft-ietf-ace-oauth-params-06
Reviewer: Elwyn Davies Review result: Not Ready I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. Document: draft-ietf-ace-oauth-params-06 Reviewer: Elwyn Davies Review Date: 2019-12-14 IETF LC End Date: 2019-12-13 IESG Telechat date: Not scheduled for a telechat I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at <">https://trac.ietf.org/trac/gen/wiki/GenArtfaq>;. Document: draft-ietf-ace-oauth-params-06 Reviewer: Elwyn Davies Review Date: 2019/12/14 IETF LC End Date: 2019/2/13 IESG Telechat date: (if known) N/A Summary: Not ready. In particular there seems to be some doubt as to whether the definitions in this document are actually stable - or alternatively that it lacks a versioning mechanism to cope with changes that the might be. Major issues: Dealing with possible updates to items defined here: In s1 the following appears: These parameters and claims can also be used in other contexts, and may need to be updated to align them with ongoing OAuth work. Therefore, these parameters and claims have been put into a dedicated document, to facilitate their use and any potential updates in a manner independent of [I-D.ietf-ace-oauth-authz]. I am unclear whether this implies that it is intended that these potential updates would alter the definitions here after they have been standardized or alternatively that the standardization of this document should be delayed until the alternative usage is defined. If the first case applies, I do not see any versioning mechanism that would allow early implementations to cope with later updates of the items defined here. In the second case, I have to ask myself why this document has been submitted for standardization before the usages have stabilized. Minor issues: ss3.1, 3.2 and 4.1: The COSE_Key type 'EC' used in several kty fields is not defined. I assume it should be 'EC2'. ss3.1, 3.2 and 4.1: Does it matter that the definitions of the x and y parameters in an EC2 key are given as 'h' encodings in RFC8152 but are given as 'b64' in this document? I am very much not an expert here. s6: This section starts with 'If CBOR is used...': The main ACE draft draft-ietf-ace-oauth-authz is apparently intended to cover both JSON and CBOR encodings of payloads, although CBOR is recommended. This is not made explicit in this addition to that specification and the use of CBOR diagnostic representation and the prominence of COSE_Key items could make it appear up until s6 that this specification is intended just for CBOR encoding. A few words at the beginning would clarify the dual alternatives. Nits/editorial comments: General: s/e.g./e.g.,/ (3 places) Abstract, 2nd sentence: s/whishes/wishes/ Abstract: Need to expand AS and RS. s2: RS, AS and (probably) various other terms are defined in RFC 6749 and need to be expanded on first use. Adding something like the para from draft-ietf-ace-oauth-authz would solve this (except for the abstract). Terminology for entities in the architecture is defined in OAuth 2.0 [RFC6749] such as client (C), resource server (RS), and authorization server (AS).s2, para 3: Need to expand CoAP on first use. s3: This section needs a reference to RFC 8152 for the specification of the CWT COSE_Key item that is used extensively. s3/s4: Some introductory text for each section is desirable. s3.1, para 2 (definition of req_cnf):: Possibly add a note that the recommendation against symmetric keys implies currently kty being 'Symmetric'. Will it ever be anything else? s3.1: The text in s3.2 of draft-ietf-ace-cwt-proof-of-possession-03 contans the following The COSE_Key MUST contain the required key members for a COSE_Key of that key type and MAY contain other COSE_Key members, including the "kid" (Key ID) member. The "COSE_Key" member MAY also be used for a COSE_Key representing a symmetric key, provided that the CWT is encrypted so that the key is not revealed to unintended parties. The means of encrypting a CWT is explained in [RFC8392]. If the CWT is not encrypted, the symmetric key MUST be encrypted as described in Section 3.3. These riders probably apply to all the subsectons of s3 and to s4.1 and could be included in the currently empty main section text. s4.1, rs_cnf - DTLS-RPK: This term needs a reference (RFC 7250). Also all other uses do not hyphenate and RPK needs to be expanded. s/DTLS-RPK handshake/DTLS
[Gen-art] Genart last call review of draft-ietf-cose-hash-sig-05
Reviewer: Elwyn Davies Review result: Almost Ready I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. Document: draft-ietf-cose-hash-sig-05 Reviewer: Elwyn Davies Review Date: 2019-10-28 IETF LC End Date: 2019-10-29 IESG Telechat date: Not scheduled for a telechat I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at <" dir="auto">https://trac.ietf.org/trac/gen/wiki/GenArtfaq>;. Document: draft-ietf-cose-hash-sig-05 Reviewer: Elwyn Davies Review Date: 2019/10/28 IETF LC End Date: 2019/10/29 IESG Telechat date: (if known) N/A Summary: Almost ready, There is one minor issue (barely above editorial) and a number of nits. I haven't checked the details of the HSS/LMS summary derived from RFC 8554 and I am taking the contents of the Appendix on trust! Major issues: None Minor issues: s1.1, last para: I found the note which provides particular motivation for this proposal rather obscure on first reading. After thinking about it, I now understand why this is here, but another sentence or so reinforcing the idea that getting the software distribution system post-quantum secure at the earlest opportunity is key to avoiding melt down should quantum computing develop more quickly than we might expect. Also referring to the SUIT WG is not future proof. Nits/editorial comments: s1, HASHSIG reference anchor: I would be inclined to stick with the 'standard' anchor for RFC 8554 i.e. [RFC8554]. s1, para 2: Expand DSA, ECDSA and EdDSA on first use ( RSA is claimed to be well-known). Arguably references for the various mechanisms might be desirable. s2, last para: s/The the/The/ s2 and subsections: The terminology and symbology used (e.g, || for concatenation) are (I believe) those defined in RFC 8554. This should be mentioned. s2.2, para 1: 'This specification supports only SHA-256': I think this is a cut-and-paste from RFC 8554. Suggest: s/This specification supports/[RFC8554] initially only supports/ and add at the end 'This specification would automatically support any such additional hash functions.' s4/s4.1: Rather than leaving an empty s4 and having a single subsection (generally frowned upon), the phraseology used at the start of s17 of RFC 8152 would be an improvement. s4: The security considerations of RFCs 8152 and 8554 are also relevant to implementations of this specification. s6: References to the relevant IANA registries for 'COSE Algrithms' and 'COSE Key Types' should be added. ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Genart last call review of draft-ietf-cbor-array-tags-07
Reviewer: Elwyn Davies Review result: Ready with Nits I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. Document: draft-ietf-cbor-array-tags-07 Reviewer: Elwyn Davies Review Date: 2019-09-06 IETF LC End Date: 2019-09-05 IESG Telechat date: Not scheduled for a telechat Summary: Ready with a couple of nits. Apologies for slightly late delivery. Major issues: None Minor issues: None Nits/editorial comments: s1, para 2: s/have received/has received/ s1, para 3: s/This also can/This can also/ s1.1, last para: s/whether that/as to whether that/ s2.1, 2nd para after Table 2 (top of page 5): OLD: It can be computed inversely to the previous formula from the length of the byte string in bytes: "bytelength >> (f + ll)". NEW: It can be computed from the length of the byte string comprising the representation of the array by inverting the previous formula: "bytelength >> (f + ll)". ENDS s2.1: The terms endianness, big endian and litle endian are jargon, if pretty well known jargon, but I don't know if they are considered to be adequately well understood to avoid the need for a reference or an explanation of what is meant. ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Genart last call review of draft-ietf-iasa2-rfc5377bis-02
Reviewer: Elwyn Davies Review result: Ready with Nits I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. Document: draft-ietf-iasa2-rfc5377bis-02 Reviewer: Elwyn Davies Review Date: 2019-08-14 IETF LC End Date: 2019-08-14 IESG Telechat date: Not scheduled for a telechat Summary: Ready with a couple of nits. The text of para 2 of section 3 refers to an initial state that is not applicable to the transition which requires this update. Emphasising continuity seems more appropriate. Major issues: None Minor issues: None Nits/editorial comments: Abstract, last sentence (very picky): Technically, what has been removed from the text of RFC 5377 are references to the IAOC. Suggest s/IASA/IAOC which was part of IASA/ s3, para 2, first sentence: The first sentence was applicable to the original creation of the licence policies and text when responsibility was initially transferred to the trustees and is inappropriate for the current modification of the trust organisation. It could probably be safely deleted, or the continuity could be emphasised by something like... OLD: The rough consensus described in this document reflects the agreement of the IETF as of the IETF Last Call, and the Trustees of the IETF Trust are to begin drafting license text and other materials to act on these instructions upon IESG approval of this document for RFC publication. NEW: To ensure continuuty, the starting point for license text and other materials will be that previiysly created by the Trustees of the IETF under the authority of [RFC5377] which this document supersedes. ENDS This requires a reference to RFC 5377. ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Genart last call review of draft-ietf-iasa2-rfc7437bis-05
Reviewer: Elwyn Davies Review result: Ready with Nits I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. Document: draft-ietf-iasa2-rfc7437bis-05 Reviewer: Elwyn Davies Review Date: 2019-06-20 IETF LC End Date: 2019-06-21 IESG Telechat date: Not scheduled for a telechat Summary: Ready with nits Major Issues: None Minor Issues: s3.2, para 1 and para 7: I feel the phrase 'superior candidate' is rather demeaning to an incumbent who may have served with distinction. Suggest in para 1 s/a superior candidate/an alternative candidate/. In para 7 s/A superior candidate is one who the NomCom believes/The nominated candidate selected for each open position by theNomCom, whether incumbent or alternative, is the one that they believe/ Nits and Editorials: s2, Confirmed Candidate: s/that has been/who has been/ (for consistency with Candidate) s3.2, para 1: s/its incumbent/its incumbent, assuming that the incumbent has indicated willingness to continue in post,/ s3.2, para 2: Section 5.4 of draft-ietf-iasa2-rfc4071bis-04 indicates that there are term limits for the IETF LLC board positions and Section 2 of draft-ietf-iasa2-trust-update-02 indicates there are term limits for IETF Trust positions. s3.3, para 3: s/is selected/are selected/ s3.7.1: The summaries of expertise need to be made public to facilitate candidate's ability to address the requirements in their submissions to the NomCom and for others to make appropriate comments on candidates. ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Genart last call review of draft-ietf-sipbrandy-osrtp-09
Reviewer: Elwyn Davies Review result: Ready with Nits I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. Document: draft-ietf-sipbrandy-osrtp-09 Reviewer: Elwyn Davies Review Date: 2019-05-16 IETF LC End Date: 2019-05-16 IESG Telechat date: Not scheduled for a telechat Summary: Ready with nits. Thanks for an easy to read document. I am not sure about whether it is acceptable to point to an expired (and effectively totally dead) draft (draft-kaplan...) for signuficant motivation (see minor issues). Please consult with higher authorities. Major issues: None Minor issues: S1, para 2: The discussion and motivation for the introduction of OSRTP is at least partially derived from the motivation explained in Section 1 of draft-kaplan-mmusic-best-effort-srtp. This is a long expired draft (2007) which is not going to become an RFC. Given this, I wonder if the text ought to be reproduced here, perhaps as an appendix? Nits/Editorial comments: Abstract: s./applied to Real-time/applied to the Real-time/ Abstract: expand SDP on first use. Abstract: expand SRTP on first use (Secure RTP). S1: The sentences expanding the meaning of cleartext and secure media could do with a little expansion to make it clear that we are talking about media streams even if that is what RTP is supposed to be about. Suggest: OLD: In terms of secure media, cleartext is RTP [RFC3550] media which is negotiated with the RTP/AVP (Audio Video Profile) [RFC3551] or the RTP/AVPF profile [RFC4585]. Comprehensive protection is Secure RTP [RFC3711], negotiated with a secure profile, such as SAVP or SAVPF [RFC5124]. NEW: In the context of transport of secure media streams using RTP and its secured derivatives, cleartext is represented by an RTP [RFC3550] media stream which is negotiated with the RTP/AVP (Audio Video Profile) [RFC3551] or the RTP/AVPF profile [RFC4585], whereas comprehensive protection is represented by a Secure RTP [RFC3711] stream, negotiated with a secure profile, such as SAVP or SAVPF [RFC5124]. ENDS (I note that SAVP and SAVPF aren't acronyms and don't need expansion. OTOH AVPF probably does.) S3: The terminology used in RFC 4566 and elsewhere seems to be m= sections rather than m- sections. Suggest s/m-/m=/g (4 places) S3.4, last sentence: the backward reference to Section 3.1 is not in RFC format. s/section [3.1]/Section 3.1/ S4, para 3: I think the 'must' here is normative. s/ an encrypted signaling channel must still be used./ an encrypted signaling channel MUST still be used./ S6: The note to the RFC Editor should also note that the referenceventries SIPCONNECT, RFC6982 and IMTC-SIP in s8 should also be removed. ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Genart telechat review of draft-ietf-pce-gmpls-pcep-extensions-14
Reviewer: Elwyn Davies Review result: Almost Ready I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please wait for direction from your document shepherd or AD before posting a new version of the draft. For more information, please see the FAQ at <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. Document: draft-ietf-pce-gmpls-pcep-extensions-14 Reviewer: Elwyn Davies Review Date: 2019-04-10 IETF LC End Date: 2018-10-29 IESG Telechat date: 2019-04-11 Summary: Almost ready, but with a large collection of nits in language and non-expansion of abbreviations. I am also concerned about the specification of behaviour in case PCC/PCEs with and without the extensions attempt to interact. The requirements and behaviour are rather woolly, and are not fully covered by capability negotiations as the negotation capability itself is not in the original PCEP specification. Major issues: None Minor issues: Interacting with PCCs that do not support these GMPLS extensions: The draft is not very clear on interactions between PCCs that do support the extensions and ones that do not. It is unclear whether a PCC that proposes to use the extensions must support the RFC 5088 or 5089 capability negotiation extensions and use them to determine if a PCEP exchange can use the extensions. The text in para 1 of s2.1.2 appears to require that a node that does not support RFC 5088 or 5089 still has to understand that it has received the GMPLS-CAPABILITY type indicator and indicate a mismatch. It seems to me that some additional explanation is needed to describe how mismatched PCC/PCEs understand the problem and deal with cases where a message with the new extensions is received (and presumably rejected) by a node that does not implement the extensions. s9.2, RFC7025: Given the references to the requirements document for this work, I would consider RFC 7025 to be normative. Nits/editorial comments: General: s/e.g. /e.g., /g Abstract: s/The Path Computation Element (PCE)/A Path Computation Element (PCE)/ s1: Expand abbreviations OTN (Optical Transport Networks) and WSON (Wavelength Switched Optical Networks). s1, para 2: s/considered/addressed/, s/those application/these applications/ s1.2, para 1: s/PCEP extension/PCEP extensions/, s/broken down in/broken down into/ s1.2: Expand following acronyms/abbreviations on first occurrence: LSP, TE-LSP, L2SC, TDM, SONET, SDH, LSC [Query: Is LSC different from L2SC?], PCC, ERO s1.2, bullet 2: A reference for the G.709 standard is needed. s1.2 and s1.3.1, items (4) and (5): There doesn't seem to be a definition of Concatenation Number in any of the documents mentioned here or anywhere on the web. I suspect it is supposed to be the number of streams that are concatenated but this needs to be properly defined or a reference provided. s1.2, bullet 5: s/Label restriction/label restriction/. I take it this refers to the use of Label Set objects as described in RFC 3473. If so please add a reference. If not lease provide the appropriate reference. s1.3.1: Expand following acronyms/abbreviations on first occurrence: TE-LSP, ODU, IRO, XRO, RRO, LSPA s1.3.1, item (4): s/Its scoped/It is scoped/ [English language note: 'Its' is the possessive pronoun derived from the third person singular impersonal pronoun 'it', whereas "It's" is a contraction of 'it is' that is not normally used in formal documents.] s1.3.1, item (4): > related to the BANDWIDTH object in MPLS networks I assume this relates to the BANDWIDTH object in RFC 5440 - please add a reference. s1.3.2, item (1): The previous two comments on s.1.3.1, item (4) apply also to this item. s1.4: OLD: 1.4 GMPLS Support and Limitation of Base PCEP Objects The support for requirements [RFC7025] is summarized in Table 1 and Table 2 NEW: 1.4 Existng Support for GMPLS in Base PCEP Objects and its Limitations The support provided by specifications in [RFC8282] and [RFC5440] for the requirements listed in [RFC7025] is summarized in Table 1 and Table 2. In some cases the support may not be complete, as noted, and additional support need to be provided in this specification. ENDS s1.4, RFC 5440 bullets, ERO: A reference for the RSVP specification covering ERO is needed. s1.4, XRO object. 1st bullet: Expand SRLG. s1.4, SWITCH-LAYER bullet: s/address/addresses/ s1.4, list of coverage gaps: Expand NVC. s1.4, added functionality needed: s/to cover the gap/to cover the gaps/ s2: Expand PCReq and PCRep message names to reflect names in RFC 5440. s2.1.2: > Moreover, in case that the PCC does not receive the >GMPLS-CAPABILITY TLV it is RECOMMENDED that the PCC does not make use >of the objects and TLVs defined in this document. I would have thought this ought to have been a MUST (when communicating with the PCC that didn't support the extensions. s2.1.2:
Re: [Gen-art] [netmod] Genart last call review of draft-ietf-netmod-module-tags-06
Hi, Christian.Thanks for the quick response.I understand your intent, but the intent and the specification appear to be in conflict.The pattern for tags is pattern '[a-zA-Z_][a-zA-Z0-9-_]*:[S ]+'; This REQUIRES two character strings separated by a colon unless I have totally forgotten how to read such patterns. Thus all tags have a prefix of the form [a-zA-Z_][a-zA-Z0-9-_]* and a part after the colon that is essentially unconstrained.S2 limits the values of the prefixes to those defined in the IANA registry of s7.1.. Further the values of the second part are constrained by the s7.2 registry if the prefix is ietf:.So, what should a YANG parser do when building datastores as per RFC 8342 if a tag prefix is not one of the ones in the s7.1 registry? Likewise if the prefix is ietf: and the whole tag is not in the s7.2 registry?If you want to make the presence of the prefix a SHOULD then I think you need to adapt the pattern to make the whole prefix part optional. However that doesn't get away from describing what the parser should do if it finds a prefix it doesn't know about. Additionally, I am not clear how the parser knows which tags should be marked as 'system' in the datastore as mentioned in the YANG module comments. Maybe it is that the ietf prefix and s7.2 value leads the tags to be marked as system tags but what should happen if it isn't in the s7.2 list? Should the parser ignore such tags, throw a fault and refuse to parse the module or maybe treat them as user tags even if they are ietf prefixed? Also if new prefixes are defined by other SDOs, as envisaged in the last paragraph of s7.1, could or would these also be system tags? Should there then be a flag or value in the registry to flag that tags with this prefix should be marked as system or otherwise?Thus also brings up another issue for the s7.1 registry. If another organisation is defining a prefix there really need to be contact and reference fields in the registry to specify the organisation maintaining this prefix, especially if such a prefix had its own equivalent of the s7.2 registry, and the document that introduces the prefix.I suggest the authors discuss the appropriate status for the three RFCs that I suggested should be normative and you disagreed with your AD. It is a rather odd situation where a standards ltrack document is updating an informational or BCP document, and also needing knowledge of items described in BCPs. With the revised policy on downrefs, this can be handled I believe.Cheers,ElwynSent from Samsung tablet. Original message From: Christian Hopps Date: 06/03/2019 22:55 (GMT+00:00) To: Elwyn Davies Cc: gen-art@ietf.org, Christian Hopps , draft-ietf-netmod-module-tags@ietf.org, "" , net...@ietf.org Subject: Re: [Gen-art] [netmod] Genart last call review of draft-ietf-netmod-module-tags-06 [I covered this in the previous reply I just sent, and updated the model text in response too..]The intent here is to not restrict users of tags where we don't have to. The prefix is only intended to avoid collision between disconnected groups (designers, implementers and users), since users are the final group to add/modify/use the tags we don't need to restrict them (and so we shouldn't).Thanks,Chris.> On Mar 6, 2019, at 2:39 PM, Elwyn Davies wrote:> > Hi.> > After completing my review, I realized that there was a further minor issue related to the possible values of tag prefixes, possible values of standardized prefixes and behaviour of implementations in the face of tag prefixes or values that are not in the relevant registries.> > I think that the text in s2 should be reinforced to emphasise that the only prefixes that should be expected are those in the IANA registry defined in s7.1.> > Either a new section or possibly in s3 text should be added to define the behaviour of YANG implementations that encounter tags with prefixes that are not in the s7.1 registry and tags with prefix ietf: that are not in the s7.2 registry.> > Regards,> Elwyn Davies> > > > > > Sent from Samsung tablet.> > ---- Original message > From: Datatracker on behalf of Elwyn Davies > Date: 06/03/2019 00:26 (GMT+00:00)> To: gen-art@ietf.org> Cc: draft-ietf-netmod-module-tags@ietf.org, i...@ietf.org, net...@ietf.org> Subject: [Gen-art] Genart last call review of draft-ietf-netmod-module-tags-06> > Reviewer: Elwyn Davies> Review result: Almost Ready> > I am the assigned Gen-ART reviewer for this draft. The General Area> Review Team (Gen-ART) reviews all IETF documents being processed> by the IESG for the IETF Chair. Please treat these comments just> like any other last call comments.> > For more information, please see the FAQ at> > <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.> > Document:
[Gen-art] Genart last call review of draft-ietf-netmod-module-tags-06
Reviewer: Elwyn Davies Review result: Almost Ready I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. Document: draft-ietf-netmod-module-tags-06 Reviewer: Elwyn Davies Review Date: 2019-03-05 IETF LC End Date: 2019-03-03 IESG Telechat date: Not scheduled for a telechat Summary: Almost ready. There are a couple of minor issues and a small number of nits. Apologies for the slightly late delivery of the review. Major issues: None Minor issues: Abstract/s1: I would judge that RFC 8407 ought to be normative since it is updated. S4.2: using the Netmod working group as contact point for the module is not future proof. I am not sure what the correct contact ought to be: IESG? S7.2: [This is a thought that occurred to me...] ought there to be an ietf: security tag? S9: I would consider RFCs 8199, 8340, 8342 and 8407 to be normative Nits/editorial comments: Abstract: s/modules/module's/ Abstract: OLD: This document also provides guidance to future model writers, as such, this document updates RFC8407. NEW: This document also provides guidance to future model writers; as such, this document updates RFC8407. ENDS S1.1, title: s/use cases of/use cases for/ S1.1, para 1: s/documents progression/document's development/ S1.1, paras 2, 3 and 5: Suggest s/E.g./For example/ S1.1, para 4: s/e.g./e.g.,/ S2, para 1: > All tags SHOULD begin with a prefix indicating who owns their definition. If I read correctly, the YANG definition in s4.2 REQUIRES that all tags have a prefix. For clarity, it would better if this read: All tags MUST begin with a prefix; it is intended that this prefix SHOULD [or maybe 'should'] indicate the ownership or origination of the definition. S2, para 1: s/yang type/YANG type/ (I think) S2.2: s/follwing/following/ S3.1, para 2: OLD: If the module definition is IETF standards track, the tags MUST also be Section 2.1. Thus, new modules can drive the addition of new standard tags to the IANA registry, and the IANA registry can serve as a check against duplication. NEW: If the module is defined in an IETF standards track document, the tags MUST use the prefix defined in Section 2.1. Thus, definitions of new modules can drive the addition of new standard tags to the IANA registry defined in Section 7.2, and the IANA registry can serve as a check against duplication. ENDS S3.2: s/standard/IETF Standard/ S3.3: It would be useful to introduce the term 'masking' used later in the YANG module definition. S4.1: I think this usage of RFC 8340 makes it normative. S4.2, extension module-tag definition: This should contain a pointer to RFC 8342 which discusses the system origin concept. Major issues: Minor issues: Nits/editorial comments: ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Genart telechat review of draft-ietf-pce-wson-rwa-ext-11
Reviewer: Elwyn Davies Review result: Ready I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please wait for direction from your document shepherd or AD before posting a new version of the draft. For more information, please see the FAQ at <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. Document: draft-ietf-pce-wson-rwa-ext-117 Reviewer: Elwyn Davies Review Date: 2019-01-28 IETF LC End Date: 2018-12-27 IESG Telechat date: 2019-02-07 Summary: Ready. There are a couple of trivial nits remaining. Otherwise, thanks very much for addressing my last call comments. Major issues: None. Minor issues: None. Nits/editorial comments: S3: The expansion of 3R needs to be at first occurrence. This is one paragraph earlier than the added expansion in v11. S3, next to last para: need to expand FEC. S4.1, para 5: s/to the allocation/used for the allocation/ ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Minor addition to gen-art review of draft-ietf-pce-wson-rwa-ext-10
I missed one nit in s10: RFC 5440 currently appears in both s10.1 and s10.2. The entries in s10.2 for RFC 5440 and RFC 5221 are mixed up. Regards,Elwyn Sent from Samsung tablet.___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Genart last call review of draft-ietf-pce-wson-rwa-ext-10
Reviewer: Elwyn Davies Review result: Ready with Nits I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. Document: draft-ietf-pce-wson-rwa-ext-10 Reviewer: Elwyn Davies Review Date: 2018-12-28 IETF LC End Date: 2018-12-27 IESG Telechat date: Not scheduled for a telechat Summary: Ready but with a lot of nits. The amount of cross referencing to other documents that supply objects or object formats, some of which are repurposed, make it difficult to be certain that all requisite definitions are present and exactly which external objects may be present. Major issues: None Minor issues: For avoidance of error during editing, the various TBD values included in the specifications and the requests in s8 should be linked by using TBDx values specific to each allocation. s3, para 6: Given that the additional multiplexing techniques are being developed, is the resulting extensibility easy to cater for in the capabilities defined here? s4.3: Various encoding errors are possible with this TLV (e.g., not exactly two link identifiers with the range case, unknown identifier types, no matching link for a given identifier). Should some error behaviour be specified here (or is it covered generically - if so where?) s6.2: Including instructions for future work to be done as per this section is inappropriate. It will necessarily be overtaken by events one way or the other. Unless there is already work in progress that can be referenced, the section should be removed. Nits/editorial comments: Tool issue: Note that the layout of 2nd and 3rd level headings does not correspond to IETF draft/RFC conventions (they are indented rather than at the left edge of the page). General: The encoding of numeric fields should be specified (once for all cases is all that is needed). General: s/TDB/TBD/ (7 places) (I assume) s3, para 4: It would be helpful to insert a new second sentence that explains the term Lambda Switch Capable. Maybe The devices used in WSONs that are able to switch signals based on signal wavelength are known as Lambda Switch Capable (LSC). The expansion of LSC can then be removed from para 5. s3, para 4: It would be helpful to expand the 3R acronym for those less familiar with optical network jargon. s3, para 4: Is it possible to say briefly in the document why all optical wavelength converters are out of scope? s3, para 6: s/both signals/the two signals/ s3, para 9: s/generic property/generic properties/ s3, para 10: s/advanced modulation processing/advanced modulation processing capabiities/; s/Those modulation properties/These modulation capabilities/; s/by the means of/indicated by means of/ s4, para 1: s/that are going to be/that are/ s4, in the two paras before figure 3: The expansion of WA should be done on first occurrence (one para earlier). s4, specification of WA Object: - Reserved bits ought to be explicitly zeroed (applies to various other places) - Unused flag bits should be zeroed. - s/The following new flags should be set/One flag bit is allocated as follows:/ - In specification of M: s/needs not be explicit/need not be explicit/ - In specification of M: s/Otherwise,/Otherwise (M bit set to 0),/; s/In such case,/If M is 0/ s4.3, above Fig 4: >The Wavelength Restriction Constraint TLV type is TBD, recommended >value is TBD. Putting in ' recommended value is TBD' is pointless if a value is not given and it needs to be removed from the published version in any case. If the authors have a preferred value for this then put in a note to IANA; otherwise leave it as TBDx for IANA to determine. Same applies in s5 above Fig 6. s4.4, paras 1 and 2: OLD: Path computation for WSON includes the check of signal processing capabilities, those capability MAY be provided by the IGP. Moreover, a PCC should be able to indicate additional restrictions for those signal compatibility, either on the endpoint or any given link. The supported signal processing capabilities are the one described in [RFC7446]: NEW: Path computation for WSON includes checking of signal processing capabilities at each interface against requested capability; this requirement MAY be implemented by the IGP. Moreover, a PCC should be able to indicate additional restrictions to signal processing compatibility, either on the endpoint or any given link. The supported signal processing capabilities are those described in [RFC7446]: ENDS s4.4: It is not clear to me where the XRO and IRO sub-objects would be used in this specification. s4.4.1: Expand XRO (Exclude Route Object?) on first use. s4.4.1, last para: which sub-sub objects are permitted/expected here? I couldn't be sur
[Gen-art] Genart telechat review of draft-ietf-rtgwg-multihomed-prefix-lfa-08
Reviewer: Elwyn Davies Review result: Ready with Issues I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please wait for direction from your document shepherd or AD before posting a new version of the draft. For more information, please see the FAQ at <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. Document: draft-ietf-rtgwg-multihomed-prefix-lfa-08 Reviewer: Elwyn Davies Review Date: 2018-10-22 IETF LC End Date: 2018-10-09 IESG Telechat date: 2018-10-25 Summary: Thank you for addressing the majority of the nitx and minor issues that I raised at last call. However, discussions with the editor have not (in my opinion) resolved my major issue. The inequalities proposed for selecting LFAs involve combining two numerical values, distance and cost. The value for distance is deterministic and unambiguous, but according to my understanding of the routing protocols to which this proposal applies, the cost values given to any given route are determined by the network manager such that the relative values for a pair of routes determine the preferred route in the conventional usage of the cost. As far as I was aware (and it is possible that my understanding is faulty), the protocols do not provide any mechanism for setting an absolute value. The implication of this would seem to be that if two identical networks used different cost scales, the sums of cost and distance would be different. Depending on the scales used, this could mean that, in one case, the cost factor was totally dominant in the inequalities because the cost values were much greater in absolute value than the distance hop counts, whereas in the other case, the cost and distance had similar impacts or the distance dominated. It seems to me that some advice, or better still, an algorithm, for scaling the costs is needed to make this a useful proposal - currently there does not appear to be any proposal for setting an appropriate scale for costs. Major issues: Lack of advice on scaling cost factor as discussed in summary above. Also addition of pointers to the places where the cost items are defined 3and the relevant fields in the messages in the associated protocol RFCs would be desirable. Minor issues: None Nits/editorial comments: None ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] Genart last call review of draft-ietf-rtgwg-multihomed-prefix-lfa-07
Hi, Uma. Thanks for your response. The nits are all sorted so we are just left with the issus of whether there are definitions of distance and cost that make them co-measurable. Clearly distance is well defined so we need to focus on the 'cost' item. I have no problem with the cost concept being *qualitatively^ well defined but I believe that the draft needs to either provide or give a reference to a *quantitative* definition that will produce a numeric value for the cost that will give a well-defined, interoperable result that is combinable with the distance so that the inequality has a useful result, rather than one or other component dominating the result. I am not a subject matter expert for the current state of the routing protocols to which this work applies, so it is entirely possible that there is a suitable quantitative definition somewhere in the existing RFCs, but it seems to me that it is essential that the draft points explicitly to the definition if it exists. Alternatively the definition needs to be given in the draft. A pointer to the distance definitikn is also desirable. I trust that the authors have made some experiments with the inequalities, so I would imagine that you have a good idea of how suitable co-measurable values are provided. Maybe you could provide a couple of handy examples in the draft? Regards,Elwyn Sent from Samsung tablet. Original message From: Uma Chunduri Date: 16/10/2018 21:13 (GMT+00:00) To: Elwyn Davies , gen-art@ietf.org Cc: draft-ietf-rtgwg-multihomed-prefix-lfa@ietf.org, i...@ietf.org, rt...@ietf.org Subject: RE: Genart last call review of draft-ietf-rtgwg-multihomed-prefix-lfa-07 Hi Elwyn, Thanks for your detailed review. Your feedback and suggestions were taken care in https://tools.ietf.org/html/draft-ietf-rtgwg-multihomed-prefix-lfa-08 Let us know if this addresses your comments. See my comments in-line [Uma]: -- Uma C. -Original Message- From: Elwyn Davies [mailto:elw...@dial.pipex.com] Sent: Wednesday, October 10, 2018 4:25 PM To: gen-art@ietf.org Cc: draft-ietf-rtgwg-multihomed-prefix-lfa@ietf.org; i...@ietf.org; rt...@ietf.org Subject: Genart last call review of draft-ietf-rtgwg-multihomed-prefix-lfa-07 Reviewer: Elwyn Davies Review result: Ready with Issues I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. Document: draft-ietf-rtgwg-multihomed-prefix-lfa-07 Reviewer: Elwyn Davies Review Date: 2018-10-10 IETF LC End Date: 2018-10-09 IESG Telechat date: Not scheduled for a telechat Summary: Ready except for one major issue which I see (although this might be due to lack of understanding). The inequalities mostly compare sums of the Distance and Cost function values. Since the unts of (administrative) cost are not specifically defined in the routing protocols, I am unclear how summing these two values without some scaling produces a value that is a useful combination. Adding more specific definitions would probably help. Please note that I am not skilled in the LFA art so I have not checked the technical value of the inequalities. Major: Compatibility of Cost and Distance metrics: The inequalities in RFC 5286 use only distance values and hence no compatibility issues arise. The inequalities proposed in this draft combine Cost and Distance metrics additively in most (all?) cases and compare them against another combination. How should the metrics be scaled to ensure that the combination and comparison makes sense? If the scales are not appropriate, one or other term is likely to dominate making nonsense of the proposal (IMO). I don't see any suggestion of how this should be achieved (or if it is irrelevant, explanation of why an aribtrary administrative cost metric would work.) [Uma]: Both these terms are well understood and based on the metrics of link or prefix. The reason separate notation of cost introduced here is because it includes the advertised prefix cost too for computing LFAs. So the additive combinations in various inequalities are on the same scale. Cost as specified in corresponding inequalities clearly specify what I mentioned above (both in Section 2 and Section 4). Minor: Lack of definitions of cost and distance terms: The key terms distance and cost are not defined. Clearly they are well-known terms of art in routing but exactly what is meant is relevant because of the above major issue. Nature of the inequalities: The nature, value of the compared terms and function of the inequaities is not explained in the abstract or intro. Mentioning that they use a combination of the key determnants of routing path selection ((Administ
[Gen-art] Genart last call review of draft-ietf-rtgwg-multihomed-prefix-lfa-07
Reviewer: Elwyn Davies Review result: Ready with Issues I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. Document: draft-ietf-rtgwg-multihomed-prefix-lfa-07 Reviewer: Elwyn Davies Review Date: 2018-10-10 IETF LC End Date: 2018-10-09 IESG Telechat date: Not scheduled for a telechat Summary: Ready except for one major issue which I see (although this might be due to lack of understanding). The inequalities mostly compare sums of the Distance and Cost function values. Since the unts of (administrative) cost are not specifically defined in the routing protocols, I am unclear how summing these two values without some scaling produces a value that is a useful combination. Adding more specific definitions would probably help. Please note that I am not skilled in the LFA art so I have not checked the technical value of the inequalities. Major: Compatibility of Cost and Distance metrics: The inequalities in RFC 5286 use only distance values and hence no compatibility issues arise. The inequalities proposed in this draft combine Cost and Distance metrics additively in most (all?) cases and compare them against another combination. How should the metrics be scaled to ensure that the combination and comparison makes sense? If the scales are not appropriate, one or other term is likely to dominate making nonsense of the proposal (IMO). I don't see any suggestion of how this should be achieved (or if it is irrelevant, explanation of why an aribtrary administrative cost metric would work.) Minor: Lack of definitions of cost and distance terms: The key terms distance and cost are not defined. Clearly they are well-known terms of art in routing but exactly what is meant is relevant because of the above major issue. Nature of the inequalities: The nature, value of the compared terms and function of the inequaities is not explained in the abstract or intro. Mentioning that they use a combination of the key determnants of routing path selection ((Administrative) Cost, (Hop) Distance) would probably do the business. Downref: Idnits notes RFC 5714 is a downref and there is no associated note (see RFC 4897). Nits/Editorial: General: The Cost() function used in the inequalities is defined using a capital letter C but is used generally with a lower case c. Should use Cost( rather than cost( throughout. Note the definitions in ss4.2.2.1/.2 use cost( also... suggest changing it for consistency. Abstract: Introduce LFA acronym (used in title): s/Loop-Free Alternates/Loop-Free Alternates (LFAs)/ (Probably worth adding it to s1.1). Requirements Language: Not in the rquired form: The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. s1, para 1: s/IP fast- reroute/IP fast-reroute/(remove space) s3.1, para 2: s/the below example network/the example network presented in Figure 3/ s3.1, para 3: s/prefix p/prefix P/ (lower->upper case) s3.1, para 4: s/the below example network/the example network presented in Figure 4/ s4.2.1, bullet 1a: s/intra area/intra-area/ s4.2.1, items 2a, 4c, 4d and 5a (line 3): idnits reports these lines as being too long (more than 72 chars). s4.2.1.1, para 1: s/cause loop/cause looping/ ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Genart telechat review of draft-ietf-dhc-dhcp4o6-saddr-opt-05
Reviewer: Elwyn Davies Review result: Ready I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please wait for direction from your document shepherd or AD before posting a new version of the draft. For more information, please see the FAQ at <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. Document: draft-ietf-dhc-dhcp4o6-saddr-opt-05 Reviewer: Elwyn Davies Review Date: 2018-10-04 IETF LC End Date: 2018-09-07 IESG Telechat date: 2018-10-11 Summary: Ready. Thanks for addressing my comments from the last call review. There are a couple of remaining trivial nits. Major issues: None. Minor issues: None. Nits/editorial comments: S7.5 , para 2: s/The default time minimum time/The default minimum time/ s10: I missed a third instance where the following change ought to be made (sorry): OLD: in the table at https://www.iana.org/assignments/dhcpv6-parameters: NEW: in the Option Codes table at https://www.iana.org/assignments/dhcpv6-parameters: ENDS ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Genart last call review of draft-ietf-dhc-dhcp4o6-saddr-opt-04
Reviewer: Elwyn Davies Review result: Ready with Nits I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. Document: draft-ietf-dhc-dhcp4o6-saddr-opt-04 Reviewer: Elwyn Davies Review Date: 2018-09-06 IETF LC End Date: 2018-09-07 IESG Telechat date: Not scheduled for a telechat Summary: Ready with nits. Thanks - well written and almost all quite clear. Major issues: None Minor issues: s7.4: >o The received bindprefix6-len value is not larger than the number > of bytes, divided by 8, received in the bind-ipv6-prefix field. > (e.g. the bindprefix6-len is 128 but the bind-ipv6-prefix field is > only 8 bytes long). Given that s6.1 gives a deterministic algorithm for calculating the length of the bind-ipv6-prefix field, I don't understand why the validation does not check that the length of the field is exactly as specified by this algorithm rather than using it as a lower limit. s7.5 and s8 (last para): Given that the time constraints and number of retries will interact and are implemented in different devices, I think these two values need some sensible defaults defined so that devices from different sources should interoperate successfully out of the box. Nits/editorial comments: General: s/e.g./e.g.,/g Abstract, sentence 2: Introduce DHCP 4o6 abbreviation: s/For DHCPv4 over DHCPv6/For DHCPv4 over DHCPv6 (DHCP 4o6)/. Abstract: Add mention of RFC 6346 and RFC 7598 for explanation of softwire scheme. Abstract, para 2: Expand ORO (Option Request Option) and give ref to rfc3315bis. s1, para 3: s/attached to any routable IPv6 prefix/attached to a network segment using any routable IPv6 prefix/ s4, para 1: It would be useful to remind readers of the expansion of BR in OPTION_S46_BR: Maybe s/the remote IPv6 address for the softwire/the remote IPv6 address used for the softwire border router/ s4, para 1: Expand ULA (not a well-known abbreviation). s7.2.1, para 1: 'flash' is colloquial and may not be generally understood. I think it can safely be removed. s7.4, para after bullets: s/For either of these cases,/If either check fails,/ s10: To be absolutely clear, there are two instances where the following change ought to be made: OLD: in the table at https://www.iana.org/assignments/dhcpv6-parameters: NEW: in the Option Codes table at https://www.iana.org/assignments/dhcpv6-parameters: ENDS ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Genart telechat review of draft-ietf-anima-autonomic-control-plane-16
Reviewer: Elwyn Davies Review result: Ready with Nits I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please wait for direction from your document shepherd or AD before posting a new version of the draft. For more information, please see the FAQ at <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. Document: draft-ietf-anima-autonomic-control-plane-16 Reviewer: Elwyn Davies Review Date: 2018-07-31 IETF LC End Date: 2018-02-26 IESG Telechat date: 2018-08-02 Summary: This document is ready but has a fair number of nits still to fix, particularly in the earlier part of the document. There are also some language issues to address which the RFC Editor will deal with. My issues from the Last Call review have been addressed. Major issues: None Minor issues: None Nits/editorial comments: General: There are three remaining examples of "intent" rather than "Intent". General: There are five instances of the construction -> "quoted text" () in s2. Need to remove -> and () in each case. This may be down to tool problems - there is a comment in the revisions list. S1, para 5: s/The ACP is designed to remains/The ACP is designed to remain/ s1, para 5: s/The details how this achieved are defined in Section 6./The details of how this achieved are described in Section 6./ s1, bullet point #1: s/supports directly/directly supports/ s1, bullet point #3: s/network/(Data-Plane) network/ S1, last para: s/Defined Networking (SDN) (see [RFC7426]), style automation/Defined Networking- (SDN-)style (see [RFC7426]) automation/ S1.1, para 2: Operational Technology is a term that is not very well-known - a reference would help. Unfortunately it seems that the text of ISA99 that defines the term is not freely available. Suggestions of a freely available alternative? s1.1, para 3: Although RPL is in the glossary in s2, this instance occurs before s2 is announced, so it would be worth adding RPL (Routing Protocol for Low-power and Lossy Networks - RFC6550) s2, "ACP address": s/the ->"ACP domain certificate" ()./the "ACP domain certificate". S2, "ACP Domain": 'of nodes with ->"ACP domain' . Remove "->" and ()? s2. "ACP Loopback interface": Need to expand VRF on first use. s2, "ACP secure channel": As wrtten this equates a security association with a secure channel. Suggest: NEW: ACP secure channel: A sequence of links established hop-by-hop between adjacent ACP nodes with a security association established for each link using the ACP secure channel protocol and the ACP Domain Certificate. The channel is used to carry traffic of the ACP VRF separated from Data-Plane traffic in-band over the same links as the Data-Plane. ENDS s2, "Data-Plane": s/non-autonomic/by means other than autonomically/ s2, "GRASP": s/required/REQUIRED/ s2, "in-band (management)": fix up two instances of -> ... (). s2, "Node-ID": s/bit/bits/; Due to a missing XML introducer, the reference to s6.10.5 hasn't been translated. s2, "(virtual) out-of-band network": fix up one instance of -> ... (); s/where historically/were historically/; In next to last sentence s/out of band/out-of-band/ s2, "ULA": s/are the first 48 bit/is the first 48 bits/ s2, "(ACP) Zone": s/protocols details/protocol's details/ s3.1: s/This way/In this way/; possibly s/other processes/single instamces of other processes/??? s3.2, last para: s/like/such as/ [like: Yuck!] s3.3, para 1: s/managment/management/ s3.3, first bullet: s/out of Band/out-of-Band/ s4, ACP2: The phrase "(can block easily at edge)" needs additional explanation. s4, ACP4: s/generic. Usable/generic, that is it MUST/ s4, last para: Need to expand eACP. s5, 2nd 'Note' bullet: s/auto discovery/auto-discovery/ s5, lata para: s/This way/In this way/ s6.1, para 4: Trailing colon s/b period. s6.1.1, last para on page 20: s/":" are not/The character ":" is not/ s6.1.1, last but 2 para: s/information element it,/information element,/(probably) s6.1.2. next to last bullet: s/peers certificate/peer's certificate/; s/peers domain/peer's domain/ s6.1.3.1, last para: Expand ttl on first use. s6.1.3.5, para 4: s/ACP nodes domain certificate/ACP node's domain certificate/; s/nodes ACP/node's ACP/ s6.3, para 2: s/State Less/Stateless/ s6.11.1.1, para 1: s/reliable network reasonably fast/reliable network with reasonably fast/ s6.12: s/hop by hop/hop-by-hop/ s8.2.1, bullets 2 and 3: s/vrf/VRF/ ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] Genart last call review of draft-ietf-payload-rtp-vc2hq-05
Hi, James. Thanks for actioning the nits. Version -06 is in prime shape! Cheers,Elwyn Sent from Samsung tablet.___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] Genart last call review of draft-ietf-bess-evpn-prefix-advertisement-10
Hi, Jorge.
I checked through version 11 and the changes look good.
The point about the alignment of the IP prefix in s3.1 is that, depending on
the length of the prefix, only a subset if the bits are relevant. It might be
'obvious' that the relevant bits are the leftmost ones but they could be the
rightmost bits. Better safe than sorry!
There are a couple of nits that could be pointed out to RFC editor if you
aren't doing any more updates.
Abstract: you aren't allowed references in bthe abstract, s/[RFC]/(RFC
)/ in two places.
s1: Expand TS on first use as it is before terminology.
S3.1 (3rd bullet afted Fig 4): s/byte/octet/
There ars a couple of instances where the global replacement of section by
Section has been over-enthusiastic: ss2, 3.2, 4, 4.3, 4.4 ('This Section'), ss2
(last para), 4.4.2 (p.29) ('Sections').
Cheers,Elwyn.
-Original Message-
Elwyn,
Thank you very much for your thorough review.
We addressed all your comments.. see below for more details, with [JORGE].
Thx
Jorge
From: Elwyn Davies
Date: Saturday, April 14, 2018 at 12:59 PM
To: "gen-art at ietf.org"
Cc: "draft-ietf-bess-evpn-prefix-advertisement.all at ietf.org"
, "ietf at ietf.org"
, "bess at ietf.org"
Subject: Genart last call review of draft-ietf-bess-evpn-prefix-advertisement-10
Resent-From:
Resent-To: , , , , , , , , , , Zhaohui Zhang
,
Resent-Date: Saturday, April 14, 2018 at 12:59 PM
Reviewer: Elwyn Davies
Review result: Almost Ready
I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair. Please treat these comments just
like any other last call comments.
For more information, please see the FAQ at
<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.
Document: draft-ietf-bess-evpn-prefix-advertisement-10
Reviewer: Elwyn Davies
Review Date: 2018-04-14
IETF LC End Date: 2018-04-10
IESG Telechat date: 2018-05-10
Summary: Almost ready. My main concerns are the lack of a good
introduction
and a rather weak definition of the format of the new EVPN route option
(looking back on RFC 7342, I think this could be said about that document
also!). This is very technical material and a good introduction would help
readers who are not already deeply into the Data Center area to understand
what is going on. Also this document has some remaining vestiges of being
written like an academc paper (some were fixed in the previous revision),
particularly the spurious notion of having 'conclusions' (material actually
deserves to be in the Intro)
Major issues:
None
Minor issues:
Lack of a proper introduction: An introduction should precede the
terminology
section and needs to be somewhat clearer about the context (presumably
multi-tenant data centers). A reference to RFC 7365 which describes the data
center model in which the EVPN mechanism is expected to be employed would be
very useful. A somewhat expanded version of the text in s2 would be a good
basis for the introduction. The ss2.1 and 2.2 with a short new header would
become a new section (3) which is the Problem Statement.
[JORGE] OK, I shifted the intro and terminology sections, and expanded the
introduction as you suggested.
s5: Associated with my previous comment... An RFC is not a scientific paper
and
does not have 'conclusions'. On reading s5, it strikes me that this text
would
actually make quite a nice part of the introduction, probably interpolated
after the first paragraph of the current s2.
[JORGE] ok, removed the conclusions section and took the content to the
introduction.
Terminology import: The current s1 contains a number of terms that are
actually
defined in RFC 7365 (Data Center, Tenant System, Network Virtualization
Edge,
etc). Pointing to RFC 7365 s1.1 would be helpful.
[JORGE] Added this in the terminology section:
"This document also assumes familiarity with the terminology of
[RFC7432], [RFC8365] and [RFC7365]."
s1, VNI: There is some difference between the usage of VNI in RFC 8365
(Section
5.1), in RFC 7365 (s3.1.2) where it means Virtual Network Instance and in
this
draft (... Identifier). This is potentially confusing to the naive reader
and
definitely confusing with the usage of VNI in item (4) of s4.1 where the
VNI is
the VXLAN Network Identifier. It would be better if VNI meant the same
thing in
all this closely related work. Please review all instances of VNI in the
draft
to make sure they are talking about the same thing.
[JORGE] Done. I also added:
"VNI: Virtual Network Identifier. As in [RFC8365], the term is used as
a representation of a 24-bit NVO instance identifier, with the
[Gen-art] Genart last call review of draft-ietf-payload-rtp-vc2hq-05
Reviewer: Elwyn Davies Review result: Ready I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. Document: draft-ietf-payload-rtp-vc2hq-05 Reviewer: Elwyn Davies Review Date: 2018-05-04 IETF LC End Date: 2018-05-16 IESG Telechat date: Not scheduled for a telechat Summary: Ready. A well written and comprehensible document. Thanks! I spotted a few minor nits noted below. Major issues:\ None Minor issues: None Nits/editorial comments: Abstract, S1 and VC2 reference: Expand SMPTE (Soc of Motion Picture and Television Engineers). s4, para 3: This para would probably be more helpful as a set of six bulleted entries for the six different packet formats, and omitting the 'one which carries' from each. s4.1, Sequecnce Number: s/extneded/extended/ ss4.1, 4.2: The encoding and bit ordering of the numeric fields should be specified (presumably this can be covered by a single statement that they are all unsigned integers encoded in Network Byte Order.). s4.4, third bullet: s/Hight/High/ s6.1, last para: Presumably this is left over from the template and should be removed. s8, para 1: s/This responsibility lays on anyone/This responsibility lies with anyone/ ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Fwd: Re: Gen-art LC Review of draft-ietf-anima-autonomic-control-plane-13
Hi. It has been about 6 weeks since responses to the review were postponed till after IETF 101 any thoughts yet? Regards,Elwyn Sent from Samsung tablet. Original message From: Elwyn Davies <elw...@dial.pipex.com> Date: 02/03/2018 12:04 (GMT+00:00) To: Brian E Carpenter <brian.e.carpen...@gmail.com>, gen-art@ietf.org Cc: draft-ietf-anima-autonomic-control-plane@ietf.org Subject: Re: [Gen-art] Gen-art LC Review of draft-ietf-anima-autonomic-control-plane-13 Just taking up one point for the time being Even if the reference model is informational, I was relying on RFC 8067, s1, para 3: Section 2 of [RFC3967] lists some conditions under which downrefs may make sense. In addition to those, it has become common for working groups to produce foundational documents (which contain important information such as terminology definitions and architectural design and considerations) at Informational status, and those documents are often needed as normative references in the Standards Track protocol documents that follow. I would say that sombody implementing ACP really needs to have read and understood the reference model and so I would argue:1. That it needs to be normative,and2. The downref is sanctioned by the language in RFC 8067. I am on holiday for a week and others are fighting the draft deadline so perhaps we can postpone discussion of the other points until the draft panic has subsided. Cheers,Elwyn Sent from Samsung tablet.___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Genart last call review of draft-ietf-bess-evpn-prefix-advertisement-10
Reviewer: Elwyn Davies Review result: Almost Ready I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. Document: draft-ietf-bess-evpn-prefix-advertisement-10 Reviewer: Elwyn Davies Review Date: 2018-04-14 IETF LC End Date: 2018-04-10 IESG Telechat date: 2018-05-10 Summary: Almost ready. My main concerns are the lack of a good introduction and a rather weak definition of the format of the new EVPN route option (looking back on RFC 7342, I think this could be said about that document also!). This is very technical material and a good introduction would help readers who are not already deeply into the Data Center area to understand what is going on. Also this document has some remaining vestiges of being written like an academc paper (some were fixed in the previous revision), particularly the spurious notion of having 'conclusions' (material actually deserves to be in the Intro) Major issues: None Minor issues: Lack of a proper introduction: An introduction should precede the terminology section and needs to be somewhat clearer about the context (presumably multi-tenant data centers). A reference to RFC 7365 which describes the data center model in which the EVPN mechanism is expected to be employed would be very useful. A somewhat expanded version of the text in s2 would be a good basis for the introduction. The ss2.1 and 2.2 with a short new header would become a new section (3) which is the Problem Statement. s5: Associated with my previous comment... An RFC is not a scientific paper and does not have 'conclusions'. On reading s5, it strikes me that this text would actually make quite a nice part of the introduction, probably interpolated after the first paragraph of the current s2. Terminology import: The current s1 contains a number of terms that are actually defined in RFC 7365 (Data Center, Tenant System, Network Virtualization Edge, etc). Pointing to RFC 7365 s1.1 would be helpful. s1, VNI: There is some difference between the usage of VNI in RFC 8365 (Section 5.1), in RFC 7365 (s3.1.2) where it means Virtual Network Instance and in this draft (... Identifier). This is potentially confusing to the naive reader and definitely confusing with the usage of VNI in item (4) of s4.1 where the VNI is the VXLAN Network Identifier. It would be better if VNI meant the same thing in all this closely related work. Please review all instances of VNI in the draft to make sure they are talking about the same thing. s2.1: >[RFC7432] is used as the control plane for a Network Virtualization >Overlay (NVO3) solution in Data Centers (DC), The acronym NVO3 is used here as opposed to NVO which is used elsewhere in the document. NVO3 is used in RFC 7365 to refer to an overlay with an L3 underlay network. It is not quite clear to me whether this is a typo with EVPN NOT being an NVO3 example or whether the sentence really ought to refer to RFC 7365 and explicitly say "Network Virtualization Overlay over Layer 3 tunnels". In any case you can't use an RFC as a control plane - they don't come with knobs on ;-) ! Suggest: NEW: [RFC7432] describes how a BGP MPLS-based Ethernet VPN (EVPN) can provide the control plane for a Network Virtualization Overlay [over Layer 3 Tunnels] (NVO[3]) solution in Data Centers (DC), ENDS If this is a real NVO3 then probably the NVO3 acronym should be used in the rest of the draft in place of NVO. s3.1: The encoding of the IP Prefix Route encoding is both underspecified and to some extent confusing. [I note that this is, in part, inherited from RFC 7342, where I consider Section 7 to be grossly underspecified.] Specifically: - Figure 3: Expand RD on first use. - 1st bullet after Fig 3: The usage of RD appears to be defined on a per route type basis in RFC 7342. Accordingly I don't think it is sufficient to refer to how it is done in RFC 7342. - 2nd bullet after Fig 3: s/byte/octet/ for consistency - 3rd bullet: Encoding not specified (presumably unsigned integer) - 4th bullet: The alignment of the prefix bits in the field is not specified (presumably left aligned). The second sentence about the size of the field is unnecessary and confusing if the total length specification is given clearly. - 6th bullet: The alighment/encoding of the field is not specified (high order doesn't have any meaning without this). - 7th bullet: It would be better to have the length specification as the first bullet - this then clarifies the length possibilities of the IP Prefix and GW IP address fields. Given that the field lengths are given in octets it would be clearer to specify the total length of the BGP EVPN NLRI variable portion in octets (and to repeat in s3 as in RFC 7342 that th
Re: [Gen-art] Your Gen-ART review of draft-ietf-dhc-rfc3315bis
Thanks Bernie. I am fine with -13. Cheers,Elwyn Sent from Samsung tablet. Original message From: "Bernie Volz (volz)" <v...@cisco.com> Date: 07/04/2018 14:35 (GMT+00:00) To: Elwyn Davies <elw...@dial.pipex.com>, Suresh Krishnan <sur...@kaloom.com> Cc: gen-art@ietf.org, draft-ietf-dhc-rfc3315bis@ietf.org, dh...@ietf.org Subject: Re: Your Gen-ART review of draft-ietf-dhc-rfc3315bis Hi: Regarding: >s21.22, 9th para after Table 36: s/The client SHOULD NOT send an IA Prefix >option with 0/The client SHOULD NOT send an IAPrefix option with 0/ [space >removed] The “IA Prefix” (and IA Address) are used throughout the document. The option is code is IAPREFIX, but the name of the option “IA Prefix”. The -13 has been published. Thanks Elwyn for the re-review and comments! Bernie From: Bernie Volz <v...@cisco.com> Date: Friday, April 6, 2018 at 7:52 PM To: Elwyn Davies <elw...@dial.pipex.com> Cc: Suresh Krishnan <sur...@kaloom.com>, General Team <gen-art@ietf.org>, "draft-ietf-dhc-rfc3315bis@ietf.org" <draft-ietf-dhc-rfc3315bis@ietf.org> Subject: Re: Your Gen-ART review of draft-ietf-dhc-rfc3315bis I’ll update and put out a -13 over the weekend. s20.3, para 2: > This method MUST be supported by all protocols. This seems to be rather presumptious! I’ll fix this as it is supposed to ne all Authentication option protocols. - Bernie (from iPad) On Apr 6, 2018, at 7:29 PM, Elwyn Davies <elw...@dial.pipex.com> wrote: Hi, Suresh and draft authors. Sorry for my inaction on checking the updates. I have now run through the changes (phew!) and think you are almost good to go. There are a couple of minor typos and a query about RFC 8213. Otherwise, thanks for addressing most of my issues/suggestions - I am gennerally happy with the outcome. Last few thoughts: s18.1: s/facility/facilitate/ s19.4, next to last para: s/insert an option to/insert an option into/ s20.3, para 2: > This method MUST be supported by all protocols. This seems to be rather presumptious! s20.3, para 3: s/a message with RDM field/a message with the RDM field/ s21.22, 9th para after Table 36: s/The client SHOULD NOT send an IA Prefix option with 0/The client SHOULD NOT send an IAPrefix option with 0/ [space removed] s20.1/s27.2: Keeping RFC 8213 as a separate item is fair enough, but I still feel it should be normative Cheers, Elwyn Sent from Samsung tablet. Original message From: Suresh Krishnan <sur...@kaloom.com> Date: 06/04/2018 04:15 (GMT+00:00) To: Elwyn Davies <elw...@dial.pipex.com> Subject: Your Gen-ART review of draft-ietf-dhc-rfc3315bis Hi Elwyn, As I spoke to you during IETF week, the authors of draft-ietf-dhc-rfc3315bis have addressed your review comments with text changes as well as explanations in case there are no text changes. Can you take a quick look at the latest rev to see if there are any open issues? I would like to get this draft approved by the end of this week. The latest draft is here https://tools.ietf.org/html/draft-ietf-dhc-rfc3315bis-12 The issues and the changes are tracked here https://docs.google.com/spreadsheets/d/1Yu6-BSV6aWPnhPGxKMPkokSaevjpfzTXe5_98ceoUMU/edit#gid=0 Thanks Suresh ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] Your Gen-ART review of draft-ietf-dhc-rfc3315bis
Hi, Suresh and draft authors. Sorry for my inaction on checking the updates. I have now run through the changes (phew!) and think you are almost good to go. There are a couple of minor typos and a query about RFC 8213. Otherwise, thanks for addressing most of my issues/suggestions - I am gennerally happy with the outcome. Last few thoughts: s18.1: s/facility/facilitate/ s19.4, next to last para: s/insert an option to/insert an option into/ s20.3, para 2: > This method MUST be supported by all protocols.This seems to be rather presumptious! s20.3, para 3: s/a message with RDM field/a message with the RDM field/ s21.22, 9th para after Table 36: s/The client SHOULD NOT send an IA Prefix option with 0/The client SHOULD NOT send an IAPrefix option with 0/ [space removed] s20.1/s27.2: Keeping RFC 8213 as a separate item is fair enough, but I still feel it should be normative Cheers,Elwyn Sent from Samsung tablet. Original message From: Suresh Krishnan <sur...@kaloom.com> Date: 06/04/2018 04:15 (GMT+00:00) To: Elwyn Davies <elw...@dial.pipex.com> Subject: Your Gen-ART review of draft-ietf-dhc-rfc3315bis Hi Elwyn, As I spoke to you during IETF week, the authors of draft-ietf-dhc-rfc3315bis have addressed your review comments with text changes as well as explanations in case there are no text changes. Can you take a quick look at the latest rev to see if there are any open issues? I would like to get this draft approved by the end of this week. The latest draft is here https://tools.ietf.org/html/draft-ietf-dhc-rfc3315bis-12 The issues and the changes are tracked here https://docs.google.com/spreadsheets/d/1Yu6-BSV6aWPnhPGxKMPkokSaevjpfzTXe5_98ceoUMU/edit#gid=0 Thanks Suresh ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] Gen-art LC Review of draft-ietf-anima-autonomic-control-plane-13
Just taking up one point for the time being Even if the reference model is informational, I was relying on RFC 8067, s1, para 3: Section 2 of [RFC3967] lists some conditions under which downrefs may make sense. In addition to those, it has become common for working groups to produce foundational documents (which contain important information such as terminology definitions and architectural design and considerations) at Informational status, and those documents are often needed as normative references in the Standards Track protocol documents that follow. I would say that sombody implementing ACP really needs to have read and understood the reference model and so I would argue:1. That it needs to be normative,and2. The downref is sanctioned by the language in RFC 8067. I am on holiday for a week and others are fighting the draft deadline so perhaps we can postpone discussion of the other points until the draft panic has subsided. Cheers,Elwyn Sent from Samsung tablet. Original message From: Brian E Carpenter <brian.e.carpen...@gmail.com> Date: 01/03/2018 02:45 (GMT+01:00) To: Elwyn Davies <elw...@dial.pipex.com>, gen-art@ietf.org Cc: draft-ietf-anima-autonomic-control-plane@ietf.org Subject: Re: [Gen-art] Gen-art LC Review of draft-ietf-anima-autonomic-control-plane-13 Replying as a protagonist - First thanks for the really thorough review with many good points. Now a few replies in-line: On 28/02/2018 15:24, Elwyn Davies wrote: > I am the assigned Gen-ART reviewer for this draft. The General Area > Review Team (Gen-ART) reviews all IETF documents being processed > you need a stand-by generator, you need a stand-by enrollment server). > s15.2: I think some of these references are normative: > especially ietf-anima-reference-model, Definitely not, it's an informational document. Regards Brian ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Gen-art LC Review of draft-ietf-anima-autonomic-control-plane-13
I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. Document: draft-ietf-anima-autonomic-control-plane-13.txt Reviewer: Elwyn Davies Review Date: 2016/02/27 IETF LC End Date: 2016/02/26 IESG Telechat date: (if known) - Summary: Not ready. There are a number of minor issues and a host of nits and editorial fixes needed. I would also consider that the expected status (expeimental vs standards track) ought to be discussed on account of the areas where it is incomplete (e.g., incompleteness of the key Intent mechanism). Major issues: I am sure this has been considered elsewhere, but the amount of future work and areas where operation might discover problems indicates to me that maybe this should be an experimental proposal rather than standards track. Minor issues: Clarity regarding limitations of the ACP approach:The document is relentlessly positive about the ACP approach. Clearly certain problems will not allow the ACP to function. For example it implies that the physical network and interfaces are a shared resource: low level failures or misconfiguration at (say) Level 2, may still knockout the ACP as well as the data-plane. Some brief words on this would not go amiss. This could well be in s4. s2, para 2: There are several instances in the terminology definitions that are confusing before the term has been fully introduced later (and in some cases even then, e.g., the cryptic reference to 'paragraph 21' in the ACP address definition.) This should be cleared up. Notes are given in the Nits/Editorial comments below, s4, "ACP4", also s6.8.2: Clients of the ACP MUST NOT be tied to a particular application or transport protocol. It may be that I don't understand the problem, but the communication between the ACP nodes seems to be tied to the secure channels. I am not sure how this is compatible with the any transport protocol requirement. There doesn't seem to be any further explanation of how this requirement is fufilled. This is linked to he means that is not specified by which the ACP address TLS connections are connected to the secure channels. This may be because I don't understand the problem s6.1.1: RFC 5280 discusses the option of leaving the subjectName blank if the subjectAltName is present. What would we expect to find in the subjectName field of the ACP Domain cert? s6.1.1: I don't understand where the routing-subdomain element is carried. routing-subdomain is a top level production in the ABNF that isn't referenced in the rest of the ABNF and a separate example is given. Is the intention that the subjectAltName would consist of a sequence of two rfc822names as allowed by the X.509 syntax if the routing-subdomain is required? s6.1.3: I don't understand why the EST renewal server address has to (or, at least, might) be configured into all ACP nodes when the EST server announces itself with M_FLOOD messages. For one thing it goes (further) against automicity. s6.7.x, Security algorithm agility?: Each of the options specifies a MTI, minimum (in today's tems) capability set of cyypto algorithms. It is not clear (to me) how this will be adapted if and when these algorithms are no longer adequately secure. Some words on ths may be necessary. s9.1, "Network Partition": I am not sure I believe the story on partition - It seems possinle that one of the segments could be left without an enrollment server after partition. Am I right and does it matter? s12: There is no registration policy specified for the new registry created. Nits/editorial comments: General: The style used for introducing acronyms is not consistent with normal RFC style, which is expansion followed by acronym in parentheses, thus... Example (in the Abstract): s/OAM (Operations Administration and Management)/Operations Administration and Management (OAM)/ General: s/e.g.:/e.g.,/ (global) General: In English thequestion mark (?) is not separated by space from the last word in the sentence. There are many instanxes of this problem, especially in s10. Exclusive usage of IPv6: It would be useful to mention (probably somewhere in the last two paras of s1) that the ACP is stricly an IPv6 construct. Abstract and 3 other places: s/out of band/out-of-band/ Abstract: In the last sentence is "not misconfigured" correct? I would have thought it shuld be "misconfigured". s1, para 1: The phraseology "currently being defined in the document" for the reference model is not future proof. Replace with "specified in". s1, para 3: A construct cannot 'run' in a table: OLD: runs in the global routing table NEW: runs ov
Re: [Gen-art] Genart last call review of draft-ietf-rtgwg-backoff-algo-07
Hi. Thanks for the quick response. I think the message I just sent to Acee covers most of this. I'll await the final text on HOLDDOWN_INTERVAL etc. I would just say that making it even clearer that the example values for timer intervals are not defaults.. implementers may understand the language but they can be lazy. Cheers,Elwyn Sent from Samsung tablet. Original message From: bruno.decra...@orange.com Date: 16/02/2018 14:00 (GMT+00:00) To: "Acee Lindem (acee)" <a...@cisco.com>, Elwyn Davies <elw...@dial.pipex.com> Cc: draft-ietf-rtgwg-backoff-algo@ietf.org, i...@ietf.org, rt...@ietf.org, gen-art@ietf.org Subject: RE: Genart last call review of draft-ietf-rtgwg-backoff-algo-07 Hi Elwyn, Acee, Thanks for your review and comments. Please see inline [Bruno] > -Original Message- > From: Acee Lindem (acee) [mailto:a...@cisco.com] > Sent: Friday, February 16, 2018 1:31 AM > To: Elwyn Davies; gen-art@ietf.org > Cc: draft-ietf-rtgwg-backoff-algo@ietf.org; i...@ietf.org; rt...@ietf.org > Subject: Re: Genart last call review of draft-ietf-rtgwg-backoff-algo-07 > > Hi Elwyn, > > On 2/15/18, 2:12 PM, "Elwyn Davies" <elw...@dial.pipex.com> wrote: > > Reviewer: Elwyn Davies > Review result: Ready with Nits > > I am the assigned Gen-ART reviewer for this draft. The General Area > Review Team (Gen-ART) reviews all IETF documents being processed > by the IESG for the IETF Chair. Please treat these comments just > like any other last call comments. > > For more information, please see the FAQ at > > <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. > > Document: draft-ietf-rtgwg-backoff-algo-07.txt > Reviewer: Elwyn Davies > Review Date: 2018/02/15 > IETF LC End Date: 2018/02/14 > IESG Telechat date: 2016/02/22 > > Summary: Ready with nits. The draft does not refer to OSPFv3 - i am not >sure if > this is an oversight or because ODSPFv3 already has this mechanism - >either way > it should be mentioned. [Bruno] This is an oversight and has been added. > One question that occurred to me is whether the draft > could be considered as updating the OSPFv2/v3 and ISIS standards (not >that IETF > has any control over ISIS). [Bruno] I personally don't think so. I'd leave this to OSPF/IS-IS/LSR chairs and routing AD. > Major issues: > None > > Minor issues: > (Non-)Relation between HOLDDOWN_INTERVAL and *_SPF_DELAY values: I >notced that > Benjamin Kaduk's SECDIR review of this document > >(https://datatracker.ietf.org/doc/review-ietf-rtgwg-backoff-algo-07-secdir-lc-kaduk-2018-02-14/) > was concerned that certain state transitions would never occur. I >loooked at > this and realized that his assumption that LONG_SPF_DELAY < >HOLDDOWN_INTERVAL > is not required by the document and s6 explicitly resiles from offering > suggested default values. Without this assumption, the state machine >appears > to be correct. Not being familiar with the consequences of setting the > HOLDDOWN_INTERVAL relative to the *_SPF_DELAY, I am not sure if anything >could > be said about such consequences, [Bruno] There is no "significant" bad consequence. Thinking about this, I could see 2 consequences: - There could be a SPF computation scheduled after the HOLDDOWN_INTERVAL. I don't see this as an issue as, as stated below by Acee, the HOLDDOWN_INTERVAL is defined as related to the period with no IGP events. It's not defined as the period with no SPF computations (not to mention further computations e.g., from BGP). - Perhaps more importantly, if an IGP event occurs at t1 in the interval [LONG_SPF_DELAY;HOLDDOWN_INTERVAL], then the SPF computation would be triggered HOLDDOWN_INTERVAL-t1 after the IGP event. While the intuition is that it should be triggered after INITIAL_SPF_DELAY. > but I think it would avoid other people making > the same assumption as the SECDIR reviewer if it was explicitly stated >that > HOLDDOWN_INTERVAL is not necessarily bigger than any of the *_SPF_DELAY >values > and adding any advice from experience about how to choose appropriate >values. > This might also avoid naive implementers shortcutting the state machine > implementation if they made the same assumption. [Bruno] ok, I would propose the following change: OLD: In order to satisfy the goals stated in Section 2, operators are RECOMMENDED to configure delay intervals such that INITIAL_SPF_DELAY = SHORT_SPF_DELAY and SHORT_SPF_DELAY = LONG_SPF_DELAY. NEW: In order to satisfy the goals stated in Section 2, operato
Re: [Gen-art] Genart last call review of draft-ietf-rtgwg-backoff-algo-07
Hi. Thanks forthe quick response. Some coments in line below (EBD==>). Cheers,Elwyn Sent from Samsung tablet. Original message From: "Acee Lindem (acee)" <a...@cisco.com> Date: 16/02/2018 00:30 (GMT+00:00) To: Elwyn Davies <elw...@dial.pipex.com>, gen-art@ietf.org Cc: draft-ietf-rtgwg-backoff-algo@ietf.org, i...@ietf.org, rt...@ietf.org Subject: Re: Genart last call review of draft-ietf-rtgwg-backoff-algo-07 Hi Elwyn, On 2/15/18, 2:12 PM, "Elwyn Davies" <elw...@dial.pipex.com> wrote: Reviewer: Elwyn Davies Review result: Ready with Nits I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. Document: draft-ietf-rtgwg-backoff-algo-07.txt Reviewer: Elwyn Davies Review Date: 2018/02/15 IETF LC End Date: 2018/02/14 IESG Telechat date: 2016/02/22 Summary: Ready with nits. The draft does not refer to OSPFv3 - i am not sure if this is an oversight or because ODSPFv3 already has this mechanism - either way it should be mentioned. One question that occurred to me is whether the draft could be considered as updating the OSPFv2/v3 and ISIS standards (not that IETF has any control over ISIS). Major issues: None Minor issues: (Non-)Relation between HOLDDOWN_INTERVAL and *_SPF_DELAY values: I notced that Benjamin Kaduk's SECDIR review of this document (https://datatracker.ietf.org/doc/review-ietf-rtgwg-backoff-algo-07-secdir-lc-kaduk-2018-02-14/) was concerned that certain state transitions would never occur. I loooked at this and realized that his assumption that LONG_SPF_DELAY < HOLDDOWN_INTERVAL is not required by the document and s6 explicitly resiles from offering suggested default values. Without this assumption, the state machine appears to be correct. Not being familiar with the consequences of setting the HOLDDOWN_INTERVAL relative to the *_SPF_DELAY, I am not sure if anything could be said about such consequences, but I think it would avoid other people making the same assumption as the SECDIR reviewer if it was explicitly stated that HOLDDOWN_INTERVAL is not necessarily bigger than any of the *_SPF_DELAY values and adding any advice from experience about how to choose appropriate values. This might also avoid naive implementers shortcutting the state machine implementation if they made the same assumption. The definition of HOLDDOWN_INTERVAL explicitly states: HOLDDOWN_INTERVAL: The time required with no received IGP events before considering the IGP to be stable again and allowing the SPF_DELAY to be restored to INITIAL_SPF_DELAY. e.g., 3 seconds. The HOLDDOWN_INTERVAL MUST be defaulted or configured to be longer than the TIME_TO_LEARN_INTERVAL. Perhaps, it should be restated in the third paragraph of section 6. EBD==> The definition of HOLDDOWN_INTERVAL is fine. The issue is the relationship (or otherwise) between *_SPF_DELAY and HOLDDOWN_INTERVAL. It is (presumably) deliberately not specified: However it would be helpful to make this explicit and say something about whether there are any downsides to setting the HOLDDOWN_INTERVAL smaller or larger than the delays. Requirements Language: Suggest s/RFC2119/RFC8174/ as there are uses of lower case versions of the reserved words. I believe this was brought up before and we will make this change. If not, we'll change to the RFC 8174 language. Default values for parameters: There is a possible conflict between s3, where example values for the various interval parameters are given and s6 which states that no default values are specified in the document. The difference in termnology maybe too subtle for some implementers. I would expect those implementing IGPs to know the different between an "example" and a "default". Aborting or otherwise of SPF calculation if an IGP event occurs while an SPF calculation is in progress. A note about whether this should happen (if it is possible) would be desirable. This is certainly out scope and I'm not sure why anyone would deduce from this draft that an implementation should or shouldn't do this. EBD==> I can't see that it is out of scope. The whole point of the draft is to avoid wasting processor cycles on useless runs of the SPF algorithm. If an IGP event occurs just after the SPF algorithm has started there might be some point to aborting it or at least avoiding loading the routing tables. Along the lines of 'Consideration could be given ..."
Re: [Gen-art] Genart last call review of draft-ietf-rtgwg-backoff-algo-07
Hi.
Thanks for the response.
Couple of points:- Where I have suggested lower case 'recommended' it is
because they are not normatively enforceable - they are operational decisions
that don't affect the bits on the wire. There are a couple of others I missed
(see recent DISCUSS).- s1, para 2: Try 'happening' instead of 'eventuating'.
s1, para 2:' Jargon 'removal': BTW I wasn't suggesting removing the rest of
the sentence (after 'and') - the comment on micro-loops is definitely helpful.
s8: I wasn't trying to suggest that the algorithms described using the other
terms would be replaced, but merely that the document provides an alternative
way of implementing the concepts but with different names.
I'll await the new version.
Cheers,Elwyn
Sent from Samsung tablet.
Original message From: "Acee Lindem (acee)" <a...@cisco.com>
Date: 16/02/2018 18:39 (GMT+00:00) To: Elwyn Davies <elw...@dial.pipex.com>,
gen-art@ietf.org Cc: draft-ietf-rtgwg-backoff-algo@ietf.org, i...@ietf.org,
rt...@ietf.org Subject: Re: Genart last call review of
draft-ietf-rtgwg-backoff-algo-07
Hi Elwyn,
Also thank you much for your editorial comments. I must say I'm surprised that
we didn’t catch some of these before. We will adopt most of them. One thing I'm
not clear on is why you believe we should change RECOMMENDED to lowercase in
the deployment recommendations. Unless convinced otherwise, we'll leave this
for the IESG to decide. See inline.
On 2/15/18, 2:12 PM, "Elwyn Davies" <elw...@dial.pipex.com> wrote:
Nits/editorial comments:
General: The term 'back-off' may not be familiar to non-Emglish mother
tongue
speakers and on first occurrence needs a little explanation for naive
readers
to indicate what it means and to what the back-off is being applied. I have
suggested some additional text to this end for the abstract and s1.
Abstract:
OLD:
This document defines a standard algorithm to back-off link-state IGP
Shortest Path First (SPF) computations.
NEW:
This document defines a standard algorithm to temporararily postpone or
'back-off' link-state IGP Shortest Path First (SPF) computations to
reduce
the computational load on IGP nodes if network events occurring at
closely
spaced times would otherwise lead to multiple, essentially redundant
recalculations of the routing tables.
ENDS
This is a rather long sentence. I don't have a problem with adding "to
temporarily postpone or". However, I'd split the second clause into a new
sentence and shorten it.
This reduces the computational load on IGP nodes when multiple network
events trigger multiple SPF computations over a short time interval.
Or simply:
This reduces the computational load on IGP nodes when multiple
temporally close network events trigger multiple SPF computations.
s1, para 1: s/at the same time/essentially at the same time/
Ok,
s1, para 2: s/new Shortest Path First (SPF)/new Shortest Path First (SPF)
routing table/
We already changed this as per Benjamin's comment.
s1, para 2:
OLD:
experiencing multiple temporally close failures over a short
period of time
NEW:
experiencing multiple temporally close failures (that is, eventuating
over a
short period of time)
ENDS
I'm not sure "eventuating" is any clearer than "temporally" and the latter is
more precise.
s1, para 2: There is a right bracket missing in the following and starting a
clause with 'such as' and ending it with an ellipsis ('...') is redundant.
>
such as LDP [RFC5036], RSVP-TE [RFC3209], > BGP [RFC4271], Fast ReRoute
computations (e.g. Loop Free Alternates > (LFA) [RFC5286], FIB
updates...
It is unclear to me where the bracket should go: maybe after [RFC5286] or at
the end. Please clarify.
This should be
(e.g., Loop Free Alternates (LFA) [RFC5286], FIB updates, etc.).
s1, para 2: the phrase
> This also reduces the churn on
> routers and in the network and.
is useless, vague jargon. The previous sentence expresses what I suspect is
meant by 'churn'. so this is redundant and can be omitted.
We definitely want the explicitly reference to microloops and this clause sets
the correct context. Perhaps, we could shortend to "This also reduces network
churn and".
s1, para 3:
OLD:
To allow for this, IGPs implement an SPF back-off algorithm.
NEW:
To allow for this, IGPs usually implement an SPF back-off algorithm that
postpones or backs-off the running of the SPF calculation when the algorithm
predicts that a run would be essentially redundant or even
counter-productive
because it appears that multiple closely timed routing-affecting events can
be
expecte
[Gen-art] Genart last call review of draft-ietf-rtgwg-backoff-algo-07
Reviewer: Elwyn Davies
Review result: Ready with Nits
I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair. Please treat these comments just
like any other last call comments.
For more information, please see the FAQ at
<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.
Document: draft-ietf-rtgwg-backoff-algo-07.txt
Reviewer: Elwyn Davies
Review Date: 2018/02/15
IETF LC End Date: 2018/02/14
IESG Telechat date: 2016/02/22
Summary: Ready with nits. The draft does not refer to OSPFv3 - i am not sure if
this is an oversight or because ODSPFv3 already has this mechanism - either way
it should be mentioned. One question that occurred to me is whether the draft
could be considered as updating the OSPFv2/v3 and ISIS standards (not that IETF
has any control over ISIS).
Major issues:
None
Minor issues:
(Non-)Relation between HOLDDOWN_INTERVAL and *_SPF_DELAY values: I notced that
Benjamin Kaduk's SECDIR review of this document
(https://datatracker.ietf.org/doc/review-ietf-rtgwg-backoff-algo-07-secdir-lc-kaduk-2018-02-14/)
was concerned that certain state transitions would never occur. I loooked at
this and realized that his assumption that LONG_SPF_DELAY < HOLDDOWN_INTERVAL
is not required by the document and s6 explicitly resiles from offering
suggested default values. Without this assumption, the state machine appears
to be correct. Not being familiar with the consequences of setting the
HOLDDOWN_INTERVAL relative to the *_SPF_DELAY, I am not sure if anything could
be said about such consequences, but I think it would avoid other people making
the same assumption as the SECDIR reviewer if it was explicitly stated that
HOLDDOWN_INTERVAL is not necessarily bigger than any of the *_SPF_DELAY values
and adding any advice from experience about how to choose appropriate values.
This might also avoid naive implementers shortcutting the state machine
implementation if they made the same assumption.
Requirements Language: Suggest s/RFC2119/RFC8174/ as there are uses of lower
case versions of the reserved words.
Default values for parameters: There is a possible conflict between s3, where
example values for the various interval parameters are given and s6 which
states that no default values are specified in the document. The difference in
termnology maybe too subtle for some implementers.
Aborting or otherwise of SPF calculation if an IGP event occurs while an SPF
calculation is in progress. A note about whether this should happen (if it is
possible) would be desirable.
OSPFv3: Does this (not) equally apply to OSPF v3 for IPv6? If so it should be
mentioned and RFC 5340 included in the references.
s12: I suspect (although it could be arguable) that the ISIS definition, RFC
2328 (OSPFv2) and (if added) RFC5340 are normative as you need to understand
how they work. This work could even be considered to update these documents.
Nits/editorial comments:
General: The term 'back-off' may not be familiar to non-Emglish mother tongue
speakers and on first occurrence needs a little explanation for naive readers
to indicate what it means and to what the back-off is being applied. I have
suggested some additional text to this end for the abstract and s1.
Abstract:
OLD:
This document defines a standard algorithm to back-off link-state IGP
Shortest Path First (SPF) computations.
NEW:
This document defines a standard algorithm to temporararily postpone or
'back-off' link-state IGP Shortest Path First (SPF) computations to reduce
the computational load on IGP nodes if network events occurring at closely
spaced times would otherwise lead to multiple, essentially redundant
recalculations of the routing tables.
ENDS
s1, para 1: s/at the same time/essentially at the same time/
s1, para 2: s/new Shortest Path First (SPF)/new Shortest Path First (SPF)
routing table/
s1, para 2:
OLD:
experiencing multiple temporally close failures over a short
period of time
NEW:
experiencing multiple temporally close failures (that is, eventuating over a
short period of time)
ENDS
s1, para 2: There is a right bracket missing in the following and starting a
clause with 'such as' and ending it with an ellipsis ('...') is redundant. >
such as LDP [RFC5036], RSVP-TE [RFC3209], >BGP [RFC4271], Fast ReRoute
computations (e.g. Loop Free Alternates >(LFA) [RFC5286], FIB updates...
It is unclear to me where the bracket should go: maybe after [RFC5286] or at
the end. Please clarify.
s1, para 2: the phrase
> This also reduces the churn on
>routers and in the network and.
is useless, vague jargon. The previous sentence expresses what I suspect is
meant by 'churn'. so this is redundant and can be omitted.
s1, para 3:
OLD:
To allow for this, IGPs implement an SPF back-off algorithm.
NEW:
To allow for this, IGPs usually implement an SPF back-off algorithm tha
Re: [Gen-art] Genart telechat review of draft-ietf-dhc-rfc3315bis-10
:-) I'll look out for updates. Cheers,Elwyn Sent from Samsung tablet. Original message From: "Bernie Volz (volz)" <v...@cisco.com> Date: 19/01/2018 14:55 (GMT+00:00) To: Elwyn Davies <elw...@dial.pipex.com>, gen-art@ietf.org Cc: dh...@ietf.org, i...@ietf.org, draft-ietf-dhc-rfc3315bis@ietf.org Subject: RE: Genart telechat review of draft-ietf-dhc-rfc3315bis-10 Elwyn: On behalf of the authors of draft-ietf-dhc-rfc3315bis, thanks much for the very thorough review (most of your comments look appropriate to apply). - Bernie -Original Message----- From: Elwyn Davies [mailto:elw...@dial.pipex.com] Sent: Thursday, January 18, 2018 1:00 PM To: gen-art@ietf.org Cc: dh...@ietf.org; i...@ietf.org; draft-ietf-dhc-rfc3315bis@ietf.org Subject: Genart telechat review of draft-ietf-dhc-rfc3315bis-10 Reviewer: Elwyn Davies Review result: Almost Ready [This is a Last Call Review, not a telechat review]. I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. Document: draft-ietf-dhc-rfc3315bis-10 Reviewer: Elwyn Davies Review Date: 2018-01-18 IETF LC End Date: 2018-01-24 IESG Telechat date: 2018-01-25 Summary: Amost ready. To the best of my abiity I have done a thorough check of the merging of the various earlier documents into the new -bis and the incorporation of the various Errata. All seems to be good from this point of view. I am slightly surprised that two other RFCs (7283 and 8213) were not subsumed into this document. Both are pure updates of 3315 with some important improvements and are pretty short in themselves. I also found that the new document did not do a good job on the interactions between relay-agents and servers. Particularly on the processing of options between relays and servers and details of reception of Relay-forward messages a little more detail would halp naive readers. Finally the draft has not made much of an effort to support possible alternative security algorithms - IETF policy now encourages protocols to deal with algorithm flexibility - DHCPv6 as it stands is pretty thoroughly wedded to HMAC-MD5 and would need some (relatively small) IANA improvements plus some thought to cope with different algorithms. There are also a fair number of nits, partly due to inconsistent cross referencing in s18. Major Issues: None Minor Issues: Non-incorporation of RFC 7283: Is there a good reason why the update of relay agent behaviour (which is apparently of general application across DHCPv6) is not incorporated into this document as with several other items? The update is short and would be readily addressed in s19 here. As it is one is left with another document with some key modifications left around rather than achieving the unification aim of this -bis. Non-incoporation of RFC 8213: Similarly regarding use of IPsec for server-relay agent comms. Definitions of T1 andT2: I find the definitions of T1 and T2 as replicated in many places to be a little confusing. T1 and T2 are actually time intervals rather than absolute times. I suggest a global substitution as follows: OLD: The time at which the client contacts the server NEW: The time interval after which the client would be expected to contact the server END s6: Might be worth pointing out the pitfalls of defining additional stateful services as had to be sorted out with RFC 7550. s11.2: [This is not explicitly an issue with this document, but affects its usage] The list of hardware types originally listed for ARP, is now well out of date - in particular it doesn't cover Ethernet interfaces faster than 10Mb/s. Perhas somebody could suggest some updates to Carlos Pignatoro (the designated expert). s12.2: > A client must create at least one distinct > IA_PD. Is it not the case that the majority of simple hosts are not concerned with IA_PD? I think this needs qualifying to say that if a client is interested in obtaining a prefix, then it has to create an IA_PD. s18.3, s18.3.11 and s19, Recording and/or reproduction of the relay address chain in servers: I found the lack of description of server handling of received messages embedded in relay-forward messages in s18.3 required considerable searching to understand what needed to be done, and there is no mention of the expectation that the relay address chain would (or at least might) need to be recorded to facilitate later generation of Reconfigure messages that are originated by the server. I think it would be helpful to add some words about this is in s18.3 as follows: ADD (probably as new para 6, et seq): All messages sent from clients may arrive encapsulated in Relay-forward messa
[Gen-art] Genart telechat review of draft-ietf-dhc-rfc3315bis-10
Reviewer: Elwyn Davies Review result: Almost Ready [This is a Last Call Review, not a telechat review]. I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. Document: draft-ietf-dhc-rfc3315bis-10 Reviewer: Elwyn Davies Review Date: 2018-01-18 IETF LC End Date: 2018-01-24 IESG Telechat date: 2018-01-25 Summary: Amost ready. To the best of my abiity I have done a thorough check of the merging of the various earlier documents into the new -bis and the incorporation of the various Errata. All seems to be good from this point of view. I am slightly surprised that two other RFCs (7283 and 8213) were not subsumed into this document. Both are pure updates of 3315 with some important improvements and are pretty short in themselves. I also found that the new document did not do a good job on the interactions between relay-agents and servers. Particularly on the processing of options between relays and servers and details of reception of Relay-forward messages a little more detail would halp naive readers. Finally the draft has not made much of an effort to support possible alternative security algorithms - IETF policy now encourages protocols to deal with algorithm flexibility - DHCPv6 as it stands is pretty thoroughly wedded to HMAC-MD5 and would need some (relatively small) IANA improvements plus some thought to cope with different algorithms. There are also a fair number of nits, partly due to inconsistent cross referencing in s18. Major Issues: None Minor Issues: Non-incorporation of RFC 7283: Is there a good reason why the update of relay agent behaviour (which is apparently of general application across DHCPv6) is not incorporated into this document as with several other items? The update is short and would be readily addressed in s19 here. As it is one is left with another document with some key modifications left around rather than achieving the unification aim of this -bis. Non-incoporation of RFC 8213: Similarly regarding use of IPsec for server-relay agent comms. Definitions of T1 andT2: I find the definitions of T1 and T2 as replicated in many places to be a little confusing. T1 and T2 are actually time intervals rather than absolute times. I suggest a global substitution as follows: OLD: The time at which the client contacts the server NEW: The time interval after which the client would be expected to contact the server END s6: Might be worth pointing out the pitfalls of defining additional stateful services as had to be sorted out with RFC 7550. s11.2: [This is not explicitly an issue with this document, but affects its usage] The list of hardware types originally listed for ARP, is now well out of date - in particular it doesn't cover Ethernet interfaces faster than 10Mb/s. Perhas somebody could suggest some updates to Carlos Pignatoro (the designated expert). s12.2: > A client must create at least one distinct >IA_PD. Is it not the case that the majority of simple hosts are not concerned with IA_PD? I think this needs qualifying to say that if a client is interested in obtaining a prefix, then it has to create an IA_PD. s18.3, s18.3.11 and s19, Recording and/or reproduction of the relay address chain in servers: I found the lack of description of server handling of received messages embedded in relay-forward messages in s18.3 required considerable searching to understand what needed to be done, and there is no mention of the expectation that the relay address chain would (or at least might) need to be recorded to facilitate later generation of Reconfigure messages that are originated by the server. I think it would be helpful to add some words about this is in s18.3 as follows: ADD (probably as new para 6, et seq): All messages sent from clients may arrive encapsulated in Relay-forward messages. For example, if client C sent a message that was relayed by relay agent A to relay agent B and then to the server, the server would receive the following Relay-forward message to process and, in general, generate an appropriate Relay-reply to be returned to the client: msg-type: RELAY-FORWARD hop-count: 1 link-address: 0 peer-address: A Relay Message option, containing: msg-type: RELAY-FORWARD hop-count:0 link-address: address from link to which C is attached peer-address: C Relay Message option: Figure xx: Relay-forward Example Thus the server MUST record the sequence of link addresses and peer addresses together with their associated hop count values to allow the response to the received message to be relayed through the same relay agents as
Re: [Gen-art] Post-telechat review of draft-ietf-lime-yang-connectionless-oam-16
Hi, Qin. A great improvement - thanks. The only thing I would say (as I said in my last set of comments) is that I would add the identity of the document that defines the module that is imported i the actual code ofthe YANG module. The reason for this is that the YANG code will eventually be freestanding and so it is useful to be able to see where the import is coming from in the actual code rather than having to look back in the RFC. Alsoat present the document does explicitly tie the YANG module names to the defining documents which means a reader has to look through all the documents tofind whic is which (or look in the YANG index). This could be handled by a note to the RFC editor or in Auth48. Cheers,Elwyn Sent from Samsung tablet. Original message From: Qin Wu <bill...@huawei.com> Date: 12/11/2017 15:23 (GMT+00:00) To: 'Elwyn Davies' <elw...@folly.org.uk> Subject: RE: Post-telechat review of draft-ietf-lime-yang-connectionless-oam-16 Incorporated your comments in v-17, https://tools.ietf.org/rfcdiff?url2=draft-ietf-lime-yang-connectionless-oam-17.txt -Qin -邮件原件- 发件人: Qin Wu 发送时间: 2017年11月10日 15:08 收件人: Elwyn Davies <elw...@folly.org.uk>; gen-art@ietf.org; draft-ietf-lime-yang-connectionless-oam@ietf.org 主题: RE: Post-telechat review of draft-ietf-lime-yang-connectionless-oam-16 Thanks Elwyn for taking last sanity check. We will wrap up your comments in v-(17) -Qin -----邮件原件- 发件人: Elwyn Davies [mailto:elw...@folly.org.uk] 发送时间: 2017年11月10日 3:28 收件人: gen-art@ietf.org; draft-ietf-lime-yang-connectionless-oam@ietf.org 主题: Post-telechat review of draft-ietf-lime-yang-connectionless-oam-16 Hi. Some remaining comments from the earlier gen-art reviews that perhaps ought to be addressed plus some additional introduced nits. Apologies for the long delay - I failed to notice that -16 had been published and gen-art reviewers don't get new version notifications. Minor Issues: Sources of imported models: It would be useful to list the RFCs/I-Ds that define the models that are imported as a new section before the YANG definitions. Currently draft-ietf-netmod-schema-mount, draft-ietf-rtgwg-ni-model and draft-ietf-rtgwg-routing-types that are under development are not mentioned; the existing standards of RFC 6021 and RFC 7223 should also be referenced (7223 is). They should all be normative. [The references are present but they need to be linked to the module names and listed separately from the YANG specification.] Nits: s1, bullet 1: s/networks/network/ [Qin]: Fixed. s1, end of para 7: s/OAM protcols/OAM protocols/ [Qin]: Fixed. s1, last para: s/Connectionless Communicatioms/connectionless communications/ [Qin]: Fixed. s2.2, TP definition: s/diagnostic test/diagnostic tests/ [Qin]: Fixed. s3, para 10 (top of page 6): s/test- point/test-point/ [Qin]: Fixed. s3, last para: The term 'proactive' has not yet been defined. A forward reference to s3.2 is needed (e.g., "proactive (see Section 3.2)"). [Qin]: Fixed. s3.2, last para: s/be extended to specific OAM technology/is extended to cover a specific OAM technology/ [Qin]: Fixed. s3.3, para 2: OLD: OAM neighboring test points are referred to a list of neighboring test points in adjacent layers up and down the stack for the same interface that are related to the current test point. NEW: Each OAM test point may have an associated list of neighboring test points in other layers up and down the protocol stack for the same interface and are therefore related to the current test point. ENDS [Qin]: Accepted. ss3.6 and 3.7: The use of single quotes and associated spacing in these sections is not correct, and there are some other language corrections. The corrected version is suggested here: NEW: 3.6. Path Discovery Data This is a generic grouping for the path discovery data model that can be retrieved by any data retrieval methods including RPC operations. Path discovery data output from methods, includes 'src-test-point' container, 'dst-test-point' container, 'sequence-number'leaf, 'hop- cnt' leaf, session statistics of various kinds, path verification and path trace related information. Path discovery includes data to be retrieved on a 'per-hop' basis via a list of 'path-trace-info- list' items which includes information such as 'timestamp' grouping, 'ingress-intf-name', 'egress-intf-name' and 'app-meta-data'. The path discovery data model is made generic enough to allow different methods of data retrieval. None of the fields are made mandatory for that reason. Note that a set of retrieval methods are defined in [I-D.ietf-lime-yang-connectionless-oam-methods]. 3.7. Continuity Check Data This is a generic grouping for the continuity check data model that can be retrieved by any data retrieval methods including RPC operations. Continuity check data o
[Gen-art] Post-telechat review of draft-ietf-lime-yang-connectionless-oam-16
Hi. Some remaining comments from the earlier gen-art reviews that perhaps ought to be addressed plus some additional introduced nits. Apologies for the long delay - I failed to notice that -16 had been published and gen-art reviewers don't get new version notifications. Minor Issues: Sources of imported models: It would be useful to list the RFCs/I-Ds that define the models that are imported as a new section before the YANG definitions. Currently draft-ietf-netmod-schema-mount, draft-ietf-rtgwg-ni-model and draft-ietf-rtgwg-routing-types that are under development are not mentioned; the existing standards of RFC 6021 and RFC 7223 should also be referenced (7223 is). They should all be normative. [The references are present but they need to be linked to the module names and listed separately from the YANG specification.] Nits: s1, bullet 1: s/networks/network/ s1, end of para 7: s/OAM protcols/OAM protocols/ s1, last para: s/Connectionless Communicatioms/connectionless communications/ s2.2, TP definition: s/diagnostic test/diagnostic tests/ s3, para 10 (top of page 6): s/test- point/test-point/ s3, last para: The term 'proactive' has not yet been defined. A forward reference to s3.2 is needed (e.g., "proactive (see Section 3.2)"). s3.2, last para: s/be extended to specific OAM technology/is extended to cover a specific OAM technology/ s3.3, para 2: OLD: OAM neighboring test points are referred to a list of neighboring test points in adjacent layers up and down the stack for the same interface that are related to the current test point. NEW: Each OAM test point may have an associated list of neighboring test points in other layers up and down the protocol stack for the same interface and are therefore related to the current test point. ENDS ss3.6 and 3.7: The use of single quotes and associated spacing in these sections is not correct, and there are some other language corrections. The corrected version is suggested here: NEW: 3.6. Path Discovery Data This is a generic grouping for the path discovery data model that can be retrieved by any data retrieval methods including RPC operations. Path discovery data output from methods, includes 'src-test-point' container, 'dst-test-point' container, 'sequence-number'leaf, 'hop- cnt' leaf, session statistics of various kinds, path verification and path trace related information. Path discovery includes data to be retrieved on a 'per-hop' basis via a list of 'path-trace-info- list' items which includes information such as 'timestamp' grouping, 'ingress-intf-name', 'egress-intf-name' and 'app-meta-data'. The path discovery data model is made generic enough to allow different methods of data retrieval. None of the fields are made mandatory for that reason. Note that a set of retrieval methods are defined in [I-D.ietf-lime-yang-connectionless-oam-methods]. 3.7. Continuity Check Data This is a generic grouping for the continuity check data model that can be retrieved by any data retrieval methods including RPC operations. Continuity check data output from methods, includes 'src-test- point' container, 'dst-test-point' container, 'sequence-number' leaf, 'hop-cnt' leaf and session statistics of various kinds. The continuity check data model is made generic enough to allow different methods of data retrieval. None of the fields are made mandatory for that reason. Noted that a set of retrieval methods are defined in [I-D.ietf-lime-yang-connectionless-oam-methods]. ENDS s5: The import items should have a description indicating the modules from which they come including the relevant RFC numbers. Note this is in addition to a section in the introductory text summarisng what modules are imported (as noted in minor issues). s5, "container path=trace-info" description: s/like/such as/ s5. "grouping timestamp": It would be good to add references (including section numbers) to the description showing where the various timestamps are defined in the IEE PTP doc and the NTP RFC. s5, "container timestamp-64bit": I believe there is a typo in the description: OLD: "Only applies when Truncated NTP or 64bit NTP Timestamp."; NEW: "Only applies when Truncated PTP or 64bit NTP Timestamp."; ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] Genart telechat review of draft-ietf-lime-yang-connectionless-oam-13
Hi, Qin. Thanks for the quick repsonse. The fixes look good - I'll await the new version and give it a good read. One thing I forgot to check through was whether all tha abbreviations were either 'well known' (as documented in the RFC editor's list (https://www.rfc-editor.org/materials/abbrev.expansion.txt) or expanded on first occurrence. Needing expansion: DSCP (s3.1), VRF (s3.5), OWAMP/TWAMP (s4, description of grouping session-delay-statistics), MP (s4, several descriptions in grouping tp-address), AS (s4, description of identity as-number-address-type , also description of as-number - in this case it might be that s/AS number/as-number/ in the description), LSP (s4, description of lsp-id), MPLS-TE (s5.1.1.2). Checking for this has raised some additional points In the descriptions items in the features section of s4, the abbreviations rpc, ptp, ntp and icmp should be in capitals (RPC, PTP, NTP, ICMP). I think you also need references for the PTP and NTP timestamp formats. I am not sure where the short and long NTP timestamp formats are defined! Also I am not sure whether the PTP standard is readily accessible. I think you may need to look at all the various timestamp fomats that are mentioned (I missed this yesterday) and ensure that there are pointers to proper definitions in all cases. Also it would be good to explicitly mention RFC 6020 adjacent to YANG in the abstract (but not in reference format of course) and also in Section 1 as a reference. Cheers,Elwyn Sent from Samsung tablet. Original message From: Qin Wu <bill...@huawei.com> Date: 24/10/2017 08:21 (GMT+00:00) To: Elwyn Davies <elw...@dial.pipex.com>, gen-art@ietf.org Cc: draft-ietf-lime-yang-connectionless-oam@ietf.org, l...@ietf.org, i...@ietf.org Subject: RE: Genart telechat review of draft-ietf-lime-yang-connectionless-oam-13 Elwyn: Thank for your valuable comments. Please see my reply inline below. -Qin -邮件原件- 发件人: Elwyn Davies [mailto:elw...@dial.pipex.com] 发送时间: 2017年10月24日 8:42 收件人: gen-art@ietf.org 抄送: draft-ietf-lime-yang-connectionless-oam@ietf.org; l...@ietf.org; i...@ietf.org 主题: Genart telechat review of draft-ietf-lime-yang-connectionless-oam-13 Reviewer: Elwyn Davies Review result: Ready with Issues I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please wait for direction from your document shepherd or AD before posting a new version of the draft. For more information, please see the FAQ at <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. Document: draft-ietf-lime-yang-connectionless-oam-13 Reviewer: Elwyn Davies Review Date: 2017-10-23 IETF LC End Date: 2017-10-25 IESG Telechat date: 2017-10-26 Summary:Not really ready. There are several missing references and the English needs cleaning up to make the document comprehensible. I found s3 to be almost totally opaque. The fundamental concept of a Test Point needs a proper definition in s2 and a clearer introduction in s3. The concept of 'neighboring test points' confused me for some time: I was thinking of neighboring nodes in the network whereas what seesm to be meant is a possibility of a multiplicity of Major issues: None Minor issues: Title and description of model: The title refers to 'connectionless networks'. In practice the YANG model could be used with both connectionless and connection-oriented communication technologies. I think the intention is to be able to support the management of OAM protocols that operate in a connectionless manner (i.e., using connectionless *technologies*, as per RFC 7276) rather than connectionless networks. In the title - OLD: Generic YANG Data Model for Operations, Administration, and Maintenance(OAM) protocols for Connectionless networks NEW: Generic YANG Data Model for the Management of Operations, Administration, and Maintenance (OAM) Protocols that use Connectionless Communications END [Qin]: Your understanding is correct, the title change in v-13 is based on one proposal from latest comments, I agree with your new proposed changes. Thanks. Similarly, in s1, para 1, s/connections/communications/. [Qin]: Okay. In next to last para of s1: OLD: Note that the Connection-Oriented OAM YANG DATA model is defined in [I-D.ietf-lime-yang-connection-oriented-oam-model]. NEW: Note that the YANG DATA model for OAM protcols using connection-oriented communications is defined in [I-D.ietf-lime-yang-connection-oriented-oam-model]. END [Qin]: Accepted, thanks. s2.1: The term 'Test point' needs some actual definition - It appears from the body of the document that a TP is effectively equated to an interface together with an associated stack layer (MAC, IP, etc) or superimposed application technology (VPN end point, etc.). One query that came i
[Gen-art] Genart telechat review of draft-ietf-lime-yang-connectionless-oam-13
Reviewer: Elwyn Davies
Review result: Ready with Issues
I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair. Please wait for direction from your
document shepherd or AD before posting a new version of the draft.
For more information, please see the FAQ at
<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.
Document: draft-ietf-lime-yang-connectionless-oam-13
Reviewer: Elwyn Davies
Review Date: 2017-10-23
IETF LC End Date: 2017-10-25
IESG Telechat date: 2017-10-26
Summary:Not really ready. There are several missing references and the English
needs cleaning up to make the document comprehensible. I found s3 to be almost
totally opaque. The fundamental concept of a Test Point needs a proper
definition in s2 and a clearer introduction in s3. The concept of 'neighboring
test points' confused me for some time: I was thinking of neighboring nodes in
the network whereas what seesm to be meant is a possibility of a multiplicity of
Major issues:
None
Minor issues:
Title and description of model:
The title refers to 'connectionless networks'. In practice the YANG model
could be used with both connectionless and connection-oriented communication
technologies. I think the intention is to be able to support the management of
OAM protocols that operate in a connectionless manner (i.e., using
connectionless *technologies*, as per RFC 7276) rather than connectionless
networks. In the title - OLD:
Generic YANG Data Model for Operations, Administration, and
Maintenance(OAM) protocols for Connectionless networks
NEW:
Generic YANG Data Model for the Management of Operations,
Administration, and Maintenance (OAM) Protocols that
use Connectionless Communications
END
Similarly, in s1, para 1, s/connections/communications/.
In next to last para of s1:
OLD:
Note that the Connection-Oriented OAM YANG DATA model is defined in
[I-D.ietf-lime-yang-connection-oriented-oam-model].
NEW:
Note that the YANG DATA model for OAM protcols using connection-oriented
communications is defined in
[I-D.ietf-lime-yang-connection-oriented-oam-model].
END
s2.1: The term 'Test point' needs some actual definition - It appears from the
body of the document that a TP is effectively equated to an interface together
with an associated stack layer (MAC, IP, etc) or superimposed application
technology (VPN end point, etc.). One query that came into my mind around this
was what happens if the IP address associated with an interface is changed
dynamically (e.g., when using IPv6 privacy addresses). Can the YANG manager
understand that it is still dealing with the same interface although the IP
address has changed? I wondered if the interfaces really needed some sort of
identifier (e.g., interface number) that would tie all the pieces together as
well as the intra-/inter-layer pointers.
s3.3:
>OAM
>neighboring test points are referred to a list of neighboring test
>points in the same layer that are related to the current test point.
>This allows users to easily navigate between related neighboring
>layers to efficiently troubleshoot a defect. In this model, the
>'position' leaf defines the relative position of the neighboring test
>point corresponding to the current test point in the same layer, and
>is provided to allow correlation of faults at different locations.
I don't understand what is going on here. Doesn't fault correlation require
association of test points in adjacent layers up amd down the stack for the
same interface rather than the same layer? The before/after story then allows
the manager to go up and down the stack looking at wat is going on in the
different layers. I can't see any likelihood of there being multiple test
points in the same layer in a given interface (unless this has something to do
with possible different administrative domains. Help! If this is altered, the
similar text in the descriptions of oam-neighboring-tps (in s4) will need to be
made consistent.
Sources of imported models: It would be useful to list the RFCs/I-Ds that
define the models that are imported. Currently draft-ietf-netmod-schema-mount,
draft-ietf-rtgwg-ni-model and draft-ietf-rtgwg-routing-types that are under
development are not mentioned; the existing standards of RFC 6021 and RFC 7223
should also be referenced (7223 is). They should all be normative.
Nits/editorial comments:
idnits: complains about some overlong lines... probably ones with 'when
"derived-from-or-self(' General: As mentioned by other reviews, there area
considerable number of places where it appears that " '" should really be "' "
and there are missing spaces after single quotes.
General: The document is inconsistent in its use of
connectionless/connection-less/connection less.
Re: [Gen-art] [Teas] Genart last call review of draft-ietf-teas-rsvp-te-scaling-rec-06
Hi, Pavan. Sorry for the delay in replying. Yes, I meant RFC 2205 in a couple of places where I said RFC 2209. Oops! I had a think about the points below and I believe there may still be things to be noted. My thoughts are inline below. Cheers, Elwyn On 06/10/2017 22:23, Vishnu Pavan Beeram wrote: Lou, Thanks for the response. I think that settles the "update" debate. Elwyn, Hi! Are you satisfied with my other responses? I'll submit a new revision as agreed in my responses. Regards, -Pavan On Fri, Oct 6, 2017 at 3:31 PM, Lou Berger <lber...@labn.net <mailto:lber...@labn.net>> wrote: Hi Pavan, On 10/05/2017 07:44 AM, Vishnu Pavan Beeram wrote: > Lou, Hi! > > Responses inline (prefixed PB). > > Regards, > -Pavan > > From: Lou Berger <lber...@labn.net <mailto:lber...@labn.net> <mailto:lber...@labn.net <mailto:lber...@labn.net>>> > Date: Thursday, October 5, 2017 at 6:41 AM > To: "ext-vishnupa...@gmail.com <mailto:ext-vishnupa...@gmail.com> <mailto:ext-vishnupa...@gmail.com <mailto:ext-vishnupa...@gmail.com>>" > <vishnupa...@gmail.com <mailto:vishnupa...@gmail.com> <mailto:vishnupa...@gmail.com <mailto:vishnupa...@gmail.com>>>, Elwyn Davies > <elw...@dial.pipex.com <mailto:elw...@dial.pipex.com> <mailto:elw...@dial.pipex.com <mailto:elw...@dial.pipex.com>>> > Cc: "gen-art@ietf.org <mailto:gen-art@ietf.org> <mailto:gen-art@ietf.org <mailto:gen-art@ietf.org>>" <gen-art@ietf.org <mailto:gen-art@ietf.org> > <mailto:gen-art@ietf.org <mailto:gen-art@ietf.org>>>, > "draft-ietf-teas-rsvp-te-scaling-rec@ietf.org <mailto:draft-ietf-teas-rsvp-te-scaling-rec@ietf.org> > <mailto:draft-ietf-teas-rsvp-te-scaling-rec@ietf.org <mailto:draft-ietf-teas-rsvp-te-scaling-rec@ietf.org>>" > <draft-ietf-teas-rsvp-te-scaling-rec@ietf.org <mailto:draft-ietf-teas-rsvp-te-scaling-rec@ietf.org> > <mailto:draft-ietf-teas-rsvp-te-scaling-rec@ietf.org <mailto:draft-ietf-teas-rsvp-te-scaling-rec@ietf.org>>>, > "t...@ietf.org <mailto:t...@ietf.org> <mailto:t...@ietf.org <mailto:t...@ietf.org>>" <t...@ietf.org <mailto:t...@ietf.org> > <mailto:t...@ietf.org <mailto:t...@ietf.org>>>, ietf <i...@ietf.org <mailto:i...@ietf.org> <mailto:i...@ietf.org <mailto:i...@ietf.org>>> > Subject: Re: [Teas] Genart last call review of > draft-ietf-teas-rsvp-te-scaling-rec-06 > > Hi Pavan, > > WRT if this document updates rfc2961: > > I don't have a strong opinion on or objection to this document updating > rfc2961. To have this document be an update, I do think we and it need > to be clear on what exactly is being updated in 2961. After rereading > both it's unclear to me what you see is being updated. As best I can > see, this document basically relates to 2961 in that it says (a) use the > reliable message delivery defined in 2961 and (b) restates that 2205 > refresh processing of path and resv messages still applies after a rapid > retry period expires and (c) sending acks moves from recommended to > required. > > What did I miss? > > FWIW I think (a) and (c) are requirements of this document not 2961 and > (b) seems like an informative statement that the basic refresh > processing rules of rfc2205 still apply. > > -- > [PB] This is all about how we interpret (b). RFC2961 doesn’t explicitly > state what happens the rapid retry period expires. The current draft > explains what needs to be done. Does this warrant an official update to > RFC2961? The RFC doesn't generally review unmodified RFC2205 processing, nor has that been the normal practice when defining RSVP extensions. An informative statement in this draft certainly would do no harm if you feel that it is needed, but I don't think it raises to the level of an update. Thanks, Lou > — > > Thanks > Lou > > On October 1, 2017 9:14:15 AM Vishnu Pavan Beeram <vishnupa...@gmail.com <mailto:vishnupa...@gmail.com> > <mailto:vishnupa...@gmail.com <mailto:vishnupa...@gmail.com>>> wrote: > >> Elwyn, Hi! >> >> Please see inline for responses. >> >> Regards, >> -Pavan >> >> On Fri, Sep 29, 2017 at 1:34 PM, Elwyn Davies <elw...@
Re: [Gen-art] [Teas] Genart last call review of draft-ietf-teas-rsvp-te-scaling-rec-06
Hi, Pavan. I've checked through the changes in -07 and I think all is good as regards fixing the 'major issue', restucturing s2 and fixing the nits - thanks. Looking at the IESG comments I think you have covered most of them except it would be good to put a pointer to Appendix A into the intro of s2. With reference to Appendix A(d), it would be helpful to s/periodic retransmission interval/Periodic Retransmission Interval/ and possibly give it a name (Rpri or some such) in s2.3 and Appendix A(d). Adding the name of the interval after "retransmission of these on a slower timer" migt mak it clearer also. However, I think you still need to address all three of the minor issues:- Capability object: A 'basic' implementation of RFC 2209/RFC3209 will not include the RFC5063 extensions. I think you should therefore make it explicit that a prerequisite for your extensions is an implementation of the Capability object as specified in RFC5063 (my proposal for s3) , making it clear that this does not require any of the other functionality of RFC 5063, especially no support for the S bit in the Capabilities.- Your response regarding what happens if a peer initially acknowledges that it supports the new capabilities by setting the I/F bits in the Capability and sends some messages with the Refresh-Reduction-Capable bit set, but then stops setting the Refresh-Reduction-Capable bit doesn't really address the problem. Would this mean that the receiver should assume that the peer can no longer support the extensions? Is this a permanent state or could the peer start setting the Refresh-Reduction-Capable bit again and restore initial functionality - or should this just not be allowed. I think you need to think through what happes in the various possible cases and explain what an implementation should do in each case.- So, I have done my homework and checked back on what happens when there is no acknowledgement of refreshes. The relevant parameter is the cleanup time. However, this leaves us with a problem.. the cleanup time is typically set as a multiple of the refresh interval (9 times seems to be the default) - indeed I see that the interface configuration on a Juniper router (!) actually sets it by asking for the multiple rather than an absolute value. Wth the new dispensation in ths document, there are two time periods involved: I think you do need to respecify how to calculate a sensible cleanup interval, and note that the retransmissions will then halt after this interval. Does this last modification constitute an update of RFC 2209? I am not sure -consult your AD! Regards,Elwyn Sent from Samsung tablet. Original message From: Vishnu Pavan Beeram <vishnupa...@gmail.com> Date: 28/09/2017 03:48 (GMT+00:00) To: Elwyn Davies <elw...@dial.pipex.com> Cc: gen-art@ietf.org, draft-ietf-teas-rsvp-te-scaling-rec@ietf.org, ietf <i...@ietf.org>, t...@ietf.org Subject: Re: [Teas] Genart last call review of draft-ietf-teas-rsvp-te-scaling-rec-06 Elwyn, Hi! Thanks for the detailed review and the text suggestions. We just posted a new revision (-07) to address the concerns listed below. Please go through the new diffs (https://www.ietf.org/rfcdiff?url2=draft-ietf-teas-rsvp-te-scaling-rec-07) and let us know if additional changes are required. Please see inline for further responses (prefixed VPB). Regards, -Pavan On Fri, Sep 22, 2017 at 6:06 PM, Elwyn Davies <elw...@dial.pipex.com> wrote: Reviewer: Elwyn Davies Review result: Not Ready I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. Document: draft-ietf-teas-rsvp-te-scaling-rec-06 Reviewer: Elwyn Davies Review Date: 2017-09-22 IETF LC End Date: 2017-09-22 IESG Telechat date: 2017-09-28 Summary: Not ready, primarily because the title and presentation give the impression that the content is really a BCP when it isn't. This conceals the considerable amount of tweaking of RFC 2961 functionality and addition of new RSVP Capabilities described in the document. There are also a couple of minor issues that need to be sorted out. Major issues: Title and way proposals are presented: The document defines two new 'capabilities' for RSVP-TE and is indeed (as specified in the document header) correctly intended for Standards Track status. However the title and the whole of the meat of the document in Section 2 presents the proposals as 'recommendations' which says to me that I am expecting a BCP where a profile of available options from existing standards is recommended as the best choice for implementation and deployment. In my opinion, the title would
[Gen-art] Genart last call review of draft-ietf-teas-rsvp-te-scaling-rec-06
Reviewer: Elwyn Davies Review result: Not Ready I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. Document: draft-ietf-teas-rsvp-te-scaling-rec-06 Reviewer: Elwyn Davies Review Date: 2017-09-22 IETF LC End Date: 2017-09-22 IESG Telechat date: 2017-09-28 Summary: Not ready, primarily because the title and presentation give the impression that the content is really a BCP when it isn't. This conceals the considerable amount of tweaking of RFC 2961 functionality and addition of new RSVP Capabilities described in the document. There are also a couple of minor issues that need to be sorted out. Major issues: Title and way proposals are presented: The document defines two new 'capabilities' for RSVP-TE and is indeed (as specified in the document header) correctly intended for Standards Track status. However the title and the whole of the meat of the document in Section 2 presents the proposals as 'recommendations' which says to me that I am expecting a BCP where a profile of available options from existing standards is recommended as the best choice for implementation and deployment. In my opinion, the title would be better as something like "Additional Capabilities Designed to Improve the Scalability of RSVP-TE Deployments". Whilst the proposals are based on the techniques in RFC 2961, the document *requires* the implementor to conform to rules that were optional and constrains configurable values to different ranges in order to be able to deliver the capabilities defined in the document as well as defining new RSVP extensions modifying some of the behaviour defined in RFC 2961. Thus although some of the rules could be met by choosing particular values within the RFC 2961 set, the use of MUST, tweaking of functionality and variation of ranges takes it well beyond a set of recommendations for RFC 2961 options selections. In view of this Section 1 needs to be written as an introduction to the definitions of the new capabilities rather than advocacy for selection of RFC 2961 options and the implication that the techniques mentioned in the last paragraph of s1 are just a matter of selecting a profile of option values. In actuality new protocol values are introduced and ss2.2 and 2.3 define novel extensions to RSVP beyond what is available for RFC 2961 and requiring modification to basic RFC 2961 functionality.. Minor issues: Interaction with RFC 5063: The document does not explicitly state that an implementation would need to support (at least) the extra capability obect defined in s4.2 of RFC 5063. Some words about interaction with RFC 5063 are probably required in that s4.2.1 of RFC 5063 rather assumes that if there is a capability object, by default its S bit will be set. Behaviour if a node stops setting Refresh-Reduction-Capable bit: The last para of s2 in RFC 2961 discusses behaviour if a node stops setting this bit in messages. What would happen with the extensions defined in this document if this happened while either of the extensions is in use? As a matter of interest, if a peer offers the capabilities defined in this draft, is it possible or sensible for it to stop setting the Refresh-Reduction-Capable bit without stopping offering the extensions? s2.1.3, para 2: As specified, it appears that the 'slower timer' transmission of Path and Resv messages can go on indefinitely if no ack arrives. What puts an end to this repetition? [It may be that I have forgotten how basic RSVP works, but since this is altering the behaviour it would be good to explain how it terminates, and whether this requires any additional modification to timers.] Nits/editorial comments: Abstract: RSVP-TE is not a 'well-known' abbreviation: s/RSVP-TE/RSVP Traffic Engineering (RSVP-TE)/ Abstract and s1, first para: This para is not future proof. Suggest: OLD: The scale at which RSVP-TE [RFC3209] Label Switched Paths (LSPs) get deployed is growing continually and there is considerable onus on RSVP-TE implementations across the board to keep up with this increasing demand in scale. NEW: At the time of writing, networks which utilise RSVP Traffic Engineering (RSVP-TE) [RFC3209] Label Switched Paths (LSPs) are encountering limitations in the ability of implementations to support the growth in the number of LSPs deployed. This document defines two additional RSVP-TE extensions that are intended to reduce the number of messages needed to maintain RSVP-TE soft state in routers and hence allow implementations to support larger scale deployments. ENDS Note: Omit reference from Abstract. s1, para 2: s/under certain/beyond a certain/ s1, para 3: s/makes a set of concrete implementation recomme
Re: [Gen-art] [Teas] Genart telechat review of draft-ietf-teas-pce-central-control-04
Hi, Adrian. OK, it's a fair cop. Cheers,Elwyn Sent from Samsung tablet. Original message From: Adrian Farrel <adr...@olddog.co.uk> Date: 04/09/2017 17:59 (GMT+00:00) To: 'Elwyn Davies' <elw...@dial.pipex.com>, gen-art@ietf.org Cc: draft-ietf-teas-pce-central-control@ietf.org, i...@ietf.org, t...@ietf.org Subject: RE: [Teas] Genart telechat review of draft-ietf-teas-pce-central-control-04 Hi Elwyn, -04 has Some of this will be the TED as is normal for a PCE and can be collected using the mechanisms already in place (such as listening to the IGPs, using BGP-LS [RFC7752], or northbound export of YANG- encoded data [I-D.ietf-teas-yang-te-topo]).-05 has Some of this will be the TED as is normal for a PCE and can be collected using the mechanisms already in place (such as listening to the IGPs, using BGP-LS [RFC7752], or northbound export of YANG- encoded data [I-D.ietf-teas-yang-te-topo] from the network elements to the controller). I think that probably gives enough context. Yes, thanks for the typo in 2.1.2. I'll save it for Auth48. A From: Elwyn Davies [mailto:elw...@dial.pipex.com] Sent: 04 September 2017 14:46 To: adr...@olddog.co.uk; gen-art@ietf.org Cc: draft-ietf-teas-pce-central-control@ietf.org; i...@ietf.org; t...@ietf.org Subject: RE: [Teas] Genart telechat review of draft-ietf-teas-pce-central-control-04 Hi, Adrian. Two points:- I don't see an explanation of northbound in -05.- In the new text at the end of s2.1.2 s/whole the controllers/while the controllers/ Otherwise, the extra text and changes look helpful. Best wshes,Elwyn Sent from Samsung tablet. Original message From: Adrian Farrel <adr...@olddog.co.uk> Date: 04/09/2017 10:47 (GMT+00:00) To: 'Elwyn Davies' <elw...@dial.pipex.com>, gen-art@ietf.org Cc: draft-ietf-teas-pce-central-control@ietf.org, i...@ietf.org, t...@ietf.org Subject: RE: [Teas] Genart telechat review of draft-ietf-teas-pce-central-control-04 Thanks Elwyn, Clarified in the next revision. Adrian > -Original Message- > From: Teas [mailto:teas-boun...@ietf.org] On Behalf Of Elwyn Davies > Sent: 28 August 2017 20:24 > To: gen-art@ietf.org > Cc: draft-ietf-teas-pce-central-control@ietf.org; i...@ietf.org; t...@ietf.org > Subject: [Teas] Genart telechat review of draft-ietf-teas-pce-central-control-04 > > Reviewer: Elwyn Davies > Review result: Ready with Nits > > I am the assigned Gen-ART reviewer for this draft. The General Area > Review Team (Gen-ART) reviews all IETF documents being processed > by the IESG for the IETF Chair. Please wait for direction from your > document shepherd or AD before posting a new version of the draft. > > For more information, please see the FAQ at > > <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. > > Document: draft-ietf-teas-pce-central-control-04 > Reviewer: Elwyn Davies > Review Date: 2017-08-28 > IETF LC End Date: 2017-08-24 > IESG Telechat date: 2017-08-31 > > Summary: Thanks for addressing my Last Call comments on -03. The new version > is ready with one introduced nit. Also I am still of the abstract is somewhat > overlong. > > Nit: > s6, para 2: The SDN term 'northbound' has appeared in the new version. Needs > brief explanation. > > Major issues: > > Minor issues: > > Nits/editorial comments: > > > ___ > Teas mailing list > t...@ietf.org > https://www.ietf.org/mailman/listinfo/teas___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] [Teas] Genart telechat review of draft-ietf-teas-pce-central-control-04
Hi, Adrian. Two points:- I don't see an explanation of northbound in -05.- In the new text at the end of s2.1.2 s/whole the controllers/while the controllers/ Otherwise, the extra text and changes look helpful. Best wshes,Elwyn Sent from Samsung tablet. Original message From: Adrian Farrel <adr...@olddog.co.uk> Date: 04/09/2017 10:47 (GMT+00:00) To: 'Elwyn Davies' <elw...@dial.pipex.com>, gen-art@ietf.org Cc: draft-ietf-teas-pce-central-control@ietf.org, i...@ietf.org, t...@ietf.org Subject: RE: [Teas] Genart telechat review of draft-ietf-teas-pce-central-control-04 Thanks Elwyn, Clarified in the next revision. Adrian > -Original Message- > From: Teas [mailto:teas-boun...@ietf.org] On Behalf Of Elwyn Davies > Sent: 28 August 2017 20:24 > To: gen-art@ietf.org > Cc: draft-ietf-teas-pce-central-control@ietf.org; i...@ietf.org; t...@ietf.org > Subject: [Teas] Genart telechat review of draft-ietf-teas-pce-central-control-04 > > Reviewer: Elwyn Davies > Review result: Ready with Nits > > I am the assigned Gen-ART reviewer for this draft. The General Area > Review Team (Gen-ART) reviews all IETF documents being processed > by the IESG for the IETF Chair. Please wait for direction from your > document shepherd or AD before posting a new version of the draft. > > For more information, please see the FAQ at > > <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. > > Document: draft-ietf-teas-pce-central-control-04 > Reviewer: Elwyn Davies > Review Date: 2017-08-28 > IETF LC End Date: 2017-08-24 > IESG Telechat date: 2017-08-31 > > Summary: Thanks for addressing my Last Call comments on -03. The new version > is ready with one introduced nit. Also I am still of the abstract is somewhat > overlong. > > Nit: > s6, para 2: The SDN term 'northbound' has appeared in the new version. Needs > brief explanation. > > Major issues: > > Minor issues: > > Nits/editorial comments: > > > ___ > Teas mailing list > t...@ietf.org > https://www.ietf.org/mailman/listinfo/teas ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Genart telechat review of draft-ietf-teas-pce-central-control-04
Reviewer: Elwyn Davies Review result: Ready with Nits I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please wait for direction from your document shepherd or AD before posting a new version of the draft. For more information, please see the FAQ at <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. Document: draft-ietf-teas-pce-central-control-04 Reviewer: Elwyn Davies Review Date: 2017-08-28 IETF LC End Date: 2017-08-24 IESG Telechat date: 2017-08-31 Summary: Thanks for addressing my Last Call comments on -03. The new version is ready with one introduced nit. Also I am still of the abstract is somewhat overlong. Nit: s6, para 2: The SDN term 'northbound' has appeared in the new version. Needs brief explanation. Major issues: Minor issues: Nits/editorial comments: ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Genart last call review of draft-ietf-teas-pce-central-control-03
Reviewer: Elwyn Davies Review result: Almost Ready I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. Document: draft-ietf-teas-pce-central-control-03 Reviewer: Elwyn Davies Review Date: 2017-08-20 IETF LC End Date: 2017-08-24 IESG Telechat date: 2017-08-31 Summary: Amost ready. I found this a well-written and mostly readily comprehensible document although it contains a couple of instances of unexplained SDN/PCE jargon (notably 'southbound'). My main concern is that the archtecture suggests that extensions to PCEP will a.s. be needed and implies that mechanisms will be needed to provide multiple extensions but neither specifies detailed guidance as to how this might be done or points to work in progress that would provide this guidance. The implication of the statements in this document are that an implementation or deployment might need to check if particlar extensions are implemented in communication partners and also how to behave if an unreconixed extension is received especially to avoid possible DoS. The other minor issues are only just abve the level of nits. Major issues: None Minor issues: Abstract: The abstract is probably overlong. s1: RFC 4655 is itself an architecture that introduces the PCE. It would be helpful to explain that this document is an extension of the basic PCE arcitecture except that it relies on the specific use f the PCEP for intercommunication between architectural elements providing traffic control and routing whereas RFC 4655 does not assume any particular protocol. s3.2: It would be desirable to reiterate the problem of synchronization mentioned in s2.1.2 which is relevant to all the high level functions. s4: Since this document effectively gurantees that extensions to PCEP will be created and since RFC 5440 contains no extensibility procedures/guidelines, it seems to me that either this document should indicate how PCEP extensions and profiles are added to the base protocol or should point to a (normative and currently non-existent) document that updates RFC 5440 and defines how extensions shoould be structured and provides ways for implementations to determine what is supported, if necessary. s5, para 2: The second part of this paragraph; However, debate will rage over overall system security and the opportunity for attacks in an architecture with a central controller since the network can be vulnerable to denial of service attacks on the controller, and the forwarding system may be harmed by attacks on the messages sent to individual NEs. In short, while the interactions with a PCE-based controller are not substantially different from those in any other SDN architecture, the security implications of SDN are still open for discussion. The IRTF's SDN Research Group (SDNRG) discussed this topic. This text needs to be rewritten to be suitable for inclusion in an RFC that is a document of record. s6: The PCE, depending on which of the aspects mentioned in s3 and the technology being managed (LSPs, transport paths, etc.) are involved in a particular imlemetation/deployment, will need to access the relevant state information in NEs and possibly other PCEs using relevant managent protcol(s) and MIBs or similar. Integrating this state information with the PCEP management information wil be key to effective operation of the centralized PCE system. s10: It is arguable, IMO, that RFC 5440 and I-D.ietf-pce-pce-initiated-lsp are normative references. The architecture implies their usage and someone implementing the architecture would need to be familiar with the details of the extended PCEP, particularly in respect of the manageability and security aspects of the protocol. Nits/editorial comments: Abstract, para 1: Statements of implied omnipotence by mortals a.s. lead to hubristic consequences... s/any definition of "optimal"/virtually any definition of "optimal"/ Abstract (and subseqently): The term 'southbound' is SDN specific jargon and should be explained. Given that the abstract is already (IMO) too long, it would be wise to remove it from the abstract (I don't think it is essential) and provide the explation in s1. s1, para 4: See comment above... s/any form of routed or switched network./virtually any form of routed or switched network./ s2, para 2 and Figures 1-7: It would be useful to add a note in s2 to indicate that the TED box in all the figures should imply that other databases may also be accessed. s2, last para (just before Fig.3): s/use case- specific/use case-specific [or use case specific]/ s2.1, para 1: The text at the beginning of the para doesn't read very easily - the 'or' disguises the fact that the
[Gen-art] Genart telechat review of draft-ietf-sipcore-content-id-07
Reviewer: Elwyn Davies Review result: Ready I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please wait for direction from your document shepherd or AD before posting a new version of the draft. For more information, please see the FAQ at <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. Document: draft-ietf-sipcore-content-id-07 Reviewer: Elwyn Davies Review Date: 2017-07-04 IETF LC End Date: 2017-06-27 IESG Telechat date: 2017-07-06 Summary: Ready. Thank you for addressing the comments in my last call review. Major issues: Minor issues: Nits/editorial comments: The references to RFC 5368 and RFC 6442 are informative rather than normative - you don't need the details to implement this update. ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] Genart last call review of draft-ietf-sipcore-content-id-06
Hi, Christer. Thanks for the quick response. Looks like we are clear on all this, except that:1. I would suggest making it explicit that you can add a Content-ID header even to a message with a multipart message-body to avoid any confusion. I am not sure that it makes any sense but I guess it wouldn't do any harm. 2. If a message of a kind that can legitimately have a Content-ID arrives with a Content-ID (or indeed any Content-*) header but no message-body, presumably one would send a 400 error with a suitable reason phrase. I think it would be worth being explicit about this. Cheers,Elwyn Sent from Samsung tablet. Original message From: Christer Holmberg <christer.holmb...@ericsson.com> Date: 23/06/2017 12:45 (GMT+00:00) To: Elwyn Davies <elw...@dial.pipex.com>, gen-art@ietf.org Cc: draft-ietf-sipcore-content-id@ietf.org, sipc...@ietf.org, i...@ietf.org Subject: RE: Genart last call review of draft-ietf-sipcore-content-id-06 Hi Elwyn, Thank You for the review! Please see inline. >Summary: >Ready with nits. There are a couple of minor issues related to the procedures >after inappropriate usage of the new header. > >Major issues: >None > >Minor issues: > > s3.4.1, last para: In line with the last sentence of Section 3.2, the > Content-ID URL only needs to be unique within the SIP message where it occurs. > I assume it does not make sense to have a Content-ID header combined with a >mutipart message-body (this isn't stated - maybe it should be); I am not aware of any current use-case, but I see no reason to forbid it. Perhaps someone will come up with a use-case in future. > I am not sufficiently knowledgeable in this area of SIP to know if there > could be content-id URLs in other headers if there is a Content-ID > header in the message. Thus either the statement about global uniqueness is > irrelevant (as there is only one) and can be removed or it > should be made consistent with s3.2 so that the Content URLs are unique > within the message. Global uniqueness is neither possible or required. The statement about global uniqueness is a bug, and will be fixed. The value only has to be unique within the message. > s3.4.1, para 1: Following on from the previous comment: Is a UA allowed to > add a Content-ID header to a message with a multipart message-body? I see no reason to forbid it. > s3.4.1: What should a UA do if it receives a message with a Content-ID header > when the message is not allowed to > contain one? Is there some generic error procedure that should be referenced? Normal RFC 3261 procedures apply. I don't think we want to copy/paste the generic header processing rules, > s6.1: I started looking for specification that told me that items added to > the SIP header fields registry effectively > extend the definition of the message-header production in Section 25.1of RFC > 3261. Bit obvious perhaps, but it > would be nice if it had been said somewhere! Time for an Erratum perhaps? In the ABNF of RFC 3261, "message-header" contains the header fields defined in the RFC, plus "extension-header", which is used for new headers. I assume people think that is clear enough :) Having said that, what you suggest is not necessarily a bad idea, but it is outside the scope of this draft. >Nits/editorial comments: > >Abstract: I would suggest adding a sentence that clarifies what the update of >RFC 5621 is modifying: > >OLD: The document also updates RFC 5621, to enable a Content-ID URL to >reference a complete >message-body and metadata provided by some additional SIP header fields. > >NEW: The document also updates RFC 5621, which only allows a Content-ID URL >to reference a >body-part that is part of a multipart message-body. This update enables a >Content-ID URL to >reference a complete message-body and metadata provided by some additional SIP >header fields. END Looks ok. I will modify as suggested. >s1.2, first bullet: s/for providing location/for providing location >information/ Will be fixed as suggested. >s1.4.1: Need to expand UAC (User Agent Client) on first usage. I realized the first usage is in section 1.3, so I will expend it there. >s1.4.1, para 1: s/can be e.g. of/can be, for example, of/ Will be fixed as suggested. >s3.4.1: Need to expand UA (User Agent) on first usage (in section title). Will be fixed as suggested. >s4, NEW text: s/allow creating/allow the creation of/ Will be fixed as suggested. Regards, Christer ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Genart last call review of draft-ietf-sipcore-content-id-06
Reviewer: Elwyn Davies Review result: Ready with Nits I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. Document: draft-ietf-sipcore-content-id-06 Reviewer: Elwyn Davies Review Date: 2017-06-22 IETF LC End Date: 2017-06-27 IESG Telechat date: Not scheduled for a telechat Summary: Ready with nits. There are a couple of minor issues related to the procedures after inappropriate usage of the new header. Major issues: None Minor issues: s3.4.1, last para: In line with the last sentence of Section 3.2, the Content-ID URL only needs to be unique within the SIP message where it occurs. I assume it does not make sense to have a Content-ID header combined with a mutipart message-body (this isn't stated - maybe it should be); I am not sufficiently knowledgeable in this area of SIP to know if there could be content-id URLs in other headers if there is a Content-ID header in the message. Thus either the statement about global uniqueness is irrelevant (as there is only one) and can be removed or it should be made consistent with s3.2 so that the Content URLs are unique within the message. Global uniqueness is neither possible or required. s3.4.1, para 1: Following on from the previous comment: Is a UA allowed to add a Content-ID header to a message with a multipart message-body? s3.4.1: What should a UA do if it receives a message with a Content-ID header when the message is not allowed to contain one? Is there some generic error procedure that should be referenced? s6.1: I started looking for specification that told me that items added to the SIP header fields registry effectively extend the definition of the message-header production in Section 25.1of RFC 3261. Bit obvious perhaps, but it would be nice if it had been said somewhere! Time for an Erratum perhaps? Nits/editorial comments: Abstract: I would suggest adding a sentence that clarifies what the update of RFC 5621 is modifying: OLD: The document also updates RFC 5621, to enable a Content-ID URL to reference a complete message-body and metadata provided by some additional SIP header fields. NEW: The document also updates RFC 5621, which only allows a Content-ID URL to reference a body-part that is part of a multipart message-body. This update enables a Content-ID URL to reference a complete message-body and metadata provided by some additional SIP header fields. END s1.2, first bullet: s/for providing location/for providing location information/ s1.4.1: Need to expand UAC (User Agent Client) on first usage. s1.4.1, para 1: s/can be e.g. of/can be, for example, of/ s3.4.1: Need to expand UA (User Agent) on first usage (in section title). s4, NEW text: s/allow creating/allow the creation of/ ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Genart telechat review of draft-ietf-oauth-native-apps-11
Reviewer: Elwyn Davies Review result: Almost Ready I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please wait for direction from your document shepherd or AD before posting a new version of the draft. For more information, please see the FAQ at <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. Document: draft-ietf-oauth-native-apps-11 Reviewer: Elwyn Davies Review Date: 2017-05-23 IETF LC End Date: 2017-05-16 IESG Telechat date: 2017-05-25 Summary: (still) Almost ready. Thanks for the responses to my last call review of -10 which have addressed several of the comments. It seems to me that there still some issues with ensuring the selection of, and hence the connection to, the browser providing access to the authorization services is secure (this was referred to in my previous review but only (IMO)pary addressed). This feels like a considerable problem but I am neither a deep security expert or OAuth expert so I may be wrong. My old fogey soul is deeply offended by this new fangled usage of 'app' which is still in my book an abbreviation, but I guess I have to bow to the changing times and the acknowledgment that 'app' is now dignified by an appearance in the OED. >shame<. Still, given that RFC 6749 lives on the other side of the app/application divide, I think that the examples in the abstract and the beginning of s1 should match with RFC 6749 which uses 'native application(s).' There are also a couple more nits that I missed on the previous pass. [BTW UI is indeed a well-known abbreviation but given it is only used once it might be worh expanding it.] I understand that -12 has been submitted but had not been placed in the public repository as of 9pm UTC on 2017/05/23 (Tuesday evening my time). Major issues: Possibly 2nd minor issue is actually major. Minor issues: Relationship between (web) browser, (operating) system and user choice of browser: The terminology definition of 'browser' in s3: "browser" The default application launched by the operating system to handle "http" and "https" scheme URI content. The terminology of 'system browser' used in version 10 of the draft has been removed but the term 'default application' could still be interpreted as a system choice. As far as I know, although some operating systems have a preinstalled browser which will be the 'default browser', this is a commercial decision and users usually have the option to install an alternative browser and instruct the OS to use this as the application used to handle http/https content. I suggest that 'user selected application' would be clearer than 'default application'. In particular Linux installations have no default application - the user/installer has to separately install a browser and set it as the default. Security implications of browser application selection and activation: [This could possibly be consdiered as a major issue.] AFAIK the choice of application that is invoked to handle http/https content is a user choice made on a per-user configuration that does not require special privileges. Typically a browser application will allow a user to select it as default http/https content when it is first run by a given user and the choice can be changed at the user's whim subsequently. However there is no requirement to involve the user. A user-level application could (AFAICS) happily hijack the configuration and install itself as selected browser without any user intervention. Apart from the obvious possibility of DoS, I am not sufficiently expert in the details of OAuth to know what the consequences of a bad actor installing a malicious pseudo-browser, potentially acting as a MiTM or otherwise, might be. It strikes me that a user of OAuth might be concerned that the browser acting as intermediary was what s/he thought it was. Nits/editorial comments: Abstract: 'Native apps' needs a reference to Section 9 of RFC 6749. I note that there they are (still) called 'native applications'. Suggest you postpone introducing the shorthand 'native apps' to section 1 and indicate that the browser is a web browser. Thus: OLD: OAuth 2.0 authorization requests from native apps should only be made through external user-agents, primarily the user's browser. This specification details the security and usability reasons why this is the case, and how native apps and authorization servers can implement this best practice. NEW: OAuth 2.0 authorization requests from native applications, as described in Section 9 of RFC 6749, should only be made through external user-agents, primarily the user's web browser. This specification details the security and usability reasons why this is the case, and how native applications and authorization servers can implement this best practice. END s1, para 1: In
[Gen-art] Genart last call review of draft-ietf-oauth-native-apps-10
Reviewer: Elwyn Davies Review result: Almost Ready I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. Document: draft-ietf-oauth-native-apps-10 Reviewer: Elwyn Davies Review Date: 2017-05-15 IETF LC End Date: 2017-05-16 IESG Telechat date: 2017-05-25 Summary: Almost ready. A couple of simple minor issues could do with addressing. Major issues: None. Minor issues: s3: "browser": The browser that acts as the Oauth user-agent is conflated with the user's choice of default browser. Firstly this is not something that is discussed in RFC 6749. Secondly, the concept of 'default browser' would normally be thought of by users as the browser that is used to display the content associated with hyperlinks rather than providing Oauth services. I suggest that the implication in the body of the draft that 'the browser' is the user selected or system selected default browser needs to be at least discussed explicitly rather than buried in the terminology definitions in s3. I wonder whether ths connection is something that should be made by a separate OS setting or a setting in each native app rather than conflated with the default browser. The term "designated browser" might be useful. In all cases there might be secuity implications if a bad actor could subvert the designated browser setting. s8.1, Requirement of use of PKCE in some cases: This strict requirement really needs to be introduced in the body of the discussion rather than buried in the seurity considerations. Nits/editorial comments: General: s/i.e./i.e.,/ (3 places) Title and Abstract: s/apps/applications/g (uses before we get to terminology in s3) s1, para 1: Suggest the following to make it clear that the definition is in RFC 6749 rather than here. OLD: The OAuth 2.0 [RFC6749] authorization framework documents two approaches in Section 9 for native apps to interact with the authorization endpoint: an embedded user-agent, and an external user- agent. NEW: The OAuth 2.0 [RFC6749] authorization framework defines "native applications" in Section 9 of RFC 6749 (see also Section 3 below) and documents two approaches by whch they can interact with the authorization endpoint: an embedded user-agent, and an external user-agent. END s1, para 2: s/apps/applications/(2places) . For second case: s/native apps/native applications (shortened to "native apps" or just "apps" hereafter)/ s3, "native app": s/app/application/g in the definition. After that in the document "[native] app" is fine except for the definitions mentioned in the next comment. Worth repeating the link to Section 9 of RFC 6749. s3, All definitions after "app"; s/app/application/g in the definitions as these are not restricted to (native) apps as defined here. s3, "embedded user-agent": s/modify/modifyng/ s4, last para: s/emcompasses/encompasses/ s4, last para: s/inter-process/inter-app/ (since this term is defined) s4, last para: Might be worth pointing to the 'SHOULD' about client type assumptions in s2.1 of RFC 6749 withe reference to servers that do make assumptions. s4.1, para below figure 1: s/system browser/browser/ (or maybe "designated browser"). s5, paras 1 and 2: Reword to clarify and remove 'we gain' usage (not allowed in RFCs): OLD: Just as URIs are used for OAuth 2.0 [RFC6749] on the web to initiate the authorization request and return the authorization response to the requesting website, URIs can be used by native apps to initiate the authorization request in the device's browser and return the response to the requesting native app. By applying the same principles from the web to native apps, we gain benefits seen on the web, like the usability of a single sign-on session and the security of a separate authentication context. It also reduces the implementation complexity by reusing similar flows as the web, and increases interoperability by relying on standards- based web flows that are not specific to a particular platform. NEW: Just as URIs are used for OAuth 2.0 [RFC6749] in the HTTP protocol on the web to initiate the authorization request and return the authorization response to the requesting website, URIs can be used by native apps to initiate the authorization request in the device's browser and return the response to the requesting native app. By extending the techniques from the web to native apps, the benefits gained in the web context will also be reaped when using OAuth with native apps; benefits include the usability of a single sign-on session and the security of a separate authentication cont
[Gen-art] Genart last call review of draft-ietf-core-links-json-07
Reviewer: Elwyn Davies Review result: Not Ready I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. Document: draft-ietf-core-links-json-07 Reviewer: Elwyn Davies Review Date: 2017-04-25 IETF LC End Date: 2017-04-21 IESG Telechat date: 2017-04-27 Summary:Not ready for publication. There a number of issues that need to be addressed as discussed below. In particular whether the formats could be returned as the web link specification instead of RFC 6990 format in response to a GET /.well-known/core request. Having thought about the quote stripping/addition issue cited in Adam Roach's DISCUSS, I would take a slightly different view... see below. Major issues: Intentions: Is it one of the intentions of this draft that a server should be able to return web link descriptions using JSON or CBOR, specifically in response to GET /.well-known/core? Content formats for the new formats are registered (s3.2) - could a user ask for the alternative formats by specifying at ct filter with the GET request? It strikes me that if one has a constrained server of sufficiently limited capabilities that it wants to use CBOR then having to encode the RFC 6690 format responses for the web links requests is wasting resources. Some more thought needs to be given to this as an update to RFC 6690 - If I read correctly, RFC 6690 implicitly requires that a response to GET /.well-known/core MUST be encoded as described in RFC6690. Minor issues: Title: The document appears only to address the CoRE Web Links format rather than any other. Should the title reflect this more precisely, e.g., Representing CoRE Web Links Format in JSON and CBOR s1.1: Concerning: o The simplest thing that could possibly work * Do not cater for RFC 5988 complications caused by HTTP header character set issues [RFC2047] Having ferreted around in RFC 5988 and RFC 2047, I can't see what is being referred to here. However, I observe later that the "title*" attribute (with language specifier) does not appear to be supported (It is missing from Table 1) - is this what is relevant here? If so it needs clarification. [Aside: I notice that the relevant ABNF in s5 of RFC 5998 is missing external references to various productions (e.g., ext-value, quoted-string) that are defined in other documents - in the given examples RFC 2987, RFC 2616.] s2.2/s5: This statement: The resulting structure can be represented in CDDL [I-D.greevenbosch-appsawg-cbor-cddl] as: requires that the CDDL draft is a normative reference rather than informative. [Aside: Having skimmed the CDDL draft, I am of the opinion that a good deal more work will be needed to get this ready for publication, possibly to the extent that the CDDL quoted here becomes invalid. Given the simplicity of the specification could it be done without the use of CDDL?] s2.2: There needs to be some discussion of handling of double quoted and non-double quoted strings during conversion: I think it works to require that... >From RFC 6690 to JSON: - If the parameter value is a double quoted string then it should have the double quotes stripped, any necessary JSON character encodings performed and the double quotes repapplied. - if the parameter value is anything else, then the necessary JSON character encodings are done and the result enclosed in double quotes. [what about % encodings on the RFC 6690 side?] >From RFC 6690 to CBOR: - If the parameter value is a double quoted string, the double quotes are stripped and the result used as the CBOR string type value. - Otherwise, the parameter value is used as the CBOR string value. [what about % encodings on the RFC 6690 side?] >From JSON to RFC 6690: - Remove the double quotes from the JSON string value and do any necessary decoding and encoding. Reapply double quotes. Note that this may result in values that were originally not enclosed in double quotes in the RFC 6690 repreentation becoming enclosed in double quotes. However, [AFAICS] this does not alter the semantics of any of the predefined parameters. For example the ABNF productions mean that ct=40 and ct="40" are equivalent (the second case is needed so that one can also have ct="40 41 42"). What IS needed is a statement that this must also apply to any application specific parameters. For example the case in examples 4 and 5 of ..;foo="bar";foo=3;... transforming to "foo":["bar","3"] and then back to ...;foo="bar";foo="3";.. MUST require that the two RFC 6690 representations are equivalent. >From CBOR to RFC 6690: [Essentially the same process - decode/encode and apply dou
[Gen-art] Review of draft-ietf-jsonbis-rfc7159bis-03
Reviewer: Elwyn Davies Review result: Ready I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. Document: draft-ietf-jsonbis-rfc7159bis-?? Reviewer: Elwyn Davies Review Date: 2017-03-03 IETF LC End Date: 2017-03-07 IESG Telechat date: 2017-03-16 Summary: Ready for IESG. I checked through the varous errata cited and it seems these are all covered as specified. Thanks. ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] Review of draft-ietf-mmusic-4572-update-11
Hi, Christer. Thanks for the rapid response. That's all fine. Re s4, para 2: First, i realised I missed another instance of 'new' in the abstract. I think that 'the' is correct in the new [sic] version in both places. It's pernickety but when it was 'a new' what you have is shorthand for "a new protocol identifier to be called 'TCP/TLS'..." (an addition to the existng list) whereas because the identifier is no longer new we now have "the protocol identifier [named] 'TCP/TLS'...". Cheers,Elwyn Sent from Samsung tablet. Original message From: Christer Holmberg <christer.holmb...@ericsson.com> Date: 25/01/2017 13:40 (GMT+00:00) To: Elwyn Davies <elw...@dial.pipex.com>, gen-art@ietf.org Cc: draft-ietf-mmusic-4572-update@ietf.org, i...@ietf.org, mmu...@ietf.org Subject: Re: Review of draft-ietf-mmusic-4572-update-11 Hi Elwyn, Thanks for your review! See inline. Nits/editorial comments: >s1, para 2: s/TLS protocol/The TLS protocol/ (as per RFC 4572) I will fix as suggested. >s4, para 2: s/a new protocol identifier/the protocol identifier/ (it >isn't new any more) I am happy to remove ³new², but doesn¹t ³a² still sound better than ³the²? >s5.1: Suggest s/m- line/"m" line/ for consistency with s3.4 I will replace with single quotes (Œm¹), for consistency with s3.4 and s4. >s5.1, para 1: s/e.g./e.g.,/ I will fix as suggested. >s5.1, para 4: s/that each used certificate matches/that each >certificate used matches/ I will fix as suggested. >s5.1, para 5: s/each used certificate matches/each certificate used >matches/ I will fix as suggested. >s8, para 5: ' This specification creates a new IANA registry named >"Hash Function Textual Names".' >The registry is no longer new. Perhaps s/creates a new IANA >registry/takes over the IANA registry from RFC 4572/ I suggest: "This specification takes over the IANA registry named "Hash Function Textual Names², that was created in RFC 4572. It will not be part of the SDP Parameters.² Regards, Christer ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Telechat Review of draft-ietf-manet-olsrv2-sec-threats-03
[For whatever reason, this draft was placed on the 2017/01/05 telechat agenda on 2016/12/16 but did not appear on the review reqest notification email fromJean on 2016/12/22 and is not in the iist of reviews pending. I have not had any response to the last call review from the authors but did have an email exchange with Christopher Dearlove regarding the thoughts on malicious hop count modification. There has not been any update of the draft since the end of last call. Copying to Robert in case this is a bug in the datatracker review tracking mechanism. Also I am not sure if I can insert this into the review tracker manually either at all or without confusing things.] I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please wait for direction from your document shepherd or AD before posting a new version of the draft. For more information, please see the FAQ at <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>;. Document: draft-ietf-manet-olsrv2-sec-threats-03.txt Reviewer: Elwyn Davies Review Date: 2017/01/02 IETF LC End Date: 2016/12/20 IESG Telechat date: 2017/01/05 Summary: There has not been an update since the end of last call. Hence:Ready with nits as per Last Call review https://mailarchive.ietf.org/arch/msg/gen-art/-siuf_-3HlLw1vp30fjZxyY3Eh0 Sent from Samsung tablet.___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] Review of draft-ietf-manet-olsrv2-sec-threats-03
Right, it is always up to the authors (subject to wg consensus)... but it certainly helps me understand - so many thanks for that. Cheers,Elwyn Sent from Samsung tablet. Original message From: "Dearlove, Christopher (UK)" <chris.dearl...@baesystems.com> Date: 20/12/2016 14:50 (GMT+00:00) To: Elwyn Davies <elw...@dial.pipex.com>, gen-art@ietf.org Cc: draft-ietf-manet-olsrv2-sec-threats@ietf.org, ma...@ietf.org, i...@ietf.org Subject: RE: Review of draft-ietf-manet-olsrv2-sec-threats-03 Elwyn I was just commenting as an author of most of the RFCs referred to - but not this one. So that’s down to the authors of this one to accept, adjust or whatever. But in my personal capacity, I think a comment on packet ICVs would not go amiss - but it needs to get its layering right. (It’s not “if OLSRv2 uses packet ICVs” its “if OLSRv2 runs over an implementation of 5444 with packet ICVs enabled”, roughly speaking. And that can be an also or an instead.) (I’m assuming you saw my other email in which I noted I’d forgotten that 7183 does not discuss packet ICVs, only 7182 does. That’s because of that layering issue.) Also, if the authors were to go further into tradeoffs between packet and message ICVs, whether we have a single shared key or per router keys for that latter makes a big difference. 7183 is really about the shared case - but 7182 does allocate at least one code point that must be per router, 7859 - experimental - has a more detailed non-shared case. Roughly, with a shared key, there’s no real advantage in message ICVs over packet ICVs. With individual keys that’s not so, there are pros and cons each way (though message ICVs probably have more pros, but hop count/limit attacks are not one of them). Christopher -- Christopher Dearlove Senior Principal Engineer BAE Systems Applied Intelligence Laboratories __ T: +44 (0)1245 242194 | E: chris.dearl...@baesystems.com BAE Systems Applied Intelligence, Chelmsford Technology Park, Great Baddow, Chelmsford, Essex CM2 8HN. www.baesystems.com/ai BAE Systems Applied Intelligence Limited Registered in England & Wales No: 01337451 Registered Office: Surrey Research Park, Guildford, Surrey, GU2 7YP From: Elwyn Davies [mailto:elw...@dial.pipex.com] Sent: 20 December 2016 14:29 To: Dearlove, Christopher (UK); gen-art@ietf.org Cc: draft-ietf-manet-olsrv2-sec-threats@ietf.org; ma...@ietf.org; i...@ietf.org Subject: RE: Review of draft-ietf-manet-olsrv2-sec-threats-03 *** WARNING *** This message originates from outside our organisation, either from an external partner or the internet. Consider carefully whether you should click on any links, open any attachments or reply. For information regarding Red Flags that you can look out for in emails you receive, click here. If you feel the email is suspicious, please follow this process. Hi. Thanks, Christopher. So, I think the situation can be clarified - and would have provided a clearer answer to my question by 1. adding a couple of sentences to s6.2 to point up the alternative packet and message protections; and 2. explaining in s6.2.1 that that the 'hole' in the mitigation only occurs if message rather than packet ICVs are in use, and then a malicious node can just update the hop-limit/-count fields without actively getting involved in neighbour or topology discovery and then do a fast retransmit, but that it still never gets involved in data transmission or (probably) any other of the threats (see the other question I asked). The 'hole' would then be a one of the entries in the list of things still to be mitigated that I suggested. Cheers - and Merry Christmas, Elwyn Sent from Samsung tablet. Original message From: "Dearlove, Christopher (UK)" <chris.dearl...@baesystems.com> Date: 19/12/2016 10:40 (GMT+00:00) To: Elwyn Davies <elw...@dial.pipex.com>, gen-art@ietf.org Cc: draft-ietf-manet-olsrv2-sec-threats@ietf.org, ma...@ietf.org, i...@ietf.org Subject: RE: Review of draft-ietf-manet-olsrv2-sec-threats-03 Elwyn Davies > s3.2: I do not know enough about the details of NHDP and OLSRv2 to know if > this is a silly question: Would it be possible for a compromised node to > perform hop-limit or hop-count modification attacks even with RFC 6183 > security in place just by modifying these fields and reforwarding the packet even if it wasn't actually in the network topology? If so, it would be desirable to mention this if it can do any harm. No, not a silly question at all. But there are details that make the answer longer than yes or no. (Typo: RFC 6183 is RFC 7183.) You need to distinguish packets from messages (this is RFC 5444 territory). And NHDP
Re: [Gen-art] Review of draft-ietf-manet-olsrv2-sec-threats-03
Hi. Thanks, Christopher. So, I think the situation can be clarified - and would have provided a clearer answer to my question by 1. adding a couple of sentences to s6.2 to point up the alternative packet and message protections; and 2. explaining in s6.2.1 that that the 'hole' in the mitigation only occurs if message rather than packet ICVs are in use, and then a malicious node can just update the hop-limit/-count fields without actively getting involved in neighbour or topology discovery and then do a fast retransmit, but that it still never gets involved in data transmission or (probably) any other of the threats (see the other question I asked). The 'hole' would then be a one of the entries in the list of things still to be mitigated that I suggested. Cheers - and Merry Christmas, Elwyn Sent from Samsung tablet. Original message From: "Dearlove, Christopher (UK)" <chris.dearl...@baesystems.com> Date: 19/12/2016 10:40 (GMT+00:00) To: Elwyn Davies <elw...@dial.pipex.com>, gen-art@ietf.org Cc: draft-ietf-manet-olsrv2-sec-threats@ietf.org, ma...@ietf.org, i...@ietf.org Subject: RE: Review of draft-ietf-manet-olsrv2-sec-threats-03 Elwyn Davies > s3.2: I do not know enough about the details of NHDP and OLSRv2 to know if > this is a silly question: Would it be possible for a compromised node to > perform hop-limit or hop-count modification attacks even with RFC 6183 > security in place just by modifying these fields and reforwarding the packet > even if it wasn't actually in the network topology? If so, it would be > desirable to mention this if it can do any harm. No, not a silly question at all. But there are details that make the answer longer than yes or no. (Typo: RFC 6183 is RFC 7183.) You need to distinguish packets from messages (this is RFC 5444 territory). And NHDP doesn't matter here, as its message (HELLO) is not forwarded and any hop count or limit is either ignored or possibly used as a reason to reject. So OLSRv2 messages (TC) are forwarded, but at each hop they are put into a packet. That packet is assembled from one or more messages, and at each hop it is broken apart and a new packet formed. So the TC message may share a packet with different other messages at each hop. RFC 7183, which forwards to RFC 7182 where the actual work is defined, allows you to protect either messages, or packets (or both). Packet protection protects hop count and hop limit, but has other limitations (it is not end to end). Message protection is applied to each message, and is end to end (or rather, originator to each processing/forwarding router) but does not protect hop count and hop limit. So if using RFC 7183/7182 just to protect messages (it also covers sender addresses) then there is an attack. Attacker receives packet, sends new packet that resets hop count and limit in those messages it includes in a new packet to only one more hop before end of life. Sends quickly (normal forwarding may be delayed, especially if using RFC 5148) and possibly even elsewhere in network (wormhole attack). This "penultimate hop" message poisons the real message, if it arrives later, as it is seen before, and not forwarded, while the penultimate hop message will go one hop and stop. (Can we do this with a "last hop" message to poison even more successfully? That I would need to check some details in RFC 7181 to determine.) Could this be prevented? I can imagine a revision of RFC 7181's forwarding rules that recorded hop count/limit, and if seeing a longer range message decided to forward that even if seen before with a lower range. But that introduces a new attack of creating a sequence of increasing range messages to add to the traffic load. Or you could use both packet and message ICVs, which does prevent this attack but increases overhead. Or (potential future that I know someone is working on, but is not a solution now as far as I know) find a form of aggregating signature that overcomes this problem efficiently. This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Review of draft-ietf-manet-olsrv2-sec-threats-03
Reviewer: Elwyn Davies Review result: Ready with Nits I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>;. Document: draft-ietf-manet-olsrv2-sec-threats-03.txt Reviewer: Elwyn Davies Review Date: 2016/12/18 IETF LC End Date: 2016/12/20 IESG Telechat date: 2017/01/05 Summary: Ready with nits Major issues: None. Minor issues: s3.2: I do not know enough about the details of NHDP and OLSRv2 to know if this is a silly question: Would it be possible for a compromised node to perform hop-limit or hop-count modification attacks even with RFC 6183 security in place just by modifying these fields and reforwarding the packet even if it wasn't actually in the network topology? If so, it would be desirable to mention this if it can do any harm. s6: I am unclear whether the RFC 6183 security mitigates all the threats mentioned here and in RFC 7186. It would be useful to list any that remain unmitigated at the end of s9 as items for further study (or say that all of these are covered). Nits/editorial comments: idnits indicates that RFC 6779 has been obsoleted by RFC 7939. I think this ref ought to be updated. I noticed that Ian Chakeres' affiliation is out of date. Abstract: s/threats of/threats that might apply to/ s1, para 2: s/requirements presented/requirements that need to be addressed / s1, para 2: s/utopia/utopian/ s1, para 2: OLD: For the Internet, with an increase in users, an increase in attacks and abuses followed necessitating a change in recommended practices. NEW: With deployent in the wider Internet, with a resultant increase in user numbers, an increase in attacks and abuses has followed necessitating a change in recommended practices. ENDS s1, para 3: s/often is/is often/ s1, para 3: s/particular/greater/ s1, para 3: OLD: there is commonly no physical protection as otherwise known for wired networks. NEW: there are commonly no physical constraints on the conformation of nodes and communication links that make up the network as could be expected for wired networks. ENDS s1, para 4: s/secured/well-secured/ s1, para 2: s/to OLSRv2/of OLSRv2 s1,next to last para: It would be good to reference RFC 6130 for NHDP here. s1.1, para 1: OLD: Link State Advertisements, They are described in the below with sufficient details for elaborating the analyses in this document. NEW: Link State Advertisements. They are described in the sections below with sufficient details to allow elaboration of the analyses in this document. ENDS s1.3: s/correctly looking/apparently correct/ s1.4; s/henceforth/henceforth identified as/ s1.3: s/disrupt the the LSA process,/disrupt the LSA process,/ s3, para 1: s/TCs to not being delivered to/TCs not being delivered to/ s3.1, para 1: s/a jittering/a jittering mechanism/ s3.2.1, para 1: s/forwarding the message/forwarding for the message/ s3.2.1, para 2: s/transmissions arrives/transmissions arrive/ s4.3.1, s4.3.2 and s5.1: The statements that 'this threat can be mitigated...' are premature and belong to s6. Suggest removing the sentences. s4.4, para 6: OLD: The compromised OLSRv2 router will indicate its willingness to be zero (thus, avoid being selected as MPR) NEW: The compromised OLSRv2 router will indicate its willingness to be selected as an MPR as zero (thus, avoid being selected as MPR) ENDS s5.1, para 1: OLD: The inconsistent topology maps due to neighborhood discovery has been NEW: The creation of inconsistent topology maps due to neighborhood discovery has been ENDS s6.2.1, "Modifying the hop limit/count": I think you mean "mutable" rather than "mutual" (2 places)! s6.2.3, "Identity Spoofing": s/may further allow to revoke/may give the possibility of revoking/ s9: There is some discussion as to whether an Informational RFC can have Normative References. I think it shouldn't, but if it does then I would argue that RFC 6130 and RFC 7183 are also normative. ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Post-Telechat update (was Re: Gen-art LC review of draft-ietf-mpls-rfc4379bis-07)
Hi Carlos, :-) Thanks for addressing the comments. I have looked through -08 and there are a couple of extra points that I noticed - the s3.4 issue was effectively mentioned wrt s4.5 in my previous notes. Generally things are in good shape but there are some items that haven't been addressed or there is a quibble. If there is another version over the weekend I'll do my very best to check it before Monday. Regards, Elwyn Extra Points: === I Forgot to mention that there is lack of consistency in capitalisation of the message names: Personally I would go with Echo Request and Echo Reply throughout to make it clear that these are message names. s3,4, para 1: If the replying router is the destination (Label Edge Router) of the FEC, then a Downstream Detailed Mapping TLV SHOULD NOT be included in the MPLS echo reply. Otherwise, the replying router SHOULD include a Downstream Detailed Mapping object for each interface over which this FEC could be forwarded. I suspect that the SHOULD NOT ought to be MUST NOT. Otherwise it needs an explanation of the circumstances in which the DDMAP TLV could be included. Similarly, the SHOULD needs to explain in what circumstances you wouldn't include one or more DDMAP TLVs. s6.2.3: The Unassigned row should have a blank reference. On 28/10/2016 02:29, Carlos Pignataro (cpignata) wrote: Deal Elwyn, Many thanks for a great review! I just finished addressing all your comments: the major issue (easy to address, editorial fix, but with important implications), the minors, and all the nits. Surprisingly, I found a few small additional editorials, which I fixed as well. Rev -08 would address all outstanding issues, from this review, Mirja, and a couple others. Please see inline for a line-by-line set of responses. On Oct 20, 2016, at 4:42 PM, Elwyn Davies <elw...@dial.pipex.com <mailto:elw...@dial.pipex.com>> wrote: I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. Document: draft-ietf-mpls-rfc4379bis-07.txt Reviewer: Elwyn Davies Review Date: 2016/10/21 IETF LC End Date: 2016/10/18 IESG Telechat date: (if known) - Summary: Not ready. There is one major issue (already notified to authors and agreed as an issue) and a considerable number of minor and editorial issues. I have worked through the various RFCs and errata that are subsumed into the new version and almost everything has been correctly translated AFAICS. A couple of minor points are covered in the comments. Major issues: s3.4: A number of items that are used in the normative Downstream Detailed Mapping TLV were originally defined in s3.3 (Downstream Mapping TLV format) but have been shifted to Appendix A.2. This appendix is marked as non-normative. Thus there are now no normative definitions for the various TLVs used in s3.4 that are defined in A.2. I fear that these need to be returned to the normative part of the specification. This is an excellent catch. Thank you. The fix is simple and purely editorial but the implication is clear. I finished addressing this, which you will see posted as the new revision. I am super happy with the outcome. Looks good to me! [I think it would be simplest and least error prone to swap the text that was in s3.3 of RFC 4379 back out of A.2 and put backward references to the new s3.4 into A.2 as necessary.] Minor issues: Sender/receiver terminology: The document can be somewhat confusing to a naive reader. Sender and receiver are used in multiple contexts. Where the context appears to relate to LSP ping, both senders and receivers are involved in sending LSP ping packets. In general, sender and receiver appear to imply sending and receiving of Echo Request messages with their roles reversed with respect to Echo Responses, with the receiver stimulated to send an Echo Response by receiving an Echo Request. It would help if this terminology and usage was explicitly set out early in the document. Additionally, some instances would be made more comprehensible by making the function explicit in the text e.g., in the operation of return codes. Re-reading after fixing all the nits below, which include some sender clarifications, looks good. There is one place (s3.1, para 1) where I think it could be made clearer. Adding a few words to that section will help overall as well as just in that section. s1.4/s3/s6.2.3: The R (Global) flag is defined in RFC 6426. Unfortunately it isn't in the IANA considerations there as was spotted in RFC Erratum 4012. Might be worth mentioning the erratum (probably in s1.4?) Alternatively this document can b
[Gen-art] Gen-art LC review of draft-ietf-mpls-rfc4379bis-07
I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. Document: draft-ietf-mpls-rfc4379bis-07.txt Reviewer: Elwyn Davies Review Date: 2016/10/21 IETF LC End Date: 2016/10/18 IESG Telechat date: (if known) - Summary: Not ready. There is one major issue (already notified to authors and agreed as an issue) and a considerable number of minor and editorial issues. I have worked through the various RFCs and errata that are subsumed into the new version and almost everything has been correctly translated AFAICS. A couple of minor points are covered in the comments. Major issues: s3.4: A number of items that are used in the normative Downstream Detailed Mapping TLV were originally defined in s3.3 (Downstream Mapping TLV format) but have been shifted to Appendix A.2. This appendix is marked as non-normative. Thus there are now no normative definitions for the various TLVs used in s3.4 that are defined in A.2. I fear that these need to be returned to the normative part of the specification. [I think it would be simplest and least error prone to swap the text that was in s3.3 of RFC 4379 back out of A.2 and put backward references to the new s3.4 into A.2 as necessary.] Minor issues: Sender/receiver terminology: The document can be somewhat confusing to a naive reader. Sender and receiver are used in multiple contexts. Where the context appears to relate to LSP ping, both senders and receivers are involved in sending LSP ping packets. In general, sender and receiver appear to imply sending and receiving of Echo Request messages with their roles reversed with respect to Echo Responses, with the receiver stimulated to send an Echo Response by receiving an Echo Request. It would help if this terminology and usage was explicitly set out early in the document. Additionally, some instances would be made more comprehensible by making the function explicit in the text e.g., in the operation of return codes. s1.4/s3/s6.2.3: The R (Global) flag is defined in RFC 6426. Unfortunately it isn't in the IANA considerations there as was spotted in RFC Erratum 4012. Might be worth mentioning the erratum (probably in s1.4?) Alternatively this document can be made to provide the IANA specification for the R flag and the erratum closed. s2.1/s6: An update to http://www.iana.org/assignments/iana-ipv4-special-registry/iana-ipv4-special-registry.xhtml is needed to replace RFC 4379 with RFC-to-be for special exceptions to usage rules. s3.5, Clandestine Channel via Pad TLV: As specified the value part of a Pad TLV can serve as a clandestine channel since the value field contents are ignored. s3.5, Usefulness of Pad TLV: Could you explain circumstances in which a Pad TLV would be needed please. I can't see any at present. Nits/editorial comments: == General: s/i.e. /i.e., / (two instances s3.2, last para; s4.5.1, para 3) s1, para 1: s/methods of reliable reply/methods of providing reliable reply/ s1.4, bullet 4: Need to expand acronym PW on first use. s1.4, bullet 4: need to move expansion of FEC acronym to here from s2. s1.4, bullet 8: Acronyms DSMAP/DDMAP: When defining Return Code 14 in s3.1, the text is 'See DDM TLV...'. DDM is not expanded anywhere although it is clearly the same as DDMAP. But has by now made it into the IANA repository and is probably better to use it for 'Downstream Detailed Mapping', so I suggest: OLD: o Incorporate the updates from RFC 6424, by deprecating the Downstream Mapping TLV (DSMAP) and adding the Downstream Detailed Mapping TLV (DDMAP), updating two new return codes, updating the procedures, IANA section, Security Considerations, and obsoleting RFC 6424. NEW: o Incorporate the updates from RFC 6424, by deprecating the Downstream Mapping TLV (DSM) and adding the Downstream Detailed Mapping TLV (DDM), adding two new return codes, updating the procedures, IANA section, Security Considerations, and obsoleting RFC 6424. END Then s/DSMAP/DSM/g, s/DDMAP/DDM/g in the rest of the document. s1.4: Ought to mention the addition of the motivation (LSP stitching) for the additions in RFC 6424. s2.1, paras 7 and 8: This contains "the newly designated IPv4 link local addresses". Given that RFC 3927 is now over 11 years old, the qualifier is no longer appropriate, but it might be useful to provide a ref. Thus: OLD: the newly designated IPv4 link local addresses NEW: the IPv4 link local addresses [RFC3927] END The text in para 8 is also no longer appropriate. Suggest OLD: Furthermore, the IPv4 link local address range has only recently b
[Gen-art] Gen-art Telechat review of draft-ietf-avtcore-5761-update-05
I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please wait for direction from your document shepherd or AD before posting a new version of the draft. For more information, please see the FAQ at <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>;. Document: draft-ietf-avtcore-5761-update-05.txt Reviewer: Elwyn Davies Review Date: 2016/10/11 IETF LC End Date: 2016/09/22 IESG Telechat date: 2016/10/13 Summary: Ready. Thanks for fixing the couple of nits from last call. Sent from Samsung tablet.___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] Gen-art LC review of draft-ietf-avtcore-5761-update-02
That's fine. Cheers,Elwyn Sent from Samsung tablet. Original message From: Christer Holmberg <christer.holmb...@ericsson.com> Date: 04/10/2016 17:53 (GMT+00:00) To: Christer Holmberg <christer.holmb...@ericsson.com>, Elwyn Davies <elw...@dial.pipex.com> Cc: draft-ietf-avtcore-5761-update@ietf.org, gen-art@ietf.org Subject: RE: Gen-art LC review of draft-ietf-avtcore-5761-update-02 Hi, I submitted a new version (-05) of the draft, with the new title. Regards, Christer From: Christer Holmberg [mailto:christer.holmb...@ericsson.com] Sent: 04 October 2016 18:41 To: Elwyn Davies <elw...@dial.pipex.com> Cc: draft-ietf-avtcore-5761-update@ietf.org; gen-art@ietf.org Subject: RE: Gen-art LC review of draft-ietf-avtcore-5761-update-02 Hi, >I was just having a look at the updated draft - the changes are fine AFAICS. > >However, looking at it again, I think a more informative title would not go >amiss. How about: > > Clarifications to SDP offer/answer Negotiations in RFC 5761 > >Sorry - should have noticed on previous pass. Don’t worry – I agree a more informative title would be useful :) What about “RFC 5761 SDP Offer/Answer Clarifications”? Regards, Christer ---- Original message From: Elwyn Davies <elw...@dial.pipex.com> Date: 16/09/2016 23:45 (GMT+00:00) To: Christer Holmberg <christer.holmb...@ericsson.com> Cc: draft-ietf-avtcore-5761-update@ietf.org, gen-art@ietf.org Subject: RE: Gen-art LC review of draft-ietf-avtcore-5761-update-02 Hi Christer. Thanks. That's fine. Cheers, Elwyn Sent from Samsung tablet. ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] Gen-art LC review of draft-ietf-avtcore-5761-update-02
Hi, Christer. I was just having a look at the updated draft - the changes are fine AFAICS. However, looking at it again, I think a more informative title would not go amiss. How about: Clarifications to SDP offer/answer Negotiations in RFC 5761 Sorry - should have noticed on previous pass. Cheers,Elwyn Sent from Samsung tablet. Original message From: Elwyn Davies <elw...@dial.pipex.com> Date: 16/09/2016 23:45 (GMT+00:00) To: Christer Holmberg <christer.holmb...@ericsson.com> Cc: draft-ietf-avtcore-5761-update@ietf.org, gen-art@ietf.org Subject: RE: Gen-art LC review of draft-ietf-avtcore-5761-update-02 Hi Christer. Thanks. That's fine. Cheers,Elwyn Sent from Samsung tablet.___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] Gen-art LC review of draft-ietf-avtcore-5761-update-02
Hi Christer. Thanks. That's fine. Cheers,Elwyn Sent from Samsung tablet. Original message From: Christer Holmberg <christer.holmb...@ericsson.com> Date: 16/09/2016 22:40 (GMT+00:00) To: Elwyn Davies <elw...@dial.pipex.com> Cc: draft-ietf-avtcore-5761-update@ietf.org Subject: RE: Gen-art LC review of draft-ietf-avtcore-5761-update-02 Hi Elwyn, Thanks for your review! Please see inline. Nits/editorial comments: >s3.1: It is a bit pedantic, but 'to be sure, to be sure', add new first line: > In the rest of this section references to Sections 4 and 8 are to sections >in [RFC 5761]. I’ll do that. >s3.1: Maybe s/OLD TEXT/EXISTING TEXT/ and s/NEW TEXT/REPLACEMENT TEXT/ I’ve used OLD and NEW in the past, so I’d prefer to do that in this draft too :) >s5: s/specifcation/specification/ (sorreee!) I’ll fix that. Thanks! Regards, Christer ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Gen-art LC review of draft-ietf-avtcore-5761-update-02
I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>;. Document: draft-ietf-avtcore-5761-update-02.txt Reviewer: Elwyn Davies Review Date: 2016/09/15 IETF LC End Date: 2016/09/22 IESG Telechat date: (if known) - Summary: Ready (apart from a tiny bit of pedantry). Major issues:None Minor issues: None Nits/editorial comments:s3.1: It is a bit pedantic, but 'to be sure, to be sure', add new first line: In the rest of this section references to Sections 4 and 8 are to sections in [RFC 5761]. s3.1: Maybe s/OLD TEXT/EXISTING TEXT/ and s/NEW TEXT/REPLACEMENT TEXT/ s5: s/specifcation/specification/ (sorreee!)Sent from Samsung tablet.___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] Gen-art LC2/Telechat review of draft-ietf-insipid-session-id-24
Whether the session ID draft needs reworking or holding depends on whether the IESG (and the rest of the community) wants to prejudge the meaning/wordng of Barry's draft before it becomes an RFC. As you say, the other case in point is somewhat different. I'll repeat that given the existence of the agreed text and the (IMO) non-foundational nature of the reqs RFC, I'd bite the bullet and copy over the text. There is nothing else referring to these definitions, it would get the whole thing in one place making it easier for implementors, and if anybody else wants to refer to it, it is then in 'canonical form' as a reference target in a standards track document. 'Nuff said. Cheers,Elwyn Sent from Samsung tablet. Original message From: Ben Campbell <b...@nostrum.com> Date: 17/08/2016 23:26 (GMT+00:00) To: Elwyn Davies <elw...@folly.org.uk> Cc: General area reviewing team <gen-art@ietf.org>, draft-ietf-insipid-session-id@ietf.org Subject: Re: [Gen-art] Gen-art LC2/Telechat review of draft-ietf-insipid-session-id-24 On 17 Aug 2016, at 12:04, Elwyn Davies wrote: > Hi, Ben. > > Having read Barry's proposed update for RFC 3967, I would be happy > for that to become the status quo. However, I would distinguish > between truly foundational documents that are produced in tandem with > the protocol standards or subsequently (as mentioned in Barry's draft) > and what one might call WG process documents such as requirements > documents and problem statements. I was going to use the word > 'ephemera' to describe these latter types, but that is doing them a > disservice: Such documents, along with mailing list archives, can > provide insight into the thought processes that went into the > generation of the WG output for future reference. Both the software > industry and the standards industry is incredibly bad at remembering > how decisions were reached - the concept of a 'design diary' never > seems to have taken hold - with the result that we spend an awful lot > of time reopening topics that were shown to be blind alleys and such > like especially after the original participants have moved on. > > That being said, I think that the 'design diary' category of documents > probably ought to be archived elsewhere than the RFC series; > additionally, it is unclear whether applying the RFC review processes > and resources to an essentially random subset of WG's design thoughts > is appropriate (that is a random set of WGs rather than a random set > of thoughts from any one WG - I hope :-) ). As mentioned below, it is > not generally known in advance that parts of such documents might end > up being key references in later standards which can affect both the > way in which the documents are written (applicable in this case to > some extent) and the rigour of review (the WG seems to have done a > good job in this case). > > Up until last month, I think that the foundational documents extension > would have covered the situation - RFC 6707 broke the mould, and I do > not consider that foundational covers it. Without prejudice to your points (many of which I agree with), can I safely assume that the discussion above this point is more around Barry's draft, that we don't need to hold draft-ietf-insipid-session-id hostage to the completion of that discussion? > > Back to the current document: I have reread s3 of RFC 7206 and there > are some points that need to be sorted out: > > - The term 'end-to-end' is given a slightly specialized meaning in RFC > 7206. This is presumably carried through to the draft under review, > but the need to refer to the end-to-end definition is not mentioned in > the draft. > > - The use of 'session' as a shorthand for the specific meaning of > 'communication session' defined in RFC 7206 ought to be emphasized > within the draft since the shorthand in RFC 7206 is technically > limited to the RFC (ok, this is somewhat nitpicking but easy to > misinterpret.) I agree with both of the above points. Authors? > > - The last para of s3.1 of RFC 7206 states: > >> This definition, along with the constraints imposed by the >> requirements in this document, > There is no explicit statement that this standard meets all the > requirements, so this is difficult to verify and might be > problematical in future. I think that text, taken in context, is about the ability to use the session-id across protocols, not the definition of session-id in general. That is, even if the protocol fails to meet some of the requirements, the definition does not change. > > Overall, I am of the opinion that in this sort of situation, I'd do a > copy and paste exercise and tweak the text just a little to fit the > context mo
