[Gen-art] Genart last call review of draft-ietf-cellar-ffv1-16

[Joel Halpern via Datatracker]

Reviewer: Joel Halpern
Review result: Ready

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

.

Document: draft-ietf-cellar-ffv1-16
Reviewer: Joel Halpern
Review Date: 2020-07-13
IETF LC End Date: 2020-07-16
IESG Telechat date: Not scheduled for a telechat

Summary: This document appears to be ready for publication as an Informational
RFC.

*I would have raised question about the intended status, but it appears that
this is an established IETF convention and I see no reason to argue.)

Major issues:

Minor issues:
Section 3.4 (Context) introduces the notation Q_{#}[ subscript }.  As that
is the first reference to Q_{#}, it is rather confusing to the reader.  I
grant that the term is defined in the next section (3.5).  Couldn't they be
reversed?

Section 3.8.1.1 refers to C(i), C_{i}, and C_i.  Are these all the same
thing.

Section 3.8.1.2 refers to get-rac (which is treated as a function in the
pseudo-code) as being the process described in section 3.8.1.1.  The text
in 3.8.1.1 does not call out any of its computed values as an explicit
result or return.  While I would guess that the intention is to use the
byte stream (B()), the text does not actually say that.  If that is the
intention, could the last line of 3.8.1.1 be "get_rac() returns sequential
bytes from the Byte Stream (B()) as computed by the computation described
in section 3.8.1.1"?

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-idr-rfc8203bis-06

[Dale Worley via Datatracker]

Reviewer: Dale Worley
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-rfc8203bis-06
Reviewer:  Dale R. Worley
Review Date:  2020-07-13
IETF LC End Date:  2020-07-14
IESG Telechat date:  not known

Summary:

This draft is basically ready for publication, but has nits that
should be fixed before publication.

* Minor issues:

3.  Operational Considerations

See the comments about Appendix B.

Appendix B.  Changes to RFC 8203

xThis appendix should describe upward-compatibility considerations.
The body says that the Communication should be limited to 128 octets
if feasible.  But there could be situations where the sender sends a
longer Communication without knowing that the receiver implements
8203bis, and the receiver in fact does not.  How to recover from that
situation?  E.g., will the NOTIFICATION be rejected with a specific
error message?  Can the sender detect the problem by the subsequent
behavior of the receiver?  Is it even well-defined that the receiver
will reject the message?  Can the situation be compensated by
immediately sending another NOTIFICATION without the Communication?

Indeed these considerations probably should be put in section 3.

* Nits/editorial comments:

Abstract

It seems like it would be useful to note here "This document updates
RFC 4486 and obsoletes RFC 8203 by defining an Extended BGP
Administrative Shutdown Communication >>>of up to 255 octets<<< to
improve communication using multibyte character sets." since the
length extension is the only significant change this document
introduces.

1.  Introduction

   via offline methods such email or telephone calls.  This document

Insert "such >>>as<<< email".

2.  Shutdown Communication

  This field is not NULL terminated.

The best phrasing is "NUL terminated", as the name of the character is
NUL.  (See RFC 20.)  However, it is common to say "null terminated",
which is valid because "null" is a common adjective (i.e., not a
proper adjective) that describes the variety of termination.  But
"NULL terminated", though not infrequently used, isn't reallly
correct.  (Unless the RFC Editor says otherwise!)

6.  Security Considerations

   UTF-8 "Shortest Form" encoding is
   REQUIRED to guard against the technical issues outlined in [UTR36].

It might be useful to repeat this restriction in the description of
the Communication field in section 2.

[END]



___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Genart last call review of draft-ietf-mmusic-msrp-usage-data-channel-21

[Brian E Carpenter]

Thanks Christer, that all looks good to me,

Regards
   Brian

On 13-Jul-20 20:58, Christer Holmberg wrote:
> Hi Brian,
> 
> Thank You for the review! Please see inline.
> 
> 
> Nits:
> -
> 
>>> 4.1.  MSRP URI
>>> 
>>> transport  /= "dc"
>>>
>>> I see that RFC7977 takes a slightly different approach to updating the ABNF:
>>>
>>> transport  =  "tcp" / "ws" / 1*ALPHANUM
>>>
>> The advantage of listing out
>>
>>  transport  =  "tcp" / "ws" / "dc" / 1*ALPHANUM
>>
>> would be that the reader sees the full list.
> 
> The MMUSIC WG has previously decided to take the approach of only writing the 
> new value, using the "/=" format.
> 
> ---
> 
>>>  ; Add "dc" to existing transports per [RFC4975]
>>>
>>> I suggest
>>>
>>> ; Add "dc" to existing transports per Section 9 of [RFC4975]
> 
> Will modify as suggested.
> 
> ---
> 
>>> 4.6.  Session Closing
>>>
>>>   The SDP answerer must ensure that no dcmap or dcsa attributes are
>>>   present in the SDP answer if no corresponding attributes are present
>>>   in the received SDP offer.
>>>
>>> Should that be MUST?
> 
> The reason for "must" is that is referring to generic data channel SDP O/A 
> procedures.
> 
> I suggest to remove the paragraph.
> 
> ---
> 
>>> B2BUA
>>>
>>> Define the acronym please.
> 
> We normally don't do that in MMUSIC specifications. Also, it is on the IETF 
> list of well-known acronyms.
> 
> Having said that, I am fine to enhance it on first occurrence: 'Back-to-Back 
> User Agent (B2BUA)'
> 
> ---
> 
>>> 9.2.  Subprotocol Identifier MSRP
>>>
>>>   A reference to this document is added to the subprotocol identifier
>>>   "msrp" in the "WebSocket Subprotocol Name Registry"
>>>
>>> s/this document/RFC/
> 
> Will modify as suggested.
> 
> ---
> 
>>> 11.  CHANGE LOG
>>>
>>> Mark this section for deletion by the RFC Editor
> 
> I think the RFC Editor will delete it by default, but we can add explicit 
> text.
> 
> Regards,
> 
> Christer
> 

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Genart last call review of draft-ietf-mmusic-msrp-usage-data-channel-21

[Brian E Carpenter]

On 14-Jul-20 02:58, Paul Kyzivat wrote:
> Brian,
> 
> On 7/12/20 6:40 PM, Brian Carpenter via Datatracker wrote:
> 
>> Nits:
>> -
>>
 4.1.  MSRP URI
>> 
  transport  /= "dc"
>>
>> I see that RFC7977 takes a slightly different approach to updating the ABNF:
>>
  transport  =  "tcp" / "ws" / 1*ALPHANUM
>>
>> The advantage of listing out
>>
>>transport  =  "tcp" / "ws" / "dc" / 1*ALPHANUM
>>
>> would be that the reader sees the full list.
> 
> While it might be nice to see the full list, it can't be counted on to 
> remain the full list. If each update did this, then every draft that 
> updates the list should formally Update every other document that 
> updates the list.
> 
> The *point* of /= in abnf is that it decouples the particular addition 
> from all others.

Sure, I realise that. But...
 
> This sort of thing should really have an IANA registry. But often the 
> expectation is that changes aren't made often enough to justify that. 

Indeed, that occurred to me as an alternative approach but a registry
with 3 entries is a bit light (and also, readers starting at RFC4975
wouldn't know to look for the registry).

> Lacking that, IMO /= is the preferred way to go.

It was only a nit...

Brian

> 
>   Just kibitzing,
>   Paul
> 
> 
> 

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Genart last call review of draft-ietf-mmusic-msrp-usage-data-channel-21

[Paul Kyzivat]

Brian,

On 7/12/20 6:40 PM, Brian Carpenter via Datatracker wrote:


Nits:
-


4.1.  MSRP URI



 transport  /= "dc"


I see that RFC7977 takes a slightly different approach to updating the ABNF:


 transport  =  "tcp" / "ws" / 1*ALPHANUM


The advantage of listing out

   transport  =  "tcp" / "ws" / "dc" / 1*ALPHANUM

would be that the reader sees the full list.


While it might be nice to see the full list, it can't be counted on to 
remain the full list. If each update did this, then every draft that 
updates the list should formally Update every other document that 
updates the list.


The *point* of /= in abnf is that it decouples the particular addition 
from all others.


This sort of thing should really have an IANA registry. But often the 
expectation is that changes aren't made often enough to justify that. 
Lacking that, IMO /= is the preferred way to go.


Just kibitzing,
Paul


___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Genart last call review of draft-ietf-stir-passport-divert-07

[Peterson, Jon]

Thanks for these notes, Pete. I incorporated these fixes into the -08 (but 
apparently neglected to write and say so at the time).

Jon Peterson
Neustar, Inc.

Document: draft-ietf-stir-passport-divert-07
Reviewer: Pete Resnick
Review Date: 2020-01-09
IETF LC End Date: 2019-12-02
IESG Telechat date: Not scheduled for a telechat

Summary: Ready with Nits

While I found the document (and particularly section 4) very technically 
dense,
I think the detail will help implementers tremendously. Nothing other than a
few editorial issues.

Major issues: None

Minor issues: None

Nits/editorial comments:

Section 3, paragraph 1:

   Note that
   a new PASSporT is only necessary when the canonical form of the
   "dest" identifier (per the canonicalization procedures in [RFC8224]
   Section 8) changes due to this retargeting.  If the canonical form of
   the "dest" identifiier is not changed during retargeting, then a new
   PASSporT with a "div" claim MUST NOT be produced.

Seems to me that these two sentences should be in their own paragraph. It 
took
me a second to figure out that the following sentence was not related to 
these.

Section 4:

   ...Other using protocols of PASSporT

Don't you mean "Other protocols using PASSporT"?

Section 4.2, paragraph 2:

I think you mean "necessarily", not "necessary"




___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] [core] I-D Action: draft-ietf-core-resource-directory-25.txt

[Christian Amsüss]

Hello Russ and Adam,

On Mon, Jul 13, 2020 at 06:42:09AM -0700, internet-dra...@ietf.org wrote:
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-core-resource-directory/

the newly submitted -25 was uploaded to address the points you've
brought up in your respective reviews.

Most noteworthy -- especially because it may affect the secdir review --
are the changes to the security policies section that caught Major
Concerns around the use of concrete security mechanisms.  Discussion
during the April interim meeting[1] has shown that the text had caught a
drift towards giving concrete and detailled (and in some details wrong)
measures without consideration for the bigger picture, which encompasses
a variety of applications with a wild variety of assurances they may or
may not need from an RD.

Consequently, that section that previously stated which parts of the RD
are protected now describes aspects that an application should consider
when deciding on a particular security model to employ.

The remaining changes should be sufficiently described in the changelog
and copied below for completeness.

Thanks again for your reviews
Christian


[1]: https://datatracker.ietf.org/doc/minutes-interim-2020-core-02-202004161500/


Remaining change log:

*  Add concrete suggestions (twice as long as registrant number with
   retries, or UUIDs without) for random endpoint names

*  Point out that simple registration can have faked origins,
   RECOMMEND mitigation when applicable and suggest the Echo mechanism
   to implement it.

*  Reference existing and upcoming specifications for DDOS mitigation
   in CoAP.

*  Explain the provenance of the example's multicast address.

*  Make "SHOULD" of not manipulating foreign registrations a "should"
   and explain how it is enforced

*  Clarify application of RFC6570 to search parameters

*  Syntactic fixes in examples

*  IANA:

   -  Don't announce expected number of registrations (goes to write-
  up)

   -  Include syntax as part of a field's validity in entry
  requirements

*  Editorial changes

   -  Align wording between abstract and introduction

   -  Abbreviation normalization: "ER model", "RD"

   -  RFC8174 boilerplate update

   -  Minor clarity fixes

   -  Markup and layouting

-- 
To use raw power is to make yourself infinitely vulnerable to greater powers.
  -- Bene Gesserit axiom


signature.asc
Description: PGP signature
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Genart last call review of draft-ietf-mmusic-msrp-usage-data-channel-21

[Christer Holmberg]

Hi Brian,

Thank You for the review! Please see inline.


Nits:
-

>> 4.1.  MSRP URI
>> 
>> transport  /= "dc"
>>
>> I see that RFC7977 takes a slightly different approach to updating the ABNF:
>>
>> transport  =  "tcp" / "ws" / 1*ALPHANUM
>>
> The advantage of listing out
>
>  transport  =  "tcp" / "ws" / "dc" / 1*ALPHANUM
>
> would be that the reader sees the full list.

The MMUSIC WG has previously decided to take the approach of only writing the 
new value, using the "/=" format.

---

>>  ; Add "dc" to existing transports per [RFC4975]
>>
>>I suggest
>>
>> ; Add "dc" to existing transports per Section 9 of [RFC4975]

Will modify as suggested.

---

>>4.6.  Session Closing
>>
>>   The SDP answerer must ensure that no dcmap or dcsa attributes are
>>   present in the SDP answer if no corresponding attributes are present
>>   in the received SDP offer.
>>
>> Should that be MUST?

The reason for "must" is that is referring to generic data channel SDP O/A 
procedures.

I suggest to remove the paragraph.

---

>> B2BUA
>>
>> Define the acronym please.

We normally don't do that in MMUSIC specifications. Also, it is on the IETF 
list of well-known acronyms.

Having said that, I am fine to enhance it on first occurrence: 'Back-to-Back 
User Agent (B2BUA)'

---

>> 9.2.  Subprotocol Identifier MSRP
>>
>>   A reference to this document is added to the subprotocol identifier
>>   "msrp" in the "WebSocket Subprotocol Name Registry"
>>
>> s/this document/RFC/

Will modify as suggested.

---

>> 11.  CHANGE LOG
>>
>> Mark this section for deletion by the RFC Editor

I think the RFC Editor will delete it by default, but we can add explicit text.

Regards,

Christer

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] [Last-Call] Genart last call review of draft-ietf-lamps-rfc7030est-clarify-08

[Ines Robles]

Hi Michael,

Yes, that would be great, if possible.

Thank you,

Ines

On Mon, Jul 13, 2020 at 3:56 AM Michael Richardson 
wrote:

>
> Ines Robles via Datatracker  wrote:
> > 2- Introduction: "reports from implementers suggest..." It would be
> nice to add
> > reference/s here
>
> Well, I'm not sure how I can add a reference to private emails.
> I can ask the implementers to write a public email if that is intended.
> Please advise.
>
>
> --
> Michael Richardson , Sandelman Software Works
>  -= IPv6 IoT consulting =-
>
>
>
>
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art