Re: [Softwires] [Gen-art] Genart last call review of draft-ietf-softwire-iftunnel-04

[Alissa Cooper]

Dale, thanks for your review. Med, thanks for your response. I entered a No 
Objection ballot.

Alissa

> On May 6, 2019, at 3:49 AM, mohamed.boucad...@orange.com wrote:
> 
> Dear Dale, 
> 
> Thank for the review. 
> 
> Please see inline.
> 
> Cheers,
> Med
> 
>> -Message d'origine-
>> De : Dale Worley via Datatracker [mailto:nore...@ietf.org]
>> Envoyé : lundi 6 mai 2019 04:22
>> À : gen-...@ietf.org
>> Cc : softwires@ietf.org; i...@ietf.org; draft-ietf-softwire-
>> iftunnel@ietf.org
>> Objet : Genart last call review of draft-ietf-softwire-iftunnel-04
>> 
>> 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-softwire-iftunnel-04
>> Reviewer:  Dale R. Worley
>> Review Date:  2019-05-05
>> IETF LC End Date:  2019-05-07
>> IESG Telechat date:  [not known]
>> 
>> Summary:
>> 
>>   This draft is ready for publication as a Standards Track RFC.
>> 
>> Nits/editorial comments:
>> 
>>   Editorial Note (To be removed by RFC Editor)
>> 
>> This section is a great idea.  I haven't seen this usage before.
>> 
>>   Please update the "revision" date of the YANG modules.
>> 
>> This sentence doesn't say what to update the revision date to.
>> 
> 
> [Med] The revision date will be updated with the publication date of the 
> (future) RFC. The RFC editor is used with that. 
> 
>>   1.  Introduction
>> 
>>   This document specifies the initial version of the iana-tunnel-type
>>   YANG module identifying tunnel interface types.
>> 
>> This could be made more specific, e.g.,
>> 
>>   This document specifies the initial version of the iana-tunnel-type
>>   YANG module containing a collection of IANA maintained YANG
>>   identities identifying tunnel interface types.
>> 
> 
> [Med] OK.
> 
>> --
>> 
>>   2.  IANA Tunnel Type YANG Module
>> 
>>   The initial version of the module includes tunnels types defined in
>>   [RFC4087], [RFC7856], [RFC7870], and [RFC6346].
>> 
>> s/tunnels types/tunnel types/
>> 
> 
> [Med] Fixed.
> 
>> Should this mention the provenance of IP-HTTPS, which is in none of
>> these RFCs?
> 
> [Med] This is already covered by the "reference" clause. 
> 
>> 
>> identity iphttps {
>>   base ift:tunnel;
>>   description
>> "IP over HTTPS (IP-HTTPS) Tunneling Protocol.";
>>   reference
>> "Microsoft Corporation, IP over HTTPS (IP-HTTPS) Tunneling
>>  Protocol Specification,
>>  https://msdn.microsoft.com/en-us/library/dd358571.aspx;;
>> }
>> 
>> This type's reference doesn't appear in the list of references.
> 
> [Med] That is on purpose because otherwise that reference will need to be 
> called out in the core text. 
> 
>> 
>>   3.  Security Considerations
>> 
>>   These identies are intended to be
>>   referenced by other YANG modules, and by themselves do not expose any
>>   nodes which are writable, contain read-only state, or RPCs.
>> 
>> Logically, this is correct, but I think it would read better if
>> s/contain read-only state/contain readable state/.
> 
> [Med] I will leave the initial wording. 
> 
>> 
>>   4.1.  YANG Module
>> 
>>   The name of the "identity" is the same as the corresponding
>>   enumeration in the IANAifType-MIB (i.e., IANAtunnelType).
>> 
>> This should be "... is the lower-case of the corresponding enumeration
>> ...".
>> 
>>   "base":Contains the name assigned to the tunnel type, in
>>  lowercase.
>> 
>> The description of this item should be "Contains 'ift:tunnel'.".
> 
> [Med] Good catch. Thanks. 
> 
>> 
>>   6.2.  Informative References
>> 
>>   [TUNNELTYPE-IANA-REGISTRY]
>>  Internet Assigned Numbers Authority, "tunnelType
>>  Definitions", >  numbers/smi-numbers.xhtml#smi-numbers-6>.
>> 
>> Given that this document specifies substantial interaction with this
>> registry, this reference should be normative.
> 
> [Med] We used to have this one as normative but we received comments asking 
> to move it informative. I will leave this one to the AD. 
> 
>> 
>> The title of this reference cannot be "tunnelType Definitions",
>> because that text does not appear in either the referenced URL or the
>> IANA assigned numbers index (https://www.iana.org/protocols).  The
>> title of the entire web page is "Structure of Management Information
>> (SMI) Numbers (MIB Module Registrations)"; the title of the section
>> that is referenced is "Internet-standard MIB -
>> mib-2.interface.ifTable.ifEntry.ifType.tunnelType", which is a
>> subsection of the section titled "ifType definitions".  There is no
>> reference to the section from the IANA 

Re: [Softwires] [Gen-art] Genart telechat review of draft-ietf-softwire-map-radius-24

[Alissa Cooper]

Joel, thanks for your review. I entered a No Objection ballot.

Alissa

> On Jun 6, 2019, at 6:28 PM, Joel Halpern via Datatracker  
> wrote:
> 
> 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 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-softwire-map-radius-24
> Reviewer: Joel Halpern
> Review Date: 2019-06-06
> IETF LC End Date: None
> IESG Telechat date: 2019-06-13
> 
> Summary: This document is ready for publication as a Proposed Standard RFC
> 
> My thanks to the authors for addressing the comments I raised.
> 
> Major issues: N/A
> 
> Minor issues: N/A
> 
> Nits/editorial comments: N/A
> 
> 
> 
> ___
> Gen-art mailing list
> gen-...@ietf.org
> https://www.ietf.org/mailman/listinfo/gen-art

___
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires

Re: [Softwires] [Gen-art] Genart last call review of draft-ietf-softwire-yang-06

[Alissa Cooper]

Roni, thanks for your reviews. Ian, thanks for your responses. I entered a 
DISCUSS ballot concerning the security considerations.

Best,
Alissa

> On Jan 7, 2019, at 7:42 AM, ianfar...@gmx.com wrote:
> 
> Hi Roni,
> 
> My apologies for the oversight. I’ve just posted -14 which includes the 
> RESTCONF reference in the Introduction.
> 
> Thanks,
> Ian
> 
>> On 9. Oct 2018, at 09:02, Roni Even > > wrote:
>> 
>> Reviewer: Roni Even
>> 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-softwire-yang-??
>> Reviewer: Roni Even
>> Review Date: 2018-10-08
>> IETF LC End Date: 2018-10-11
>> IESG Telechat date: Not scheduled for a telechat
>> 
>> Summary:
>> The document is ready for publication as a standard track RFC with nits
>> 
>> Major issues:
>> 
>> Minor issues:
>> 
>> Nits/editorial comments:
>> 1. In section 1 it says that the YANG data model can be used with netconf , I
>> noticed that restconf is only mentioned in the security section as network
>> management. why not add restconf to introduction?
>> 
>> 
>> ___
>> Softwires mailing list
>> Softwires@ietf.org 
>> https://www.ietf.org/mailman/listinfo/softwires 
>> 
> 
> ___
> Gen-art mailing list
> gen-...@ietf.org 
> https://www.ietf.org/mailman/listinfo/gen-art 
> 
___
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires

[Softwires] Alissa Cooper's Discuss on draft-ietf-softwire-yang-14: (with DISCUSS and COMMENT)

[Alissa Cooper]

Alissa Cooper has entered the following ballot position for
draft-ietf-softwire-yang-14: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-softwire-yang/



--
DISCUSS:
--

The security considerations do not seem to follow the YANG security guidelines
<https://trac.ietf.org/trac/ops/wiki/yang-security-guidelines>. They do not
list the specific writeable and readable subtrees/nodes and why they are
sensitive. The fact that all the writeable nodes could "negatively affect
network operations" seems trivially true for most writeable YANG module nodes.
In the case of these modules, there seem to be multiple different threats
relevant to different nodes, including exposure of data about individual
users/customers, potential for disruption of the operations of the BR or CE,
etc.


--
COMMENT:
--

I think "external party" would make more sense than "abuse party."


___
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires

Re: [Softwires] [Gen-art] Genart telechat review of draft-ietf-softwire-mesh-multicast-23

[Alissa Cooper]

Brian, thanks for your reviews of this document. WG, thanks for your responses. 

I entered a No Objection ballot. I think Ole’s response on your point below 
clarified this.

Alissa

> On Sep 21, 2018, at 8:19 PM, Brian Carpenter  
> wrote:
> 
> Reviewer: Brian Carpenter
> Review result: Ready with Issues
> 
> Gen-ART telechat review of draft-ietf-softwire-mesh-multicast-23
> 
> 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-softwire-mesh-multicast-23.txt
> Reviewer: Brian Carpenter
> Review Date: 2018-09-22
> IETF LC End Date: 2018-09-06
> IESG Telechat date: 2018-09-27 
> 
> Summary: Ready with issues
> 
> 
> Comments: 
> -
> 
> Thank you for handling my Last Call comments. I am mentioning my previous
> issue again in case the IESG thinks any further change is needed.
> 
> Issue:
> --
> 
> "7.3.  Fragmentation
> 
>   The encapsulation performed by an upstream AFBR will increase the
>   size of packets.  As a result, the outgoing I-IP link MTU may not
>   accommodate the larger packet size.  It is not always possible for
>   core operators to increase the MTU of every link, thus fragmentation
>   after encapsulation and reassembling of encapsulated packets MUST be
>   supported by AFBRs [RFC5565].  The specific requirements for
>   fragmentation and tunnel configuration COULD be referred to in
>   [I-D.ietf-intarea-tunnels], which is under revision currently."
> 
> This text is significantly improved. However, I still wonder, if I-IP is
> IPv6, how does the originator of the IPv6 packet (the AFBR) know that it
> needs to include a fragment header? In addition to the discussion in
> [I-D.ietf-intarea-tunnels], isn't it necessary to specify that PMTUD
> should be enabled and that ICMPv6 packets must not be filtered?
> 
> Nit:
> 
> 
> Please change COULD to SHOULD in the above paragraph.
> 
> ___
> Gen-art mailing list
> gen-...@ietf.org
> https://www.ietf.org/mailman/listinfo/gen-art

___
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires

[Softwires] Alissa Cooper's No Objection on draft-ietf-softwire-mesh-multicast-23: (with COMMENT)

[Alissa Cooper]

Alissa Cooper has entered the following ballot position for
draft-ietf-softwire-mesh-multicast-23: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-softwire-mesh-multicast/



--
COMMENT:
--

Building off of Mirja's comment and the Gen-ART review, I have a specific
suggestion for Sec. 7.3:

OLD
The specific requirements for
   fragmentation and tunnel configuration COULD be referred to in
   [I-D.ietf-intarea-tunnels], which is under revision currently.

NEW
Fragmentation and tunnel configuration considerations are provided in [RFC4459]
and [I-D.ietf-intarea-tunnels].


___
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires

Re: [Softwires] [Gen-art] Genart telechat review of draft-ietf-softwire-dslite-yang-15

[Alissa Cooper]

Russ, thanks for your reviews of this document. I have entered a No Objection 
ballot.

Alissa

> On Apr 5, 2018, at 9:27 AM, Russ Housley  wrote:
> 
> Reviewer: Russ Housley
> 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-softwire-dslite-yang-15
> Reviewer: Russ Housley
> Review Date: 2018-04-05
> IETF LC End Date: 2018-02-26
> IESG Telechat date: 2018-05-24
> 
> Summary: Ready
> 
> Major Concerns: None
> 
> Minor Concerns: None
> 
> 
> ___
> Gen-art mailing list
> gen-...@ietf.org
> https://www.ietf.org/mailman/listinfo/gen-art

___
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires

[Softwires] Alissa Cooper's No Objection on draft-ietf-softwire-dslite-mib-12: (with COMMENT)

[Alissa Cooper]

Alissa Cooper has entered the following ballot position for
draft-ietf-softwire-dslite-mib-12: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-softwire-dslite-mib/



--
COMMENT:
--

This may be because this is not my area, but it wasn't immediately
obvious what is meant by "the number of the current IPv4 Session" and
"the number of the current IPv6 Session." Is that an internal identifier
for statistics-gathering purposes? If you think it's worth clarifying,
feel free.


___
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires