[Gen-art] Genart last call review of draft-ietf-trill-mtu-negotiation-05

[Brian Carpenter]

Reviewer: Brian Carpenter
Review result: Ready with Issues

Gen-ART Last Call review of draft-ietf-trill-mtu-negotiation-05

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

For more information, please see the FAQ at
.

Document: draft-ietf-trill-mtu-negotiation-05.txt
Reviewer: Brian Carpenter
Review Date: 2017-06-24
IETF LC End Date: 2017-06-28
IESG Telechat date: 2017-07-06

Summary: Ready with issues


Minor issues: 
-

> 2. Link-Wide TRILL MTU Size
...
>   ...RBridges MUST support the Extended L1 Circuit-Scoped
>   (E-L1CS) flooding scope LSP (FS-LSP). They use that flooding to
>   exchange their maximally supportable value of "Lz".

Where does that value come from? Is it configured, derived from
the interface in some way, or discovered?

> 2.1. Operations
>
>   Lz is reported using a originatingSNPBufferSize TLV that MUST occur
>   in fragment zero of the RBridge's E-L1CS FS-LSP. An
>   originatingSNPBufferSize APPsub-TLV occurring in any other fragment
>   is ignored.

Is that really what you mean? I thought Lz was an optional extra. So I think
you mean:

2.1. Operations

   Lz MAY be reported using a originatingSNPBufferSize TLV that occurs
   in fragment zero of the RBridge's E-L1CS FS-LSP. An
   originatingSNPBufferSize APPsub-TLV occurring in any other fragment
   MUST be ignored.

> 3. Link MTU Size Testing
...
>   Step 0:
...
>  b) Link MTU size is set to 1470, lowerBound is set to 1470,
> upperBound is set to the link-wide Lz, linkMtuSize is set to
> [(lowerBound + upperBound)/2] (Operation "[...]" returns the
> fraction-rounded-up integer.).  

This is confusing. "linkMtuSize" was defined as a local variable.
But what is "Link MTU size"? Is that another local variable?
If so, how is it different from "linkMtuSize"?
It is used again in part 2) of step 2 below.

Also, I assume "Lz" is the value previously agreed among the nodes,
but that should be made clear to the reader.

Nits:
-

> 1. Introduction
...
>   topology. While in this document, a new RECOMMENDED link-wide minimum
>   inter-RBridge MTU size, Lz, is specified. By calculating a using Lz
>   as specified herein, link-scoped PDUs can be formatted greater than
>   the campus-wide Sz up to the link-wide minimum acceptable inter-
>   RBridge MTU size potentially improving the efficiency of link
>   utilization and speeding link state convergence.

I cannot parse those two sentences. What does the "While" refer to? 
What does "By calculating a using Lz" mean?

> 3. Link MTU Size Testing
...
>  b) Link MTU size is set to 1470, lowerBound is set to 1470,
> upperBound is set to the link-wide Lz, linkMtuSize is set to
> [(lowerBound + upperBound)/2] (Operation "[...]" returns the
> fraction-rounded-up integer.).  

This would be easier to understand:

3. Link MTU Size Testing
...
  b) Link MTU size is set to 1470, lowerBound is set to 1470,
 upperBound is set to the link-wide Lz, linkMtuSize is set to
 [(lowerBound + upperBound)/2], rounded up to the nearest integer.

Repeat this in the following two cases; a normal reader will not
remember the rounding rule:

...
   1) If RB1 fails to receive an MTU-ack from RB2 after k tries: 

 upperBound is set to linkMtuSize and linkMtuSize is set to
 [(lowerBound + upperBound)/2], rounded up to the nearest integer.

   2) If RB1 receives an MTU-ack to a probe of size linkMtuSize from
  RB2:

 link MTU size is set to linkMtuSize, lowerBound is set to
 linkMtuSize and linkMtuSize is set to [(lowerBound +
 upperBound)/2], rounded up to the nearest integer.

--


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

Re: [Gen-art] Gen-Art review of draft-ietf-precis-7564bis-07

[Peter Saint-Andre - Filament]

Hi Christer,

Thanks for your review. Comments below.

