[Gen-art] Genart last call review of draft-ietf-6man-comp-rtg-hdr-05

[Elwyn Davies via Datatracker]

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

.

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

[Elwyn Davies via Datatracker]

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

.

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

[Elwyn Davies via Datatracker]

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

.

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 necessary after the draft
has been approved in case there 

[Gen-art] Genart last call review of draft-ietf-opsawg-rfc7125-update-05

[Elwyn Davies via Datatracker]

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

.

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

[Elwyn Davies via Datatracker]

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

.

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

[Elwyn Davies via Datatracker]

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

.

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

[Elwyn Davies via Datatracker]

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

.

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

[Elwyn Davies via Datatracker]

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

.

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

[Elwyn Davies via Datatracker]

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

.

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

[Elwyn Davies via Datatracker]

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

.

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

[Elwyn Davies via Datatracker]

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

.

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

[Elwyn Davies via Datatracker]

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

.

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

[Gen-art] Genart last call review of draft-ietf-drip-rid-24

[Elwyn Davies via Datatracker]

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

.

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

[Elwyn Davies via Datatracker]

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

.

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

[Elwyn Davies via Datatracker]

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

.

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

[Elwyn Davies via Datatracker]

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

.

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

[Elwyn Davies via Datatracker]

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

.

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

[Elwyn Davies via Datatracker]

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

.

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

[Gen-art] Genart last call review of draft-ietf-core-senml-versions-02

[Elwyn Davies via Datatracker]

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

.

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

[Elwyn Davies via Datatracker]

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

.

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

[Elwyn Davies via Datatracker]

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

.

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 to go for specification required
and 

[Gen-art] Genart last call review of draft-ietf-idr-bgp-ls-registry-04

[Elwyn Davies via Datatracker]

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

.

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

[Elwyn Davies via Datatracker]

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

.

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 message arrives after the 

[Gen-art] Genart last call review of draft-ietf-roll-unaware-leaves-24

[Elwyn Davies via Datatracker]

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

.

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 Information (RPI) 

[Gen-art] Genart last call review of draft-ietf-emu-eaptlscert-05

[Elwyn Davies via Datatracker]

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

.

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-service attacks. NEW: Other 

[Gen-art] Genart last call review of draft-ietf-dnsop-dns-zone-digest-09

[Elwyn Davies via Datatracker]

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

.

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

[Elwyn Davies via Datatracker]

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

.

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

[Elwyn Davies via Datatracker]

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

.

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

[Gen-art] Genart last call review of draft-ietf-ospf-mpls-elc-13

[Elwyn Davies via Datatracker]

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

.

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

[Elwyn Davies via Datatracker]

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

.

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

[Elwyn Davies via Datatracker]

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

.

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

[Elwyn Davies via Datatracker]

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

.

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 Raw Public Key (RPK) handshake [RFC7250]/

[Gen-art] Genart last call review of draft-ietf-cose-hash-sig-05

[Elwyn Davies via Datatracker]

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

.

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

[Elwyn Davies via Datatracker]

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

.

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

[Elwyn Davies via Datatracker]

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

.

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

[Elwyn Davies via Datatracker]

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

.

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

[Elwyn Davies via Datatracker]

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

.

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

[Elwyn Davies via Datatracker]

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

.

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: s/OPEN message/Open