Re: [Gen-art] Gen-art LC2/Telechat review of draft-ietf-insipid-session-id-24

[Elwyn Davies]

Hi, Ben.
AFAICS there is only one really similar case (downref to RFC 6707) which was 
approved just last month (based on a problem statement).  My concern here is 
that the other framework and requirements documents are documents that continue 
to have a relevance (such as telling a network operator what is necessary to 
allow deployment of some IETF-defined technology) rather than being something 
that defines what a WG is intending to work on (RFC 6707 and RFC 7206 are 
respectively a problem statement and a protocol requirements statement).  As we 
know, there has been some considerable discussion of whether we should really 
be publishing these documents as RFCs given that they are snapshots of a 
discussion position at a point in time and are only really of academic interest 
once the working group has done its work.  Allowing them to be used as 
normative references further embeds them into the system.
I would also caution that terminology and such like as defined in (protocol) 
requirements and problem statements are generally written and approved prior to 
the standards documents in which the are referenced. Further, I am not totally 
convinced that the same degree of rigour is applied to the review of this type 
of document.  Thus it is vitally important to ensure that the definitions are 
still correct, complete and reflect what is needed for the standard(s):  The 
protocols don't always exactly match the requirements - and there may have been 
some subtle bending of the meaning of terms over time!
If the downref is to be accepted, then I (and other reviewers) need to go back 
and have a harder read of the definitions, unless they think they already did.  
One consequential question: Is it time for either an update or some commentary 
on RFC 3967 as there seems to be a relaxation of the statements in Section 2?   
 
However
My view is just that... if the authors, WG, you as AD and the IESG are happy 
with the downref and I am in a minority of one (or a very small number) of the 
IETF, then there is rough concensus and I'll be fine with the outcome.  It is 
only a gen-art revew...
Cheers,Elwyn
PSI note that it wouldn't be too late to undo the relaxation.. the draft 
referencing RFC 6707 is still with the RFC Editor ;-)
/E

Sent from Samsung tablet.
 Original message From: Ben Campbell  Date: 
12/08/2016  19:58  (GMT+00:00) To: Elwyn Davies  Cc: 
General area reviewing team , 
draft-ietf-insipid-session-id@ietf.org Subject: Re: Gen-art LC2/Telechat 
review of draft-ietf-insipid-session-id-24 
On 12 Aug 2016, at 10:40, Elwyn Davies wrote:

> I am the assigned Gen-ART reviewer for this draft. The General Area
> Review Team (Gen-ART) reviews all IETF documents being processed
> 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-insipid-session-id-26.txt
> Reviewer: Elwyn Davies
> Review Date: 2016/08/12
> IETF LC End Date: 2016/08/04
> IESG Telechat date: 2016/08/18
>
> Summary: (2nd Last Call and Telechat) Almost ready. The points from my 
> review of -24 in the first Last Call have all been addressed - thanks 
> - with the exception of the location of the key definitions of 
> "session id" and "communication session".  The latest version (-26) 
> refers the reader to RFC 7206 which needs to be a normative reference 
> but is an Informational RFC, creating a downref.    I cannot see that 
> a requirements document meets the criteria for an allowable downref as 
> described in Section 2 of RFC 3967. Reproducing the two definitions in 
> the new draft (and ensuring that they are accurate for the standards 
> document) seems to be a better solution IMO.

Hi Elwyn,

Thanks for all of your reviews on this so far. I agree with the original 
issue, but I disagree with what I understand to be your preferred 
solution.

I agree the definitions are needed to understand this draft. And if 
these were simple definitions, I would agree that this draft should 
simply copy them. But they are not, they are nuanced definitions with 
quite a bit of discussion text. Copying them into this draft would 
require the wholesale copying of 2 sections from RFC 7206, which contain 
about 20 paragraphs and one diagram. That's roughly 20% of the body of 
7206 (not counting front material or references.)

I disagree that this is not an allowable downref. The list in section 2 
of RFC 3967 is a list of examples, not an exhaustive list. We have lots 
of examples of approved RFCs with downrefs to informational RFCs because 
the referenced RFC defined terminology needed to understand the 
dependent document.

Thanks!

Ben.