On 6/22/17 1:09 AM, Christer Holmberg wrote:
> 
> I am the assigned Gen-ART reviewer for this draft. For background on
> Gen-ART, please see the FAQ at
> 
> 
>  
> 
> Document:   draft-ietf-precis-7564bis-07.txt
> 
> Reviewer: Christer Holmberg
> 
> Review Date:   22 June 2017
> 
> IETF LC End Date:   13 June 2017
> 
> IETF Telechat Date:6 July 2017
> 
>  
> 
> Summary: The document is well written, and almost ready for publication.
> However, I have one comment (see below) that I would like the authors to
> address.
> 
> 
> Major Issues: None
> 
>  
> 
> Minor Issues: 
> 
> 
> Q1: Section 13.2 says that PRECIS only support Unicode. While Unicode is
> mentioned throughout that document, is that restriction mentioned
> elsewhere? I think it would be good to make it explicit already in the
> Introduction, or by indicating it in an Applicability/Scope section in
> the beginning of the document.

Perhaps we could add the following sentence to the first paragraph of
the introduction:

   (PRECIS is restricted to Unicode and does not support any other
   coded character set [RFC6365].)

Would that address your concern?

Peter


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

[Gen-art] Gen-ART Last Call review of draft-baeuerle-netnews-cancel-lock-05

[Paul Kyzivat]

[Resending with corrected review date]

I am the assigned Gen-ART reviewer for this draft. The General Area 
Review Team (Gen-ART) reviews all IETF documents being processed by the 
IESG for the IETF Chair. Please wait for direction from your document 
shepherd or AD before posting a new version of the draft. For more 
information, please see the FAQ at 
<​http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.


Document: draft-baeuerle-netnews-cancel-lock-05
Reviewer: Paul Kyzivat
Review Date: 2017-06-23
IETF LC End Date: 2017-06-28
IESG Telechat date: TBD

Summary:

This draft is on the right track but has open issues, described in the 
review.


General Comments:

I have not attempted to validate the security properties of this 
document - leaving that to a security review.


I have also not attempted to verify the operational suitability of this 
mechanism because I don't have the experience needed to do so.


Issues:

Major: 1
Minor: 3
Nits:  0

(1) MAJOR:

In Section 2, the ABNF syntax provided does not do what you want it to. 
You supply:


  fields =/ *( cancel-lock / cancel-key )

as an extension to the definition in RFC5536:

   fields  =/ *( approved /
 archive /
 control /
 distribution /
 expires /
 followup-to /
 injection-date /
 injection-info /
 lines /
 newsgroups /
 organization /
 path /
 summary /
 supersedes /
 user-agent /
 xref )

and that in turn extends RFC5322:

   fields  =   *(trace
 *optional-field /
 *(resent-date /
  resent-from /
  resent-sender /
  resent-to /
  resent-cc /
  resent-bcc /
  resent-msg-id))
   *(orig-date /
   from /
   sender /
   reply-to /
   to /
   cc /
   bcc /
   message-id /
   in-reply-to /
   references /
   subject /
   comments /
   keywords /
   optional-field)

   message =   (fields / obs-fields)
   [CRLF body]

RFC5536 got this wrong, and the new draft continues the mistake. The 
problem is with the way things are grouped. Let me give a simpler example:


   foo = *("a" / "b") / *("c" / "d")

This means the following are valid: ab aabb bab cd ccdd dcd
But the following are not: abcd ac

The latter is what you want, for which the syntax would be:

   foo = *("a" / "b" / "c" / "d")

This isn't easy to fix because of way the ABNF of RFC5322 is structured. 
What you need is for RFC5322 to be restructured as follows:


   fields  =   *trace-prefix
   *normal-field


   trace-prefix=   trace
 *optional-field /
 *resent
 *(resent-date /
  resent-from /
  resent-sender /
  resent-to /
  resent-cc /
  resent-bcc /
  resent-msg-id)

   normal-field =  orig-date /
   from /
   sender /
   reply-to /
   to /
   cc /
   bcc /
   message-id /
   in-reply-to /
   references /
   subject /
   comments /
   keywords /
   optional-field

(Note: I've focused on the normal-field part. Additional work is 
probably required on the trace-prefix to get proper extensibility.)


Once that is done, then RFC5536 could be revised as follows:

   normal-field=/approved /
 archive /
 control /
 distribution /
 expires /
 followup-to /
 injection-date /
 injection-info /
 lines /
 newsgroups /
 organization /
 path /
 summary /
 supersedes /
 user-agent /
 xref

And your ABNF can then be:

  normal-field =/ cancel-lock / cancel-key

Then 

[Gen-art] Gen-ART Last Call review of draft-baeuerle-netnews-cancel-lock-05

[Paul Kyzivat]

I am the assigned Gen-ART reviewer for this draft. The General Area 
Review Team (Gen-ART) reviews all IETF documents being processed by the 
IESG for the IETF Chair. Please wait for direction from your document 
shepherd or AD before posting a new version of the draft. For more 
information, please see the FAQ at 
<​http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.


Document: draft-baeuerle-netnews-cancel-lock-05
Reviewer: Paul Kyzivat
Review Date: 2017-04-22
IETF LC End Date: 2017-06-28
IESG Telechat date: TBD

Summary:

This draft is on the right track but has open issues, described in the 
review.


General Comments:

I have not attempted to validate the security properties of this 
document - leaving that to a security review.


I have also not attempted to verify the operational suitability of this 
mechanism because I don't have the experience needed to do so.


Issues:

Major: 1
Minor: 3
Nits:  0

(1) MAJOR:

In Section 2, the ABNF syntax provided does not do what you want it to. 
You supply:


  fields =/ *( cancel-lock / cancel-key )

as an extension to the definition in RFC5536:

   fields  =/ *( approved /
 archive /
 control /
 distribution /
 expires /
 followup-to /
 injection-date /
 injection-info /
 lines /
 newsgroups /
 organization /
 path /
 summary /
 supersedes /
 user-agent /
 xref )

and that in turn extends RFC5322:

   fields  =   *(trace
 *optional-field /
 *(resent-date /
  resent-from /
  resent-sender /
  resent-to /
  resent-cc /
  resent-bcc /
  resent-msg-id))
   *(orig-date /
   from /
   sender /
   reply-to /
   to /
   cc /
   bcc /
   message-id /
   in-reply-to /
   references /
   subject /
   comments /
   keywords /
   optional-field)

   message =   (fields / obs-fields)
   [CRLF body]

RFC5536 got this wrong, and the new draft continues the mistake. The 
problem is with the way things are grouped. Let me give a simpler example:


   foo = *("a" / "b") / *("c" / "d")

This means the following are valid: ab aabb bab cd ccdd dcd
But the following are not: abcd ac

The latter is what you want, for which the syntax would be:

   foo = *("a" / "b" / "c" / "d")

This isn't easy to fix because of way the ABNF of RFC5322 is structured. 
What you need is for RFC5322 to be restructured as follows:


   fields  =   *trace-prefix
   *normal-field


   trace-prefix=   trace
 *optional-field /
 *resent
 *(resent-date /
  resent-from /
  resent-sender /
  resent-to /
  resent-cc /
  resent-bcc /
  resent-msg-id)

   normal-field =  orig-date /
   from /
   sender /
   reply-to /
   to /
   cc /
   bcc /
   message-id /
   in-reply-to /
   references /
   subject /
   comments /
   keywords /
   optional-field

(Note: I've focused on the normal-field part. Additional work is 
probably required on the trace-prefix to get proper extensibility.)


Once that is done, then RFC5536 could be revised as follows:

   normal-field=/approved /
 archive /
 control /
 distribution /
 expires /
 followup-to /
 injection-date /
 injection-info /
 lines /
 newsgroups /
 organization /
 path /
 summary /
 supersedes /
 user-agent /
 xref

And your ABNF can then be:

  normal-field =/ cancel-lock / cancel-key

Then you will have a syntax that reflects your 

Re: [Gen-art] Genart last call review of draft-ietf-sipcore-content-id-06

[Christer Holmberg]

Hi,

>Looks like we are clear on all this, except that:
>1.  I would suggest making it explicit that you can add a Content-ID header 
>even to a
> message with a multipart message-body to avoid any confusion.  I am not sure 
> that it
> makes any sense but I guess it wouldn't do any harm.