>
> Major issues:
> None
>
> Minor issues:
> Downref to RFC 7206 - see above.
>
> Editorial/Nits:
> Missing 

Re: [Gen-art] Generate review of draft-ietf-tsvwg-gre-in-udp-encap-16

[Lucy yong]

Hi Jouni,

OOPS, forget this one, sorry.

o My “complaint” of this document is basically on the following.. these are 
writing
   style things so feel free to neglect:
   - It repeats.. the same statements multiple times.
Lucy: perhaps some can reference previous section. 
   - When reading the document I get the feeling it is actually two documents. 
The
 technical specification (which is very short) and the general deployment
 considerations document. I would have split it to two but that is just me.
Lucy: When we were developing this document, we kindly became clear ourselves, 
we need to address two parts and want to do in one document.

Regards,
Lucy



-Original Message-
From: Gen-art [mailto:gen-art-boun...@ietf.org] On Behalf Of Jouni
Sent: Friday, August 12, 2016 1:51 AM
To: gen-art@ietf.org (gen-art@ietf.org); 
draft-ietf-tsvwg-gre-in-udp-encap@ietf.org
Subject: [Gen-art] Generate review of draft-ietf-tsvwg-gre-in-udp-encap-16

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-tsvwg-gre-in-udp-encap-16
Reviewer: Jouni Korhonen
Review Date: 8/11/2016
IETF LC End Date: 2016-08-12
IESG Telechat date: (if known)

Summary:  Ready with minor nits.

Major issues: None.

Minor issues: Read on..

Editorials/nits:
 o My “complaint” of this document is basically on the following.. these are 
writing
   style things so feel free to neglect:
   - It repeats.. the same statements multiple times.
   - When reading the document I get the feeling it is actually two documents. 
The
 technical specification (which is very short) and the general deployment
 considerations document. I would have split it to two but that is just me.

The other nits.

 o There are bunch of acronyms that are not expanded either never or on their 
first use. 
   Some examples include UDP, DSCP, DS, PMTU, MPLS, VNP, .. Pay attention to 
these.
 o In the Introduction give a reference to EtherType e.g., the repository where 
they
   are maintained or by whom they are maintained.
 o On line 129 is says: 
   This document specifies GRE-in-UDP tunnel requirements for two
   Based on the earlier text I would suggest saying “..document also 
specifies..”
 o On line 143 I would also (following the previous style in the paragraph) 
capitalize
   “wide area networks” as well.
 o In multiple places (lines 236, 887) the reference is after the full stop. 
Place full
   stop after the reference.
 o The document uses both tunnel ingress/egress and encapsulator/decapsulator. 
Is there a
   specific reason to have this differentiation? If not use common terminology 
throughout
   the document.
 o On line 654 is says:
MUST comply with requirement 1 and 8-10 in Section 5 of
   How is this “MUST” enforced?
 o In Section 7.1 I find it a bit odd discussing NATs in the specific context 
of IPv6. If
   you have a specific IPv6 NAT scenario in mind either spell it out or give a 
reference
   to a specification that describes the technology/use case.
 o In Section 8 and lines 784-785 has a “MUST NOT” for traffic that is not 
known to be
   congestion-controlled.. I would be interested in knowing how to enforce this 
“MUST”
   specifically in the Internet case.
 o Line 909 typo “ether” -> “either”.

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

Re: [Gen-art] Generate review of draft-ietf-tsvwg-gre-in-udp-encap-16

[Lucy yong]

Hi Jouni,

Thank you for the review and correction. Pls see inline below.

-Original Message-
From: Gen-art [mailto:gen-art-boun...@ietf.org] On Behalf Of Jouni
Sent: Friday, August 12, 2016 1:51 AM
To: gen-art@ietf.org (gen-art@ietf.org); 
draft-ietf-tsvwg-gre-in-udp-encap@ietf.org
Subject: [Gen-art] Generate review of draft-ietf-tsvwg-gre-in-udp-encap-16

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-tsvwg-gre-in-udp-encap-16
Reviewer: Jouni Korhonen
Review Date: 8/11/2016
IETF LC End Date: 2016-08-12
IESG Telechat date: (if known)

Summary:  Ready with minor nits.

Major issues: None.

Minor issues: Read on..

Editorials/nits:
 o My “complaint” of this document is basically on the following.. these are 
writing
   style things so feel free to neglect:
   - It repeats.. the same statements multiple times.
   - When reading the document I get the feeling it is actually two documents. 
The
 technical specification (which is very short) and the general deployment
 considerations document. I would have split it to two but that is just me.

The other nits.

 o There are bunch of acronyms that are not expanded either never or on their 
first use. 
   Some examples include UDP, DSCP, DS, PMTU, MPLS, VNP, .. Pay attention to 
these.
[Lucy] I will check. 
 o In the Introduction give a reference to EtherType e.g., the repository where 
they
   are maintained or by whom they are maintained.
[Lucy] I will put RFC7042 as the reference.
 o On line 129 is says: 
   This document specifies GRE-in-UDP tunnel requirements for two
   Based on the earlier text I would suggest saying “..document also 
specifies..”
[Lucy] ack.
 o On line 143 I would also (following the previous style in the paragraph) 
capitalize
   “wide area networks” as well.
[Lucy] ack.
 o In multiple places (lines 236, 887) the reference is after the full stop. 
Place full
   stop after the reference.
[Lucy] My mistake. Will correct them.
 o The document uses both tunnel ingress/egress and encapsulator/decapsulator. 
Is there a
   specific reason to have this differentiation? If not use common terminology 
throughout
   the document.
[Lucy] I would prefer to use two teams in the document. Tunnel ingress and 
egress is the view from network perspective,
And encapsulator/decapsulator is the view at the ingress or egress. E.g. it is 
odd to say encapsulator IP address. I open to add a clarification if that 
causes a concern.

 o On line 654 is says:
MUST comply with requirement 1 and 8-10 in Section 5 of
   How is this “MUST” enforced?
[Lucy] Do you concern on the wording or the implementation? 

 o In Section 7.1 I find it a bit odd discussing NATs in the specific context 
of IPv6. If
   you have a specific IPv6 NAT scenario in mind either spell it out or give a 
reference
   to a specification that describes the technology/use case.
[Lucy] This section describes middlebox specialty on IPv6 traffic. Most UDP 
applications do not perform UDP checksum in IPv4 network; most UDP applications 
perform UDP checksum in IPv6 network because of IPv6 requirement [RFC2460]. 
Thus some middleboxes validate UDP checksum if it is in IPv6. [RFC6935] 
[RFC6936] relax the need to perform UDP checksum in some special cases, which 
is applicable to this draft. But we need to state out the potential impact that 
is specific in IPv6.  
 o In Section 8 and lines 784-785 has a “MUST NOT” for traffic that is not 
known to be
   congestion-controlled.. I would be interested in knowing how to enforce this 
“MUST”
   specifically in the Internet case.
[Lucy] By IETF standard. :)  How about replace "MUST NOT" with "are not 
appropriate"? (match the wording in requirement 3 of Section 2.1.1)  
 o Line 909 typo “ether” -> “either”.
[Lucy] ack. Thx. 

Regards,
Lucy

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

Re: [Gen-art] Gen-art LC2/Telechat review of draft-ietf-insipid-session-id-24

[Ben Campbell]

On 12 Aug 2016, at 10:40, Elwyn Davies wrote:


I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
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-insipid-session-id-26.txt
Reviewer: Elwyn Davies
Review Date: 2016/08/12
IETF LC End Date: 2016/08/04
IESG Telechat date: 2016/08/18

Summary: (2nd Last Call and Telechat) Almost ready. The points from my 
review of -24 in the first Last Call have all been addressed - thanks 
- with the exception of the location of the key definitions of 
"session id" and "communication session".  The latest version (-26) 
refers the reader to RFC 7206 which needs to be a normative reference 
but is an Informational RFC, creating a downref.I cannot see that 
a requirements document meets the criteria for an allowable downref as 
described in Section 2 of RFC 3967. Reproducing the two definitions in 
the new draft (and ensuring that they are accurate for the standards 
document) seems to be a better solution IMO.


Hi Elwyn,

Thanks for all of your reviews on this so far. I agree with the original 
issue, but I disagree with what I understand to be your preferred 
solution.