I suggest adding the following note to the end of section 3.3.


“NOTE: The message body identified by the Content-ID header field can be a

non-multipart message-body or a multipart message-body.”

>2.  If a message of a kind that can legitimately have a Content-ID arrives 
>with a
>
>Content-ID (or indeed any Content-*) header but no message-body, presumably 
>one would
> send a 400 error with a suitable reason phrase.  I think it would be worth 
> being explicit about this.

Well, there is actually a use-case for a Content-Type value (I did not check 
the other header fields) but no message-body.

Section 20.15 of RFC 3261 says:


“If the body is empty, and a Content-Type header field is present, it 
indicates that the body of the specific

type has zero length (for example, an empty audio file).”

And, to echo Paul, I don’t see a reason to say something specific for the 
Content-* header fields. Normal SIP procedures should apply regarding receiving 
header fields with no meaning for a particular SIP message.

Regards,

Christer



 Original message 
From: Christer Holmberg 
>
Date: 23/06/2017 12:45 (GMT+00:00)
To: Elwyn Davies >, 
gen-art@ietf.org
Cc: 
draft-ietf-sipcore-content-id@ietf.org,
 sipc...@ietf.org, i...@ietf.org
Subject: RE: Genart last call review of draft-ietf-sipcore-content-id-06

Hi Elwyn,

Thank You for the review! Please see inline.

>Summary:
>Ready with nits.  There are a couple of minor issues related to the procedures 
>after inappropriate usage of the new header.
>
>Major issues:
>None
>
>Minor issues:
>
> s3.4.1, last para: In line with the last sentence of Section 3.2, the 
> Content-ID URL only needs to be unique within the SIP message where it occurs.
> I assume it does not make sense to have a Content-ID header combined with a 
> mutipart message-body (this isn't stated - maybe it should be);

I am not aware of any current use-case, but I see no reason to forbid it. 
Perhaps someone will come up with a use-case in future.

> I am not sufficiently knowledgeable in this area of SIP to know if there 
> could be content-id URLs in other headers if there is a Content-ID
> header in the message.  Thus either the statement about global uniqueness is 
> irrelevant (as there is only one) and can be removed or it
> should be made consistent with s3.2 so that the Content URLs are unique 
> within the message. Global uniqueness is neither possible or required.

The statement about global uniqueness is a bug, and will be fixed. The value 
only has to be unique within the message.

> s3.4.1, para 1: Following on from the previous comment: Is a UA allowed to 
> add a Content-ID header to a message with a multipart message-body?

I see no reason to forbid it.

> s3.4.1: What should a UA do if it receives a message with a Content-ID header 
> when the message is not allowed to
> contain one?  Is there some generic error procedure that should be referenced?

Normal RFC 3261 procedures apply. I don't think we want to copy/paste the 
generic header processing rules,

> s6.1: I started looking for specification that told me that items added to 
> the SIP header fields registry effectively
> extend the definition of the message-header production in Section 25.1of RFC 
> 3261.  Bit obvious perhaps, but it
> would be nice if it had been said somewhere!  Time for an Erratum perhaps?

In the ABNF of RFC 3261, "message-header" contains the header fields defined in 
the RFC, plus "extension-header", which is used for new headers. I assume 
people think that is clear enough :)

Having said that, what you suggest is not necessarily a bad idea, but it is 
outside the scope of this draft.

>Nits/editorial comments:
>
>Abstract:  I would suggest adding a sentence that clarifies what the update of 
>RFC 5621 is modifying:
>
>OLD: The document also updates RFC 5621, to enable a Content-ID URL to 
>reference a complete
>message-body and metadata provided by some additional SIP header fields.
>
>NEW: The document  also updates RFC 5621, which only allows a Content-ID URL 
>to reference a
>body-part that is part of a multipart message-body.  This update enables a 
>Content-ID URL to
>reference a complete message-body and metadata provided by some additional SIP 
>header fields. END

Looks ok. I will modify as suggested.

>s1.2, first bullet: s/for providing location/for providing location 
>information/

Will be fixed as suggested.

>s1.4.1: Need 

Re: [Gen-art] Genart last call review of draft-ietf-sipcore-content-id-06

[Paul Kyzivat]

On 6/23/17 10:53 AM, Elwyn Davies wrote:

2.  If a message of a kind that can legitimately have a Content-ID 
arrives with a Content-ID (or indeed any Content-*) header but no 
message-body, presumably one would send a 400 error with a suitable 
reason phrase.  I think it would be worth being explicit about this.


I don't see any reason for this. It is a degenerate case, but harmless.

The reason for including Content-ID is to allow use of cid: URLs. 
Presumably a cid: url referencing a Content-ID where there is no body 
would be problematic, though perhaps there may again be some degenerate 
case where it could make sense.


Thanks,
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-sipcore-content-id-06

[Elwyn Davies]

Hi, Christer.
Thanks for the quick response.
Looks like we are clear on all this, except that:1.  I would suggest making it 
explicit that you can add a Content-ID header even to a message with a 
multipart message-body to avoid any confusion.  I am not sure that it makes any 
sense but I guess it wouldn't do any harm. 2.  If a message of a kind that can 
legitimately have a Content-ID arrives with a Content-ID (or indeed any 
Content-*) header but no message-body, presumably one would send a 400 error 
with a suitable reason phrase.  I think it would be worth being explicit about 
this.
Cheers,Elwyn


Sent from Samsung tablet.
 Original message From: Christer Holmberg 
 Date: 23/06/2017  12:45  (GMT+00:00) To: Elwyn 
Davies , gen-art@ietf.org Cc: 
draft-ietf-sipcore-content-id@ietf.org, sipc...@ietf.org, i...@ietf.org 
Subject: RE: Genart last call review of draft-ietf-sipcore-content-id-06 
Hi Elwyn,

Thank You for the review! Please see inline.

>Summary:
>Ready with nits.  There are a couple of minor issues related to the procedures 
>after inappropriate usage of the new header.
>
>Major issues:
>None
>
>Minor issues:
>
> s3.4.1, last para: In line with the last sentence of Section 3.2, the 
> Content-ID URL only needs to be unique within the SIP message where it occurs.
> I assume it does not make sense to have a Content-ID header combined with a 
>mutipart message-body (this isn't stated - maybe it should be);

I am not aware of any current use-case, but I see no reason to forbid it. 
Perhaps someone will come up with a use-case in future.

> I am not sufficiently knowledgeable in this area of SIP to know if there 
> could be content-id URLs in other headers if there is a Content-ID 
> header in the message.  Thus either the statement about global uniqueness is 
> irrelevant (as there is only one) and can be removed or it 
> should be made consistent with s3.2 so that the Content URLs are unique 
> within the message. Global uniqueness is neither possible or required.

The statement about global uniqueness is a bug, and will be fixed. The value 
only has to be unique within the message.

> s3.4.1, para 1: Following on from the previous comment: Is a UA allowed to 
> add a Content-ID header to a message with a multipart message-body?

I see no reason to forbid it.

> s3.4.1: What should a UA do if it receives a message with a Content-ID header 
> when the message is not allowed to 
> contain one?  Is there some generic error procedure that should be referenced?

Normal RFC 3261 procedures apply. I don't think we want to copy/paste the 
generic header processing rules,

> s6.1: I started looking for specification that told me that items added to 
> the SIP header fields registry effectively
> extend the definition of the message-header production in Section 25.1of RFC 
> 3261.  Bit obvious perhaps, but it 
> would be nice if it had been said somewhere!  Time for an Erratum perhaps?

In the ABNF of RFC 3261, "message-header" contains the header fields defined in 
the RFC, plus "extension-header", which is used for new headers. I assume 
people think that is clear enough :)

Having said that, what you suggest is not necessarily a bad idea, but it is 
outside the scope of this draft.

>Nits/editorial comments:
>
>Abstract:  I would suggest adding a sentence that clarifies what the update of 
>RFC 5621 is modifying: 
>
>OLD: The document also updates RFC 5621, to enable a Content-ID URL to 
>reference a complete 
>message-body and metadata provided by some additional SIP header fields. 
>
>NEW: The document  also updates RFC 5621, which only allows a Content-ID URL 
>to reference a 
>body-part that is part of a multipart message-body.  This update enables a 
>Content-ID URL to 
>reference a complete message-body and metadata provided by some additional SIP 
>header fields. END