I agree the definitions are needed to understand this draft. And if 
these were simple definitions, I would agree that this draft should 
simply copy them. But they are not, they are nuanced definitions with 
quite a bit of discussion text. Copying them into this draft would 
require the wholesale copying of 2 sections from RFC 7206, which contain 
about 20 paragraphs and one diagram. That's roughly 20% of the body of 
7206 (not counting front material or references.)


I disagree that this is not an allowable downref. The list in section 2 
of RFC 3967 is a list of examples, not an exhaustive list. We have lots 
of examples of approved RFCs with downrefs to informational RFCs because 
the referenced RFC defined terminology needed to understand the 
dependent document.


Thanks!

Ben.




Major issues:
None

Minor issues:
Downref to RFC 7206 - see above.

Editorial/Nits:
Missing definitions of "session id" and "communication session" - see 
above.


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

[Gen-art] Gen-art LC2/Telechat review of draft-ietf-insipid-session-id-24

[Elwyn Davies]

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-insipid-session-id-26.txt
Reviewer: Elwyn Davies
Review Date: 2016/08/12
IETF LC End Date: 2016/08/04
IESG Telechat date: 2016/08/18

Summary: (2nd Last Call and Telechat) Almost ready. The points from my 
review of -24 in the first Last Call have all been addressed - thanks - 
with the exception of the location of the key definitions of "session 
id" and "communication session".  The latest version (-26) refers the 
reader to RFC 7206 which needs to be a normative reference but is an 
Informational RFC, creating a downref.I cannot see that a 
requirements document meets the criteria for an allowable downref as 
described in Section 2 of RFC 3967. Reproducing the two definitions in 
the new draft (and ensuring that they are accurate for the standards 
document) seems to be a better solution IMO.


Major issues:
None

Minor issues:
Downref to RFC 7206 - see above.

Editorial/Nits:
Missing definitions of "session id" and "communication session" - see above.

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

[Gen-art] Generate review of draft-ietf-tsvwg-gre-in-udp-encap-16

[Jouni]

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-tsvwg-gre-in-udp-encap-16
Reviewer: Jouni Korhonen
Review Date: 8/11/2016
IETF LC End Date: 2016-08-12
IESG Telechat date: (if known)

Summary:  Ready with minor nits.

Major issues: None.

Minor issues: Read on..

Editorials/nits:
 o My “complaint” of this document is basically on the following.. these are 
writing
   style things so feel free to neglect:
   - It repeats.. the same statements multiple times.
   - When reading the document I get the feeling it is actually two documents. 
The
 technical specification (which is very short) and the general deployment
 considerations document. I would have split it to two but that is just me.

The other nits.

 o There are bunch of acronyms that are not expanded either never or on their 
first use. 
   Some examples include UDP, DSCP, DS, PMTU, MPLS, VNP, .. Pay attention to 
these.
 o In the Introduction give a reference to EtherType e.g., the repository where 
they
   are maintained or by whom they are maintained.
 o On line 129 is says: 
   This document specifies GRE-in-UDP tunnel requirements for two
   Based on the earlier text I would suggest saying “..document also 
specifies..”
 o On line 143 I would also (following the previous style in the paragraph) 
capitalize
   “wide area networks” as well.
 o In multiple places (lines 236, 887) the reference is after the full stop. 
Place full
   stop after the reference.
 o The document uses both tunnel ingress/egress and encapsulator/decapsulator. 
Is there a
   specific reason to have this differentiation? If not use common terminology 
throughout
   the document.
 o On line 654 is says:
MUST comply with requirement 1 and 8-10 in Section 5 of
   How is this “MUST” enforced?
 o In Section 7.1 I find it a bit odd discussing NATs in the specific context 
of IPv6. If
   you have a specific IPv6 NAT scenario in mind either spell it out or give a 
reference
   to a specification that describes the technology/use case.
 o In Section 8 and lines 784-785 has a “MUST NOT” for traffic that is not 
known to be
   congestion-controlled.. I would be interested in knowing how to enforce this 
“MUST”
   specifically in the Internet case.
 o Line 909 typo “ether” -> “either”.

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