Looks ok. I will modify as suggested.

>s1.2, first bullet: s/for providing location/for providing location 
>information/

Will be fixed as suggested.

>s1.4.1: Need to expand UAC (User Agent Client) on first usage.

I realized the first usage is in section 1.3, so I will expend it there.

>s1.4.1, para 1: s/can be e.g. of/can be, for example, of/

Will be fixed as suggested.

>s3.4.1: Need to expand UA (User Agent) on first usage (in section title).

Will be fixed as suggested.

>s4, NEW text: s/allow creating/allow the creation of/

Will be fixed as suggested.

Regards,

Christer

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

Re: [Gen-art] Genart last call review of draft-ietf-sipcore-content-id-06

[Christer Holmberg]

Hi Elwyn,

Thank You for the review! Please see inline.

>Summary:
>Ready with nits.  There are a couple of minor issues related to the procedures 
>after inappropriate usage of the new header.
>
>Major issues:
>None
>
>Minor issues:
>
> s3.4.1, last para: In line with the last sentence of Section 3.2, the 
> Content-ID URL only needs to be unique within the SIP message where it occurs.
> I assume it does not make sense to have a Content-ID header combined with a 
>mutipart message-body (this isn't stated - maybe it should be);

I am not aware of any current use-case, but I see no reason to forbid it. 
Perhaps someone will come up with a use-case in future.

> I am not sufficiently knowledgeable in this area of SIP to know if there 
> could be content-id URLs in other headers if there is a Content-ID 
> header in the message.  Thus either the statement about global uniqueness is 
> irrelevant (as there is only one) and can be removed or it 
> should be made consistent with s3.2 so that the Content URLs are unique 
> within the message. Global uniqueness is neither possible or required.

The statement about global uniqueness is a bug, and will be fixed. The value 
only has to be unique within the message.

> s3.4.1, para 1: Following on from the previous comment: Is a UA allowed to 
> add a Content-ID header to a message with a multipart message-body?

I see no reason to forbid it.

> s3.4.1: What should a UA do if it receives a message with a Content-ID header 
> when the message is not allowed to 
> contain one?  Is there some generic error procedure that should be referenced?

Normal RFC 3261 procedures apply. I don't think we want to copy/paste the 
generic header processing rules,

> s6.1: I started looking for specification that told me that items added to 
> the SIP header fields registry effectively
> extend the definition of the message-header production in Section 25.1of RFC 
> 3261.  Bit obvious perhaps, but it 
> would be nice if it had been said somewhere!  Time for an Erratum perhaps?

In the ABNF of RFC 3261, "message-header" contains the header fields defined in 
the RFC, plus "extension-header", which is used for new headers. I assume 
people think that is clear enough :)

Having said that, what you suggest is not necessarily a bad idea, but it is 
outside the scope of this draft.

>Nits/editorial comments:
>
>Abstract:  I would suggest adding a sentence that clarifies what the update of 
>RFC 5621 is modifying: 
>
>OLD: The document also updates RFC 5621, to enable a Content-ID URL to 
>reference a complete 
>message-body and metadata provided by some additional SIP header fields. 
>
>NEW: The document  also updates RFC 5621, which only allows a Content-ID URL 
>to reference a 
>body-part that is part of a multipart message-body.  This update enables a 
>Content-ID URL to 
>reference a complete message-body and metadata provided by some additional SIP 
>header fields. END

Looks ok. I will modify as suggested.

>s1.2, first bullet: s/for providing location/for providing location 
>information/

Will be fixed as suggested.

>s1.4.1: Need to expand UAC (User Agent Client) on first usage.

I realized the first usage is in section 1.3, so I will expend it there.

>s1.4.1, para 1: s/can be e.g. of/can be, for example, of/

Will be fixed as suggested.

>s3.4.1: Need to expand UA (User Agent) on first usage (in section title).

Will be fixed as suggested.

>s4, NEW text: s/allow creating/allow the creation of/

Will be fixed as suggested.

Regards,

Christer

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