Re: [Gen-art] Genart last call review of draft-ietf-teas-ietf-network-slices-21

[Adrian Farrel]

Thanks Reese,

Thanks for taking the time to read and comment.

All comments accepted and addressed except...

> Please consider redrawing the figures using SVG instead of ASCII.
> Especially Figure 4 would greatly benefit from this enhancement.

I think Figure is about as complex as they get, and it doesn't delight me.
But using SVG is a step too far for me.

> Section 6.3
>
> "The controller provides the following functions.
> […]
> Determines an abstract topology connecting the SDPs of the IETF Network Slice
> that meets criteria specified via the IETF Network Slice Service Interface"
>
> I find "determine" to be an odd choice of words if this phrase is about
> implementing the Slice. I suggest using "identify" or a similar term.

I went for "selects" as "identify" has two meanings.

Best,
Adrian

___
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-teas-rfc3272bis-24

[Adrian Farrel]

 
 
  
   Thanks Behcet.
   
  
    
   
  
   The "n.d." is an artefact of xml2rfc. I'll leave that for the RFC Editor to worry about.
   
  
    
   
  
   We could add an abreviations section if anyone feels strongly (I don't, and I'm not looking for extra work :-)
   
  
    
   
  
   Cheers,
   
  
   Adrian
   
   
   
On 06/07/2023 18:10 BST Behcet Sarikaya via Datatracker  wrote:

   
 

   
 

   
Reviewer: Behcet Sarikaya

   
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-teas-rfc3272bis-??

   
Reviewer: Behcet Sarikaya

   
Review Date: 2023-07-06

   
IETF LC End Date: 2023-07-11

   
IESG Telechat date: Not scheduled for a telechat

   
 

   
Summary:This document is a bis document intended to obsolete RFC3272 that

   
describes the principles of traffic engineering in the Internet. Since RFC3272

   
published in 2003 is an informational RFC, this document's status is also set

   
as informational RFC although it could have been a BCP. The document gives a

   
nice account of all changes that happened on traffic engineering since the past

   
20 years. I specifically looked for IPv6, YANG to replace SNMP, SDN,

   
Virtualization and also Quic and MPTCP in the context of ATSSS, they were all

   
very well covered. The document is very well written. What I couldn't find are

   
the coverage of cloud issues, edge computing, data center interconnect which

   
are just mentioned and identifier locator separation work not even mentioned.

   
 

   
Major issues:N/A

   
 

   
Minor issues:N/A

   
 

   
Nits/editorial comments:

   
The last two references FT01 and GRPC have n.d. meaning no date?

   
The document has a nice terminology section 1.4 and most acronyms have been

   
spelled out but there is no acronyms section

  
 


___
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-bess-datacenter-gateway-10

[Adrian Farrel]

Hi Gyan,

Thanks for the work.

> Attached is a txt version -gsm update of version 10

No attachment received.

Best,
Adrian

___
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-idr-bgp-ls-registry-04

[Adrian Farrel]

Thanks Elwyn,

> The document is fine except that I think it would be appropriate to
> give a brief explanation of the reason for the change

Ah, yes, erm 

I understand why you're interested. Of course, we don't normally explain why 
IANA policies are selected. 

There's been a fair amount of debate on the list, and the result was we arrived 
at wanting these policies. I'd prefer not try to summarise how/why the WG ended 
up like this.

> 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

I had a couple of rounds of discussion on this with Alvaro. That led us to move 
nearly every SHOULD to become a MUST, and just two remain.

As well as being the pen-holder for the document, I'm also one of the DEs, so I 
want to be a bit careful discussing the text that governs how I'm supposed to 
act.

My reading of this is:

   2.  The Designated Experts SHOULD only consider requests that arise
   from I-Ds that have already been accepted as Working Group
   documents or that are planned for progression as AD Sponsored
   documents in the absence of a suitably chartered Working Group.

This allows consideration of other sources of requests. The alternate would be 
to say "The DE MAY consider requests that arise from I-Ds that have not been 
accepted by a working group, or other forms of documentation." That's not very 
helpful. But, I think the important point is that bullet 4 covers what would 
happen.

   8.  In the event that the document is a Working Group document or is
   AD Sponsored, and that document fails to progress to publication
   as an RFC, the Working Group chairs or AD SHOULD contact IANA to
   coordinate about marking the code points as deprecated.

This is actually guidance to the WG chairs and not the DE. The point here is, I 
think, that the code points don't need to be marked as deprecated, but it would 
be good practice. It's not clear to me why chairs wouldn't want to mark such a 
code point as deprecated, but "MUST" seems a bit strong. 

> Minor issues:
> s2.1, bullet2:

I think this refers to the above?

Cheers,
Adrian

___
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-pce-pcep-flowspec-09

[Adrian Farrel]

Thanks for taking time to so the review, Roni.

Best,
Adrian
-Original Message-
From: Roni Even via Datatracker  
Sent: 03 July 2020 08:08
To: gen-art@ietf.org
Cc: p...@ietf.org; last-c...@ietf.org; draft-ietf-pce-pcep-flowspec@ietf.org
Subject: Genart last call review of draft-ietf-pce-pcep-flowspec-09

Reviewer: Roni Even
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-pce-pcep-flowspec-??
Reviewer: Roni Even
Review Date: 2020-07-03
IETF LC End Date: 2020-07-06
IESG Telechat date: Not scheduled for a telechat

Summary:
The document is ready for publication as standard track RFC

Major issues:

Minor issues:

Nits/editorial comments:



___
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-bess-nsh-bgp-control-plane-12

[Adrian Farrel]

Hi Brian,

Thanks for your time with this.

In line...

> Comments:
> -
>
> I am not a BGP expert and did not check the BGP details. This
> is a pretty complex mechanism so I would have liked to hear of
> at least a lab-scale implementation. I wouldn't be shocked if
> this was diverted to Experimental.

At the moment I don't have access to a lab, so I won't comment about that.
I will note four things:
1. I don't consider the mechanism to be "pretty complex", but "rather simple". 
It may be that the difference is whether you have to pick up all of BGP to 
understand this draft or whether it comes as a small increment.
2. Obviously (?) the document has had eyes from a number of BGP experts 
especially a very careful review by the document shepherd. It was shared with 
IDR and caught comments from one of the IDR chairs.
3. It's an IBGP mechanism not an EBGP mechanism, so the exposure to the 
stability of the Internet is reduced.
4. The BESS chairs ran a poll on the list to determine whether to progress as 
is in advance of implementations.

> Minor issues:
> -
> Actually these are mainly questions:

Questions are good.

> There are numerous references, starting in the Abstract, to the
> "Controller" but it isn't defined or described in any one place.
> I expected to find it in RFC8300, but no. So what is the Controller?

Right. This is a good catch. A "controller" is a centralised component 
responsible for determining SFPs and maybe more. It is akin to an SDN 
controller. We definitely need to add text for this.

It is not an 8300 concept. Indeed, 8300 is principally focused on the 
forwarding plane.
Furthermore, the control plane and orchestration aspects of SFC are a bit 
sketchy in 7665.
draft-ietf-sfc-control-plane might have been a good source of information, but 
the SFC WG appears to have given up on it.

So, yes, we need a short definition in 1.2, and a paragraph in 2.2.

> RFC8300 requires NSH+original_packet to be encapsulated in a Transport
> Encapsulation. In section 2.1 we find:
>
>>  Note that the presence of the NSH can make it difficult for nodes in
>>  the underlay network to locate the fields in the original packet that
>>  would normally be used to constrain equal cost multipath (ECMP)
>>  forwarding.  Therefore, it is recommended that the node prepending
>>  the NSH also provide some form of entropy indicator that can be used
>>  in the underlay network.  How this indicator is generated and
>>  supplied, and how an SFF generates a new entropy indicator when it
>>  forwards a packet to the next SFF are out of scope of this document.
>
> I would have expected that text to state that the entropy indicator is
> a property of the Transport Encapsulation required by RFC8300. (Isn't
> the Service Function Overlay Network in fact the embodiment of the
> Transport Encapsulation?) 

Well, yes and no.
The entropy indicator is carried in the transport encapsulation, and is used by 
the transport (underlay) network.
But it is a property of the payload. In particular, it is a property of what is 
encapsulated by the NSH.
The mechanism that encapsulates for the transport would normally have 
visibility into the payload to create the entropy indicator (hashing on 
specific fields), but the inclusion of the NSH makes that harder. Hence the 
recommendation that the entropy indicator is provided by the mechanism that 
prepends the NSH.

I think the text says this and that those skilled in the art (you have to 
understand the use of the entropy indicators and the inclusion of the NSH) will 
get this.

> In section 2.2 we find:
>
>>  When choosing the next SFI in a path, the SFF uses the SPI and SI as
>>  well as the SFT to choose among the SFIs, applying, for example, a
>>  load balancing algorithm or direct knowledge of the underlay network
>>  topology as described in Section 4.
>
> I'm probably missing something, but doesn't that risk a conflict with
> the statement above about the entropy indicator? How would this choice
> of path be guaranteed congruent with the choice of path by the underlay
> network? Or doesn't that matter?

No, this is a choice of SFIs, not a choice of paths between SFFs.
The former is determining the path in the overlay, the latter (using the 
entropy indicator) is selecting the path through the underlay.

>> 4.4.  Classifier Operation
>>
>>  As shown in Figure 1, the Classifier is a component that is used to
>>  assign packets to an SFP.
>>
>>  The Classifier is responsible for determining to which packet flow a
>>  packet belongs (usually by inspecting the packet header),...
>
> Would it be better to state explicitly that the method of classification
> is out of scope for this document? There is a whole world of complexity
> in that "(usually...)".

Yes, happy to say it is out of scope.

>> 4.5.  Service Function Forwarder Operation
>
> This section left me a bit puzzled. We've got the original packet,
> the classifier puts an NSH in front, we've got 

Re: [Gen-art] [Pce] Genart last call review of draft-ietf-pce-hierarchy-extensions-10

[Adrian Farrel]

Hi,

Thanks, Dan, for your response here.

Just to follow up on one point:

>> 2. In section 3.2.1 or section 4.1 if the originator sends PCC or PCE
>> sends an open with P flag =0 can the response open be sent with a
>> P flag =1 and if yes what should be the action of the originator. I 
>> did not see any text about this case.
>
> DK>> According to RFC 5440, the Open message is not a request response
> exchange. Both entities send an Open message, and indeed they may even
> overlap. In our H-PCE extensions the P flag indicates that the sender
wants
> the receiver to act as its parent. In the example we give, it should be
fine
> for one party to not set the P flag in the first Open message seen on the
> wire, and for the second part to set the P flag in the second Open message
> seen on the wire. Therefore, I don't think this needs to be address as an
> implementor should be familiar with the Open message behavior. 

Dan is right that the Open is not a request response exchange, but two Open
messages that flow (one in each direction). The second might be sent in
response to the first, or they might be originated independently and be
matched up.

The P flag applies to the sender's requested relationship with the receiver.
It is possible for:
- neither Open to have the P flag set
- both Opens to have the P flag set
- either one of the Opens to have the P flag set
But, if both Opens have the P flag set then the session set-up must fail
according to 3.1.1.
If one speaker doesn't like the setting of the P flag it receives (most
notably if the receiver does not want to act as a parent) it fails the
session according to 4.1.

Thanks,
Adrian

___
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-mpls-sr-over-ip-02

[Adrian Farrel]

That's a good review, Robert, thank you.

The changes look achievable to me, and I'm sure the author team can work to 
include them.

Cheers,
Adrian
--
Want to buy a signed copy of a book of fairy stories for adults of all ages?
Send me an email and I'll bring one to Prague for you.
"Tales from the Wood"
"More Tales from the Wood"
"Tales from Beyond the Wood"
https://www.feedaread.com/profiles/8604/

-Original Message-
From: ietf  On Behalf Of Robert Sparks
Sent: 20 February 2019 15:48
To: gen-art@ietf.org
Cc: m...@ietf.org; i...@ietf.org; draft-ietf-mpls-sr-over-ip@ietf.org
Subject: Genart last call review of draft-ietf-mpls-sr-over-ip-02

Reviewer: Robert Sparks
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-mpls-sr-over-ip-02
Reviewer: Robert Sparks
Review Date: 2019-02-20
IETF LC End Date: 2019-02-26
IESG Telechat date: Not scheduled for a telechat

Summary: Ready, but with nits that should be addressed before publication as a
Standards Track RFC

Nits

The 2nd sentence of the introduction is complex. It should be easy to simplify.

It would help to place the reference to draft-ietf-mpls-spring-entropy label at
"If encoding of entropy is desired". (Or if some other reference is better, use
that)

In that same paragraph, something is wrong at "make use of entropy label
mechanism." Should that be "the entropy label mechanism"?

SRGB is used without expansion.

Where is "the lower bound" of an SRGB defined? The string "lower bound" doesn't
occur in either of the routing-extensions drafts referenced where SRGB is first
used.

Section 3.1 is about ostensibly about constructing a FIB entry, but its last
step is sending a packet.

The first sentence in section 3.2 is more complex than it needs to be. It
should be easy to simplify.

It would be nice if you could make the differences between the routers in
figures 3 and 4 visually apparent rather than relying on text to explain the
difference. Something like (view in a fixed width font):

s-s  i-i
|  A  +--+  B  +--
s-s  i--+--i
|

At the first paragraph on page 9: s/and then process/and then processes/

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

Re: [Gen-art] Genart telechat review of draft-ietf-l2sm-l2vpn-service-model-08

[Adrian Farrel]

Thanks Joel,

There's a lot to digest here. The chairs will work with the authors on a 
response.

Adrian

> -Original Message-
> From: Joel Halpern [mailto:j...@joelhalpern.com]
> Sent: 25 February 2018 01:00
> To: gen-art@ietf.org
> Cc: l...@ietf.org; i...@ietf.org; 
> draft-ietf-l2sm-l2vpn-service-model@ietf.org
> Subject: Genart telechat review of draft-ietf-l2sm-l2vpn-service-model-08
> 
> Reviewer: Joel Halpern
> Review result: On the Right Track
> 
> 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-l2sm-l2vpn-service-model-08
> Reviewer: Joel Halpern
> Review Date: 2018-02-24
> IETF LC End Date: 2018-03-26
> IESG Telechat date: 2018-04-05
> 
> Summary: Given the number of Major and minor issues, this document is not yet
> ready for publication as a Proposed Standard RFC.
> 
> Major:
> Introduction: The phrasing of "an abstract model", "this model is not a
> configuration model..." creates some confusion in the reader as to whether
> this model represent the current state of service deliveyr, the desired
> state of service delivery (which would drive configuration) or both.
> Please clarify.
> 
> The "valid-provider-identifiers' distinguish between cloud-identifier and
> remote-carrier-identifier.  It i unclear why the VPN service provider
> should know or care whether the remote provider he is connecting with is a
> cloud provider, and another L2 service provider, or both.  And if it is
> both, which identifier should be used.
> 
> Also, it is very unclear how these identifiers will be used.  They
> presumably are names of something.  But of what?  As known to whom?
> Derived from where?  I do not see how a provider / customer pair using 
> this
> model will know what values to use for this.  Even if the intention is 
> that
> these be names made available by the provider by external means, the YANG
> model needs to say that if it is to be usable. I did eventually find some
> explanation in section 5.15.  At the very least a forward reference is
> needed.  I think more explanation of what these things names would also
> help.
> 
> The use of different sets of what read like service types (is cloud access
> a service type?  Is remote-access a service type?) and the use of similar
> but not the same terminology between provider descriptions, service types,
> and service topologies, leaves the reader VERY confused.  Please, do not
> use the same term for kinds of providers, kinds of services, and kinds of
> topologies unless the names are fully congruent (which they currently are
> not.)
> 
>  It is unclear why "Cloud-Access" is listed in the VPN Service Overview
>  (section 5.2),  or even why Cloud Access is any different from any other
>  access.  Presumably, the customer can configure authorization for the
>  sites to meet his needs.   Any topological effect would be capture in
>  5.2.2 on VPN Service Topology, not as a different kind of VPN Service.
> 
>  Regarding VPN Service Type (svc-type) the text in section 5.2 says that
>  this is explicitly for the local administrator to use to flexibly define
>  the CPN service type.  Section 5.2.1 then says that it has one of six
>  values, implying that if other values are needed they will need to be
>  defined in an extension to the model.  If they are for model use, and for
>  model extension, then they should be using a two-level identity (where 
> the
>  second level provides the possible values.)
> 
> Given taht this is a model for providers and customers to use to
> collaborate on the configuration of VPNs, I would expect to see some
> discussion of how this is used on the provider end so as to collaborate
> with multiple customers, working with each only about their VPNs.  I 
> missed
> any such description.
> 
> Minor:
> I would have expected some reference to the MEF Ethernet service
> definitions and MEF defined parameters of interest, as industry usage 
> seems
> to reflect those as the common basis for L2 services.  I udnerstand that
> this model is not mandated to conform to the MEF Forum work.  I would
> expect some discussion of the relationship.  This may be a deliberate
> working group choice, as I see in teh change log that there were 
> references
> to EVC and OVC.  It still seems that it would help readers to have
> something.
> 
> The structure of the vpn-profile-cfg grouping seems very strange.  It is a
> series of 4 lists, each of which only contains an id leaf.  

Re: [Gen-art] Genart last call review of draft-farrel-sfc-convent-05

[Adrian Farrel]

Thanks for the time, Robert.

Adrian

> -Original Message-
> From: ietf [mailto:ietf-boun...@ietf.org] On Behalf Of Robert Sparks
> Sent: 26 January 2018 20:14
> To: gen-art@ietf.org
> Cc: draft-farrel-sfc-convent@ietf.org; i...@ietf.org; s...@ietf.org
> Subject: Genart last call review of draft-farrel-sfc-convent-05
> 
> Reviewer: Robert Sparks
> 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-farrel-sfc-convent-05
> Reviewer: Robert Sparks
> Review Date: 2018-01-26
> IETF LC End Date: 2018-01-31
> IESG Telechat date: 2018-02-08
> 
> Summary: Ready for Publication as a Proposed Standard
> 


___
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-wu-l3sm-rfc8049bis-07

[Adrian Farrel]

Top-posting 'cos I'm lazy.

We need to be careful to not confuse two aspects of security in this model.
One is security in the use of the model: who can read and write to the 
operator, whether the data is protected in transit, etc.
The other is security within the VPN that is modelled: how sites secure their 
access to the VPN, how VPN data is protected.

The former is handled by the protocol used to exchange the model. We assume 
Netconf, and that comes with a variety of security features.
The latter is about what VPN (or VPN site) behaviour is configured.

All that said, the points about authentication and authorisation are well made. 
Authorisation based on unauthenticated identity is not strong security 
(basically equates to "guess a valid user name").

A

> -Original Message-
> From: ietf [mailto:ietf-boun...@ietf.org] On Behalf Of tom p.
> Sent: 26 October 2017 12:10
> To: Qin Wu; Jari Arkko; gen-art@ietf.org
> Cc: i...@ietf.org; draft-wu-l3sm-rfc8049bis@ietf.org
> Subject: Re: Genart last call review of draft-wu-l3sm-rfc8049bis-07
> 
> < see inline>
> Tom Petch
> 
> 
> - Original Message -
> From: "Qin Wu" 
> Sent: Thursday, October 26, 2017 8:02 AM
> 
> > -邮件原件-
> > 发件人: Jari Arkko [mailto:jari.ar...@piuha.net]
> > 发送时间: 2017年10月26日 4:53
> >
> > Reviewer: Jari Arkko
> > 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-wu-l3sm-rfc8049bis-??
> > Reviewer: Jari Arkko
> > Review Date: 2017-10-25
> > IETF LC End Date: 2017-10-11
> > IESG Telechat date: 2017-10-26
> >
> > Summary: I'm not an expert on YANG *at all*. And not an expert on the
> topic in question either. And I had far too little time to spend on this
> long document.
> > But as far as the textual content of the document goes, it seems
> reasonable. I have a difficulty in assessing how complete and
> implementable this model is however. Are there implementations?
> >
> > [Qin]: Yes, there are implementations, something broken in RFC8049
> needs to get right.
> >
> > I did enjoy the classification of Internet connectivity as a special
> case of cloud service :-) You may be onto something.
> >
> > [Qin]:Yes, internet connectivity is special example of public cloud,
> in my understanding,:-)
> >
> > I did observe a couple of question marks or issues that probably
> deserve some thought or small revisions.
> >
> > Major issues: -
> >
> > Minor issues:
> >
> > I'm not sure I fully understand the need for "SP MUST honour
> "
> > language in the document. Are there parts of the described model that
> they SP is *not* required to honour? Other than the explicit strict
> true/false settings? And in any case, sizeable networks are likely to
> have issues that might require negotiation/human involvement.
> >
> > [Qin]: Explicit settings are covered by sub-section of section 6.6,
> such as device constraint, Site Location constraint/parameter, access
> type.
> > Unlike RFC8049, RFC8049bis change "SP SHOULD honor" into "SP MUST
> honor".
> >
> > I don't understand how 6.9.1 can say there is no authentication
> support but then 6.9.2 (encryption) talks about authentication keys. I'd
> suggest some rethinking or at least clarification might be needed here.
> >
> > [Qin]: Authentication provides you access to a resource like a
> computer or a network. Encryption provides confidentiality and controls
> whether an object can be read or not.
> 
> Qin
> 
> I do not see that usage as common in the IETF and I think that it
> reflects a fundamental flaw in this model such that the I-D should not
> go forward in its present form, except that the same flaw is present in
> RFC8049:-(
> 
> Authentication is the process of establishing that a person or object is
> who or what they claim to be, using e.g. pre-shared keys or
> certificates, in an authentication protocol.
> 
> Authorisation is the process of granting rights, privileges, access and
> such like to an authenticated identity.
> 
> Authorisation without authentication is meaningless, a fantasy of
> security
> 
> Scanning the I-D, I think that the usage of authorisation and
> authentication is mostly correct.  As the I-D points it, there is no
> support in the standard model for authentication.  Where the I-D is
> wrong, perhaps dangerously so, is in the Security Considerations where
> it says that because NETCONF may have used TLS or SSH to establish the
> connection, and the NETCONF Access Control may be used to control
> authorisation, then somehow this is secure.
> 
> You haven't a clue what identity has been authenticated and whether or
> not they should be authorised to join a VPN.  This is a 

Re: [Gen-art] [OPSAWG] Genart last call review of draft-ietf-opsawg-service-model-explained-03

[Adrian Farrel]

Thanks Robert,

> I don't have text to suggest, but please look at the first bullet of section
5.
> The explanation here was less helpful than the other bullets. Demonstrating
the
> confusion due to the reuse of the word "service" doesn't help clarify the
> confusion. I wonder if there's more conversation that hasn't been captured
that
> this paragraph is alluding to.

Yes, the paragraph is not as clear as it could be. We were trying to distinguish
between different uses of the word "service" where we are primarily interested
in connectivity services achieved by manipulating the network resources, and not
value-added services provided using other resources (compute, storage, ...) that
are reachable over the network.

I have tried to make this a bit clearer.

> (nit) I also suggest raising the level of abstraction in the security
> consideration section where it currently lists authorization, authentication,
> and encryption by speaking initially to what, and calling the how out as a
> detail.

OK

Adrian

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

Re: [Gen-art] [Teas] Genart telechat review of draft-ietf-teas-pce-central-control-04

[Adrian Farrel]

Hi Elwyn,
 
-04 has
   Some of this will be the TED as is normal for a PCE and can be
  collected using the mechanisms already in place (such as listening to
   the IGPs, using BGP-LS [RFC7752], or northbound export of YANG-
   encoded data [I-D.ietf-teas-yang-te-topo]).
-05 has
   Some of this will be the TED as is normal for a PCE and can be
   collected using the mechanisms already in place (such as listening to
   the IGPs, using BGP-LS [RFC7752], or northbound export of YANG-
   encoded data [I-D.ietf-teas-yang-te-topo] from the network elements
   to the controller).
 
I think that probably gives enough context.
 
Yes, thanks for the typo in 2.1.2. I'll save it for Auth48.
 
A
 
From: Elwyn Davies [mailto:elw...@dial.pipex.com] 
Sent: 04 September 2017 14:46
To: adr...@olddog.co.uk; gen-art@ietf.org
Cc: draft-ietf-teas-pce-central-control@ietf.org; i...@ietf.org; 
t...@ietf.org
Subject: RE: [Teas] Genart telechat review of 
draft-ietf-teas-pce-central-control-04
 
 
Hi, Adrian.
 
Two points:
- I don't see an explanation of northbound in -05.
- In the new text at the end of s2.1.2 s/whole the controllers/while the 
controllers/
 
Otherwise, the extra text and changes look helpful.
 
Best wshes,
Elwyn
 
 
Sent from Samsung tablet.
 
 Original message 
From: Adrian Farrel <adr...@olddog.co.uk> 
Date: 04/09/2017 10:47 (GMT+00:00) 
To: 'Elwyn Davies' <elw...@dial.pipex.com>, gen-art@ietf.org 
Cc: draft-ietf-teas-pce-central-control@ietf.org, i...@ietf.org, 
t...@ietf.org 
Subject: RE: [Teas] Genart telechat review of 
draft-ietf-teas-pce-central-control-04 
 
Thanks Elwyn,

Clarified in the next revision.

Adrian

> -Original Message-
> From: Teas [mailto:teas-boun...@ietf.org] On Behalf Of Elwyn Davies
> Sent: 28 August 2017 20:24
> To: gen-art@ietf.org
> Cc: draft-ietf-teas-pce-central-control@ietf.org; i...@ietf.org;
t...@ietf.org
> Subject: [Teas] Genart telechat review of
draft-ietf-teas-pce-central-control-04
> 
> 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
> 
> <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.
> 
> Document: draft-ietf-teas-pce-central-control-04
> Reviewer: Elwyn Davies
> Review Date: 2017-08-28
> IETF LC End Date: 2017-08-24
> IESG Telechat date: 2017-08-31
> 
> Summary: Thanks for addressing my Last Call comments on -03.  The new version
> is ready with one introduced nit.  Also I am still of the abstract is somewhat
> overlong.
> 
> Nit:
> s6, para 2: The SDN term 'northbound' has appeared in the new version. Needs
> brief explanation.
> 
> Major issues:
> 
> Minor issues:
> 
> Nits/editorial comments:
> 
> 
> ___
> Teas mailing list
> t...@ietf.org
> https://www.ietf.org/mailman/listinfo/teas
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] [Teas] Genart telechat review of draft-ietf-teas-pce-central-control-04

[Adrian Farrel]

Thanks Elwyn,

Clarified in the next revision.

Adrian

> -Original Message-
> From: Teas [mailto:teas-boun...@ietf.org] On Behalf Of Elwyn Davies
> Sent: 28 August 2017 20:24
> To: gen-art@ietf.org
> Cc: draft-ietf-teas-pce-central-control@ietf.org; i...@ietf.org;
t...@ietf.org
> Subject: [Teas] Genart telechat review of
draft-ietf-teas-pce-central-control-04
> 
> 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-teas-pce-central-control-04
> Reviewer: Elwyn Davies
> Review Date: 2017-08-28
> IETF LC End Date: 2017-08-24
> IESG Telechat date: 2017-08-31
> 
> Summary: Thanks for addressing my Last Call comments on -03.  The new version
> is ready with one introduced nit.  Also I am still of the abstract is somewhat
> overlong.
> 
> Nit:
> s6, para 2: The SDN term 'northbound' has appeared in the new version. Needs
> brief explanation.
> 
> Major issues:
> 
> Minor issues:
> 
> Nits/editorial comments:
> 
> 
> ___
> Teas mailing list
> t...@ietf.org
> https://www.ietf.org/mailman/listinfo/teas

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

Re: [Gen-art] [Teas] Genart last call review of draft-ietf-teas-pce-central-control-03

[Adrian Farrel]

Elwyn,

Thanks for the review.

> Summary:
> Almost ready.  I found this a well-written and mostly readily comprehensible
> document although it contains a couple of instances of unexplained SDN/PCE
> jargon (notably 'southbound').  My main concern is that the archtecture
> suggests that extensions to PCEP will a.s. be needed and implies that
> mechanisms will be needed to provide multiple extensions but neither specifies
> detailed guidance as to how this might be done or points to work in progress
> that would provide this guidance.  

I'm pretty sure that this architecture should not tell the protocol designers 
how to do their jobs. So "detailed guidance" may be too much, but Section 4 
does give "Guidance for Solution Developers".

Perhaps the simplest thing is to point at 
draft-zhao-pce-pcep-extension-for-pce-controller which is where early work on 
protocol extensions lives. It's not a working group document (yet?) and it 
still has some issues, but I've changed
OLD
   It is anticipated that new documents will be produced for each use
   case dependent on support and demand.  Such documents will explain
   the use case and define the necessary protocol extensions.
NEW
   It is anticipated that new documents (such as 
   [I-D.zhao-pce-pcep-extension-for-pce-controller]) will be produced
   for each use case dependent on support and demand.  Such documents
   will explain the use case and define the necessary protocol extensions.
END

> The implication of the statements in this
> document are that an implementation or deployment might need to check if
> particlar extensions are implemented in communication partners and also how to
> behave if an unreconixed extension is received especially to avoid possible
> DoS.

RFC 5440 already describes how to handle unknown protocol elements. 
Additionally, the PCEP Open message allows for exchange of capabilities 
information. We can make these points as:

OLD
   The only work expected to be needed is extensions to
   existing PCEP messages to carry additional or specific information
   elements for the individual use cases, which maintain backward
   compatibility and do not impact existing PCEP deployments.  Where
   possible, consistent with the general principles of how protocols are
   extended, any additions to the protocol should be made in a generic
   way such that they are open to use in a range of applications.
NEW
   The only work expected to be needed is extensions to
   existing PCEP messages to carry additional or specific information
   elements for the individual use cases, which maintain backward
   compatibility and do not impact existing PCEP deployments.  [RFC5440]
   already describes how legacy implementations handle unknown 
   PCEP extensions and how to use the PCEP Open message to indicate
   support for PCEP features.  Where possible, consistent with the general
   principles of how protocols are extended, any additions to the
   protocol should be made in a generic way such that they are open
   to use in a range of applications.
END

>  The other minor issues are only just abve the level of nits.
> 
> Major issues:
> None
> 
> Minor issues:
> 
> Abstract:  The abstract is probably overlong.

Ah, why use 3 words when 10 will do?

RFC Ed suggests that up to 20 lines is OK. We have 21. I couldn't immediately 
see anything gratuitously superfluous, so I'm leaving it as is.

> s1:  RFC 4655 is itself an architecture that introduces the PCE.  It would be
> helpful to explain that this document is an extension of the basic PCE
> arcitecture except that it relies on the specific use of the PCEP for
> intercommunication between architectural elements providing traffic control 
> and
> routing whereas RFC 4655 does not assume any particular protocol.

Hmmm. You're right. 4655 doesn't make protocol assumptions. In fact it 
pre-dated the WG's choice of a protocol.
Of course, since then PCEP has been adopted and is the de facto protocol for 
PCE. 

How about...

OLD
   This document introduces the architecture for PCE as a central
   controller, examines the motivations and applicability for PCEP as a
   southbound interface, and introduces the implications for the
   protocol.  A PCE-based central controller can simplify the processing
   of distributed control plane by blending it with elements of SDN and
   without necessarily completely replacing it.
NEW
   This document introduces the architecture for PCE as a central
   controller as an extension of the architecture described in [RFC4655]
   and assumes the continued use of PCEP as the protocol used between
   PCE and PCC.  The document also examines the motivations and 
   applicability for PCEP as a southbound interface and introduces the 
   implications for the protocol used in this way.  A PCE-based central 
   controller can simplify the processing of distributed control plane by
   blending it with elements of SDN and without necessarily completely
   replacing it.
END

> s3.2: It 

Re: [Gen-art] [mpls] Review of draft-ietf-mpls-residence-time-12

[Adrian Farrel]

I agree with Hannes on this.

However, if the document was to highlight strongly that the data is "a
non-routing related capability" (if that's what we believe!) and stress that the
information "that does not change frequently" (perhaps with some explanation of
"frequently") I believe that might help everyone.

Adrian

> >we have taken turns long-time ago to advertise non-routing
> >related information which is only relevant to controllers
> >(l2bundles comes into mind ;-)).
> >
> >while it would have been nice to get at least notice that
> >an IS-IS extension is being worked on (i mean prior to
> >IANA asking for expert review :-/ ) i see no reason why we
> >should hold this back. - we can argue perhaps whether it should
> >be part of GENAPP or ROUTERCAP TLVs, but i cannot see the
> >sky falling to advertise a non-routing related capability,
> >that does not change frequently.
> 
> I agree but was just trying to get a better idea of precisely how the
> information will be used and whether interface is the right granularity.

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

Re: [Gen-art] Gen-ART Last Call review of draft-ietf-teas-interconnected-te-info-exchange-05

[Adrian Farrel]

Hi Brian,

Thanks for the time.

> Major issues:
> -
> 
> > 5.  Building on Existing Protocols
> 
> I find it hard to read the introduction to this section and understand
> why the draft is proposed for BCP rather than Informational. 

I will punt this question direct to the responsible AD since the authors 
brought the document forward as Standards Track and were "persuaded" by the WG 
chairs and responsible AD that it was a BCP as written. 

The only hint I will offer is that the authors would be grumpy about changing 
the content of the document to fit the publication track. Let's choose the 
track to fit the document :-)



[except to note that the presence of normative references has nothing to do 
with whether a document is itself normative!]
 
> Minor issues:
> -
>
> > 1.  Introduction
> ...
> >  Such networks
> >  are often referred to as Domains [RFC4726] and we adopt that
> >  definition in this document: viz.
> >
> >For the purposes of this document, a domain is considered to be any
> >collection of network elements within a common sphere of address
> >management or path computational responsibility.  Examples of such
> >domains include IGP areas and Autonomous Systems.
> 
> Section 1.1.4. (Domain) repeats the definition in different words.
> I think it would be better to fold the text from the Introduction
> into 1.1.4.

I disagree.
I believe that an introduction needs to be stand-alone text without requiring 
reference to a terminology section that has not yet been read.

The text in the Introduction is a direct quote and cannot be modified.
The text in 1.1.4 is as near as possible to being a copy within the rules of 
abbreviation expansion.
Effectively the two definitions are identical.

> > 2.2.  Client-Server Networks
> 
> It may be considered a term of art in TE, but I found the phrase "server
> network" very confusing at first. In my world, it means "a network containing
> servers" but here it appears to mean "underlay network" or possibly "service
> network". Anyway, if you want to use this phrase, I suggest defining it
> precisely before using it.

It is certainly a term of art in multi-layered networks. I did not do a 
comprehensive search, but found it in RFCs from 2005. You may also find it used 
a lot in the ITU-T where they have some experience of transport networks 
(hoping that in your world a transport network is not a TCP network :-)

I think that you are saying that the description at the start of Section 2.2 
(that provides as a starting point the client-server relationship between 
networks) is not enough. I think we can manage a very brief definition for you 
to go in Section 1.1. Probably something like...

Server Network

A Server Network is a network that provides connectivity for another network 
(the Client Network) in a client-server relationship. A Server Network is 
sometimes referred to as an underlay network.

Client Network

A Client Network is a network that uses the connectivity provided by a Server 
Network. A Client Network is sometimes referred to as an overlay network.

> Also, the text switches to "server domain" and uses "server layer". Then in
> Figs 4, 5 and 6 the server domain has become "core domain". This terminology
> is all a bit inconsistent.

Yes, this is sloppy chat. Will scrub it. Ditto "client".

> > 4.4.  Requirements for Advertising Links and Nodes
> ...
> >  This requires a routing protocol running between the nodes in the
> >  abstraction layer network.  Note that this routing information
> >  exchange could be piggy-backed on an existing routing protocol
> >  instance, or use a new instance (or even a new protocol).
> 
> It isn't obvious to me that it could be piggy-backed on an existing
> instance in the general case; wouldn't that sometimes lead to duplicate
> or ambiguous routes?
> 
> A sentence in section 4.5 seems to suggest that ambiguity is very
> possible:
> 
> > That is, one address may mean one thing in the
> > client network, yet the same address may have a different meaning in
> > the abstraction layer network or the server network.
> 
> Address mapping plus piggy-backed routing seems like a recipe
> for disaster.

I think this is resolved by the insertion of "...(subject to different 
switching capabilities applying to the links in the different networks, or to 
adequate address space separation)..." in the quoted text from 4.4 after "... 
could be piggy-backed on an existing routing protocol instance".

> Nits
> 
> 
> > Figure 16 : A Network Comprising Three Peer Networks
> 
> There's a missing | on node B2

ack

> > 10.3.  Managing Interactions of Abstraction Layer and Server Networks
> ...
> 
> >  The abstraction layer network needs a mechanism to tell the server
> >  This mechanism could also include the ability to request additional
> >  connectivity from the server layer, ...
> 
> The first sentence of this paragraph is truncated.

good catch

> > 12.  Security Considerations

Re: [Gen-art] review: draft-sheffer-rfc6982bis-00

[Adrian Farrel]

Hi Joel,

Thanks for your time.

>  The introduction describes RFC1264 as requiring at least one
> implementation.  The general requirement in RFC 1264 is multiple
> implementations, at least two independent.  While it is a minor issue,
> this document should characterize RFC 1264 more carefully.

I'm not opposed to the change you suggest but I quote from section 4.0 of RFC
1264

|4) One or more implementations must exist.

>  In the Alternative Formats section, it strikes me that there is an
> alternative that is sometimes useful that is de-emphasised by the text
> as written.  If there has been significant insight gained from the
> implementations, that may be useful to capture in a longer-lived
> context.  In that case, an RFC describing implementation may still be
> useful.  I would appreciate it if the authors would consider adding a
> short paragraph to this effect.

Oh, it was certainly not our intention to persuade people not to add
documentation about implementations. I don't think the current text
de-emphasises anything (unless you consider that not talking about something is
de-emphasis). It would not hurt us to note how implementation reports have often
been written and how the IESG currently recommends that they are written.

Cheers,
Adrian

___
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-ccamp-flexible-grid-rsvp-te-ext-03

[Adrian Farrel]

Hi y'all,

[snip]

>> Does ‘GMPLS’ need to be expanded on first occurrence?
>> [Xian]: It is a pretty solid abbreviation for whoever needs to read for the
technical
>> content. But I think your suggestion is reasonable, just like we need to
expand to
>> RSVP-TE and LSP. Will do.

GMPLS is shown as an acceptable abbreviation to be used w/o expansion at
http://www.rfc-editor.org/materials/abbrev.expansion.txt

[snip]

>> The text in section 7 says:
>>
>>   “This section records the status of known implementations of the 
>>  protocol defined by this specification at the time of posting of

>>  this Internet-Draft,…”
>>
>> I am not sure whether we should use “Internet-Draft” terminology in a
published RFC, and
>> I am not sure what time “at the time of posting of this Internet-Draft”
refers to. 
>>
>> Perhaps you could say something like:
>>
>>   “This section records the status of known implementations of the 
>>  protocol defined by this specification at the time of writing
the
>>   specification,…”
>
> [Xian]: This section will be removed when it becomes a RFC (see the editor
note put at
> the beginning of this section in the draft). So I do not think your issue
applies. I would
> prefer to leave it, avoiding using specification twice. OK?

As co-author of this I-D and of RFC 6982, I agree with Xian on this point.

Cheers,
Adrian
--
Read my latest...
Tales from the Wood - Eighteen new fairy tales
http://www.feedaread.com/books/Tales-from-the-Wood-9781786100924.aspx
http://www.amazon.co.uk/Tales-Wood-Adrian-Farrel/dp/1786100924
Or buy from me direct.






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

Re: [Gen-art] Gen-art LC review: draft-ietf-ccamp-flexigrid-lambda-label-04

[Adrian Farrel]

Hi Daniele,

> Thanks for the careful review and your comments.
> I pretty much agree with Adrian's reply but I think explicitly having some
> backward compatibility text in the draft could be helpful.
> 
> Adrian, authors, I'd suggest changing section 5 from "Manageability
> Considerations" to "Backward Compatibility and Manageability Considerations"
> adding to the existing text backward compatibility considerations against 
> legacy
> GMPLS and legacy NMS (mostly what you've already written below).

I can work on this.

> WRT the legacy NMS I don't think it is a reasonable scenario, since before
> operating the nodes with a GMPLS implementing this draft, the node needs to be
> configured and the NMS must be flexi-grid compatible.

But wait! This is exactly the point.
Suppose there is an NMS that is inspecting an LSP at a transit node. 
That NMS does not need to be flexigrid compatible to read the details of the 
LSP at that transit node.
However, it *does* need to have some capabilities in order to not barf when it 
gets the response from the LSR.
The first thing is to handle a 64 bit label as an opaque string.
The advanced thing is to be able to parse out the 64 bits into the relevant 
fields.

Indeed, to request the setup of a flexigrid LSP does not require a flexigrid 
compatible NMS since it is possible to simply request a path and bandwidth (or 
not even request a path).

My contention is that it is quite likely that someone would try to use a legacy 
NMS to manage a new flexigrid network since "it is all just GMPLS". And it is 
not an unreasonable assumption to be able to do this if some fields (for 
example, label) can be displayed as opaque quantities.

Now, if you are talking about an EMS, I completely agree.

Cheers,
Adrian


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

Re: [Gen-art] Gen-art LC review: draft-ietf-ccamp-flexigrid-lambda-label-04

[Adrian Farrel]

Hi Robert,

Thanks for reading.

> Summary: Ready for publication as a Proposed Standard

Excellent diagnosis :-)

> One thing I'd like to check, and I suspect this pokes at a conversation
> that has already happened (as hinted in the acknowledgements section):
> 
> The discussion of managements systems having to deal with a 64 bit
> wavelength label caught my eye. This is an RFC3471 section 3.2.1.1 label
> isn't it? That document shows wavelength labels as 32 bit things. Has
> something updated 3471 to say to expect a multiple of 32 bits, and not
> 32 bits specifically? If not, maybe this document would be a good place
> to do so explicitly, rather than what appears to be fiat at the moment?

Yeah, 6205 updates 3471 (as noted in this I-D), but still only makes a 32 bit 
lambda label.

But 3.2 of 3471 makes clear that a label is of variable length according to the 
type. And also that the type is supposed to be known a priori (since otherwise 
you would go crazy) by both ends of a link.

But an implementation expecting a 32 bit lambda label would not barf 
ungracefully because the first 32 bits follow the format of 6205. It would look 
at them and not recognise the grid type (new value from IANA) and so give up on 
the whole message. And this is good because if you don't support flexigrid 
labels you simply can't process any of the related signaling.

Thus, we think that the only thing that needs fixing (external to the 
implementation that has to support flexigrid labels) is the management system 
that might be inspecting LSPs within the network.

> micro-nit: at the end of the introduction "in that regard" suggests the
> document updates the work of the ITU-T in some other regard? I suggest
> simple deleting the phrase.

Micro-ack.

Cheers,
Adrian

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

Re: [Gen-art] Gen-ART telechat review of draft-ietf-idr-ls-distribution-10

[Adrian Farrel]

Forwarding on behalf of Alexey.
 
From: Alexey Melnikov [mailto:alexey.melni...@isode.com] 
Sent: 10 May 2015 17:22
To: adr...@olddog.co.uk
Subject: Fwd: [Gen-art] Gen-ART telechat review of 
draft-ietf-idr-ls-distribution-10
 
Hi Adrian,
I am having some problems with the tools.ietf.org alias expansion. Can you 
forward to your co-editors?
 Original Message  

Subject: 
[Gen-art] Gen-ART telechat review of draft-ietf-idr-ls-distribution-10

Date: 
Sun, 10 May 2015 17:18:12 +0100

From: 
Alexey Melnikov  mailto:alexey.melni...@isode.com alexey.melni...@isode.com

To: 
draft-ietf-idr-ls-distribution@tools.ietf.org, General Area Review Team  
mailto:gen-art@ietf.org gen-art@ietf.org
 
[Resending]
 
I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
 http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq  
http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq.
 
Please wait for direction from your document shepherd
or AD before posting a new version of the draft.
 
Document: draft-ietf-idr-ls-distribution-10.txt
Reviewer: Alexey Melnikov
Review Date: 2015-05-10
IETF LC End Date: 2015-04-08
IESG Telechat date: N/A
 
My apologies for the late review of this document.
 
Summary: Ready with nits
 
 
Minor (but some of these might be more serious):
 
In 6.2.2:
 
If an implementation of BGP-LS detects a malformed attribute, then it
SHOULD use the ’Attribute Discard’ action as per
[I-D.ietf-idr-error-handling] Section 2.
 
This needs to be a Normative reference. Or you can keep it as 
Informative, if you change the sentence not to use RFC 2119 language.
 
In 3.3.1.1 - does this need a new IANA registry? (I am fine if you think 
you don't).
 
In 3.3.1.3/3.3.2.7 - what is subset of the FQDN?
 
In 3.3.2.3:
 
   The TE Default Metric TLV carries the TE-metric for this link.
   The length of this TLV is fixed at 4 octets.
 
I am probably showing my ignorance, but is the term TE-metric defined 
somewhere? The description below suggests it has substructure, which I 
don't know anything about.
 
If a source protocol (e.g.
IS-IS) does not support a Metric width of 32 bits then the high
order octet MUST be set to zero.
 
Best Regards,
Alexey
 
___
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 Last Call review of draft-ietf-roll-applicability-home-building-08

[Adrian Farrel]

Hi Peter,

This all looks good.
The changes are small, but it would be worth catching them in a new revision.
Please post it when you have it, no need to check with me.

Once you've done that, we'll hand it over to Alvaro as the incoming AD, and he
can put it on an IESG telechat.

Cheers,
Adrian


 -Original Message-
 From: peter van der Stok [mailto:stokc...@xs4all.nl]
 Sent: 23 March 2015 14:49
 To: Meral Shirazipour
 Cc: draft-ietf-roll-applicability-home-building@tools.ietf.org;
gen-art@ietf.org
 Subject: Re: Gen-ART Last Call review of draft-ietf-roll-applicability-home-
 building-08
 
 HI Meral,
 
 Thanks for the suggestions.
 I have no problem with any of them. I think they are quite justified.
 Thank you very much for pointing them out.
 Concerning scene and group control. I may suppress the word scene.
 About [occuswitch] I have to look for a valid alternative. However,
 these links are maintained by a company, which changes information
 frequently.
 Sorry for missing out some of the acronyms. I thought I caught them out
 all.
 
 Greetings,
 
 Peter
 
 
 Meral Shirazipour schreef op 2015-03-22 21:28:
  I am the assigned Gen-ART reviewer for this draft. For background on
  Gen-ART, please see the FAQ at
  http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq.
 
  Please resolve these comments along with any other Last Call comments
  you may receive.
 
  Document: draft-ietf-roll-applicability-home-building-08
  Reviewer: Meral Shirazipour
  Review Date: 2015-03-21
  IETF LC End Date:  2015-03-23
  IESG Telechat date: NA
 
 
  Summary:
  This draft is ready to be published as Standards Track RFC but I have
  some comments.
 
  Major issues:
 
  Minor issues:
 
  Nits/editorial comments:
  -[Page 1], RPL first used in title/abstract, Would be good to spell
  it out.
  -[Page 5], Section 2, Monitoring of functional correctness is at
  least as important.. As important as what? (not clear)
  -[Page 5], Section 2, Devices typically communicate their status
  regularly and send alarm messages notifying a malfunction of equipment
  or network.
  Not clear what equipment is? network node is an equipment?
  -[Page 6], Section 2.1, for large installation---for a large
  installation
  -[Page 8], Section 2.2.2, fire detectors and the smoke dampers need
  to be put in place to meet the stringent delay requirements.
  Where can we find a value for the delay requirement of fire detectors?
  A value or reference would be good.
  -[Page 9], Section 2.2.4,advanced scene and group control. Not clear
  what scene means.
  -[Page 13], Section 4.1, assumes the role as
  authoritative---assumes the role of authoritative
  -[Page 16], section 4.1.8, please spell out first use CBC-MAC (Cipher
  Block Chaining Message Authentication Code)
  -[Page 16], section 4.1.10, it would be good to give the RFCs.
  -[Page 16], section 4.2.4, MLE to spell out at first use mesh link
  establishment
  -[Page 22], CoAp first used in section 7.4, but spelled out in
  section 8.
  -[Page 18], section 5.1.1., to throw away too late messages, how are
  too late messages identified?
  -[Page 27], [I-D.ietf-6lo-lowpanz] to be replaced by RFC7428
  -[Page 28], link to [occuswitch] to be verified.
  -Through the document both ms and msec are used. Selecting one for
  consistency would be better.
 
  Best Regards,
  Meral
  ---
  Meral Shirazipour
  Ericsson
  Research
  www.ericsson.com

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

Re: [Gen-art] Gen-ART Telechat Call review of draft-ietf-mpls-lsp-ping-registry-02

[Adrian Farrel]

And thanks Meral for the review
And thanks Bruno for the response with which I agree.

Adrian

 -Original Message-
 From: Loa Andersson [mailto:l...@pi.nu]
 Sent: 05 March 2015 11:09
 To: bruno.decra...@orange.com; draft-ietf-mpls-lsp-ping-
 registry@tools.ietf.org; meral.shirazip...@ericsson.com; gen-art@ietf.org
 Subject: Re: Gen-ART Telechat Call review of
draft-ietf-mpls-lsp-ping-registry-02
 
 Folks,
 
 When I sent the question I intended to send it to the authors only,
 but only change the name of the receiver (removed .all) and let the
 .all stay in the actual mail address, so we have been spreading this a
 bit wider than intended. So I put all the initial mail addresses back.
 
 However, I agree with Bruno's responses. The difference between not
 assigned and reserved is a Bruno put it.
 
 /Loa
 
 On 2015-03-05 17:55, bruno.decra...@orange.com wrote:
  Hi Loa, all,
 
  Please see inline [Bruno] the proposed resolution
 
  From: Loa Andersson [mailto:l...@pi.nu]  Sent: Thursday, March 05, 2015
8:19
 AM
  To: draft-ietf-mpls-lsp-ping-regis...@tools.ietf.org
  Subject: Re: Gen-ART Telechat Call review of
draft-ietf-mpls-lsp-ping-registry-
  02
 
  Folks,
 
  Did we respond to the Gen ART review?
 
  [Bruno] Not yet.
 
  /Loa
 
  On 2015-03-05 03:03, Meral Shirazipour wrote:
  I am the assigned Gen-ART reviewer for this draft. For background on Gen-
  ART, please see the FAQ at 
  http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq.
 
  Please wait for direction from your document shepherd or AD before
  posting a new version of the draft.
 
  Document: draft-ietf-mpls-lsp-ping-registry-02
  Reviewer: Meral Shirazipour
  Review Date: 2015-03-04
  IETF LC End Date: 2015-03-02?
  IESG Telechat date: 2015-03-05
 
  Summary: This draft is ready to be published as Standards Track RFC but I
  have some comments.
 
  Minor issues:
  -[Page 3], Section 2.1, Table Registry Name: DS Flags.. Is there a
reason bits
  5-0 are listed as Unassigned and not Reserved (MBZ) ?, with Reference
  being RFC4379 Section 3.3.
 
  [Bruno] Indeed RFC4379 marks these flags as Reserved.
  However, my understanding is that in an IANA registry, reserved means that
 the IANA can't use it. While Unassigned means that the IANA is free to pick
a
 value and assign.
  I think we do mean Unassigned as we want the IANA to be able to make
 assignment. (otherwise, there is no point in making a IANA registry)
 
 
  -[Page 4], Section 2.3, Table Registry Name: Pad Type.. RFC4379 did not
  reserve value 0. I could be wrong please double check.
 
  [Bruno] Indeed, RFC4379 does not talk about value 0. Probably an oversight.
  IMHO it's better for this document to document value 0 (probably required by
 IANA). IMO making 0 reserved is the safest option.
  At least the WG did not object/comment.
  Hower the document indicates  0Reserved
RFC4379 and this
 is not strictly true that RFC 4379 is the reference for this value 0.
  Hence I would propose
  OLD:  0Reserved RFC4379
  New:  0Reserved This document.
 
 
  -[Page 5], Section 2.4, Table Registry Name: Interface and Label Stack
  Address Type.. Same as above, RFC4379 did not reserve value 0.
 
  [Bruno] idem
 
 
 
 
  Nits/editorial comments:
  -[Page 2], Section 2.1, please put in parenthesis (DSMAP) and (DDMAP)
right
  after when the terms are spelled out. The acronyms are use later on.
 
  [Bruno] Yes. Thank you. Done in my local copy
 
 
 
 
  Best Regards,
  Meral
  ---
  Meral Shirazipour
  Ericsson
  Research
  www.ericsson.com
 
 
  --
 
 
  Loa Anderssonemail: l...@mail01.huawei.com
  Senior MPLS Expert  l...@pi.nu
  Huawei Technologies (consultant) phone: +46 739 81 21 64
 
 
 __
 ___
 
  Ce message et ses pieces jointes peuvent contenir des informations
 confidentielles ou privilegiees et ne doivent donc
  pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu
ce
 message par erreur, veuillez le signaler
  a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
 electroniques etant susceptibles d'alteration,
  Orange decline toute responsabilite si ce message a ete altere, deforme ou
 falsifie. Merci.
 
  This message and its attachments may contain confidential or privileged
 information that may be protected by law;
  they should not be distributed, used or copied without authorisation.
  If you have received this email in error, please notify the sender and
delete this
 message and its attachments.
  As emails may be altered, Orange is not liable for messages that have been
 modified, changed or falsified.
  Thank you.
 
 
 --
 
 
 Loa Anderssonemail: l...@mail01.huawei.com
 Senior MPLS Expert  l...@pi.nu
 Huawei Technologies (consultant) 

Re: [Gen-art] Last Call Review: draft-ietf-mpls-proxy-lsp-ping-03

[Adrian Farrel]

No Tom, it isn't disregarding or ignoring your comment.
It is fumbling it.

Bad, bad authors.
Naughty step please.

Adrian

 -Original Message-
 From: Tom Taylor [mailto:tom.taylor.s...@gmail.com]
 Sent: 05 March 2015 00:03
 To: Gen Art; draft-ietf-mpls-proxy-lsp-p...@ietf.org; George Swallow; Vanson
 Lim; Sam Aldrin; mpls-cha...@ietf.org; Adrian Farrel
 Subject: Re: Last Call Review: draft-ietf-mpls-proxy-lsp-ping-03
 
 Thank you for your update (version -04).
 
 I cannot see any changes in the -04 version responding to my minor
 issues 2-4. I gather the ambiguity is considered to be in my eyes only.
 
 Tom Taylor
 
 On 13/02/2015 1:19 AM, Tom Taylor wrote:
  I am the assigned Gen-ART reviewer for this draft. For background on
  Gen-ART, please see the FAQ at
 
  http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq.
 
  Please resolve these comments along with any other Last Call comments
  you may receive.
 
  Sorry to be so last-minute. Life happens.
 
  Tom Taylor
 
  Document:  draft-ietf-mpls-proxy-lsp-ping-03
  Reviewer:  Tom Taylor
  Review Date: 2015-02-12
  IETF LC End Date: 2015-02-12
  IESG Telechat date: 2015-02-19
 
  Summary: Generally well written, but a few minor issues and a number of
  nits and editorial suggestions.
 
  Major issues:
 
  Minor issues:
 
  1. Section 3.1, Proxy Echo Parameter TLV MPLS payload size field.
 
  This section describes initiator actions, but the paragraph contains the
  text:
 
   When the payload size is non
  zero, if sending the MPLS Echo Request involves using an IP header,
  the Do not Fragment (DF) bit MUST be set to 1.
 
  This sentence logically belongs in Section 3.2 (3.2.4.1), which has no
  instructions at all regarding the payload size field.
 
  Noted that the description of the MPLS Payload Size field in Section 5.1
  has a full description, but says the DF bit SHOULD be set. Is it MUST or
  SHOULD, and if the latter, what is the exception?
 
  2. Section 3.2.1, third paragraph, second sentence currently reads:
 
 If the Proxy LSR is a budnode, a MPLS
  proxy ping reply SHOULD be sent to the initiator with the return code
  set to 3 (Reply router is Egress for FEC) with return Subcode set to
  0 and DS/DDMAPs only if the Proxy initiator requested information to
  be returned in a MPLS proxy ping reply.
 
  Do you mean that the DS/DDMAP TLV is included only if the initiator
  asked for it (which seems like redundant advice) or do you mean that the
  reply is sent only if the initiator asked for the DS/DDMAP information?
 
  3. Same paragraph, next sentence: why SHOULD rather than MUST? What is
  the exception?
 
  4. Section 3.2.1, last paragraph (dealing with MP2MP case): the second
  to fourth sentences read:
 
  LSP pings sent from a leaf of a MP2MP has
  different behavior in this case. MPLS Echo Request are sent to all
  upstream/downstream neighbors. The Proxy LSRs need to be consistent
  with this variation in behavior.
  s/has/have/ to get that out of the way.
 
  Do you mean that the initiator is a leaf of the MP2MP? How does the
  Proxy LSR know this? Does it matter? If it is the Proxy LSR that is the
  leaf, the statement makes more sense. The different behavior is that the
  Proxy LSR always sends MPLS Echo Requests in at least one direction if
  it is not sending an MPLS proxy ping reply. You could refer to the
  previous paragraph for the remaining behavioural description.
 
  The next sentence in this paragraph has the same problem as Minor Issue
  2. above, except that I see a stronger hint that the second
  interpretation suggested above is your intention.
 
  5. You are creating a new IANA registry for sub-types of the Proxy Echo
  Parameters TLV. You need to document registration procedures as per RFC
  5226.
 
 
  Nits/editorial comments:
 
  General: Is there a reason for capitalizing MPLS Echo Request but not
  MPLS proxy ping request[reply]?
 
  General: Sometimes return code text is enclosed in quotes, sometimes in
  parentheses. Choose one.
 
  1. ABSTRACT third line: s/Routers/Router/
 
  2. Section 2.1.1, first line: s/If/if/
 
  3. Same section, second paragraph has both typos and editorial glitches.
 
  OLD
 
  In the case the targeted proxy LSR does not understand LSP ping Echo
  Request at all, like any other LSR which do not understand the
  messages, they MUST be dropped and no messages is set back to the
  initiator.
 
  NEW
 
  In the case where the targeted proxy LSR does not understand
  the LSP ping Echo Request at all, like any other LSR which does not
  understand the messages, it MUST drop them and MUST NOT(?) send any
  message back to the initiator. [Was the MUST NOT intended? -- PTT]
 
  4. Section 3.1, last sentence: s/is//
 
  5. Section 3.2, first paragraph, fourth line: s/set to/to/
 
  6. Same section, fifth paragraph:
 s/Request messages/Request message/
 s/one is sent/either is sent/
 
  7. Same section

Re: [Gen-art] Last Call Review of draft-farrresnickel-harassment-05

[Adrian Farrel]

Tom,

Thanks for the review

 Nits/editorial comments:
 
 The Ombudsteam is taken for granted from Section 2 onwards. It would be
 nice to mention in the Introduction that the IESG mentioned
 Ombudspersons in its statement of anti-harassment policy [1], but did
 not define the procedures under which the Ombudsteam would be
 constituted and under which they would operate. This document remedies
 that lack.

It is my opinion that this document is not intended to build upon [1] so much 
as to address the whole situation. 

It doesn't feel right to me to pick out this specific item, when (in fact) [1] 
does little more than say that harassment is something up with which we will 
not put.

The Introduction has this document sets forth procedures to deal with such 
harassing behavior and I think the breadth of that statement covers what is in 
this document.

 Reference URIs [1] and [2] are identical. Should one be removed?

It's a feature of xml2rfc that we cannot fathom!
The RFC Editor will have to resolve it.

 Presumably the Ombudsteam web site will be set up upon approval of this
 document -- it does not exist at the moment.

Yes. And he email address, I think.
Another thankless task for Jari.

 Section 4.1, first paragraph, fourth line: s/objection/objections/

Thanks.

Adrian

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

Re: [Gen-art] Last Call Review: draft-ietf-mpls-proxy-lsp-ping-03

[Adrian Farrel]

Tom,

Thanks for the detailed review. Much appreciated. Late is better than not at 
all, and one day is not the end of the world.

 Please resolve these comments along with any other Last Call comments
 you may receive.

Well, we'll handle the comments, of course, but we'll make a special trip to do 
that since Last Call comments have already been handled.

Authors - I've pushed the I-D out to the 5/3 telechat. Sorry for the delay that 
represents, but we have to give the IESG time to review the final version that 
you'll produce by addressing Tom's comments.

Adrian

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

Re: [Gen-art] review: draft-ietf-roll-admin-local-policy-03 (was -02)

[Adrian Farrel]

Thanks Joel.

Adrian

 -Original Message-
 From: Joel Halpern [mailto:j...@joelhalpern.com]
 Sent: 12 February 2015 23:38
 To: gen-art@ietf.org; maria.ines.rob...@ericsson.com; IETF discussion list
 Cc: Adrian Farrel; r...@ietf.org
 Subject: Re: [Gen-art] review: draft-ietf-roll-admin-local-policy-03 (was -02)
 
 This is a re-review of -03 of this document.
 
 While I find it slightly odd, upon consideration I believe the statement
 that turning this protocol on is the administrative control required by
 the definition of admin-local scope is sufficient, and thus addresses my
 original concern.
 
 If for some reason this needs to be revised further, I would like to see
 an explicit statement that this behavior (scope-4 announcing and
 forwarding) MUST by default be turned.  That would seem aligned with the
 declaration that turning this behavior on is the administrative action.
 
 Otherwise, this document is now ready for publication as an
 Informational RFC.
 
 Document: draft-ietf-roll-admin-local-policy-03
   MPL forwarder policy for multicast with admin-local scope
 Reviewer: Joel M. Halpern
 Review Date: 12-Feb-2015
 IETF LC End Date: done
 IESG Telechat date: 19-Feb-2015
 
 Yours,
 Joel M. Halpern


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

Re: [Gen-art] review of draft-ietf-l3vpn-acceptown-community-09.txt

[Adrian Farrel]

Authors,

Fortunately Francis has not found any issues of substance.
Please fold these nits into the revision you are producing to address the IESG
Comments from last Thursday's telechat.

Thanks,
Adrian

 
 From: francis.dup...@fdupont.fron Behalf OfFrancis Dupont
 Sent: 09 February 2015 13:19:22 (UTC) Dublin, Edinburgh, Lisbon, London
 To: gen-art@ietf.org
 Cc: draft-ietf-l3vpn-acceptown-community@tools.ietf.org
 Subject: review of draft-ietf-l3vpn-acceptown-community-09.txt
 
 I am the assigned Gen-ART reviewer for this draft. For background on
 Gen-ART, please see the FAQ at
  http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq.
 
 Please wait for direction from your document shepherd
 or AD before posting a new version of the draft.
 
 Document: draft-ietf-l3vpn-acceptown-community-09.txt
 Reviewer: Francis Dupont
 Review Date: 20150206
 IETF LC End Date: 20141208
 IESG Telechat date: 20150205
 
 Summary: Ready
 
 Major issues: None
 
 Minor issues: None
 
 Nits/editorial comments:
  - Abstract page 1: VRF and PE are not well known abbrevs
   (cf http://www.rfc-editor.org/rfc-style-guide/abbrev.expansion.txt)
 
  - Abstract page 1 (style): I suggest:
that is distributed by the route reflector
-
that the route reflector distributes
 
  - Abstract page 1 (style):
on the same PE as - on the same PE than
 
  - Abstract page 1 (style):
(second) allowing the technique to be used - and to be used
 
  - 1 page 2: same comment about that is distributed
 
  - 1 page 3: the abbrev PE (Provider Edge) must be introduced at its
   first use (in the body of the document).
 
  - 3 page 4: i.e. - i.e.,
 
 Regards
 
 francis.dup...@fdupont.fr

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

Re: [Gen-art] Gen-ART LC review for draft-ietf-pce-rfc7150bis-01

[Adrian Farrel]

Thanks, Peter.
Adrian

 -Original Message-
 From: ietf [mailto:ietf-boun...@ietf.org] On Behalf Of Peter Yee
 Sent: 24 December 2014 20:18
 To: draft-ietf-pce-rfc7150bis@tools.ietf.org
 Cc: gen-art@ietf.org; i...@ietf.org
 Subject: Gen-ART LC review for draft-ietf-pce-rfc7150bis-01
 
 I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART,
 please see the FAQ at 
 http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq
 
 Please resolve these comments along with any other Last Call comments you may
 receive.
 
 Document: draft-ietf-pce-rfc7150bis-01
 Reviewer: Peter Yee
 Review Date: Dec-24-2014
 IETF LC End Date: Dec-24-2014
 IESG Telechat date: TBD
 
 Summary: This draft is ready for publication as a Standards Track RFC. [Ready]
 
 This draft updates RFC 7150 to clarify the use of the new PCEP-object-carried 
 TLV
 and fixes an IANA allocation clash.


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

Re: [Gen-art] Gen-ART LC review for draft-ietf-l3vpn-end-system-04

[Adrian Farrel]

Thanks for the nits, Peter.

We'll be sure to look at them if the document is open again before being passed 
to the RFC editor.

Adrian

 -Original Message-
 From: ietf [mailto:ietf-boun...@ietf.org] On Behalf Of Peter Yee
 Sent: 09 December 2014 08:09
 To: draft-ietf-l3vpn-end-system@tools.ietf.org
 Cc: gen-art@ietf.org; i...@ietf.org
 Subject: Gen-ART LC review for draft-ietf-l3vpn-end-system-04
 
 I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART,
 please see the FAQ at 
 http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq
 
 Please resolve these comments along with any other Last Call comments you may
 receive.
 
 Document: draft-ietf-l3vpn-end-system-04
 Reviewer: Peter Yee
 Review Date: Dec-8-2014
 IETF LC End Date: Dec-8-2014
 IESG Telechat date: TBD
 
 Summary: This draft is basically ready for publication as a Standards Track 
 RFC, but
 has some nits that should be fixed before publication. [Ready with nits.]
 
 This draft documents a novel means of using XMPP to signal VPN route
 information between VPN Forwarders and End-System Route Servers for use
 with BGP IP VPNs.  It discussed the requirements on each entity using the
 scheme.
 
 Major issues:
 
 Minor issues:
 
 Nits:
 
 General: Use a comma after i.e. and e.g.
 
 General: Data center doesn't require a hyphen.  Neither does virtual machine.
 Wi-Fi does, however.
 
 Page 3, definition of End-System, 1st sentence: change which to whose.
 
 Page 4, 4th paragraph, last sentence: replace recur to with rely upon.
 
 Page 6, 3rd paragraph, 1st sentence: delete then.
 
 Page 10, 1st paragraph, 1st sentence: delete redundant the.
 
 Page 10, 1st paragraph, 2nd sentence: change mac- to MAC .  Change a 
 IEEE
 to an IEEE.
 
 Page 11, figure: this figure needs a caption with a figure number.  That will 
 force
 an increment of all of the following figure numbers as well.
 
 Page 16, 1st paragraph after XML, last sentence: change convinience to
 convenience.
 
 Page 16, 2nd paragraph, 3rd sentence: replace the period with a comma and
 change the following Even to lower case to join the following clause to the
 sentence.
 
 Page 17, 4th paragraph, 2nd sentence: replace detemined with determined.
 Replace an with a.
 
 Page 17, 5th paragraph, 2nd sentence: replace mapps with maps.
 
 Page 18, Section 8, 4th paragraph, 1st sentence: change a XMPP to an XMPP.
 
 Page 19, 1st paragraph, 2nd sentence: change attachement to attachment.
 
 Page 20, 1st full paragraph, 1st sentence: I'm not certain, but would 
 inserting
 the before host help?  Or how about a host number after host?
 
 Page 20, 7th paragraph, 2nd sentence: change Assuming to Assume.
 


___
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-ccamp-rwa-info-22.txt

[Adrian Farrel]

Thanks Russ,

That looks reasonable and tractable.

Adrian

 -Original Message-
 From: ietf [mailto:ietf-boun...@ietf.org] On Behalf Of Russ Housley
 Sent: 09 November 2014 22:42
 To: IETF; ccamp-cha...@tools.ietf.org; draft-ietf-ccamp-rwa-
 info@tools.ietf.org
 Cc: General Area Review Team
 Subject: Gen-ART review of draft-ietf-ccamp-rwa-info-22.txt
 
 I am the assigned Gen-ART reviewer for this draft. For background on
 Gen-ART, please see the FAQ at
 http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq.
 
 Please resolve these comments along with any other Last Call comments
 you may receive.
 
 Document: draft-ietf-ccamp-rwa-info-22
 Reviewer: Russ Housley
 Review Date: 2014-11-09
 IETF LC End Date: 2014-11-27
 IESG Telechat date: unknown
 
 Summary: Almost ready; a few minor things to clear up.
 
 Major Concerns:
 
 None.
 
 Minor Concerns:
 
 In section 3, please add a sentence or two that explains switching
 subsystem and line subsystem.  The definitions might be best appear in
 Section 2.  I checked in RFC 6163, but I did not find a description of
 these terms there.
 
 Other Comments:
 
 Section 1 begins with:
 
The purpose of the following information model for WSONs ...
 
 In my opinion, it would be better to say something like:
 
The purpose of the WSONs information model described in this
document ...
 
 Likewise, in section 3, it says:
 
The following WSON RWA information model ...
 
 In my opinion, it would be better to say something like:
 
The WSON RWA information model in this document ...
 
 In section 5.1, 3rd paragraph, it says:
 
... Since not all input ports
can necessarily reach each resource block, the model starts with a
resource pool input matrix RI(i,p) = {0,1} whether input port i can
reach potentially reach resource block p.
 
 s/reach potentially reach/potentially reach/
 


___
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-manet-ibs-03

[Adrian Farrel]

All,

This document has completed IETF last call, but it seems to me that this
conversation may not be complete yet. Please continue it and try to reach
resolution.

The document is on the IESG telechat for 11/25 and I am confident that you will
reach some agreement (if only agreement to disagree) by then. Until that time I
will enter a Discuss ballot to track this as an open issue.

Thanks,
Adrian


 
 From: Dearlove, Christopher (UK)
 Sent: 27 October 2014 10:04:41 (UTC) Dublin, Edinburgh, Lisbon, London
 To: Martin Thomson
 Cc: draft-ietf-manet-ibs@tools.ietf.org; gen-art@ietf.org
 Subject: RE: Gen-ART review of draft-ietf-manet-ibs-03
 
 I didn't say this, and perhaps I should have, but while signature uses the
private
 key, verification uses the sender's identity (included in the packet/message)
and
 the user-independent public information only.
 
 --
 Christopher Dearlove
 Senior Principal Engineer, Information Assurance Group
 Communications, Networks and Image Analysis Capability
 BAE Systems Advanced Technology Centre
 West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
 Tel: +44 1245 242194 |  Fax: +44 1245 242124
 chris.dearl...@baesystems.com | http://www.baesystems.com
 
 BAE Systems (Operations) Limited
 Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre,
 Farnborough, Hants, GU14 6YU, UK
 Registered in England  Wales No: 1996687
 
 
 -Original Message-
 From: Dearlove, Christopher (UK)
 Sent: 27 October 2014 09:42
 To: 'Martin Thomson'
 Cc: draft-ietf-manet-ibs@tools.ietf.org; gen-art@ietf.org
 Subject: RE: Gen-ART review of draft-ietf-manet-ibs-03
 
  I'm not 100% clear on the architecture here, but I've inferred that
participating
 nodes receive a private key from the trusted authority and a set of public
keys for
 other trusted nodes.
 
 No, and that's where the win is here. You receive a private key (which
includes
 some public information). You have no advance knowledge of what other nodes
 there are, and no key state that depends on other nodes. You can even field a
 node (thus cutting any connection with the authority) when which other nodes
 are to be trusted hasn't even been decided. Each node is keyed independently
 (except for the requirement to have unique identities) and in a O(1)
operation,
 not O(N), where N is the number of nodes. This is appropriate to some ad hoc
 networks.
 
 A node of course has a public key - but it's its identity (e.g. IP address).
And just
 to forestall an obvious point, the security does not depend on the size of the
 identity space.
 
 --
 Christopher Dearlove
 Senior Principal Engineer, Information Assurance Group Communications,
 Networks and Image Analysis Capability BAE Systems Advanced Technology
 Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
 Tel: +44 1245 242194 |  Fax: +44 1245 242124 chris.dearl...@baesystems.com |
 http://www.baesystems.com
 
 BAE Systems (Operations) Limited
 Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre,
 Farnborough, Hants, GU14 6YU, UK Registered in England  Wales No: 1996687
 
 -Original Message-
 From: Martin Thomson [mailto:martin.thom...@gmail.com]
 Sent: 24 October 2014 19:31
 To: Dearlove, Christopher (UK)
 Cc: draft-ietf-manet-ibs@tools.ietf.org; gen-art@ietf.org
 Subject: Re: Gen-ART review of draft-ietf-manet-ibs-03
 
 --! WARNING ! -- This message
originates from
 outside our organisation, either from an external partner or from the
internet.
 Consider carefully whether you should click on any links, open any attachments
 or reply.
 Follow the 'Report Suspicious Emails' link on IT matters for instructions on
 reporting suspicious email messages.
 
 
 On 24 October 2014 11:17, Dearlove, Christopher (UK)
 chris.dearl...@baesystems.com wrote:
  I am also not aware of a solution that overcomes this problem without
 introducing different limitations, so it is a question of tradeoffs. This is
one point
 in that tradeoff space. If anyone has a clearly superior solution that both
avoids
 the need to trust an authority, and without introducing other limitations,
then
 there are many of us in the ad hoc network community (and elsewhere, as just
 one example, to improve on 6507) who would like to see it. Note that all of
the
 previously specified options (in RFC 7182) rely on keys shared by all
participants,
 which is clearly weaker in some regards (but acceptable to many, hence also a
 valid option).
 
 It's fairly obvious that any entity that is trusted to assert identity can
arbitrarily
 impersonate.  But PKIX doesn't require that end entities share private keying
 material with certification authorities.
 
 I'm not 100% clear on the architecture here, but I've inferred that
participating
 nodes receive a private key from the trusted authority and a set of public
keys for
 

Re: [Gen-art] GenART review of draft-ietf-l2vpn-evpn-10

[Adrian Farrel]

Hi Martin,

I firmly believe that all reviews are good reviews, and thank you for the time
you have put into this.

You'll understand, of course, the squawking noise made by the authors who
received your review the day after the IESG discussed your document on the
telechat. In fact, the last Discus cleared a short while ago, and I was just
about to click the friendly red button marked Approved.  Including the
standard GenArt boilerplate about last call comments might be a tiny but
ironic :-)

But let's cut to the chase...

 I found the overview in Section 4 to be very...wooly.  

Hmmm.
I re-read and found it relatively to the point.
Sentences are quite short, and are all definitive.

 It launches
 straight into alphabet soup, 

True there are a lot of abbreviations.
But the terms are either well-known or described in Section 3.
For example, if a reader is unfamiliar with CE, PE, MPLS, IP, GRE, then I'm
afraid they will get nothing out of the document. Expanding the terms will not
help.

 but didn't manage to identify what it was
 that the document was trying to achieve, vs. what already exists. 

Do you feel that Section 1 does not make it clear what the document is trying to
achieve?

Yes, it is true that there is no list of new protocol elements defined in this
document to supplement existing mechanisms and thereby enable EVPN. I would
argue that that list is provided by Sections 5, 6, and 7, while sections 5
through 18 describe the new protocol procedures. So, since the whole document
after the section you are discussing is about the new stuff, I think that making
a list is unnecessary.

 It
 certainly raises questions: is this document going to address the
 issue of how MAC learning is populated on devices in networks attached
 to CE? 

I think you mean a device further into the customer network (i.e., not a PE).
Why do you think that this would be changed in an EVPN? The behavior of the
nodes in customer sites are not impacted by the way the PEs are sharing
information. That could be said to be the whole point of the work.

 Is it going to deal with (MAC) learning on the PE and CE
 equipment? 

The question for PEs is answered in the third paragraph of Section 4.
The question for CEs is answered in the fifth paragraph of Section 4.

 What information does the CE really need at the MAC layer
 to do its job? 

I'm sorry, but I don't understand this question. Is the behavior of a CE in an
EVPN assumed to be different from that of a CE in any other Ethernet emulation
environment? I don't think so.

 The information provided is definitely not enough to
 make sense of the remainder of the document.

OK.
But I don't see what information is missing given that your questions (above)
are basically already addressed in the text.
Maybe some time with 7209 would help set the scene.
The text certainly points at 7209 right from the start.

 Maybe that's just a shortcoming in my own education; this subject is
 well outside of my field.

OK. That's fine. And thanks for reviewing anyway.

 I also found the sudden introduction of a bag of protocol elements
 without context very difficult to process.  So an ESI identifies an
 EVPN?  What do I do with one?

Well, the term is introduced in the terminology section and also section 5 as
identifying an Ethernet segment, and section 5 describes what an Ethernet
segment is from the perspective of the CE. There then follows text indicating
how ESIs are allocated and the rules for uniqueness.

What you are missing, I think, is the forward pointers to indicate what use is
made of the ESI (i.e., why does an Ethernet segment need an identifier). The
need comes from 7209, but the usage is later in this document.

I dare say that the text (probably in Section 5) could start with As indicated
in [RFC7290], each PE-CE Ethernet segment needs a unique identifier in an EVPN.
This section defines how such identifiers are assigned and how they are encoded
for use in EVPN signaling. Later sections of the document describe the protocol
mechanisms that utilize the identifiers. Would that have helped?

 In section 5, why is there not some sort of registry for the ESI Types
 that are defined here?

Good question.
It's a question I asked when I did my AD review back in July. The reply was:
We don't anticipate any other ESI type besides the ones mentioned here.
While I am not 100% convinced there will never be a new type, if a new type does
show up it will be a rare occurrence and can be handled by a new I-D in the BESS
working group without contention. A registry could be added later if really
necessary.

 Section 6:
 
An Ethernet Tag ID is a 32-bit field containing either a 12-bit or a
24-bit identifier that identifies a particular broadcast domain
(e.g., a VLAN) in an EVPN Instance.
 
 How do I distinguish one from t'other?

It depends on the EVPN BGP route in use for the different service interfaces.
Like the text says...

   The following subsections discuss the relationship 

Re: [Gen-art] GenART review of draft-ietf-l2vpn-evpn-10

[Adrian Farrel]

Resend with Martin's correct email

 -Original Message-
 From: iesg [mailto:iesg-boun...@ietf.org] On Behalf Of Adrian Farrel
 Sent: 17 October 2014 12:05
 To: martin.thom...@andrew.com
 Cc: draft-ietf-l2vpn-evpn@tools.ietf.org; gen-art@ietf.org; i...@ietf.org
 Subject: RE: GenART review of draft-ietf-l2vpn-evpn-10
 
 Hi Martin,
 
 I firmly believe that all reviews are good reviews, and thank you for the time
 you have put into this.
 
 You'll understand, of course, the squawking noise made by the authors who
 received your review the day after the IESG discussed your document on the
 telechat. In fact, the last Discus cleared a short while ago, and I was just
 about to click the friendly red button marked Approved.  Including the
 standard GenArt boilerplate about last call comments might be a tiny but
 ironic :-)
 
 But let's cut to the chase...
 
  I found the overview in Section 4 to be very...wooly.
 
 Hmmm.
 I re-read and found it relatively to the point.
 Sentences are quite short, and are all definitive.
 
  It launches
  straight into alphabet soup,
 
 True there are a lot of abbreviations.
 But the terms are either well-known or described in Section 3.
 For example, if a reader is unfamiliar with CE, PE, MPLS, IP, GRE, then I'm
 afraid they will get nothing out of the document. Expanding the terms will not
 help.
 
  but didn't manage to identify what it was
  that the document was trying to achieve, vs. what already exists.
 
 Do you feel that Section 1 does not make it clear what the document is trying
to
 achieve?
 
 Yes, it is true that there is no list of new protocol elements defined in
this
 document to supplement existing mechanisms and thereby enable EVPN. I
 would
 argue that that list is provided by Sections 5, 6, and 7, while sections 5
 through 18 describe the new protocol procedures. So, since the whole document
 after the section you are discussing is about the new stuff, I think that
making
 a list is unnecessary.
 
  It
  certainly raises questions: is this document going to address the
  issue of how MAC learning is populated on devices in networks attached
  to CE?
 
 I think you mean a device further into the customer network (i.e., not a PE).
 Why do you think that this would be changed in an EVPN? The behavior of the
 nodes in customer sites are not impacted by the way the PEs are sharing
 information. That could be said to be the whole point of the work.
 
  Is it going to deal with (MAC) learning on the PE and CE
  equipment?
 
 The question for PEs is answered in the third paragraph of Section 4.
 The question for CEs is answered in the fifth paragraph of Section 4.
 
  What information does the CE really need at the MAC layer
  to do its job?
 
 I'm sorry, but I don't understand this question. Is the behavior of a CE in an
 EVPN assumed to be different from that of a CE in any other Ethernet emulation
 environment? I don't think so.
 
  The information provided is definitely not enough to
  make sense of the remainder of the document.
 
 OK.
 But I don't see what information is missing given that your questions (above)
 are basically already addressed in the text.
 Maybe some time with 7209 would help set the scene.
 The text certainly points at 7209 right from the start.
 
  Maybe that's just a shortcoming in my own education; this subject is
  well outside of my field.
 
 OK. That's fine. And thanks for reviewing anyway.
 
  I also found the sudden introduction of a bag of protocol elements
  without context very difficult to process.  So an ESI identifies an
  EVPN?  What do I do with one?
 
 Well, the term is introduced in the terminology section and also section 5 as
 identifying an Ethernet segment, and section 5 describes what an Ethernet
 segment is from the perspective of the CE. There then follows text indicating
 how ESIs are allocated and the rules for uniqueness.
 
 What you are missing, I think, is the forward pointers to indicate what use is
 made of the ESI (i.e., why does an Ethernet segment need an identifier). The
 need comes from 7209, but the usage is later in this document.
 
 I dare say that the text (probably in Section 5) could start with As
indicated
 in [RFC7290], each PE-CE Ethernet segment needs a unique identifier in an
EVPN.
 This section defines how such identifiers are assigned and how they are
encoded
 for use in EVPN signaling. Later sections of the document describe the
protocol
 mechanisms that utilize the identifiers. Would that have helped?
 
  In section 5, why is there not some sort of registry for the ESI Types
  that are defined here?
 
 Good question.
 It's a question I asked when I did my AD review back in July. The reply was:
 We don't anticipate any other ESI type besides the ones mentioned here.
 While I am not 100% convinced there will never be a new type, if a new type
does
 show up it will be a rare occurrence and can be handled by a new I-D in the
BESS
 working group without contention. A registry could

Re: [Gen-art] GenART review of draft-ietf-l2vpn-evpn-10

[Adrian Farrel]

 
 BTW, since these are just editorial changes, I will just give them to the
 RFC editor, unless you want me to check the new rev in.

Give them the edits and ask whether they'd like a new rev.

Thanks,
Adrian

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

Re: [Gen-art] Gen-ART LC Review of draft-ietf-forces-model-extension-03

[Adrian Farrel]

Ben,

Thanks for the time and effort.

Adrian

 -Original Message-
 From: ietf [mailto:ietf-boun...@ietf.org] On Behalf Of Ben Campbell
 Sent: 27 August 2014 22:25
 To: Haleplidis Evangelos
 Cc: draft-ietf-forces-model-extension@tools.ietf.org; gen-art@ietf.org;
 i...@ietf.org
 Subject: Re: Gen-ART LC Review of draft-ietf-forces-model-extension-03
 
 Hi,
 
 This version addresses all of the concerns from my gen-art review.
 
 Thanks,
 
 Ben.
 
 On Aug 21, 2014, at 5:26 PM, Haleplidis Evangelos eha...@ece.upatras.gr
 wrote:
 
  Greetings Ben,
 
  Thank you very much for the review and the discussion.
  I have made all the relevant changes and have submitted (just in time it
  seems) the new version.
 
  Regards,
  Evangelos Haleplidis.
 
  -Original Message-
  From: Ben Campbell [mailto:b...@nostrum.com]
  Sent: Thursday, August 21, 2014 1:22 AM
  To: Haleplidis Evangelos
  Cc: draft-ietf-forces-model-extension@tools.ietf.org; gen-
  a...@ietf.org; i...@ietf.org
  Subject: Re: Gen-ART LC Review of draft-ietf-forces-model-extension-03
 
 
  On Aug 20, 2014, at 5:00 PM, Haleplidis Evangelos
  eha...@ece.upatras.gr wrote:
 
 
  [ΕΗ] I discussed with Joel with regards to the copyright issues.
  The short answer is that this document draws directly from RFC5812
  and
  relies on RFC5812 for such issues (as it uses the same boilerplate).
 
  Is this satisfactory?
 
 
  Hrmm. So it does. I somehow had it in my head it had the older
  boilerplate. I must have gotten that from one of the draft versions So,
  never mind :-)
 
  (It's interesting that IDNits apparently looked at the date of
  publication of the first 00 draft, not the RFC. I'm curious the history
  of what happened with RFCs that were in-process works and had changes
  in authorship at the time 5378 was published--but that's not this
  draft's problem and should probably happen in a bar discussion.)
 
  [...]
 
 
  In this particular case, it's not clear to me if the MUST actually
  constrains a choice vs being a statement of fact. If you believe it
  to be the former then I am okay with it. The rewording might help.
 
 
  [ΕΗ] I reworded it and provided also an example. The text now reads:
 
  When optional access type for components within a struct are
  defined,
  these components's access type MUST override the access type of the
  struct. For example if a struct has an access type of read-write but
  has a component that is a read-only counter, the counter's access
  type MUST be read-only.
 
  I believe that it is an implementation constraint as there are two
  possibilities (override or not). With the MUST we constrain it to
  one (override).
 
  I also changed the two it MUST be ignored to the access type MUST
  be ignored to better specify what it is.
 
 
  This helps.
 
  For the record, my suggestion on more active voice was to say what must
  do the ignoring. But I think what you've got is good enough.
 
  [...]
 
 
 
  No, I am not one.  Hopefully this will get a SecDir review as well.
  But that sort of review usually goes better if the Security
  Consideration section shows your reasoning, along the lines of
  listing the high-level types of changes, and for each, why it has no
  new security impact. Your response contains more of that sort of
  thing; it might help to add it (or parts of it) to the draft.
 
  I was a bit concerned that the default version for inheritance could
  be an issue, but you addressed that elsewhere.
 
  [...]=
 
  [ΕΗ] Ok, added part of this. Now the security considerations read the
  following:
 
  This document adds only a few constructs to the initial model defined
  in RFC5812, namely namely a new event, some new properties and a way
  to define optional access types and complex metadata. These
  constructs
  do not change the nature of the the initial model. In addition this
  document addresses and clarifies an issue with the inheritance model
  by introducing the version of the derivedFrom LFB class.
  Thus the security considerations defined in RFC5812 applies to this
  document as well as the changes proposed here are simply constructs
  to
  write XML library definitions, as where in RFC5812 and have no effect
  on security semantics with the protocol.
 
 
  You might consider adding something to say that the inheritance model
  change also does not change the security considerations. (Maybe it
  makes things better, by removing the potential for choosing a wrong
  parent class? Not sure if that's a security issue, unless there was
  some kind of parent-assertion attack.)
 
  It does seem like the inheritance change is a bona-fide extension, not
  just a clarification, since you added the version attribute.=
 

___
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-bfd-tc-mib-06

[Adrian Farrel]

Hi Christer,

Thanks for your efforts.

 Editorial nits:
 
 Section 1 (Introduction):
-
 
 Q_1:

 s/”two MIB modules”/”two Management Information Base (MIB) modules”

Note that MIB is found as well known at
http://www.rfc-editor.org/rfc-style-guide/abbrev.expansion.txt
 
Authors, please do not make this change.
 
Cheers,
Adrian

___
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-bfd-mib-17

[Adrian Farrel]

Hi David,

Thanks for the review.

To pick out one of your points:

 This MIB contains many writable objects, so the authors should
 take note of the IESG statement on writable MIB modules:
 
   http://www.ietf.org/iesg/statement/writable-mib-module.html
 
 I did not see this mentioned in the shepherd writeup.  If the OPS Area
 has not been consulted, I strongly suggest doing so during IETF Last
 Call, e.g., starting with Benoit Claise (AD).

The OPS Directorate and the MIB Doctors will have been alerted to this document
by the last call and we can expect their comments.

But this question was discussed between the AD and the authors, and the AD was
unlikely to agree to sponsor the document if he felt it went against the IESG
statement. Our discussion resulted in some reduction of writeable objects.

I think there are several points to consider:
1. This document had already been completed and publication requested (i.e.
shepherd write-up written) at the time of the IESG statement. It would be
unreasonable to make the statement retrospective.
2. There are already various implementations in equipment (not just management
stations) of proprietary modules approximating to this document and these
support write-access.
3. This is a low-level component protocol of the sort that is used on dumber
devices and that is an area where write-access is more common.

Cheers,
Adrian


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

Re: [Gen-art] Gen-art LC review: draft-ietf-l2vpn-vpls-ldp-mac-opt-11

[Adrian Farrel]

Thanks Robert,

Will be interested to hear author/shepherd responses to this.

Adrian

 -Original Message-
 From: L2vpn [mailto:l2vpn-boun...@ietf.org] On Behalf Of Robert Sparks
 Sent: 07 April 2014 20:41
 To: General Area Review Team;
draft-ietf-l2vpn-vpls-ldp-mac-...@tools.ietf.org;
 l2...@ietf.org
 Subject: Gen-art LC review: draft-ietf-l2vpn-vpls-ldp-mac-opt-11
 
 I am the assigned Gen-ART reviewer for this draft. For background on
 Gen-ART, please see the FAQ at
 
 http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq.
 
 Please resolve these comments along with any other Last Call comments
 you may receive.
 
 Document: draft-ietf-l2vpn-vpls-ldp-mac-opt-11
 Reviewer: Robert Sparks
 Review Date: 7Apr2014
 IETF LC End Date: 8Apr2014
 IESG Telechat date: not yet scheduled
 
 Summary: This draft is almost ready for publication as a Proposed
 Standard, but has minor issues (primarily editorial) that should be
 addressed.
 
 I found this document very difficult to read. It asks the reader to hop
 between sections in unusual ways (for instance, it sends the reader to
 the problem statement section for details on normative behavior). I
 strongly encourage an editorial pass focusing on document structure.
 
 There are many instances of SHOULD in the document where the text should
 just be using prose instead. It's not always clear when an
 implementation would choose to ignore the SHOULD, and what the
 consequences of that choice would be.
 
 The document is inconsistent about the level of support needed in the
 network before trying to use this extension.
 Section 5.1.2 says the assumption is everything understands it before
 it's turned on. Section 6 points back to figure 2 and says
 to use the extension over the pw where you administratively know the
 peer supports the extension, and fall back to 4762 for
 everything else. Which of those did you intend?
 
 Specific comments in document order:
 
 Section 3.2 paragraph 1: This paragraph would benefit from being broken
 into several. It's hard to find its point. The SHOULD in this paragraph
 is probably not a 2119 SHOULD (this section isn't defining the
 protocol). It would be useful in this overview to explicitly say _why_
 This cannot be achieved with ... 4762] at this point in the document.
 
 Section 3.2 paragraph 2: This SHOULD _is_ defining protocol - shouldn't
 it be in section 5?
 
 Section 4.1.1 paragraph 3: It took me some time to find Z on the figure.
 It might help to introduce it similar to how you introduce X.
 
 Section 4.1.2: paragraph 1: I think you meant to reference 4.1.1
 
 Section 5: The first sentence talks about requirements in section 4.
 Section 4 describes a problem using some examples but doesn't explicitly
 call out requirements. Doing so would help the document.
 
 Last sentence in 5.1.1 (and several other places in the document):
 Please add an article before MAC Flush message.  (I apologize for such
 a small nit, but each of these instances made making sure I was reading
 what the sentence intended significantly more difficult).
 
 Section 5.1.2 first paragraph: This section is defining behavior - why
 are you sending the reader back into the problem statement for detail on
 the behavior?
 
 5.1.2 paragraph 2: You meant section 6, not 5.
 
 5.1.2 paragraph 3: I can't follow this paragraph's structure. I think
 you're trying to say An MTU-s or PE2-rs SHOULD send MAC withdraw
 messages as defined in [RFC4762] in cases where the network is being
 upgraded and devices are not capable of understanding the optimized MAC
 flush. (But if so, the next sentence is redundant.) Why is this SHOULD?
 
 5.1.3 paragraph 1: Why is this a SHOULD and not a MUST? (Similar
 question for the SHOULD in paragraph 2). It's not clear if you're trying
 to avoid Some things won't implement this spec or Don't do this if
 you haven't administratively ensured every element understands this
 extension first or something else?
 
 5.1.3 paragraph 3: You say unless specified otherwise. Do you ever
 specify otherwise? Why is this disclaimer here?
 
 5.1.3 last paragraph: You meant section 6 not 5.
 
 
 


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

Re: [Gen-art] Gen-ART LC review of draft-ietf-mpls-lsp-ping-ttl-tlv-07

[Adrian Farrel]

Thanks for your time, Roni.
 
Adrian
 
From: ietf [mailto:ietf-boun...@ietf.org] On Behalf Of Roni Even
Sent: 03 April 2014 11:48
To: draft-ietf-mpls-lsp-ping-ttl-tlv@tools.ietf.org
Cc: gen-art@ietf.org; i...@ietf.org
Subject: Gen-ART LC review of draft-ietf-mpls-lsp-ping-ttl-tlv-07
 
I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART,
please see the FAQ at http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq.
Please resolve these comments along with any other Last Call comments you may
receive.
Document:  draft-ietf-mpls-lsp-ping-ttl-tlv-07
Reviewer: Roni Even
Review Date:2014-4-3
IETF LC End Date: 2014-4-7
IESG Telechat date: 
 
Summary: This draft is ready for publication as Standard track RFC.
 
 
Major issues:
 
Minor issues:
 
 
Nits/editorial comments:
In section 1 first paragraph request packet to any another node 
 
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Gen-ART LC review of draft-ietf-pwe3-p2mp-pw-requirements-07.txt

[Adrian Farrel]

Hi Brian,

 Minor issues:
 -
 
 The document is scoped for MPLS substrates, but I see very little in it that
 requires MPLS. Archtecturally, it is quite general. Was there any 
 consideration of making it applicable to a non-MPLS substrate?
 
  3.4.7.  Scalability
 
The solution SHOULD scale at least linearly with the number of Leaf
PEs.
 
 I think this should be at worst linearly.

I put in an RFC Ed Note for the second point, thanks.
I leave it to the authors to respond on the first point.

Cheers,
Adrian


 


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

Re: [Gen-art] Gen-art telechat review of draft-ietf-mpls-tp-psc-itu-03.txt

[Adrian Farrel]

Hi Elwyn,

  I understand from the document editor that there is a revision in waiting to
be
  posted that clears up some remaining nits from your review.
 I haven't seen this as yet, nor the psc-updates new version.

PSC-updates just posted (got stuck in a tools snafu).
Update to this I-D is pending until after IESG evaluation completes.

 I was trying to capture essentially two points:
 - As it stands this doc both introduces capabilities/modes and provides
 a definition of one new mode as well as redefining RFC 6378 as providing
 a basic mode.  In its introductory function I felt it needed to be
 explicit that if you in future wanted a new combination of capabilities
 maybe using some additional extra capabiliies then you need to specify
 some extra mode in another doc that tells you the combination of bits in
 the TLV for the new mode.  OK, there might never be any other modes but
 I was told that wasn't the original plan, but I don't understand why it
 isn't helpful to be explicit here.

OK. I was distracted by the words in your proposed text :-)
  Only combinations of capabilities specified by modes will be
  supported by implementations.
I read this to mean that implementations *of*this*specification* would reject
combinations of capabilities that were not those specified in the two modes
described here.
My reaction was to say: but the text describes this in great detail.

Now I see what you are saying with respect to capabilities so, we could update
the last three paragraphs of the Introduction:
OLD
   This document introduces capabilities and modes.  A capability is an
   individual behavior.  The capabilities of a node are advertised using
   the method given in this document.  A mode is a particular
   combination of capabilities.  Two modes are defined in this document:
   PSC mode and Automatic Protection Switching (APS) mode.

   This document describes the behavior, the priority logic, and the
   state machine of the PSC protocol when all the capabilities
   associated with the APS mode are enabled.  The PSC protocol behavior
   for the PSC mode is as defined in [RFC6378].

   This document updates [RFC6378] by adding a capability advertisement
   mechanism.  It is recommended that existing implementations of the
   PSC protocol be updated to support this capability.  Backward
   compatibility with existing implementations is described in
   Section 9.2.1.
NEW
   This document introduces capabilities and modes.  A capability is an
   individual behavior.  The capabilities of a node are advertised using
   the method given in this document.  A mode is a particular
   combination of capabilities.  Two modes are defined in this document:
   PSC mode and Automatic Protection Switching (APS) mode.  Other modes
   may be defined as new combinations of the capabilities defined in
   this document or through the definition of additional capabilities. 
   In either case, the specification defining a new mode will be 
   responsible for documenting the behavior, the priority logic, and the
   state machine of the PSC protocol when the set of capabilities in the
   new mode are enabled.

   This document describes the behavior, the priority logic, and the
   state machine of the PSC protocol when all the capabilities
   associated with the APS mode are enabled.  The PSC protocol behavior
   for the PSC mode is as defined in [RFC6378].

   This document updates [RFC6378] by adding a capability advertisement
   mechanism.  It is recommended that existing implementations of the
   PSC protocol be updated to support this mechanism.  Backward
   compatibility with existing implementations that do not support this
   mechanism is described in Section 9.2.1.

   Implementations are expected to be configured to support a specific
   set of capabilities (a mode) and to reject messages that indicate the
   use of a different set of capabilities (a different mode). Thus, the
   capabilities advertisement is not a negotiation, but a verification
   that peers are using the same mode.
END

 - I had understood from an email exchange with Huub that the authors had
 the concept that PSC messages with duff values (such as wrong lengths)
 would be picked off as 'invalid messages' and never make it to the main
 protocol engine (I assume that this will be addressed in the
 psc-updates).  Huub seemed to imply that a message with a set of
 capability bits that did not match a mode understood by the node would
 be treated as an invalid message rather than triggering the operator
 intervention.  This seemed sensible so that the alarm would only be

 triggered if an operator acciedentally reconfigured a different mode.

Implementations can fiddle with their alarm thresholds. It is likely that an
implementation that has never talked will raise a flag at once; that an
implementation might soak an individual event; and that an implementation could
track soak-avoiding flip-flops. However, I don't believe in telling people 

Re: [Gen-art] Gen-art telechat review of draft-ietf-mpls-tp-psc-itu-03.txt

[Adrian Farrel]

Hi Elwyn,

Thanks for your pursuit of excellence.

I understand from the document editor that there is a revision in waiting to be
posted that clears up some remaining nits from your review.

However, in line...

 Summary:
 Almost ready.  There are a couple of points which I raised at Last Call
 and discussed with the authors and others both by email and f2f in
 London that are not resolved.  These point revolve around being rigorous
 about wire encoding, clarifying error behaviour and being definite that
 implementations support modes as specfic combinations of capabilities so
 that arbitrary capability combinations are not allowed and result in
 invalid protocol messages.
 
 Major Issues:
 
 Minor Issues:
 s1: From my discussions with the authors and others associated with this
 document, it is my understanding that the intention is that only
 combinations of capabilities specified by modes should be legal and
 hence that implementations would support modes rather than arbitrary
 sets of capbilities. I think it would be worth being more explicit about
 this.  This would answer my comments at Last Call that it was unclear
 whether other combinations were allowed and would make it clear that a
 message that arrived with a corrupted bit in the flags field was
 definitely malformed.  I suggest adding the following text to para 16 of
 s1 (starts This document introduces capabilities and modes.) before
 the last sentence:
Only combinations of capabilities specified by modes will be
supported by implementations.

While this is true, it is also not helpful!
Any combination of capabilities (these five and any of the future
nearly-infinite number of capabilities that can be represented in the bit field)
could be specified as supported (i.e. as a mode) in the future.
There are two points of note:
1. Only two modes are currently defined
2. Any future mode must be specified in combination with the state machines for
the mode.

A message that is received containing a set of capabilities (i.e. a mode) not
supported by the receiver would be rejected. See Section 9.1.1. That is, this is
not a negotiation. This is a verification that both speakers are operating in
the same mode.

For future compatibility, there is no distinction between a corrupted set of
capability bits and an unknown mode.

 Nits/Editorial Comments:
 
 s4.4, para 1:
 OLD:
 When the modified priorities specified in this document is in use,..
 NEW:
 When the modified priorities specified in this document are in use,..
 (or maybe better:)
 When the modified priority order specified in this document is in use,..
 
 s7.3 et seq: The term selector bridge is introduced without
 definition.  I suspect it is a piece of jargon I am supposed to know but
 I think a reference would help.

Yes, it is a piece of standard terminology in protection switching. I'm sure the
authors can find a reference.

 s9.1: RFC 6378 doesn't define the encoding of the TLV type and TLV
 length fields, so it needs to be done here (Unsigned integers). It also
 doesn't define encoding of the overall TLV length field in
 the PSC header.  This may be thought to be 'obvious' but there is no
 default specified in IETF documents.

This is being fixed in draft-ietf-mpls-psc-updates that updates 4368. New
revision about to be posted before IETF last call.

 s9.1: Both RFC6378 and this document are incomplete as regards
 specifying what constitutes an invalid protocol message.  In particular
 there is no discussion of behaviour if correctly formed but unrecognized
 TLVs are received.  Do these make the message invalid or should they be
 ignored?

This should be included in draft-ietf-mpls-psc-updates as well.

 s9.1.1 and s12:
 In s12 it is stated (similar wording in s9.1.1):
 o  If the Capabilities TLV mismatches, the node MUST alert the
operator and MUST NOT perform any protection switching until the
operator resolves the mismatch in the Capabilities TLV.
 Having discussed the situation with the authors and others, I understand
 that there are circumstances, depending on the underlying transport,
 that bit errors might not be detected and hence that there is a small
 probability that corrupt PSC messages may be propagated up to the
 protocol machine.  At present there is no explicit statement that a
 corrupted flag word would be trapped as an invalid protocol message
 (this seems to be the intention) rather than triggering this operator
 alert.  I think that the best that can be done is specify that a PSC
 protocol message MUST have the flags for a recognized mode set exactly
 and otherwise it will be treated as an invalid message.  The wording in
 s9.1.1 and s12 would then catch an inadvertent reconfiguration.  I
 suggest adding the following to s9.1.1:
Any PSC message that has a combination of capability bits set that
does not correspond to a defined mode will be treated as an invalid
message and ignored.

This is plain wrong!
The receiving device is 

Re: [Gen-art] Gen-art LC review: draft-mahalingham-dutt-dcops-vxlan-08

[Adrian Farrel]

Thanks Robert,
 
I also noted some of these process concerns as shepherding AD, but took over the
document half way through IETF last call. I am currently in discussion with the
authors about the best way forward.
 
Cheers,
Adrian
 
From: ietf [mailto:ietf-boun...@ietf.org] On Behalf Of Robert Sparks
Sent: 20 March 2014 21:35
To: General Area Review Team; i...@ietf.org;
draft-mahalingham-dutt-dcops-vx...@tools.ietf.org
Subject: Gen-art LC review: draft-mahalingham-dutt-dcops-vxlan-08
 
I am the assigned Gen-ART reviewer for this draft. For background on 
Gen-ART, please see the FAQ at 

 http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq
http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq. 

Please resolve these comments along with any other Last Call comments 
you may receive. 

Document: draft-malingham-dutt-dcops-vxlan-08
Reviewer: Robert Sparks
Review Date: 20 Mar 2014
IETF LC End Date: 24 Mar 2014
IESG Telechat date: not yet scheduled for a telechat

Summary: This document is not ready for publication as an Experimental IETF
Stream RFC

(Apologies to the everyone on the long list of authors - this review is
primarily about process, but I do have some comments for you below.)

To the AD and shepherd: Why is the proposed status Experimental and not
Informational?
The text in the shepherd writeup provides a strong motivation for Informational,
but not Experimental.

I understand the concern that led to the inclusion of the last sentence of the
abstract and the first part of the introduction
( The IETF consensus on this RFC represents consensus to publish this memo,
and not consensus on the text itself.), but
this sentence does not address that concern.

If you are wanting to document what exists so that other documents can talk
meaningfully about it (as the writeup suggests),
please use Informational, and replace the sentence with an adaptation of  the
bulk of the answer to question 1 in the writeup.

If you are wanting more people to implement exactly what this document describes
and learn something from those implementations,
describe in the document what you're trying to learn and get IETF consensus that
the experiment is a good one to pursue.

The combination of Experimental and there is no consensus on the text in this
document is not a good one.

It might be easier to find the right way to bring the important parts forward if
you split the format definition and the sketch of protocol behavior into a
separate document from the motivation text at the beginning and the deployment
scenario discussions at the end.

To the authors:

This _is_ good information, and clearly has already been useful in IETF protocol
development discussions.
The number of documents referencing this one is a strong indicator of that:
 
http://datatracker.ietf.org/doc/draft-mahalingam-dutt-dcops-vxlan/referencedby/

http://datatracker.ietf.org/doc/draft-mahalingam-dutt-dcops-vxlan/referencedby/


The document reads clearly, and complete enough to inform a basic
implementation.
(Though I encourage you to be more explicit about what to do if you receive a
packet with the I flag set to 0).

Please reread each sentence that begins with Another and consider either
restructuring the sections where you have a string of them so that they are not
necessary, and simply removing the clause when you use it in isolation.

6.1 is out of place - please move it to be with the other places where you put
requirements on an implementation. I suggest it belongs at the end of section 4
or as its own section between section5 and section 6.
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Gen-art LC review of draft-ietf-mpls-tp-psc-itu-02.txt

[Adrian Farrel]

Sut mae, Elwyn-gwas,

[snip]

 Politics! OK - How about we add to either s9.1.1 or s9.2 something like:

I don't think it is politics at all, and I don't really like that Huub
referenced this as IETF and ITU-T since both documents are IETF standards track
work.

There are some people who want to deploy one set of options (the empty set) and
they have an RFC.
There is another set of people who want to deploy a different set of options
(all 5 of them) and they will have this RFC.

Only combinations of capabilities specified by a mode are allowed.
Capability TLVs with other combinations will be treated as invalid
PSC messages.

But this is not true.

What we have is:
A node knows which options it supports, and those options are expressed as
bundles (modes).
A node that tries to communicate with you must offer a set of options (a mode).
Either you support the mode or you don't.
If you support it, off you go.
If you don't support it, you reject the message saying unsupported as
described in this document.

The message that offers a different set of options (i.e. a different mode) is
not invalid, it is just that you don't understand it. You can't accept it
because you don't know how to behave in that mode.

OTOH, when someone writes the new RFC describing that mode, you might enhance
your implementation to support it as well.

(Hint: it really helps to think in modes. A mode is expressed as a bit-flag with
plenty-bits of which five currently have meaning.)

I agree with you that there is some distinction to be made between invalid
message and protocol error.
But no valid message does not mean protocol error or invalid message was
received. It is a composite of possibilities that reflects the negation of
receiving a message that was small and perfectly formed.

Ciao,
Adrian

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

Re: [Gen-art] Gen-ART LC review of draft-ietf-mpls-special-purpose-labels-05

[Adrian Farrel]

Hi Roni,

Thanks for taking the time.

 Minor issues:
 1. In section 3.2 (a):  I noticed that the policy to update the registry
according
  to section 5 is standard action so it should be the same here since this is
an
 update to the registry.

Hmmm, but I don't think so.
Section 5 (and the existing registry) define the procedures to be used for
assigning new values from a namespace per 5226. Procedures for
retiring/deprecating values are rarely, if ever, documented and do not need to
follow the same rules as are used for assignments.

That said, I think I can see some value in symmetry. but it seems a bit OTT to
have a Standards Track RFC saying this code point is not used. What is certain
(and we appear to agree on this) is that IETF consensus is needed (presumably as
tested by IETF last call on the relevant I-D).

Since we disagree, but my disagreement is not too strong, I will be guided by
the IESG (and specifically our sponsoring AD) as to whether to change:
OLD
   An RFC with at
   least Informational status is required.
NEW
  A Standards 
  Track RFC is required.
END

 Nits/editorial comments:
 1. In section 3 last sentence “This answer to this” should be “The ..”

Ack

 2. In section 3.2 item c you have “for for”

Ack

Cheers,
Adrian

___
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-mpls-tp-p2mp-framework-05

[Adrian Farrel]

Hi Russ,

Thanks for the review.

 Question:
 
 Should this document be an update to the MPLS-TP Framework (RFC 5921)?
 I am not sure.  RFC 5921 does make it clear that it covers only point-
 to-point transport paths.  The answer may be further complicated by
 the fact that RFC 5921 is joint work with the ITU-T.

I don't think so.
That is, it is perfectly acceptable to build a P2P MPLS-TP system and that
system could be built on protocol solutions that do not include P2MP support.

As you say, 5921 explicitly says:

   This document defines the subset of the MPLS-TP applicable in general
   and to point-to-point transport paths.  The remaining subset,
   applicable specifically to point-to-multipoint transport paths, is
   outside the scope of this document.

...so an updates relationship would render this statement doubtful.

I'm pretty comfortable with the documents being separate.

 Other Comments:
 
 In the first sentence of Section 1, please define MPLS-TP as follows:
 OLD:
The Multiprotocol Label Switching Transport Profile is the ...
 NEW:
The Multiprotocol Label Switching Transport Profile (MPLS-TP) is ...

Sure.

 Please add TE-LSP to the terms defined in Section 1.2.

Sure.

 In Section 5.1, I cannot understand this sentence:
 
   Per [RFC6373], the definitions of P2MP, [RFC4875], and GMPLS
   recovery, [RFC4872] and [RFC4873], do not explicitly cover their
   interactions.
 
 I think that the references are getting in the way.  I think the
 message is: the definitions of P2MP and GMPLS recovery do not
 explicitly cover their interactions.  If I am correct, then some
 commas need to be removed.

Yes, you're right. And a minor rewrite could make this even clearer.

 The phrase MPLS Transport Profile appears many places, and it would
 be easier if they were replaces with MPLS-TP for consistency.

OK


___
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-ccamp-oam-configuration-fwk-11

[Adrian Farrel]

Thanks David,

Stored for future updates.

Adrian

 -Original Message-
 From: Black, David [mailto:david.bl...@emc.com]
 Sent: 30 December 2013 02:46
 To: General Area Review Team (gen-art@ietf.org); attila.tak...@ericsson.com;
 donald.fe...@alcatel-lucent.com; he...@huawei.com
 Cc: Black, David; adr...@olddog.co.uk; cc...@ietf.org; i...@ietf.org
 Subject: Gen-ART review of draft-ietf-ccamp-oam-configuration-fwk-11
 
 I am the assigned Gen-ART reviewer for this draft. For background on
 Gen-ART, please see the FAQ at
 
 http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq.
 
 Please resolve these comments along with any other Last Call comments
 you may receive.
 
 Document: draft-ietf-ccamp-oam-configuration-fwk-11
 Reviewer: David L. Black
 Review Date: December 29, 2013
 IETF LC End Date: January 5, 2014
 
 Summary: This draft is basically ready for publication, but has nits that
 should be fixed before publication.
 
 This draft describes the GMPLS framework for signaling OAM configuration,
 and specifies additional RSVP elements to support that signaling.  Knowledge
 of RSVP, and specifically RSVP-TE is assumed; beyond that, the draft is
 complete, although it is very detailed - see editorial comment below on
 Section 3.
 
 Nits/editorial comments:
 
 Sections 3.1-3.3 dive into the details very quickly.  They would be easier to
 understand if there was an overview paragraph near the start of Section 3 that
 describes the roles of the two ADMIN_STATUS flags and the two LSP Attributes
 flags in OAM configuration (establishment, change/adjustment, deletion) before
 the current text that contains the details of RSVP message processing.
 
 There are a number of instances of (IANA to assign) in section 4 that the
 RFC Editor will need to remove - an RFC Editor note to that effect should
 be inserted at the start of Section 4.
 
 Section 4.5 is necessarily incomplete on P2MP considerations, because (as
 it says) P2MP OAM mechanisms are very specific to the data plane technology.
 It would be helpful if section 4.5 contained language indicating what a
 specific data plane specification should include to completely specify
 P2MP OAM configuration for that data plane.
 
 idnits 2.13.01 didn't find anything that needs attention.
 
 Thanks,
 --David
 
 David L. Black, Distinguished Engineer
 EMC Corporation, 176 South St., Hopkinton, MA  01748
 +1 (508) 293-7953 FAX: +1 (508) 293-7786
 david.bl...@emc.com    Mobile: +1 (978) 394-7754
 

___
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-isis-rfc1142-to-historic-00

[Adrian Farrel]

Thanks,
I added an RFC editor note.

Adrian

 From: Mike Shand
 Sent: 18 December 2013 14:24:51 (UTC) Dublin, Edinburgh, Lisbon, London
 To: Les Ginsberg (ginsberg); Romascanu, Dan (Dan); gen-art@ietf.org
 Cc: draft-ietf-isis-rfc1142-to-historic@tools.ietf.org
 Subject: Re: Gen-ART review of draft-ietf-isis-rfc1142-to-historic-00
 
 I agree.
 
  Mike
 
 On 17/12/2013 14:52, Les Ginsberg (ginsberg) wrote:
  Dan -
 
  Thanx for the review.
  I have no objection to your suggestion. I would hope this change can be done
 by the RFC Editor.
 
  Les
 
 
  -Original Message-
  From: Romascanu, Dan (Dan) [mailto:droma...@avaya.com]
  Sent: Tuesday, December 17, 2013 5:35 AM
  To: gen-art@ietf.org
  Cc: draft-ietf-isis-rfc1142-to-historic@tools.ietf.org
  Subject: Gen-ART review of draft-ietf-isis-rfc1142-to-historic-00
 
 
  I am the assigned Gen-ART reviewer for this draft. For background on Gen-
 ART,
  please see the FAQ at
 
  http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq.
 
  Please resolve these comments along with any other Last Call comments you
 may
  receive.
 
  Document: draft-ietf-isis-rfc1142-to-historic-00
  Reviewer: Dan Romascanu
  Review Date: 12/17/13
  IETF LC End Date: 12/24/13
  IESG Telechat date:
 
  Summary: Ready
 
  Major issues:
 
  Minor issues:
 
  It may be more cautious refer to the 'latest available' version of the
IS-IS
  standard as we cannot be completely sure that the Second Edition will also
be
  the very last one. Suggested change in Section 1:
 
  OLD:
 
  All references to IS-IS should be to ISO/IEC 10589:2002, Second
  Edition and RFC 1142 is only of historic interest.
 
  NEW:
 
  All references to IS-IS should be to the latest edition of the IS-IS
  standard (currently ISO/IEC 10589:2002, Second
  Edition) and RFC 1142 is only of historic interest.
 
  Nits/editorial comments:
 
 
 
 
 


___
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-ccamp-gmpls-g709-framework-14

[Adrian Farrel]

Thanks Russ!

 Minor Concerns:
 
 In section 3, there is a discussion that includes ODU0, ODU2e, and ODU4,
 but these terms are not defined in the paragraph or in the terminology
 section.  I realize that these are ODUj values, but ODUflex is an ODUj,
 and it is included in the terminology section.

 I think these are covered in the Terminology section in the two paragraphs 

   LO ODU: Lower Order ODU. The LO ODUj (j can be 0, 1, 2, 2e, 3, 4,
   flex.) represents the container transporting a client of the OTN that
   is either directly mapped into an OTUk (k = j) or multiplexed into a
   server HO ODUk (k  j) container.

   HO ODU: Higher Order ODU. The HO ODUk (k can be 1, 2, 2e, 3, 4.)
   represents the entity transporting a multiplex of LO ODUj tributary
   signals in its OPUk area.

For ease of searching, I suppose this could read

OLD
(j can be 0, 1, 2, 2e, 3, 4, flex.)
NEW
(j can be 0, 1, 2, 2e, 3, 4, flex yielding ODU0, ODU1, ODU2e, ODU3, ODU4, and
ODUflex)
END

Seems a bit excessive, but if it would help the reader.

 In section 3.1, OCh needs to be defined or at least expanded.

OCh is found in the last paragraph of Section 1

   For the purposes of the control plane the OTN can be considered as
   being comprised of ODU and wavelength (Optical Channel (OCh)) layers.
   This document focuses on the control of the ODU layer, with control
   of the wavelength layer considered out of the scope. Please refer to
   [RFC6163] for further information about the wavelength layer.

 In section3.1.2.1, please expand MSI on first use.

MSI is in the terminology section 

   MSI: Multiplex Structure Identifier

 Editorial:
 
 In section 8: s/not requests/no requests/

Yes.

Cheers,
Adrian

___
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-ccamp-assoc-ext-04

[Adrian Farrel]

thnx

I was hoping for a routing directorate review (Dimitri) but it hasn't showed

Give it a couple of days and then we will move on w/o it. If the review comes in
late we will cross the bridge.

Aiming for telechat on 9/13

A

 -Original Message-
 From: Lou Berger [mailto:lber...@labn.net]
 Sent: 30 August 2012 15:28
 To: Adrian Farrel
 Cc: draft-ietf-ccamp-assoc-ext@tools.ietf.org; gen-art@ietf.org;
i...@ietf.org
 Subject: Fwd: Re: Gen-ART review of draft-ietf-ccamp-assoc-ext-04
 
 
 
 Adrian,
  Shout (or change the ID state) when you're ready for the update to
 be submitted.
 
 Thanks,
 Lou
  Original Message 
 Subject:  Re: Gen-ART review of draft-ietf-ccamp-assoc-ext-04
 Date: Thu, 30 Aug 2012 10:25:19 -0400
 From: Lou Berger lber...@labn.net
 To:   Peter Yee pe...@akayla.com
 CC:   draft-ietf-ccamp-assoc-ext@tools.ietf.org, gen-art@ietf.org,
 i...@ietf.org
 
 
 
 Peter,
   Thank you for the comments.  Please see below for responses in-line.
 
 
 On 8/29/2012 11:31 PM, Peter Yee wrote:
  I am the assigned Gen-ART reviewer for this draft. For background on
  Gen-ART,
  please see the FAQ at 
  http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq
 
  Document: draft-ietf-ccamp-assoc-ext-04
  Reviewer: Peter Yee
  Review Date: Aug-28-2012
  IETF LC End Date: Aug-29-2012
  IESG Telechat date: Not known
 
  Summary: This draft is basically ready for publication, but has nits that
  should be
  fixed before publication. [Ready with nits.]
 
  This document provides extensions to the scope of use of the RSVP
  ASSOCIATION
  object as well as providing an extended ASSOCIATION object capable of
  handling
  a longer Association ID.
 
  Nits:
 
  In the last example (Symmetric NAT), last sentence: mechanisms -
  mechanism.
 
  Section 2, 4th paragraph (the replacement text): the the - the.
 
  Section 3.2.1, 2nd paragraph, 1st sentence: are - is.  Alternatively,
  you
  could change format to formats.
 
  Section 3.2.2, 1st sentence: apply - applies.
 
  Section 4.2, 1st sentence: a - an in both occurrences.
 
  Section 4.2, last paragraph, 2nd sentence: a - an.
 
 
 Thank you!
 
  Questions:
 
  These are questions you may wish to answer but the draft is acceptable
  without response:
 
  1) In Section 4.2, 4th bullet, is there any implied relationship between the
  Extended Association ID and the Association ID?  Or are they independent
  values that simply must be matched?
 
 The latter (as the text says.)
 
 
  2) Section 4.2, 5th bullet, you make a first and only mention of padding
  bytes.
  Are you using a specific method for generating these padding bytes or are
  they random?
 
 No, as it is completely up to the creator of the object to use it
 consistently.
 
  Given the matching requirement on ASSOCIATION objects,
  it might be best to specify the padding generation so that if the object is
  regenerated, it will still be matched by intermediary nodes.  I've presumed
  that the padding bytes are for meeting the 4-byte multiple requirement,
  but I don't know if implementations would ever be free to regenerate the
  object for subsequent transmissions of that object.
 
 I'll add , without modification, to the last sentence of 3.1.2 and 3.2.2.
 
 Thank you for the comments!
 
 Lou
 
 


___
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-pce-hierarchy-fwk-04

[Adrian Farrel]

Got it, thauks.
Adriau


 -Original Message-
 From: Martin Thomson [mailto:martin.thom...@gmail.com]
 Sent: 23 August 2012 22:35
 To: draft-ietf-pce-hierarchy-fwk@tools.ietf.org; gen-art@ietf.org
 Subject: Gen-ART review of draft-ietf-pce-hierarchy-fwk-04
 
 I am the assigned Gen-ART reviewer for this draft. For background on
 Gen-ART, please see the FAQ at
 
 http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq .
 
 Please resolve these comments along with any other Last Call comments
 you may receive.
 
 Document: draft-ietf-pce-hierarchy-fwk-04
 Reviewer: Martin Thomson
 Review Date: 2012-09-23
 IETF LC End Date: 2012-08-24
 IESG Telechat date: -
 
 Summary:
 This document is ready for publication as an Informational RFC.
 
 Nits:
 I think that you probably meant to have the second letter of
 Antonymous System rotated 180 degrees.  This appears several times.

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

Re: [Gen-art] Gen-ART LC review of draft-ietf-ccamp-rfc5787bis-05

[Adrian Farrel]

Thanks Roni,
Good catches.
Adrian
 
From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Roni
Even
Sent: 13 August 2012 22:07
To: draft-ietf-ccamp-rfc5787bis@tools.ietf.org
Cc: gen-art@ietf.org; i...@ietf.org
Subject: Gen-ART LC review of draft-ietf-ccamp-rfc5787bis-05
 
I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART,
please see the FAQ at http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq.
 
Please resolve these comments along with any other Last Call comments you may
receive.
 
Document: draft-ietf-ccamp-rfc5787bis-05.
Reviewer: Roni Even
Review Date:2012-8-12
IETF LC End Date: 2012-8-17
IESG Telechat date:
 
Summary: This draft is almost ready for publication as a standard track RFC.
 
 
Major issues:
 
Minor issues:
In section 6.1  If specified more than once, instances preceding the first will
be ignored and condition SHOULD be logged for possible action by the network
operator.  I am not sure what is meant by preceding the first.
 
 
Nits/editorial comments:
 
1.  The following note appears in section 10.1, 10.2 and 10.3. Note that
the same values for the Inter-RA Export Upward sub-TLV and the Inter-RA Export
Downward Sub-TLV MUST be used when they appear in the Link TLV, Node Attribute
TLV, and Router Address TLV. - why not have it in section 10 before section
10.1.
2.  I saw in appendix  B that one of the changes from RFC 5787 was to
clarify the terminology before defining extensions, I would have found it easier
to read if the ASON hierarchy and the relation to OSPF in section 2 were
presented in figures. This was more an issue to me as a reader not familiar with
the terminology and I would like to think that the more familiar reader will not
have problem.
 
 
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Gen-ART LC Review of draft-ietf-ccamp-assoc-info-03

[Adrian Farrel]

Thanks Ben.

All entered as RFC Editor notes except the last one...


 -- 2.2, paragraph 5: ... definition of the Association ID, which is (quoting
 [RFC4872]):
 
 The quoted text this refers to is more of a description of use than a
definition.

I agree, but don't think any change is needed. The full text here is...

   They
   also share the same definition of the Association ID, which is
   (quoting [RFC4872]):

  The Association ID MUST be set to the LSP ID of the LSP being
  protected by this LSP or the LSP protecting this LSP.  If unknown,
  this value is set to its own signaled LSP ID value (default).
  Also, the value of the Association ID MAY change during the
  lifetime of the LSP.

Thus which is means and here is a description.

If you feel really strongly we can probably work something out. 

A

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

Re: [Gen-art] Gen-ART review of draft-betts-itu-oam-ach-code-point-04

[Adrian Farrel]

All (copying the IESG),

I do sincerely welcome all reviews of all I-Ds that I sponsor or where I am the
responsible AD. I even mainly welcome them when I am an author.

However, when Directorate or Review Team reviews come in so long after the end
of IETF Last Call, and especially when they arrive after the I-D has been
updated to address last call comments, I do grind my teeth a bit.

Additionally, when Directorate or Review Team reviews are repeated and bring up
new issues (even minor ones) that were in the document at the time of the first
review but didn't warrant a comment at that time, I feel like I am being asked
for a rock.

Anyway, thanks Chris for caring enough to read the document for a second time,
and see in line for answers.

 Summary: The draft is ready for publication, with a couple of editorial nits.

 Major issues: -

 Minor issues: -
 
 Nits/editorial comments:

 (The comments also applied to the -03 version, and I apologize for
 not bringing them up when I reviewed that version.)

 - General: G-ACh is mentioned throughout the document, but only in 
 section 4 is there a reference to RFC 5586. I suggest to add a reference
 on first occurrence at least to section 1. It would probably be good also
 in section 3.

Added RFC Editor note

Section1 para 2

s/Generic Associated Channel (G-ACh) Type/Generic Associated Channel (G-ACh)
Type [RFC5586]

 - Section 1: What is the purpose of the last paragraph, talking about IETF
  Experts not agreeing? For someone who has not followed the work, it
  seems as little strange.

I am not sure how to answer you without giving a long and detailed history of
this work covering the last four years. Such a history is without doubt
contentious.

You might read the referenced I-D for an alternate viewpoint. Or you might speak
privately with any number of people involved with this work.

In summary, this text is necessary to obtain consensus on the publication of
this document, and is agreed by the document author.

 - Section 3: The text says The G-ACh Type assigned by this document. I guess
 it would be better to say e.g. based on this document.

Well, of course, based on is also not right :-)

One might say, ...assigned by the IANA as a result of the request contained in
this document.
To me that is over-baked. What is more, during late-stage IANA processing, the
request text in I-Ds is replaced with action text that describes what action
IANA has taken.

Common usage is that a document that is approved for publication and that makes
an IANA request is the document that made the assignment or created the
registry.

So we won't make any change for that.

Cheers,
Adrian

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

Re: [Gen-art] Gen-ART review of draft-betts-itu-oam-ach-code-point-03

[Adrian Farrel]

Thanks Christer,

 I am the assigned Gen-ART reviewer for this draft. For background
 on Gen-ART, please see the FAQ at 
 http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq.
 
 Please wait for direction from your document shepherd or AD
 before posting a new version of the draft.
 
 Summary: The draft is ready for publication, with a couple of minor
 editorial nits.
 
 Nits/editorial comments:
 
 - Section 1: Please expand 'MPLS-TP' and 'MPLS' when first used,
and add a reference to where MPLS-TP and MPLS are defined.

 - Section 1: Please expand ACH when first used. 
 
Yes to all of this except that MPLS is a well-known acronym in the RFC
Editor's list.

Cheers,
Adrian

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

[Gen-art] Hello Russ ? [RE: Russ Housley's Discuss on draft-ietf-pim-port [Was: Gen-ART Telechat review of draft-ietf-pim-port-09.txt]]

[Adrian Farrel]

Russ,

Pingy pingy ping.

I've added to the informal agenda for 1/12/12

A

 -Original Message-
 From: Adrian Farrel [mailto:adr...@olddog.co.uk]
 Sent: 03 January 2012 22:08
 To: 'Stig Venaas'; 'Russ Housley'
 Cc: 'Suresh Krishnan'; 'draft-ietf-pim-port@tools.ietf.org'; 'General Area
 Review Team'
 Subject: RE: Russ Housley's Discuss on draft-ietf-pim-port [Was: Gen-ART
 Telechat review of draft-ietf-pim-port-09.txt]
 
 In the hope that the change (acceptable to Suresh) will work for Russ, I have
 entered the RFC Editor note.
 
 A
 
  -Original Message-
  From: Stig Venaas [mailto:sven...@cisco.com]
  Sent: 03 January 2012 17:27
  To: Russ Housley
  Cc: Suresh Krishnan; adr...@olddog.co.uk; draft-ietf-pim-
 port@tools.ietf.org;
  General Area Review Team
  Subject: Re: Russ's Discs on draft-ietf-pim-port [Was: Gen-ART Telechat
review
 of
  draft-ietf-pim-port-09.txt]
 
  Russ, I've sent 3-4 emails in December asking if your discuss can be
  resolved, but no response. I hope you can respond now.
 
  Stig
 
  On 11/28/2011 11:07 AM, Stig Venaas (svenaas) wrote:
   On 11/29/2011 10:18 AM, Suresh Krishnan wrote:
 Hi Stig,


 On 11/28/2011 12:59 PM, Stig Venaas wrote:
 Please note that the Connection ID AFI in the PORT Hello Option
   does not
 need to match the address family of PIM Hello message that carries
it.
 e.g. an IPv6 PIM Hello message could contain a PORT Hello Option with
a
 TCP Connection ID AFI of 1 (IPv4).

 While I am OK with this text, wouldn't it be better to add this to 3.1
 and 3.2 where we formally define the hello options?

 My proposal would be:

 End of 3.1:

 OLD:
 TCP Connection ID AFI: The AFI value to describe the address-family
 of the address of the TCP Connection ID field. When this field is
 0, a mechanism outside the scope of this document is used to
 obtain the addresses used to establish the TCP connection.

 NEW:
 TCP Connection ID AFI: The AFI value to describe the address-family
 of the address of the TCP Connection ID field. Note that this
 value does not need to match the address-family of the PIM Hello
 message that carries it. When this field is 0, a mechanism
 outside the scope of this document is used to obtain the
 addresses used to establish the TCP connection.

 End of 3.2:

 OLD:
 SCTP Connection ID AFI: The AFI value to describe the address-
 family of the address of the SCTP Connection ID field. When this
 field is 0, a mechanism outside the scope of this document is used
 to obtain the addresses used to establish the SCTP connection.

 NEW:
 SCTP Connection ID AFI: The AFI value to describe the address-
 family of the address of the SCTP Connection ID field. Note that
 this value does not need to match the address-family of the PIM
 Hello message that carries it. When this field is 0, a mechanism
 outside the scope of this document is used to obtain the
 addresses used to establish the SCTP connection.

 What do you think?

 This works great.
  
   Great, I hope we can then just add a note for the editor, and that the
   discuss can be cleared...
  
   Stig
  

 Thanks
 Suresh
  

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

[Gen-art] Russ's Discs on draft-ietf-pim-port [Was: Gen-ART Telechat review of draft-ietf-pim-port-09.txt]

[Adrian Farrel]

Hi,

This thread seems to have dried up. AFAICS there is no change needed to the
document.

Anything further to say before I ask Russ to clear his Discuss?

Thanks,
Adrian

 -Original Message-
 From: Stig Venaas [mailto:s...@venaas.com]
 Sent: 08 November 2011 04:02
 To: Suresh Krishnan
 Cc: draft-ietf-pim-port@tools.ietf.org; General Area Review Team; Russ
 Housley
 Subject: Re: Gen-ART Telechat review of draft-ietf-pim-port-09.txt
 
 On 07.11.2011 15:39, Suresh Krishnan wrote:
  Hi Stig,
 
  On 11/03/2011 02:28 PM, Stig Venaas wrote:
  Thanks for the review, see below.
 
  On 11/1/2011 4:18 PM, Suresh Krishnan wrote:
  I have been selected as the General Area Review Team (Gen-ART)
  reviewer for this draft (for background on Gen-ART, please see
  http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).
 
  Please wait for direction from your document shepherd
  or AD before posting a new version of the draft.
 
  Document: draft-ietf-pim-port-09.txt
  Reviewer: Suresh Krishnan
  Review Date: 2011/11/01
  IESG Telechat date: 2011/11/03
 
  Summary: This document is almost ready for publication as an
  Experimental RFC but I have a few comments.
 
  Minor
  =
 
  Section 3.1
 
  * From my reading of the document, it is not clear whether we can have a
  node advertise multiple capability options of the same transport
  protocol (say PIM-over-TCP-Capable) in the same message. e.g. A dual
  stack node might want to advertise its capability to do both IPv4 and
  IPv6. Is this possible? If so, how?
 
  For PIM we generally (not just PORT) use Hello Options in IPv4 PIM
  Hello's for IPv4 capabilities and Hello Options in IPv6 PIM Hello's
  for IPv6 capabilities. The two are completely separate.
 
  If a router supports PORT for both IPv4 and IPv6, it will send one
  option in the IPv4 Hello, and another in the IPv6 Hello.
 
  In section 4 it says:
 
  The decisions whether to use PORT, which transport, and which
  Connection IDs to use are performed independently for IPv4 and
  IPv6. Thus, if PORT is used both for IPv4 and IPv6, both IPv4 and
  IPv6 PIM Hello messages MUST be sent, both containing PORT Hello
  options.
 
  I think this is pretty clear.
 
  That clarifies a bit, but I am still unclear as to how the protocol
  selection takes place. e.g. Does IPv6+SCTP take precedence over IPv4+TCP.
 
 As it says, it is done independently for IPv4 and IPv6. So in that case
 you would have IPv6 PIM using SCTP, while IPv4 PIM using TCP.
 
 You would only have connection sharing if IPv6 PIM and IPv4 PIM end up
 using the same transport and same end-point addresses. This is all in
 the document.
 
 
 
  Section 4.7
 
  * Section 4 talks about the router with the lower connection ID
  initiating the transport layer connection but this does not really map
  into the rules mentioned in Section 4.7. Specifically, I am not sure
  Rule 3 for Node A in Section 4.7 conveys the same intent as section 4.
 
  Note that we also allow doing connections on-demand. In that case they
  one with the higher address may open a connection. That is the reason
  for rule 3.
 
  See end of section 4.5 where it says:
 
  Note that for TCP, it is the router with the lower Connection ID that
  decides whether to open a connection immediately, or on-demand. The
  router with the higher Connection ID SHOULD only initiate a
  connection on-demand. That is, if it needs to send a Join/Prune
  message and there is no currently established connection.
 
  Do you still think something is not clear?
 
  The text only describes the when it is *acceptable* for a router with a
  higher connection ID to initiate a connection, not when it should
  *actually* do so. Specifically section 4.7 should cover this.
 
 It says SHOULD only initiate a connection on-demand. This means
 that it is initiated if a join/prune needs to be sent. I think this
 is clear enough, but note that this doesn't have to be very strict. It
 is unfortunate if the one with the higher ID always tries to initiate a
 connection, but there isn't much harm if it does. It wouldn't break
 anything.
 
 Stig
 
  Thanks
  Suresh

___
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-ccamp-attribute-bnf-02

[Adrian Farrel]

Hi,

There is already an RFC Editor Note saying...

Please edit for consistency:
The objects are called LSP Attributes and LSP Required Attributes

Let me know if anything else needs to be added.

Thanks,
Adrian

 -Original Message-
 From: Lou Berger [mailto:lber...@labn.net]
 Sent: 18 October 2011 22:56
 To: Vijay K. Gurbani
 Cc: draft-ietf-ccamp-attribute-...@tools.ietf.org; dbrung...@att.com; Adrian
 Farrel; General Area Review Team
 Subject: Re: Gen-ART review of draft-ietf-ccamp-attribute-bnf-02
 
 Vijay,
 
 Please see below.
 
 On 10/17/2011 5:18 PM, Vijay K. Gurbani wrote:
  I am the assigned Gen-ART reviewer for this draft. For background on
  Gen-ART, please see the FAQ at
  http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq.
 
  Please resolve these comments along with any other Last Call comments
  you may receive.
 
  Document: draft-ietf-ccamp-attribute-bnf-02
  Reviewer: Vijay K. Gurbani
  Review Date: Oct-17-2011
  IETF LC End Date: Not known.
  IESG Telechat date: Oct-20-2011
 
  Summary: This draft is ready as a Proposed Standard.
 
  Major issues: 0
  Minor issues: 2
  Nits/editorial comments: 3
 
  Minor:
  * S2: In the phrase, ... implementations must be capable ...
is this a normative MUST?
 
  * S3: In the phrase, ... implementations must be capable ...
is this a normative MUST?
 
 
 These are both in text quoted from RFC5420, so the comment applies to
 that RFC.  Clearly we can't change it in this document. (BTW usage of
 'must' as in the English/informative usage is still legitimate.)
 
  Nits:
  * Abstract: s/how LSP attribute are/how LSP attributes are/
 
 
 LSP Attributes is a term/name defined in RFC5420.
 
 This does point out that in three places in the document, the following
 is needed:
  s/LSP attributes/LSP Attributes
 
  * S1: Two LSP Attributes related objects ... --- This reads
funny.  Did you mean Two LSP Attribute related objects...?
This oversight, if indeed it is an oversight, is repeated else-
where in the document as well.
 
At other places (e.g., S3.2.1), you simply use LSP Attribute object.
So I am not sure which one is correct.
 
 
 good catch!  it should be:
 s/LSP Attribute/LSP Attributes
 
  * S2.1: s/LSP attributed related objects/LSP attributes related objects/
 or maybe LSP Attribute related objects?
 
 another good catch:
  s/LSP attributed/LSP Attributes
 
  - vijay
 
 Much thanks!
 
 Lou

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

Re: [Gen-art] Gen-ART Telechat review of draft-ietf-vrrp-unified-mib-10

[Adrian Farrel]

Hi Ben,

Thanks for the review.

 Minor issues:
 
 -- Section 7,  first paragraph: During the review of this document, It
emerged
 that there are different possible interpretations of [RFC5798]. The Authors of
 that document and the VRRP working group were unable to reach consensus on
 which interpretation is correct.
 
 That's rather unfortunate, since that RFC specifies the protocol this MIB is
_for_. I
 wish we could do better. From my limited knowledge here, I am agnostic as to
 whether the disagreement would make a substantive difference in the MIB. I put
 this in the minor section in hopes that it does not--but people more versed
in
 the protocol should think about this.

Yes, this is really unfortunate.

The WG (now closed) was unable to reach any firm conclusion. The authors of the
original spec were a bit vague and indecisive. 

We were left with no option other than for the authors of this document to:
- pick the interpretation they thought was most likely
- document the fact
- move on

My feeling is that the lack of decisiveness in the WG for an established
protocol (not widely deployed, but reasonably well implemented and deployed)
showed that this was not an important function in the protocol. In practice, it
did not matter which choice was made in the MIB module because no-one seemed to
care which choice was made in the protocol.

Thus, if VRRP was being advance on the protocol ladder, I would look for the
feature to be removed rather than for the issue to be resolved.

Cheers,
Adrian

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

Re: [Gen-art] Note Well applicability to bar BOFs

[Adrian Farrel]

I will strongly oppose the application of Note Well to bar BoFs. Bar BoFs are
(IMHO) outside the IETF process and do not constitute any part of it.

That we gently encourage people to have meetings in bars, restaurants, hotel
bedrooms, or saunas does not make them any more part of the IETF process.

When I talk to my friend in the corridor of an IETF gathering I am not covered
by the IPR rules. When I go to the bar and find I am redesigning IPv6 (again) I
am not covered by the IPR rules.

This is a Bad Idea. Please stop it!

Cheers,
Adrian

 -Original Message-
 From: iesg-boun...@ietf.org [mailto:iesg-boun...@ietf.org] On Behalf Of Lars
 Eggert
 Sent: 09 September 2011 17:03
 To: Jorge Contreras
 Cc: draft-eggert-successful-bar-bof@tools.ietf.org; gen-art@ietf.org
Review
 Team; IESG; Spencer Dawkins; Scott O. Bradner
 Subject: Re: Note Well applicability to bar BOFs
 
 Hi, Jorge,
 
 related to the ID on side meetings during the IETF week, during the gen-art
 review of this draft, Ben had the following question, and Spencer followed it
up:
 
 Ben said:
  -- Section 6 suggests side meetings should be (somehow informally) covered
 by NOTE WELL. I think this is a very dangerous suggestion. The rest of the
 document suggests that a side meeting has no official standing. That seems to
me
 to mean it's no different than a group of people who coincidentally
participate in
 the IETF having a dinner or bar meeting on any subject at any time. Or a
hallway
 conversation, for that matter. By the logic of this section, I can't really
figure out
 how informal a meeting would need to be before it no longer fell under NOTE
 WELL.
 
  In an informal meeting, the participants should be able to follow any IPR
policy
 they like. I can even imagine an informal meeting covered by an NDA, where the
 participants want to decide if they want to have further discussions of a
subject
 under IETSF IPR rules or not.
 
  I think the best we can hope to do is suggest that side meeting organizers
and
 participants be explicit with their expectations on IPR and confidentiality,
so there
 is less chance for down-stream surprises. If we want something stronger than
 that, then we really need to create a new category of official meeting.
 
 Spencer said:
  For what it's worth, I have the same question as Ben - if this guidance
applies to
 the kinds of informal meetings in restaurants and bars that the IESG is
 encouraging, even if they aren't publicized and aren't open to the community,
is
 there any way for two or more IETF participants to talk to each other, that's
NOT
 under NOTE WELL?
 
  I think it DOES make sense to say that the kinds of informal meetings the
IESG is
 discouraging - in IETF meeting rooms, with agendas, mailing lists,
presentations,
 attendee lists, and minutes - should include NOTE WELL notifications.
 
  But if I was sitting next to Adam Roach on a plane headed for the IETF
(which
 has happened before) when he was editor of GIN and I was chair of MARTINI
 (this last part did not), and we started talking about proposed changes to the
GIN
 draft, is that covered?
 
 Could you propose a rephrasing of the original text (see below) that would
clarify
 the issues they have raised?
 
 Thanks,
 Lars
 
 
 On 2011-2-28, at 19:33, Jorge Contreras wrote:
  Gonzalo -- thanks for the document context.  Here's my suggestion for
  Section 6:
 
  6.  Applicability of IPR Rules
 
  The IETF's rules regarding intellectual property are set out in BCP 78 and
  79.  Among other things, these rules provide that any Contribution to the
  IETF Standards Process (each as defined in the rules themselves) is
  licensed to the IETF Trust for the IETF's use in developing standards, and
  also requires disclosure of related patents and patent applications.  A
  Contribution is any submission to the IETF intended by the Contributor
  for publication as all or part of an Internet-Draft or RFC and any statement
  made within the context of an IETF activity.  Thus, the fact that a
  Contribution is made at one of the BOFs or other unofficial or
  semi-official events described in this document does not change or limit
  the applicability of the IETF's IPR rules.   If you have a question
  regarding the applicability of the IETF IPR rules in any specific context or
  to any specific activity, you should consult your attorney or make an
  inquiry to the IESG.
 
  Regards,
  Jorge


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

Re: [Gen-art] Note Well applicability to bar BOFs

[Adrian Farrel]

  When I talk to my friend in the corridor of an IETF gathering I am not 
  covered
  by the IPR rules. When I go to the bar and find I am redesigning IPv6 
  (again) I
  am not covered by the IPR rules.
 
 Actually, when you as an AD talk to your friend, doesn't Note Well
 apply? Unless by The IESG, or any member thereof on behalf of the IESG
 we understand that you're not always speaking on behalf of the IESG
 (which would be a reasonable interpretation, IMHO).

You mean, I hope, when I talk as an AD to my friend.

Otherwise I am going to have to be very careful when I talk to my wife.

I wonder if Note Well applies to IESG breakfast? I have a patent on a way of 
eating eggs while reporting on hot spots. I am prepared to license it, but will 
not grant free use (unless someone has a patent on eating pain au chocloat 
while drinking coffee and reading email that they want to exchange with me).

A



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

Re: [Gen-art] Note Well applicability to bar BOFs

[Adrian Farrel]

The IESG does not (any more, and in general) allocate meeting rooms for bar
BoFs.

But you may be right that if it does then the Note Well could be made to apply.

A

 -Original Message-
 From: david.bl...@emc.com [mailto:david.bl...@emc.com]
 Sent: 09 September 2011 17:58
 To: stpe...@stpeter.im; adr...@olddog.co.uk
 Cc: draft-eggert-successful-bar-bof@tools.ietf.org; gen-art@ietf.org;
 cntre...@gmail.com; s...@harvard.edu; i...@ietf.org; lars.egg...@nokia.com;
 david.bl...@emc.com
 Subject: RE: [Gen-art] Note Well applicability to bar BOFs
 
 I would argue that if the IETF has allocated an IETF meeting room during an
IETF
 meeting week for a Bar BOF, then the Note Well should apply to that Bar BOF
 courtesy of the IETF's involvement (i.e., the multiple occurrences of IETF
in this
 sentence).
 
 Such a policy might also serve as a useful source of backpressure to the
increasing
 number of Bar BOFs that are asking for IETF meeting rooms.
 
 Thanks,
 --David
 
 David L. Black, Distinguished Engineer
 EMC Corporation, 176 South St., Hopkinton, MA  01748
 +1 (508) 293-7953 FAX: +1 (508) 293-7786
 david.bl...@emc.com    Mobile: +1 (978) 394-7754
 
 
  -Original Message-
  From: gen-art-boun...@ietf.org [mailto:gen-art-boun...@ietf.org] On Behalf
 Of Peter Saint-Andre
  Sent: Friday, September 09, 2011 12:39 PM
  To: adr...@olddog.co.uk
  Cc: draft-eggert-successful-bar-bof@tools.ietf.org; gen-art@ietf.org;
'Jorge
 Contreras'; 'Scott O.
  Bradner'; 'IESG'; 'Lars Eggert'
  Subject: Re: [Gen-art] Note Well applicability to bar BOFs
 
  On 9/9/11 10:34 AM, Adrian Farrel wrote:
 
   When I talk to my friend in the corridor of an IETF gathering I am not
covered
   by the IPR rules. When I go to the bar and find I am redesigning IPv6
(again) I
   am not covered by the IPR rules.
 
  Actually, when you as an AD talk to your friend, doesn't Note Well
  apply? Unless by The IESG, or any member thereof on behalf of the IESG
  we understand that you're not always speaking on behalf of the IESG
  (which would be a reasonable interpretation, IMHO).
 
  Peter
 
  --
  Peter Saint-Andre
  https://stpeter.im/
 
 
  ___
  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 LC review of draft-ietf-mpls-p2mp-lsp-ping-16

[Adrian Farrel]

Alexey, hello.

Thanks for the review.

In line.

Adrian

 Minor issues:
 
  1.1. Design Considerations
 
As is described in [RFC4379], to avoid potential Denial of Service
attacks, it is RECOMMENDED to regulate the LSP Ping traffic passed to
the control plane.  A rate limiter should be applied to the
well-known UDP port defined for use by LSP Ping traffic.
 
 What is this port? Is mentioning of the port significant?

It is well-known, so you obviously don't need to ask :-)

The port number is in the IANA registry and can be seen in RFC4379 (the base
definition of LSP Ping) sections 4.3, 4.4, 6, and 7.

The port number is 3503

I don't think it needs to be mentioned here. In general, restating definitions
causes potential conflicts. It is far better to have a normative reference to
RFC 4379 for all elements of LSP Ping that are not changed by this document.

 3.1.2.1. Multicast LDP FEC Stack Sub-TLVs
 
Address Family
 
   Two octet quantity containing a value from ADDRESS FAMILY NUMBERS
   in [IANA-PORT] that encodes the address family for the Root LSR
   Address.
 
[IANA-PORT] IANA Assigned Port Numbers, http://www.iana.org
 
 Which IANA registry do you have in mind? Seeing a link would be helpful.

Yes. This is a typo.
We fixed it for you in -17

 3.2. Limiting the Scope of Responses
 
The P2MP Responder Identifier TLV only has meaning on an echo request
message.  If present on an echo response message, it SHOULD be
ignored.
 
 Are there known reasons for violating the SHOULD? I.e. what are the reasons
 for having multiple sub-TLVs in the first place?

Future extensibility.
There is a corner of the world that builds conformance testers and would
interpret a MUST statement here as preventing any extensions that used this TLV
on an echo response as being in violation of this spec. Therefore we would have
to respin this spec if/when we made such an extension.
Furthermore, it is harmless to this protocol to not ignore such a TLV.

Anyway, in response to Dave Harrington's Discuss, we will be re-examining all
uses of SHOULD with a view to tightening them or supplying an appropriate
MAY clause.

 3.2.2. Node Address P2MP Responder Identifier Sub-TLVs
 
The address in this Sub-TLV SHOULD be of any transit, branch, bud or
egress node for that P2MP LSP.
 
 Is the use of SHOULD correct here (instead of a MUST)? Are there any choices
 left if the SHOULD is violated?

The MAY clause can be added.

 3.5. Downstream Detailed Mapping TLV
 
   Downstream Detailed Mapping TLV is described in [DDMT].  A transit,
   branch or bud node can use the Downstream Detailed Mapping TLV to
   return multiple Return Codes for different downstream paths. This
   functionality can not be achieved via the Downstream Mapping TLV.
 
 Are Downstream Detailed Mapping TLV and Downstream Mapping TLV two
 different things?
 
   As
   per Section 4.3 of [DDMT], the Downstream Mapping TLV as described in
   [RFC4379] is being deprecated. 

They are different precisely per the referenced text.

But well done! You caught a bug :-)

s/4.3/3.4/

 4.1.2. Jittered Responses to Echo Requests
 
Echo response jittering SHOULD be used for P2MP LSPs.  If the Echo
Jitter TLV is present in an echo request for any other type of LSPs,
the responding egress MAY apply the jitter behavior as described
here.
 
 Can you provide a bit more information about how this work?

Obviously we authors think there is nothing more to say (or we would have said
it).

Maybe you can ask a more specific question?

If a jitter TLV shows up on an echo request for (e.g.) a P2P LSP, the egress may
delay sending the echo response in exactly the same way as the leaf of a P2MP
LSP would as described here.

 4.2.1.1. Responses from Transit and Branch Nodes
 
The presence of a Downstream Detailed Mapping TLV will influence the
choice of Return Code.  As per [DDMT], the Return Code in the echo
response header MAY be set to value TBD ('See DDM TLV for Return Code
 
 Am I correct that the value TBD is specified in [DDMT]?

You are correct as in the very next line that you cut off with your question.

 If not, it is missing in the IANA Considerations section.
 
and Return SubCode') as defined in [DDMT].  The Return Code for each
Downstream Detailed Mapping TLV will depend on the downstream path as
described in [DDMT].
 
 6. OAM and Management Considerations
 
   - A MIB module is required for the control and management of LSP
 Ping operations, and to enable the reported information to be
 inspected.
 
 I think it would be better to be explicit that this document doesn't
 define such a MIB.

This section rewritten in -17

 7.2. New TLVs
 
  P2MP Responder Identifier TLV (see Section 3.2) is a mandatory
 
 What does mandatory means in this section? Mandatory for IANA?

No. There are two TLV types. Mandatory TLVs and, erm, not mandatory ones. The
registry is split accordingly.

Re: [Gen-art] Gen-ART LC Review of draft-shiomoto-ccamp-switch-programming

[Adrian Farrel]

Hi Ben,

Thanks for reading.

 Nits/editorial comments:
 
 -- section 1, paragraph 4: ...with relation to the programming...
 
 ... in relation to...

Yeah. RFC Editor note if Stewart is watching (although I'm guessing the RFC
Editor might just fix this anyway).

 -- 3.1, last paragraph:
 
 Note that the references say SHOULD rather than MUST. Using must not here,
 even non-normatively, seems a bit overstated.

Disagree. The caveat is that we are defining something different. We are looking
at the case where we want to know that it is safe to start sending data. We are
using the existence of some SHOULD statements in related RFCs that describe
related behavior, to derive a must that covers when it is known to be safe.

Cheers,
Adrian

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

Re: [Gen-art] Gen-ART LC review of draft-ietf-mpls-lsp-ping-enhanced-dsmap-09

[Adrian Farrel]

Thanks Roni,

 Nits/editorial comments:

 1. Need to expand LDP when first mentioned.

LDP is a recognised acronym at
http://www.rfc-editor.org/rfc-style-guide/abbrev.expansion.txt and does not need
to be expanded.

Cheers,
Adrian


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

Re: [Gen-art] Gen-ART LC review of draft-ietf-mpls-lsp-ping-enhanced-dsmap-09

[Adrian Farrel]

Gotta draw a line somewhere, Doug.

(RFC? IMO? IETF?)

The RFC Editor draws that line for us. The list at the page I referenced is
constructed by the RFC Editor based on input from the community. I'm guessing
things can be deleted as well as added.

A  (stands for Adrian)

 -Original Message-
 From: Doug Barton [mailto:do...@dougbarton.us]
 Sent: 24 May 2011 19:11
 To: adr...@olddog.co.uk
 Cc: 'Roni Even'; draft-ietf-mpls-lsp-ping-enhanced-dsmap@tools.ietf.org;
gen-
 a...@ietf.org; 'IETF-Discussion list'
 Subject: Re: Gen-ART LC review of draft-ietf-mpls-lsp-ping-enhanced-dsmap-09
 
 On 05/24/2011 03:15, Adrian Farrel wrote:
  Thanks Roni,
 
Nits/editorial comments:
  
1. Need to expand LDP when first mentioned.
  LDP is a recognised acronym at
  http://www.rfc-editor.org/rfc-style-guide/abbrev.expansion.txt  and does not
 need
  to be expanded.
 
 And how would someone new to the RFC series know that? :)
 
 IMO one should always expand acronyms the first time they are used. It
 adds clarity to the text for new readers, and even for old hands it's
 sometimes necessary to disambiguate recycled TLAs.
 
 
 Doug (three-letter acroynms)
 
 --
 
   Nothin' ever doesn't change, but nothin' changes much.
   -- OK Go
 
   Breadth of IT experience, and depth of knowledge in the DNS.
   Yours for the right price.  :)  http://SupersetSolutions.com/

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

Re: [Gen-art] Gen-ART LC Review of draft-ietf-ccamp-mpls-tp-cp-framework-05

[Adrian Farrel]

Thanks for the review and these minor points.

Russ, I'm going to capture Ben's review in a Comment attached to my Yes ballot,
and the authors can come back and pick them up after the IESG review complete.

Cheers,
Adrian

 -Original Message-
 From: Ben Campbell [mailto:b...@nostrum.com]
 Sent: 31 January 2011 22:25
 To: draft-ietf-ccamp-mpls-tp-cp-framework@tools.ietf.org; General Area
 Review Team
 Cc: The IETF
 Subject: Gen-ART LC Review of draft-ietf-ccamp-mpls-tp-cp-framework-05
 
 I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART,
 please see the FAQ at
 http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq.
 
 Please resolve these comments along with any other Last Call comments you may
 receive.
 
 Document: draft-ietf-ccamp-mpls-tp-cp-framework-05
 Reviewer: Ben Campbell
 Review Date: 2010-01-31
 IETF LC End Date: 2010-01-31
 IESG Telechat date: (if known)
 
 Summary:
 
 This draft is effectively ready for publication as an informational RFC. I
have some
 minor comments, nits. and editorial comments that may be worth considering
 prior to final publication.
 
 Major issues:
 
 None
 
 Minor issues:
 
 -- Section 2 (and subsections)
 
 This section appears to be made up almost entirely of restatements of
 requirements that are normatively stated elsewhere. That takes up about 16
 pages. Is that really necessary, other than to say which requirements apply to
the
 control plane? You could do that by merely calling out the numbers of the
 requirements that apply from each document, and making notes when more
 explanation is needed. Since you explicitly state that the source documents
are
 authoritative, then a careful reader will need to read those documents anyway.
 OTOH, a not-so-careful reader may not read the source documents, and
 therefore be misinformed if this document introduces any discrepancies.
 
 -- Security Considerations:
 
 Are you willing to assert that no new security considerations are introduced
by
 the existing mechanism being used in this new context?
 
 Nits/editorial comments:
 
 
 -- IDNits returns errors and warnings. Please check.
 
 -- The document lists 5 editors on the front page, and 8 authors in the author
 section. That's a bit on the high side. I have no opinion whether that is
reasonable
 for this draft--I just call it out so others can decide.
 
 -- Please number the tables.
 
 -- The document makes inconsistent use of references. For example, you jump
 between the forms of ... as defined in document[xxx], ... as defined in
 document, see [xxx], and as defined in [xxx]. More consistency would make
 for easier reading. I personally prefer the first form, and find the second
form
 disruptive to the flow of reading.
 
 -- Section 1, paragraph 1: (MPLS-TP) is being defined
 
 Be careful with time-sensitive statements such as this. An RFC lives forever,
and
 this statement may be nonsensical to readers in e future. At least qualify it
with
 something like at the time of this writing...
 
 -- Section 1, paragraph 2: as defined by the ITU-T
 
 Reference?
 
 -- Section 1.2, numbered list:
 
 This is really just normal information, not a sequence. I suggest paragraph
form,
 or a bullet list if you really need a list format.
 
 Please put space between the list entries. A long list like this is difficult
to read
 without some white space.
 
 Please expand acronyms on first use. There are a number of unexpanded
 acronyms in this section.
 
 -- section 2, first paragraph: The requirements are summarized in this
section,
 but do not replace those documents. If there are differences between this
 section and those documents, those documents shall be considered
 authoritative.
 
 I assume that makes this entire section non-normative, even though it uses
 terms like must (albeit non-capitalized). It might be good to say that
explicitly,
 as readers may not notice the lack of capitals.
 
 -- section 2.1, req 38:
 
 Do you expect to keep requirement removed in the final RFC?
 
 -- ..., req 39:
 
 Which documents are you treating as authoritative for the purpose of this
 document, the ITU or IETF documents?
 
 -- req 52:
 
 The referenced requirement says it MUST be possible to require 100% of traffic
 on the protected path. Up to 100% is not the same thing
 
 -- req 95:
 
 Is that a requirement, or an observation?
 
 -- req 100:
 
 Is that a requirement, or an observation?
 
 -- req 101:
 
 Is that a requirement, or an observation?
 
 -- section 4.1.1: Out-of-band, in-fiber
 
 You are talking about any scenario using the same physical network, right? Is
the
 concept limited to fiber in any way?
 
 -- section 4.1.1, last paragraph: Some expect the G-ACh to be used
 extensively...
 
 Who expects it? Can you say something more concrete?
 
 -- 4.1.5, 1st paragraph: ... it is deprecated, and must not be used for
MPLS-TP.
 
 Do you mean that to be normative?
 
 -- 4.1.9, last paragraph: Recovery for MPLS-TP LSPs as discussed in
[TP-SURVIVE],
 is 

Re: [Gen-art] Gen-ART LC review of draft-ietf-pim-registry-03.txt

[Adrian Farrel]

Thanks Brian,

RFC Editor is just polling to add PIM to the list of well-known acronyms.

A

 -Original Message-
 From: Brian E Carpenter [mailto:brian.e.carpen...@gmail.com]
 Sent: 18 January 2011 01:24
 To: draft-ietf-pim-registry@tools.ietf.org; General Area Review Team
 Subject: Gen-ART LC review of draft-ietf-pim-registry-03.txt
 
 Please see attached review.
 
 
 


___
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-roll-security-framework-04

[Adrian Farrel]

Hi David,

Thanks for continuing to discuss.

 [A] I remain surprised that the forwarding table in each node is not
considered to
 be an attack target (i.e., asset to be protected).

What did you have in mind?
Do you believe someone with a wrench might break into the router and steal the
routing table? :-)

The only access to the routing table is through the routing protocol and
management mechanisms. Given the scope, this draft only discusses the routing
protocol.

Maybe this is as simple as saying *why* the routing protocol would be protected,
rather than assuming that the protocol has to be protected?

 [B] I did not see any discussion of:
 
  In general, a
  routing protocol should have a robust response to partial loss of
  communication/connectivity, but within defined limits (obviously
  a routing protocol is helpless against an attacker who can disable
  all inter-node communication).
 
 That sort of robust response is probably part of the routing protocol itself
rather
 as opposed to being added security functionality that secures the routing
 protocol, but this should be discussed, especially as all of the security
features
 that support availability have MAY requirements in Section 6.4.

I think that a robust response to partial loss of communication that impacts the
routing protocol should not be part of the routing protocol since the protocol
is possibly unable to communicate effectively.

Maybe the document should give an example of such a robust response. IMHO this
is about raising alarms to the operator.

 [C] The draft does not distinguish requirements for implementation from
 requirements for usage (e.g., MUST implement  MAY use is a reasonable
 combination).  Distinguishing requirements for protocol design from those for
 protocol deployment/usage is a good idea in general.  That's a contributing
factor
 to the next issue.

Requirements for use (even for security) are surely vain! All we can do is
describe what constitutes a conformant implementation. We can supplement that by
saying that to avoid a specific security threat, an operator may/should/must use
a specific feature.

 [D] The level of confidentiality requirements remains open:
 
  - The confidentiality and privacy requirements are SHOULD.  Unless there is
a
  good reason not to do so, they both should be MUST implement (use
  can be configured and/or negotiated).
 
 As I understand the discussion in the draft, the appropriate requirements
 statements are MUST implement and SHOULD use under specific
 circumstances (e.g., when geographic information is in use).  The stated
 SHOULD requirement for privacy of geographic information is troubling, as
the
 use of SHOULD instead of MUST implement allows systems to be deployed
 that cannot be configured to provide that privacy.  It may be possible to work
 around this by stating that geographic information MUST NOT be used when
 confidentiality protection is not implemented.

I'll leave the authors to comment on this. In general, I agree with MUST
implement and disagree with an unqualified SHOULD use (a qualification would
be operators wishing to protect geographic information SHOULD use...). I do
not agree with the MUST NOT in your final sentence. Operators MUST be free to
throw their money around in the street if they want to.

 In addition, I just noticed that the word privacy in this draft is not
connected to
 the concept of confidentiality - that connection should be made.
 
 idnits 2.12.05 did not find any nits.

Cheers,
Adrian

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

Re: [Gen-art] Gen-ART LC review of draft-ietf-pim-group-rp-mapping-07.txt

[Adrian Farrel]

Hi,

IETF last call completed without further comments.

Can I suggest 

OLD
   When a Group-to-RP mapping entry is created in the
   pimGroupMappingTable in the PIM-STD MIB[RFC5060], it would be
   acceptable to have an entry with an RP with address type 'unknown'
   and a PimMode of Dense Mode or SSM.  These entries would represent
   group ranges for Dense mode or SSM.

   Also all the entries which are already included in the SSM Range
   table in the IP Mcast MIB would be copied over to
   pimGroupMappingTable.  They would have a type of configSSM and an RP
   with address type 'unknown' as described above.

   The advantage of keeping all the ranges in the table would be that
   this table will contain all the known multicast group ranges.
NEW
   An implementation of this specification can continue to be managed
   using the PIM-STD-MIB [RFC5060]. When a Group-to-RP mapping entry is
   created in the pimGroupMappingTable the RP with address type in the
   pimGroupMappingRPAddressType object is set to unknown(0), and the 
   PIM Mode in the pimGroupMappingPimMode onject is set to either
   ssm(2) or dm(5) to represent group ranges for SSM or Dense mode.
   
   Also, all the entries which are already included in the SSM Range
   table in the IP Mcast MIB [insert reference] are copied to the 
   pimGroupMappingTable. Such entries have their type in the 
   pimGroupMappingOrigin object set to configSsm(3), and the RP
   address type in the pimGroupMappingRPAddressType object set to
   unknown(0) as described above.
END

In addition, you have a few other changes to make, so I will wait for a new 
revision before asking the IESG to review the document.

 -Original Message-
 From: Bharat Joshi [mailto:bharat_jo...@infosys.com]
 Sent: 20 December 2010 02:35
 To: Brian E Carpenter; Andy Kessler (kessler)
 Cc: draft-ietf-pim-group-rp-mapping@tools.ietf.org; General Area Review
 Team; Stig Venaas; Mike McBride (mmcbride)
 Subject: RE: Gen-ART LC review of draft-ietf-pim-group-rp-mapping-07.txt
 
 Hi,
 
   3. In section 8, Clarification for MIB Objects, I'm not
  sure what we have to say to be sure its understood that this
  is a normative reference. Suggestions ?
 
  You know, maybe you need to have a MIB expert glance at this text,
  for example the original MIB Doctor who reviewed the MIB module in
  the first place. I'm not sure that any language I propose will be
  any better than what you already have. However, if 'it would be
  acceptable' becomes a MAY construct and 'would be copied' becomes
  'SHOULD be copied', then it's clearly normative.
 
   Bharat, please spin a new version...
 
  Or you can wait to see if any other last call comments come in...
 
 
 Let us wait for other last call comments. I am hoping one of the MIB Doctors 
 will
 comment on this and we can find a way to address this concern.
 
 Regards,
 Bharat
 
  Thanks
 Brian Carpenter
 
 
  On 2010-12-20 07:49, Andy Kessler (kessler) wrote:
   Ok, we have made progress.
  
   These are the suggested changes we need to make:
  
   1. In Section 3, Existing Algorithm. Add a new sentence to
  the end:
  
  The full benefits of the new algorithm will not be realized
  until it is widely deployed.
  
   2. In section 5, Common use cases, first section Default static
  Group-to-RP mapping with dynamically learned entries, add
  a sentence to the end:
  
  This is not an issue for IPv6 Multicast address ranges.
  
   3. In section 8, Clarification for MIB Objects, I'm not
  sure what we have to say to be sure its understood that this
  is a normative reference. Suggestions ?
  
   4. Section 5, Common use cases, remove the subsection More use
  cases.
  
   Bharat, please spin a new version with these changes when we
   resolve number 3 above.
  
   Thanks,
  
   Andy
  
   -Original Message-
   From: Brian E Carpenter [mailto:brian.e.carpen...@gmail.com]
   Sent: Saturday, December 18, 2010 11:54 AM
   To: Andy Kessler (kessler)
   Cc: draft-ietf-pim-group-rp-mapping@tools.ietf.org; General Area
  Review Team; Bharat Joshi; Stig Venaas; Mike McBride (mmcbride)
   Subject: Re: Gen-ART LC review of draft-ietf-pim-group-rp-mapping-
  07.txt
  
   Hi Andy, thanks for responding so promptly. A few comments in line:
  
  
   On 2010-12-18 18:36, Andy Kessler (kessler) wrote:
   Hi,
  
   Thank you for the review.
   My comments are below annotated with Andy
  
   Andy
  
  
   I am the assigned Gen-ART reviewer for this draft. For background on
   Gen-ART, please see the FAQ at
   http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq.
  
   Please resolve these comments along with any other Last Call
  comments
   you may receive.
  
   Document: draft-ietf-pim-group-rp-mapping-07.txt
   Reviewer: Brian Carpenter
   Review Date: 2010-12-18
   IETF LC End Date: 2010-12-23
   IESG Telechat date:
  
   Summary: In good shape, a few issues.
   
  
   Major issues:
   

Re: [Gen-art] Gen-ART review of draft-ietf-mpls-ip-options-05.txt

[Adrian Farrel]

Thanks, Miguel, for the comments.

I think we will go with Dave's resolutions as these are particularly small
points.

Cheers,
Adrian

 -Original Message-
 From: David Smith (djsmith) [mailto:djsm...@cisco.com]
 Sent: 01 December 2010 22:03
 To: Miguel A. Garcia; wjae...@att.com; John Mullooly (jmullool);
 tsch...@nlayer.net; George Swallow (swallow); Adrian Farrel; General Area
 Review Team
 Subject: RE: Gen-ART review of draft-ietf-mpls-ip-options-05.txt
 
 
 Hi Miguel,
 
 Many thanks for your review.
 
 Regarding your nits/editorial comments:
 
 - Please expand acronyms at first occurrence. This includes: MPLS
 
 MPLS is on the RFC Editor's list of acronyms that are well known. So
 we're inclined not to expand it.
 
 - This is also very personal, but I think the presence of the word
 Requirements in the title of the draft may mislead the reader,
 thinking that this document just contains a collection of functional
 requirements but does not affect a protocol implementation. Since the
 draft proposes real actions at LERs, then I would suggest to remove
 Requirements for from the title.
 
 The current title was specifically recommended by active members of the
 MPLS WG. So we're inclined not to change it.
 
 Adrian - Let us know if you think otherwise. We'll change if required.
 
 Regards,
 
 /dave
 
 -Original Message-
 From: Miguel A. Garcia [mailto:miguel.a.gar...@ericsson.com]
 Sent: Monday, November 29, 2010 6:36 AM
 To: wjae...@att.com; John Mullooly (jmullool); tsch...@nlayer.net; David
 Smith (djsmith); George Swallow (swallow); Adrian Farrel; General Area
 Review Team
 Subject: Gen-ART review of draft-ietf-mpls-ip-options-05.txt
 
 I have been selected as the General Area Review Team (Gen-ART) reviewer
 for this draft. For background on Gen-ART, please see the FAQ at
 http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq
 
 Please resolve these comments along with any other comments you may
 receive.
 
 Document: draft-ietf-mpls-ip-options-05.txt
 Reviewer: Miguel Garcia miguel.a.gar...@ericsson.com Review Date:
 2010-11-29 IETF LC End Date: 2010-11-30 IESG Telechat date: (if known)
 
 Summary: The documetn is ready for publication as a proposed standard
 RFC.
 
 Major issues: none
 
 Minor issues: none
 
 Nits/editorial comments:
 
 - Please expand acronyms at first occurrence. This includes: MPLS
 
 - This is also very personal, but I think the presence of the word
 Requirements in the title of the draft may mislead the reader,
 thinking that this document just contains a collection of functional
 requirements but does not affect a protocol implementation. Since the
 draft proposes real actions at LERs, then I would suggest to remove
 Requirements for
 from the title.
 
 Other than that, the document looks good.
 
 /Miguel
 
 --
 Miguel A. Garcia
 +34-91-339-3608
 Ericsson Spain

___
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-ccamp-gmpls-ethernet-pbb-te-06.txt

[Adrian Farrel]

Thanks David,

[snip]


The following 3 IANA-related nits still need attention:

- In Section 4.1, remove the note to IANA after 2) and instead
insert this instruction into Section 7.


This is already the first bullet point in Section 7.
The RFC Editor will spot suggested value in 4.1 and update it.


- In Figure 4, the type is TBA.  Add an instruction to Section 7 for IANA
to fill this in after it is allocated.


RFC Editor has the practice of searching for TBA and replacing with the 
values assigned by IANA.


- In the fourth bullet in Section 7, please state that the registry is 
created

by the MLN-EXT draft if that is the case.


This was already added in -06

Thanks,
Adrian 


___
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-ccamp-gmpls-ethernet-pbb-te-05.txt

[Adrian Farrel]

David,

Thanks for this.

Authors: please consider these comments as part of the IETF last call, and 
come to resolution (possibly needing RFC Editor comments or a new revision).


Thanks,
Adrian
- Original Message - 
From: david.bl...@emc.com
To: gen-art@ietf.org; donald.fe...@alcatel-lucent.com; 
hs...@force10networks.com; nabil.n.bi...@verizon.com; 
attila.tak...@ericsson.com
Cc: david.bl...@emc.com; lber...@labn.net; dbrung...@att.com; 
adrian.far...@huawei.com; dan...@olddog.co.uk; cc...@ietf.org

Sent: Thursday, August 26, 2010 6:01 PM
Subject: Gen-ART review of draft-ietf-ccamp-gmpls-ethernet-pbb-te-05.txt


I am the assigned Gen-ART reviewer for this draft. For background on 
Gen-ART, please see the FAQ at 
http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq .


Please resolve these comments along with any other comments you may receive.

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


This draft describes the use of a GMPLS control plane to configure explicit 
forwarding in Ethernet bridges for PBB-TE (Provider Backbone Bridge Traffic 
Engineering).


In general, the draft is in good shape; the two open issues are in Section 
5.1.2 and are minor:
- Is the has to allocate a VID statement in Section 5.1.2 correct when 
shared forwarding

is in use as described in Section 3.1 ?
- The error value: MPLS Label allocation failure (9) appears to be 
inconsistent with the
second bullet in Section 7 that requests IANA to allocate a new error value: 
PBB-TE
Ethernet Label VID allocation failure (suggested value: 35?)  for this 
case.


Nits:

In Section 2, what are the I and B components of an IB-BEB?  Interface and 
Bridge?


In Figure 1, the VIP acronym is not in Section 2's list of acronyms.

In Section 4.1, remove the note to IANA after 2) and instead insert this 
instruction into Section 7.


In Figure 4, the type is TBA.  Add an instruction to Section 7 for IANA to 
fill this in after it is allocated.


In the fourth bullet in Section 7, please state that the registry is created 
by the MLN-EXT draft if that is the case.


idnits 2.12.04 ran clean.

Thanks,
--David

David L. Black, Distinguished Engineer
EMC Corporation, 176 South St., Hopkinton, MA 01748
+1 (508) 293-7953 FAX: +1 (508) 293-7786
david.bl...@emc.com Mobile: +1 (978) 394-7754




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

Re: [Gen-art] Gen Art LC review of draft-ietf-pce-manageability-requirements-10

[Adrian Farrel]

Please resolve these comments along with any other Last Call comments you 
may receive.


Will try, but it may be hard to reach resolution on some of them :-)


Major issues: None

Minor issues: None

Nits/editorial comments: None


Many thanks for taking the time to read and review.

Adrian
___
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-pce-pcep-svec-list-04.txt

[Adrian Farrel]

Thanks Miguel!


Minor issues:

- I noticed that the draft, although it uses normative verbs, they are all 
written in lower case. Additionally, there is no dependency to RFC 2119. I 
guess this is done on purpose because the draft is Informational. Is this 
the intention?


In the past the IETF has created Informational RFCs that contain normative 
text written in dependency with RFC 2119. I am not sure if there is a 
directive to change that way of working now.


I don't think it is a directive so much as a correct reading of RFC 2119 and 
its purpose.


I think some Informational RFCs use 2119-like language in order to highlight 
requirements, but I think the usage here is correct.



Nits/editorial comments:

- Expand acronyms at their first occurrence. This includes: SRLG, BRPC.


Yup. We''l do that if there is a respin.

- Section 5.2, first sentence in the 2nd paragraph. I guess the sentence 
looks incomplete. At least, it looks like an introductory part, but there 
is no consequence:


   If a PCC sends path computation requests to a PCE and then sends
   another path computation requests, which are dependent on the first
   requests and has been associated by using a SVEC list.


Yes. This looks broken.

Authors, please send me the fixed text for me to include in an RFC Editor 
note.


Thanks,
Adrian


___
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-ccamp-gmpls-mln-extensions-12

[Adrian Farrel]

Thanks for your thoroughness, David.

RFC Editor note has been created.

Cheers,
Adrian
- Original Message - 
From: black_da...@emc.com
To: dimitri.papadimitr...@alcatel-lucent.be; 
martin.vigour...@alcatel-lucent.fr; shiomoto.ko...@lab.ntt.co.jp; 
dbrung...@att.com; jean-louis.ler...@rd.francetelecom.com; 
gen-art@ietf.org
Cc: lber...@labn.net; adrian.far...@huawei.com; cc...@ietf.org; 
black_da...@emc.com

Sent: Monday, February 22, 2010 10:12 PM
Subject: Gen-ART review of draft-ietf-ccamp-gmpls-mln-extensions-12


The -12 version of this draft resolves all of the comments from the Gen-ART 
review of the -11 version with one minor exception -- the word Call needs 
to be inserted into the second line of section 5.1.5 as indicated below:


   5.1.5 Call Inheritance Flag

  This document introduces a specific Call Inheritance Flag at
  position bit 0 (most significant bit) in the Attributes Flags
  ^
  |
Call --/

An RFC Editor Note would be a fine way of handling this change, but it does 
need to be made.


Thanks,
--David



-Original Message-
From: Black, David
Sent: Friday, February 12, 2010 9:11 PM
To: dimitri.papadimitr...@alcatel-lucent.be; 
martin.vigour...@alcatel-lucent.fr;
shiomoto.ko...@lab.ntt.co.jp; dbrung...@att.com; 
jean-louis.ler...@rd.francetelecom.com; 'gen-

a...@ietf.org'
Cc: Black, David; Lou Berger; Adrian Farrel; cc...@ietf.org
Subject: Gen-ART review of draft-ietf-ccamp-gmpls-mln-extensions-11

I have been selected as the General Area Review Team (Gen-ART)
reviewer for this draft (for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).

Please resolve these comments along with any other Last Call
comments you may receive.

Document: draft-ietf-ccamp-gmpls-mln-extensions-11
Reviewer: David L. Black
Review Date: February 12, 2010
IETF LC End Date: February 16, 2010

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

Comments:
This draft extends GMPLS routing and signaling to support the
operation of GMPLS Multi-Layer/Multi-Region Networks.  One needs to be
a GMPLS expert to fully understand this draft - although, I'm not a
GMPLS expert, the draft reads reasonably well.  All of these comments
are minor.

The IACD sub-TLV formats for OSPF and IS-IS appear to be identical.  If
they are in fact identical, a single ASCII text diagram should be used
for both.

The description of the IACD sub-TLV format does not describe the
Max LSP Bandwidth fields.  At a minimum the units and/or encoding of
these fields should be described here, even thought the full
specification may be elsewhere.

Please add the values for Type and Length for the XRO SC subobject
into the ASCII figure in Section 4.1.1 .

Section 4.1.2 defines a new subobject by making minor changes to an
existing one in another RFC; a complete ASCII diagram of the new
subobject would be helpful - please add one.

Sections 5.1.4, 5.2.1 and 8 have me confused about the Attributes Flags 
TLV:

- Section 5.1.4 defines an Attributes Flags TLV here
- Section 5.2.1 points to RFC 5420 for what's apparently a different
Attributes Flags TLV and defines a Pre-Planned LSP flag in
that TLV.
- Section 8 then apparently instructs IANA to put that bit into the
Attributes Flags TLV defined in Section 5.1.4 .
Something appears to be wrong with this combination - what was
the intent?  If these two TLVs are the same, or share a common bit
assignment registry, that should be stated.

idnits 2.12.00 found three nits:

  == The page length should not exceed 58 lines per page, but there was 1
 longer page, the longest (page 1) being 62 lines

  ** There are 144 instances of too long lines in the document, the 
longest

 one being 1 character in excess of 72.

  == Line 781 has weird spacing: '...ndwidth  is st...'

Thanks,
--David

David L. Black, Distinguished Engineer
EMC Corporation, 176 South St., Hopkinton, MA 01748
+1 (508) 293-7953 FAX: +1 (508) 293-7786
black_da...@emc.com Mobile: +1 (978) 394-7754





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

[Gen-art] Next steps with draft-ietf-ccamp-gmpls-mln-extensions

[Adrian Farrel]

Hi Dimitri,

Looking at your response to David Black's review, I think an update to the 
draft is needed. I'd like to get it onto an IESG agenda before Anaheim as it 
has several Ethernet drafts backed up behind it.



Sections 5.1.4, 5.2.1 and 8 have me confused about the
Attributes Flags TLV:
- Section 5.1.4 defines an Attributes Flags TLV here


for Virtual TE links: the CALL ATTRIBUTE is defined in this document


- Section 5.2.1 points to RFC 5420 for what's apparently a different
  Attributes Flags TLV and defines a Pre-Planned LSP flag in
that TLV.


for Soft FA's: the LSP ATTRIBUTE defined in RFC 5420 is used to
introduced a new flag


- Section 8 then apparently instructs IANA to put that bit into the
  Attributes Flags TLV defined in Section 5.1.4 .
  Something appears to be wrong with this combination - what was
  the intent?  If these two TLVs are the same, or share a common bit
  assignment registry, that should be stated.


I will clarify this because as they both refer to attributes precision 
of the terms

used is indeed critical


I think David is quite right that there is confusion. My understanding is as 
follows...


There are two separate objects: the Call_Attribute object and the 
LSP_Attribute object.


Both of these objects can carry a TLV called the Attributes Flags TLV. But 
this is a DIFFERENT TLV for the two objects. In the first case, it is for 
use in the Call_Attribute object and is defined in this document. In the 
second case it is for use on the LSP_Attribute object and is defined in RFC 
4020 with this document only defining a new flag.


My suggestion to make this crystal clear is to change the name of the 
Attributes Flags TLV carried in the Call_Attribute object to be the Call 
Attibutes Flags TLV. I think this is a really easy search and replace, and 
fixes this issue.


David also said...


The IACD sub-TLV formats for OSPF and IS-IS appear to be
identical.  If they are in fact identical, a single ASCII text diagram
should be used for both.


They are identical, but that is only good fortune. There is no requirement 
that they be the same, and there is no required mapping between the two. 
Furthermore, a future revision might need to change the format or content 
for one protocol, but not for the other, etc. Thus, we prefer to keep the 
definitions distinct.



The description of the IACD sub-TLV format does not describe the
Max LSP Bandwidth fields.  At a minimum the units and/or encoding of
these fields should be described here, even thought the full
specification may be elsewhere.


David is correct that the fields should be mentioned, but I think it would 
be OK to include a reference to RFC4203 and RFC5307.



Please add the values for Type and Length for the XRO SC
subobject into the ASCII figure in Section 4.1.1 .


The convention in RSVP-TE is to not include the Type and Length (most 
relevantly, see RFC 4874). It would be inappropriate to change that 
convention here.



Section 4.1.2 defines a new subobject by making minor changes to an
existing one in another RFC; a complete ASCII diagram of the new
subobject would be helpful - please add one.


There is absolutely no change in the format of the subobject. The only 
difference is the interpretation of the L bit. In order to keep the 
subobjects in lock-step, it is preferable to not include a further ASCII 
diagram.



idnits 2.12.00 found three nits:

  == The page length should not exceed 58 lines per page, but
there was 1 longer page, the longest (page 1) being 62 lines


This is the first page caused by leading several CRLF


  ** There are 144 instances of too long lines in the
   document, the longest one being 1 character in
   excess of 72.


Seems to be a product of MS Word.
I think the whole thing needs to be left-shifted by 7 spaces.


  == Line 781 has weird spacing: '...ndwidth  is st...'


Yup. Section 5.2.2 para 2 has a double space.

Finally, could you or Lou please confirm the IANA actions in the email from 
Amanda on the 16th.


Many thanks,
Adrian 


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

Re: [Gen-art] Next steps with draft-ietf-ccamp-gmpls-mln-extensions

[Adrian Farrel]

Ah thanks, I had only checked the datatracker. I guess this will pop out on 
Monday when the Secretariat get to work.


It seems to address the points.

Thanks.

Adrian
- Original Message - 
From: Lou Berger lber...@labn.net

To: Adrian Farrel adrian.far...@huawei.com
Cc: PAPADIMITRIOU Dimitri dimitri.papadimitr...@alcatel-lucent.com; 
black_da...@emc.com; 
draft-ietf-ccamp-gmpls-mln-extensi...@tools.ietf.org; 
ccamp-cha...@tools.ietf.org; gen-art@ietf.org

Sent: Sunday, February 21, 2010 12:37 PM
Subject: Re: Next steps with draft-ietf-ccamp-gmpls-mln-extensions



Adrian,
It looks like Dimitri is one step ahead (at least for now ;-)  Take a
look at:

http://tools.ietf.org/rfcdiff?difftype=--hwdiffurl1=draft-ietf-ccamp-gmpls-mln-extensions-11.txturl2=http://www.ietf.org/staging/draft-ietf-ccamp-gmpls-mln-extensions-12.txt

I suspect all issues are addressed in this rev.  Once you and David
confirm, we can respond to IANA with the requisite changes.

Please confirm that there are/are not remaining open issues.

Much thanks,

Lou

On 2/21/2010 6:28 AM, Adrian Farrel wrote:

Hi Dimitri,

Looking at your response to David Black's review, I think an update to 
the
draft is needed. I'd like to get it onto an IESG agenda before Anaheim as 
it

has several Ethernet drafts backed up behind it.


Sections 5.1.4, 5.2.1 and 8 have me confused about the
Attributes Flags TLV:
- Section 5.1.4 defines an Attributes Flags TLV here


for Virtual TE links: the CALL ATTRIBUTE is defined in this document


- Section 5.2.1 points to RFC 5420 for what's apparently a different
  Attributes Flags TLV and defines a Pre-Planned LSP flag in
that TLV.


for Soft FA's: the LSP ATTRIBUTE defined in RFC 5420 is used to
introduced a new flag


- Section 8 then apparently instructs IANA to put that bit into the
  Attributes Flags TLV defined in Section 5.1.4 .
  Something appears to be wrong with this combination - what was
  the intent?  If these two TLVs are the same, or share a common bit
  assignment registry, that should be stated.


I will clarify this because as they both refer to attributes precision
of the terms
used is indeed critical


I think David is quite right that there is confusion. My understanding is 
as

follows...

There are two separate objects: the Call_Attribute object and the
LSP_Attribute object.

Both of these objects can carry a TLV called the Attributes Flags TLV. 
But

this is a DIFFERENT TLV for the two objects. In the first case, it is for
use in the Call_Attribute object and is defined in this document. In the
second case it is for use on the LSP_Attribute object and is defined in 
RFC

4020 with this document only defining a new flag.

My suggestion to make this crystal clear is to change the name of the
Attributes Flags TLV carried in the Call_Attribute object to be the Call
Attibutes Flags TLV. I think this is a really easy search and replace, 
and

fixes this issue.

David also said...


The IACD sub-TLV formats for OSPF and IS-IS appear to be
identical.  If they are in fact identical, a single ASCII text diagram
should be used for both.


They are identical, but that is only good fortune. There is no 
requirement

that they be the same, and there is no required mapping between the two.
Furthermore, a future revision might need to change the format or content
for one protocol, but not for the other, etc. Thus, we prefer to keep the
definitions distinct.


The description of the IACD sub-TLV format does not describe the
Max LSP Bandwidth fields.  At a minimum the units and/or encoding of
these fields should be described here, even thought the full
specification may be elsewhere.


David is correct that the fields should be mentioned, but I think it 
would

be OK to include a reference to RFC4203 and RFC5307.


Please add the values for Type and Length for the XRO SC
subobject into the ASCII figure in Section 4.1.1 .


The convention in RSVP-TE is to not include the Type and Length (most
relevantly, see RFC 4874). It would be inappropriate to change that
convention here.


Section 4.1.2 defines a new subobject by making minor changes to an
existing one in another RFC; a complete ASCII diagram of the new
subobject would be helpful - please add one.


There is absolutely no change in the format of the subobject. The only
difference is the interpretation of the L bit. In order to keep the
subobjects in lock-step, it is preferable to not include a further ASCII
diagram.


idnits 2.12.00 found three nits:

  == The page length should not exceed 58 lines per page, but
there was 1 longer page, the longest (page 1) being 62 lines


This is the first page caused by leading several CRLF


  ** There are 144 instances of too long lines in the
   document, the longest one being 1 character in
   excess of 72.


Seems to be a product of MS Word.
I think the whole thing needs to be left-shifted by 7 spaces.


  == Line 781 has weird spacing: '...ndwidth  is st...'


Yup. Section 5.2.2 para 2

Re: [Gen-art] Gen-ART review of draft-ietf-ccamp-gmpls-dcsc-channel-ext-03.txt

[Adrian Farrel]

Hi Miguel,

I think IANA owns the MIB module.

You're right, we should chase IANA to make sure they understand what to do.

Lou, can you ping them?

A
- Original Message - 
From: Miguel A. Garcia miguel.a.gar...@ericsson.com
To: lber...@labn.net; donald.fe...@alcatel-lucent.com; 
ccamp-cha...@tools.ietf.org; adrian.far...@huawei.com

Cc: General Area Review Team gen-art@ietf.org
Sent: Thursday, February 04, 2010 8:08 AM
Subject: Gen-ART review of draft-ietf-ccamp-gmpls-dcsc-channel-ext-03.txt


I have been selected as the General Area Review Team (Gen-ART)
reviewer for this draft (for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).

Please resolve these comments along with any other Last Call comments
you may receive.

Document: draft-ietf-ccamp-gmpls-dcsc-channel-ext-03.txt
Reviewer: Miguel Garcia miguel.a.gar...@ericsson.com
Review Date: 04-Feb-2010
IETF LC End Date: 05-Feb-2010
IESG Telechat date: (if known)

Summary: The document is ready for publication as a Standards track RFC.

Nits/editorial comments:

The document is well written and very clear. My only concern lies in 
Section 4.1, last paragraph:


   It should be noted that the assigned value should be reflected in
   IANAGmplsSwitchingTypeTC at
   http://www.iana.org/assignments/ianagmplstc-mib.

So, I don't really know if IANA needs to modify the MIB, or someone needs 
to modify the MIB and uploaded to IANA, or nothing is supposed to happen 
here. I noticed in the I-D tracker that IANA is not planning to take any 
action with respect the MIB, is this the authors' intention?


/Miguel

--
Miguel A. Garcia
+34-91-339-3608
Ericsson Spain



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

Re: [Gen-art] draft-ietf-pce-p2mp-req-04.txt

[Adrian Farrel]

Thanks Francis,


Summary: Ready


Good to know.


Nits/editorial comments:
- in 1 page 2: in theory you should expend the VPN abbrev (it is not
 in http://www.rfc-editor.org/rfc-style-guide/abbrev.expansion.txt
 marked as well known even IMHO it should, so the in theory)


Yup


- 2.1.4 page 3: unprocessable is not in my dictonary
 (but it is known by google :-)


I'll let the RFC Editor worry.


- 2.1.9 page 5: (wording) it MUST be possible - it MUST be allowed
 (IMHO the word possible doesn't go with a MUST)


I think the philosophy taught in French and English schools differs on this 
point :-)


This document is describing the requirements to be applied to the protocol 
spec.

The solution must make it possible to do this.

I'll let the RFC Editor correct this if it is wrong.


- BTW there are a lot of it is  I am not convince it is
 a good wording in English (it is in French so I am half very used
 to see this and half prevented against this gallicism...)


Be convinced!


- 5 page 9: (question) for instance the R3/2.1.3 reason code
is not here because it is defined in another document, isn't it?
BTW if this document is draft-ietf-pce-pcep-p2mp-extensions-06.txt
why is it not cited?


You are correct in the document you cross-reference.
But the reason it is not specified here is because this is a requirements 
document not a protocol spec.



- 7.1 page 9: PCE-P2MP-APP was published as RFC 5671


Yup

Thanks again,
Adrian 


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

Re: [Gen-art] review of draft-ietf-roll-building-routing-reqs-07.txt

[Adrian Farrel]

Thanks Francois,

Good to have your review.

Coming as it does, after both IETF last call and IESG review, we will try to 
sort your comments by importance and pass them on as pointers to the RFC 
Editor.


Cheers,
Adrian

- Original Message - 
From: Francis Dupont francis.dup...@fdupont.fr

To: gen-art@ietf.org
Cc: jerald.p.marto...@jci.com; nicolas.r...@fr.schneider-electric.com; 
pieter.de...@intec.ugent.be; wou...@vooruit.be; 
adrian.far...@huawei.com

Sent: Friday, October 02, 2009 9:45 AM
Subject: review of draft-ietf-roll-building-routing-reqs-07.txt



I have been selected as the General Area Review Team (Gen-ART)
reviewer for this draft (for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).

Please resolve these comments along with any other Last Call comments
you may receive.

Document: draft-ietf-roll-building-routing-reqs-07.txt
Reviewer: Francis Dupont
Review Date: 2009-09-29
IETF LC End Date: 2009-09-24
IESG Telechat date: unknown

Summary: Ready

Major issues: None

Minor issues:
- IMHO the document is a bit USA centric (but it is not a problem
 if it is stated in the document, for instance with a reference
 from the (US) building automation community, cf 8.2 comment below)

Nits/editorial comments:
- the language of the document is not at the usual level (but at it
 should be considered as better it is not a concern)
- 2 page 4, 5.1 and 5.1.1 page 12, 5.3 page 13, 5.4.1 and 5.4.2 page 14.
 5.7.2 and 5.7.4 page 16, 5.7.7 page 17. 5.8.4 page 18, 9.2.1 page 20:
  e.g. - e.g.,
- 3.1 page 5: use the occasion to introduce the FMS abbrev, i.e.,
 add (MS) after facility management system
- 4 page 10: the P in P2P (and MP2P / P2MP) is ambiguous:
 it can stand for point and the point-to-point term usually
 refers to link topology. I propose:
  P2P - (peer-to-peer, P2P)
  (MP2P) - (multi-peers-to-peer, MP2P)
  (P2MP) - (peer-to-multi-peers, P2MP)
- 4 page 10 and 5.4.3 page 14: acknowledgement - acknowledgment
 (for uniformity with the section title where this spelling is
  enforced) (multiple occurrences)
- 5.1 page 11: no network knowledge - no communication network knowledge
- 5.2.2 page 13: even it is also overloaded:
 point-to-point - end-to-end
- 5.4 page 14: i.e. - i.e.,
- 5.4.3 page 14: 2000mah - 2000mAh
- 5.7.6 page 17: msec - ms
- 7 page 19: J. P. - JP.
- 8.2 page 19: I'd really like to get a reference from the building
automation community: explaining networking to them or an introduction
for us (networking community) or both. I expect there are at least
some framework standards.
- 9.1.2 page 19: 2.4Ghz - 2.4GHz
 (BTW the ISM band text is very USA centric :-)
- 9.3.1 page 20: missing final '.'
- Authors' Addresses page 22: unfinished (???), add +1 for USA phone
number, -- - - (and BTW try to use the same separator)

Regards

francis.dup...@fdupont.fr



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

Re: [Gen-art] review of draft-ietf-mpls-gmpls-lsp-reroute-04.txt

[Adrian Farrel]

Francis,

Get a conformant dictionary :-)

Compliant has two meanings. The most used would describe a submissive 
person.

Conformant has the same meaning as the other meaning of compliant.

Lou, were you proposing that a further change is made here?
Can you handle it in Auth48?

A
- Original Message - 
From: Lou Berger lber...@labn.net

To: Francis Dupont francis.dup...@fdupont.fr
Cc: gen-art@ietf.org; dimitri.papadimitr...@alcatel-lucent.be; 
j...@cisco.com; adrian.far...@huawei.com

Sent: Tuesday, September 29, 2009 11:28 PM
Subject: Re: review of draft-ietf-mpls-gmpls-lsp-reroute-04.txt



okay, reasonable enough.  While it is jargon, I think it is accepted in
the computer science space...

Thanks,
Lou

On 9/29/2009 6:10 PM, Francis Dupont wrote:

 In your previous mail you wrote:

= oops, catching an old message.

 - 2.2 page 6 and 2.3 page 6: conformant - compliant

   Why?

= just because conformant is not in my dictionary, compliant is
and is supposed to mean the same thing... Now my dictionary is
not universal and is British oriented (:-).

Regards

francis.dup...@fdupont.fr







___
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-mpls-tp-requirements

[Adrian Farrel]

All,

I propose the following RFC Editor note...

Section 1

OLD
  Although both static and dynamic configuration of MPLS-TP transport
  paths (including Operations, Administration and Maintenance (OAM) and
  protection capabilities) is required by this document, it MUST be
  possible for operators to be able to completely operate (including
  OAM and protection capabilities) an MPLS-TP network in the absence of
  any control plane.
NEW
  MPLS-TP transport paths may be established using static or dynamic
  configuration. It should be noted that the MPLS-TP network and its
  transport paths can always be operated fully (including OAM and
  protection capabilities) in the absence of any control plane.

- - - -

Section 2
OLD
  This document specifies the requirements of an MPLS Transport Profile
  (MPLS-TP).  The requirements are for the behavior of the protocol
  mechanisms and procedures that constitute building blocks out of
  which the MPLS transport profile is constructed.  That is, the
  requirements indicate what features are to be available in the MPLS
  toolkit for use by MPLS-TP.  The requirements in this document do not
  describe what functions an MPLS-TP implementation supports.  The
  purpose of this document is to identify the toolkit and any new
  protocol work that is required.
NEW
  The MPLS-TP requirements set out in this section are for the behavior
  of the protocol mechanisms and procedures that constitute building
  blocks out of which the MPLS transport profile is constructed.
  That is, the requirements indicate what features are to be available
  in the MPLS toolkit for use by MPLS-TP.

- - - -

Please let me know if this is acceptable.

A
- Original Message - 
From: Christian Vogt christian.v...@ericsson.com

To: i...@ietf.org
Cc: benjamin.niven-jenk...@bt.com; nurit.sprec...@nsn.com; 
satoshi.u...@ntt.com; Gen-ART Mailing List gen-art@ietf.org; 
bett...@nortel.com; dbrung...@att.com

Sent: Thursday, July 16, 2009 1:25 AM
Subject: Gen-ART review of draft-ietf-mpls-tp-requirements



I have been selected as the General Area Review Team (Gen-ART)
reviewer for this draft (for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).

Please resolve these comments along with any other Last Call
comments you may receive.


Document..:  draft-ietf-mpls-tp-requirements
Reviewer..:  Christian Vogt
Review date...:  July 15, 2009


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

This document specifies protocol requirements for MPLS in packet
transport networks.  The document is of very good quality, with an
elaborate introduction explaining the background for this document.

Two editorial nits that the authors should consider addressing prior
to publication of this document are the following:

- The fourth paragraph on page 6, which is part of the introduction,
  already specifies a requirement.  I suggest moving this to section
  2, since this is the section that is dedicated to requirements.

- The first paragraph of section 2 is a duplicate; it already appears in
  the introduction.  I suggest removing it from section 2.  The
  paragraph is important for the reader to understand the scope of the
  document, and hence should retain its prominent position in the
  introduction rather than the position in section 2.

Best regards,
- Christian



On Jul 2, 2009, The IESG wrote:

The IESG has received a request from the Multiprotocol Label  Switching 
WG

(mpls) to consider the following document:

- 'MPLS-TP Requirements '
  draft-ietf-mpls-tp-requirements-09.txt as a Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send substantive comments to  the
i...@ietf.org mailing lists by 2009-07-16. Exceptionally,
comments may be sent to i...@ietf.org instead. In either case, please
retain the beginning of the Subject line to allow automated sorting.

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-requirements-09.txt


IESG discussion can be tracked via
https://datatracker.ietf.org/public/pidtracker.cgi?command=view_iddTag=18021rfc_flag=0




___
Ietf mailing list
i...@ietf.org
https://www.ietf.org/mailman/listinfo/ietf




___
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-mpls-tp-gach-gal-05.txt

[Adrian Farrel]

Hi,


- Rule of 5 authors. The draft lists 6 authors, of which 2 of them are
listed as Editors. While this is not an impediment for its
publication, certainly it brakes the RFC Editor's rule of 5 authors.


I'm waiting for guidance from Loa and Adrian on this one.


I thought I sent this.

Document header...
M. Bocci, Ed.
M. Vigoureux, Ed.

Merge sections 7 and 8 to read...

  The editors gratefully acknowledge the contributions of Sami Boutros,
  Italo Busi, Marc Lasserre, Lieven Levrau and Siva Sivabalan

  The authors would like to thank Malcolm Betts, ITU-T Study Group 15,
  and all members of the teams (the Joint Working Team, the MPLS
  Interoperability Design Team in IETF and the MPLS-TP Ad-Hoc Team in
  ITU-T) involved in the definition and specification of the MPLS
  Transport Profile.

New section Editors' Addresses...
M. Bocci, Ed.
M. Vigoureux, Ed.

Authors' Addresses...
George Swallow
David Ward
Stewart Bryant
Rahul Aggarwal



Cheers,
Adrian

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

Re: [Gen-art] review of draft-ietf-mpls-p2mp-te-mib-08.txt (full)

[Adrian Farrel]

Thanks Francis,

I'll catch these with an update after IETF last call completes

Adrian
- Original Message - 
From: Francis Dupont francis.dup...@fdupont.fr

To: gen-art@ietf.org
Cc: adr...@olddog.co.uk; s.yasuk...@hco.ntt.co.jp; tom.nad...@bt.com; 
rcal...@juniper.net

Sent: Friday, April 17, 2009 1:09 PM
Subject: review of draft-ietf-mpls-p2mp-te-mib-08.txt (full)



I have been selected as the General Area Review Team (Gen-ART)
reviewer for this draft (for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).

Please resolve these comments along with any other Last Call comments
you may receive.

Document: draft-ietf-mpls-p2mp-te-mib-08.txt
Reviewer: Francis Dupont
Review Date: 2009-04-16
IETF LC End Date: 2009-04-17
IESG Telechat date: unknown

Summary: Ready

Major issues: None

Minor issues: None

Nits/editorial comments:
- Abstract: add '(MIB)' as it is done in the introduction

- Abstract: if you need to enforce the do-not-cite-rfc in the Abstract
 put reference to RFC 3812 and 4802 into parenthesis?

- 4 page 5: remove spurious line break between:
  objects and tables some of which extend tables in MPLS-TE-STD-MIB

  [RFC3812]. [RFC4461] and [RFC4875] are clear that they apply to

- 4.2 page 6: additional features or different behavior is required
  - are required

- 4.2.1 page 8 (title): Compatiblity - Compatibility

- 4.2.1 page 9: sematics - semantics

- 4.2.2 page 10 (title): Compatiblity - Compatibility

- 4.7 page 12: diagramatic - diagrammatic

- 5.2 page 20 (multiple): SeesionAttribute - SessionAttribute

- 5.2 page 24: thre - there

- mplsTeP2mpTunnelRowStatus page 26: mplsTunneltable - mplsTunnelTable

- mplsTeP2mpTunnelDestOperStatus page 47: aply - apply and
 destinaton - destination

- mplsTeP2mpTunnelDestUp page 51: mplsTeP2mpTunneldestOperStatus -
 mplsTeP2mpTunnelDestOperStatus

- Module Conformance Statement page 52: remove spurious line break
 between:
   for MPLS-TE-P2MP-STD-MIB. Such devices can be monitored and

   also be configured using this MIB module.

- 8 page 56: please extend the VACM and USM abbrevs.

- 8 page 57: IPSec - IPsec
 (BTW if the common way to deploy IPsec is to use it for infrastructure
  protection, IPsec can also be used with a finer grain for application
  protection, i.e., transport mode vs. tunnel mode)

- 12 page 60: please add the country in Thomas' address.

Regards

francis.dup...@fdupont.fr

PS: experience has shown spelling errors in MIB ids can't be fixed
(because of backward compatibility). IMHO we should have a specific
tool to help this spelling check. I sorted the output of a spell
checker so I got some (fortunately in comments)...




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

Re: [Gen-art] Gen-ART LC review of draft-ietf-ccamp-gmpls-ason-routing-ospf-07

[Adrian Farrel]

Hi Ben,

New revision just out fixes the issues.

Thanks again.
Adrian
- Original Message - 
From: Ben Campbell b...@estacado.net

To: PAPADIMITRIOU Dimitri dimitri.papadimitr...@alcatel-lucent.be
Cc: Adrian Farrel adr...@olddog.co.uk; General Area Review Team 
gen-art@ietf.org; rcal...@juniper.net; dw...@cisco.com

Sent: Tuesday, March 17, 2009 7:54 PM
Subject: Re: Gen-ART LC review of 
draft-ietf-ccamp-gmpls-ason-routing-ospf-07



For the record, this email along with Adrian's address all of my 
comments.


Thanks!

Ben.


On Mar 13, 2009, at 8:19 AM, PAPADIMITRIOU Dimitri wrote:


Adrian:


-Original Message-
From: Adrian Farrel [mailto:adr...@olddog.co.uk]
Sent: Friday, March 13, 2009 2:07 PM
To: Ben Campbell; PAPADIMITRIOU Dimitri; General Area Review Team
Cc: rcal...@juniper.net; dw...@cisco.com
Subject: Re: Gen-ART LC review of
draft-ietf-ccamp-gmpls-ason-routing-ospf-07

Hi Ben,

Thanks for your review.

Dimitri, need your help!
See in line below.

Adrian


Minor issues:

-- Section 9.1:

This section shows the sub-TLV types as TBD, but at least

some of the

references sections specify type numbers.


OK, I found section 9.1
|   ValueSub-TLV
Reference
|   ---  
--
|   TBD  Local TE Router ID
[This.ID]

But, in section 5.3
| The Type of the Local TE Router-ID sub-TLV is 5

Similarly,
|   TBD  Local and Remote TE Router ID
[This.ID]

But, section 5.2
|The Type of the Local and Remote TE Router-ID sub-TLV is 17

Also,
|   TBD  Node IPv4 Local Prefix
[This.ID]
|   TBD  Node IPv6 Local Prefix
[This.ID]

But in section 3
|  - Node IPv4 Local Prefix sub-TLV: Type 3 - Length: variable
|  - Node IPv6 Local Prefix sub-TLV: Type 4 - Length: variable

Dimitri, are these values:
- required
- desired
- suggested?


The former.


Nits/editorial comments:

-- general:

It would be helpful to have referenceable numbers for the

TLV format

figures.


Yeah, might be nice, but since the figures are not referenced
outside the
section in which they appear, I think we won't bother this time.


usually we ref. the sub-section itself.


Using non-mnemonic citations as if they were nouns in a

sentence  creates

extra work for the reader, who must flip back to the  references to
understand the sentence.  That is, the form  ...defined

in [xxx].  It's

better to say defined in foo [xxx]. It's not as bad  with

mnemonic

citations (e.g. defined in [foo]), but it can still

cause confusion if

text is quoted in other documents without the  associated reference
section.


Hmmm.
This notation seems to be used pretty widely.
I'd hate to see text that said ..defined in RFC 1234 [RFC1234]. :-)


it is correct but as most IETF refs. are RFCs it reads often like  Adrian
states.


-- section 2, 2nd paragraph: The
  limit of the subdivision results is an RA that contains just two
  sub-networks interconnected by a single link.

I don't follow the last sentence. Is it possible results

is was  meant

to be results in?


Yes. Thanks.


-- section 3.1, last paragraph, first sentence: The local

addresses  that

can be learned from Opaque TE LSAs.

incomplete sentence. Is that spurious?


Good catch.
OLD
  The local addresses that can be learned from Opaque TE
LSAs. That is,
  router address and TE interface addresses SHOULD NOT be advertised
  in the node IPv4 local prefix sub-TLV.
NEW
  The local addresses that can be learned from Opaque TE
LSAs (that is,
  the router address and TE interface addresses) SHOULD NOT be
  advertised in the node IPv4 local prefix sub-TLV.


section 3.2, first paragraph after the figure: Length is

set to Sum[n] [4

+ #32-bit words/4] where n is the
  number of local prefixes included in the sub-TLV.

I'm not sure I understand the expression.


But you think you might? :-)

Hard doing scientific notation in ASCII, isn't it?
OLD
Length is set to Sum[n][4 + #32-bit words/4] where n is the
  number of local prefixes included in the sub-TLV. The
encoding of
  each prefix potentially using fewer than four 32-bit words is
  described below.
NEW
Length is set to the sum over all of the local prefixes
included in
  the sub-TLV of (4 + (number of 32-bit words in the prefix)/4 ).
  The encoding of each prefix potentially using fewer than four
  32-bit words is described below.


correct.


-- section 4.1, 3rd paragraph:

Please expand LSC and PSC on first use.


oke


-- section 6, 3rd paragraph:

s/informtation/information


oke


-- idnits reports the following:


Who can keep up with the IPR change rate?
All IPR notices correct at time of submission.
No doubt they will be updated and correct many times in the
next weeks.


is there something specific here to be done from my side ?

much thanks,
-dimitri.

Many thanks,
Adrian







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

Re: [Gen-art] Gen-ART review of draft-ietf-pce-global-concurrent-optimization-08

[Adrian Farrel]

Thanks David!


Comments:

I am concerned about Section 6.2's recommendation for MIB
extension work.  Is the work to extend the MIB underway?  How
important is that MIB extension to manageability (hence
usability in practice) of this protocol?


No, the work on MIB extensions has not been started.
It is not uncommon for MIB work to lag behind the protocol work.
I don't think any of the MIB work is critical to the usability of this 
protocol.


The MIB work is desirable because:
- the IESG asks for it
- it helps to develop the maturity of the protocol


The following items are all minor, but should be dealt with:


Yes.


p.5, last paragraph, 3rd line:
wheres this ID -- whereas this ID

p.6, 3rd line of PCECP definition:
requests a PCC -- requests from a PCC

p.8, 1st new paragraph, 4th line
in which to compute -- that computes


Its on page 9.


Section 5.3 defines two new bits in the RP object.  The
bit numbers should be included in this section in addition to
including them in the IANA Considerations section.


Yeah. Might be helpful.


Section 5.5: Please explain what the Optional TLV(s) are
in Figure 3.


This is a good point...
Authors: I presume you have put this here for extensibility, but have 
defined no TLVs at this stage.

You need to:
- Note that no TLVs are defined in this document. Use some
 text like that in Section 7.3 of RFC 5440
- State that the TLV format and processing is consistent with
  Section 7.1 of RFC 5440
- State that any TLVs will be allocated from the PCEP TLV
  Type Indicators registry

I think that means you need to do a quick update, please.

Thanks,
Adrian

___
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-ccamp-pc-and-sc-reqs-06.txt

[Adrian Farrel]

Sure. Whatever.

Actually I am completely baffled by this comment as the terminology section 
in this I-D is Section 2. We are talking about the same I-D aren't we? 
draft-ietf-ccamp-pc-and-sc-reqs-06.txt


All I see after the Abstract is a section with RFC 2119 language. Maybe this 
should be toned differently for a requirements draft, but I find it useful 
and helpful to use 2119 language in requirements documents. As to the 
placement of 2119 boilerplate we should observe that the RFC Editor will 
always position this where he thinks it appropriate in an RFC and this has 
nothing to do with whether the document is ready for publication. Sometimes, 
it is true, this is immediately after the Introduction, and sometimes it is 
immediately after the Abstract. See 
http://www.rfc-editor.org/rfc/rfc5316.txt and 
http://www.rfc-editor.org/authors/rfc5440.txt for examples of each.


Thanks,
Adrian

PS In case there should be any doubt, I really do appreciate the work done 
by the GenArt review team to improve the quality of our RFCs.


- Original Message - 
From: Ross Callon rcal...@juniper.net

To: Gonzalo Camarillo gonzalo.camari...@ericsson.com
Cc: gen-art@ietf.org; ccamp-cha...@tools.ietf.org; 
draft-ietf-ccamp-pc-and-sc-r...@tools.ietf.org

Sent: Tuesday, January 27, 2009 8:17 PM
Subject: RE: Gen-art review of draft-ietf-ccamp-pc-and-sc-reqs-06.txt


I proposed to the authors to put in an RFC editor's note to cover your
comment. If all are fine with this, then we should be ready to put this
on an IESG telechat.

Thanks, Ross

-Original Message-
From: Gonzalo Camarillo [mailto:gonzalo.camari...@ericsson.com]
Sent: 27 January 2009 04:31
To: draft-ietf-ccamp-pc-and-sc-r...@tools.ietf.org
Cc: Ross Callon; gen-art@ietf.org; ccamp-cha...@tools.ietf.org
Subject: Gen-art review of draft-ietf-ccamp-pc-and-sc-reqs-06.txt

Hi,

I have been selected as the General Area Review Team (Gen-ART)
reviewer for this draft (for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).

Please resolve these comments along with any other Last Call comments
you may receive.


Draft:  draft-ietf-ccamp-pc-and-sc-reqs-06.txt
Reviewer: Gonzalo Camarillo gonzalo.camari...@ericsson.com
Review Date: 27 January 2009

Summary:

This draft is ready for publication as an Informational RFC.


Comments:

The Terminology Section is not usually appended to the Abstract. It is
usually placed after the Introduction as a regular section.


Thanks,

Gonzalo



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

Re: [Gen-art] Gen-art LC review of draft-ietf-pce-of-05

[Adrian Farrel]

Hi Robert,

Thanks for reading.

The security consideration section is pretty light (particularly given 
how long this set of documents appears to have been cooking). Are  there 
really no additional considerations over what's in [PCEP]  introduced by 
this document? A couple of sentences further supporting  that (if it's the 
case) would go a long way.


Sure. I think it is probably the length of cooking that led to the brevity 
of this section.


I guess if we added further text it would look something like...

PCEP security mechanisms are described in [PCEP] and are used to secure 
entire PCEP messages. Nothing in this document changes the message flows or 
introduces any new messages. This document introduces a single new object 
that may optionally be carried on PCEP messages and will be automatically 
secured using the mechanims described in [PCEP]. If a PCEP message is 
vulnerable to attack, for example because security mechanisms are not used, 
then the OF object could be used as part of an attack, however, it is likely 
that other objects will provide far more significant ways of attacking a PCE 
or PCC in this case.


We probably left this out because it was obvious. Would it address you 
concerns if we added it?


This is probably a naive question, but what happens if a PCC sets the  OF 
flag in a request, doesn't provide a OF object, and the OF object  in the 
response has a function code the client has never heard of  before? (If 
this is clear, where in the document suite is it captured?)


The PCC is not required to process the OF object on the PCRep.
If the PCC gets a function code it doesn't understand it can:
- ignore it and use the response
- add the function code to its view of the PCE's repetoire for
 later request/exclusion
- discard the response and ask another PCE to compute for it
- discard the response and ask the same PCE to compute
  excluding the function used.

I'm not sure we need to tell implementers how to write code here.

Also (and to check my understanding of how extensibility of the flags 
field in the RP object is supposed to work) - it's possible for the OF 
flag to be set in a request but for the response to not contain an OF 
object (if the PCE doesn't know about the extension in this draft it  MUST 
ignore the non-zero flag bit according to the definitions on page  30 of 
[PCEP]). Should this document explicitly mention this case?


Right, this would be the behavior of a legacy node.
The PCC that set the OF flag would receive a PCRep carrying no OF object 
(i.e., in breach of this I-D).

The PCC would either:
- discard the PCRep because it *really* wanted the OF object returned
- shrug its shoulders and continue

Again, I'm not sure that we need to tell people how to write code. This 
certainly doesn't change the protocol behavior onthe wire.


This draft uses RBNF (draft-farrel-rtg-common-bnf). The proto writeup 
indicates that no tool was used to verify the RBNF in the draft. Has 
there been a careful review by a human? (There isn't much of it, but 
enough for a typo or dangling reference to slip in).


Did you find any problems?

I wrote RBNF and also reviewed the I-D as doc shepherd. I found some issues 
in an earlier review and these have been fixed. I see no other issues.


||Has the
||Document Shepherd personally reviewed this version of the
||document and, in particular, does he or she believe this
||version is ready for forwarding to the IESG for publication?
|
| Adrian Farrel is the document shepherd.
| He has personally reviewed the I-D and believes it is ready for
| forwarding to the IESG for publication.

I'm probably being dense, but I can't make the literal 0x200 in the 
definition of the OF flag make sense. It doesn't seem to have anywhere  to 
go in the registry that [PCEP] creates. Additionally, that registry  asks 
for a Capability Description and this document only provides a  Name 
(of OF).


Yes, you're right. The IANA section of the PCEP spec has been updated 
several times in the last month and has left this I-D behind.


I think, based on Section 9.6 of [PCEP] we need to use Bit 25, but we need 
to check other I-Ds in the pipeline.


Section 8.2 is, if I read it correctly, a note that more standards  work 
needs to happen, not that an implementer needs to do something. I  suggest 
not using 2119 language here.


Yes, I'm happy with that.
I'm not sure the Ops ADs are so comfortable :-)


The rest of these comments are minor:

- The abstract does not capture that the document defines/registers 
objective functions/metric types


Add...

This document defines objective function code types for six objective 
functions previously listed in the PCE requirments work.


- There's an extra closing parenthesis in the function on Objective 
Function Code 3: r(Lpi)) -here


Good catch

- It would make IANA's job easier to point to the registries this 
document is adding values to (rather than creating

Re: [Gen-art] Gen-ART LC Review of draft-ietf-mpls-te-scaling-analysis-03

[Adrian Farrel]

Hi Ben,

Oops, I messed up the Gen-ART review boilerplate. Please mentally  insert 
the following text at the top of my review:


I think we'll let you off just this once.


Document: draft-ietf-mpls-te-scaling-analysis-03
Reviewer: Ben Campbell
Review Date:  2008-11-25
IETF LC End Date: 2008-11-30
IESG Telechat date: (if known)

Summary:

This draft is ready for publication as an informational RFC.

Nits:

-- Don't forget the new IPR boilerplate.


Yes, lucky us. When we revise the I-D we will hack in the new boilerplate.


-- Abstract, paragraph 3:

Section 8 talks about MP2P, so it is not strictly true that this 
document only considers P2P . (Repeated at end of introduction).


Yes, I suppose this could be clearer.
The point is that only the issue of how to scale the provision of P2P LSPs 
is considered. The fact that one of the solutions is MP2P confuses this, so 
I am sure we can come up with a few words to make it a little clearer.



-- Section 2, 1st paragraph:

Please expand LSR on first mention.

-- Section 2.4, 2nd paragraph:

Please expand NMS and EMS on first mention.


Yes to all three.


-- Section 3.3, paragraph 2: The consideration must be...

Is there a word missing? I assume you don't mean The consideration  to 
mean the _only_ consideration, since you mention others below.


In fact, the other considerations mentioned in later paragraphs in that 
section are factors of physical topology. So we really did intend that there 
was only one primary consideration. But we can wordsmith this a little.


Cheers,
Adrian 


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

Re: [Gen-art] Gen-ART LC review of draft-ietf-pce-path-key-03

[Adrian Farrel]

Hi Ben,

Thanks for the time and effort.

Responding as an author not as a WG chair...


Section 2.1, paragraph 3:

The last sentence is confusing. ...until the LSR that can process  it. 
does not seem to describe an event that one can wait until.  Should it 
say ...until it reaches the LSR...?


The grammer and syntax are fine (you just have to know the normal ERO 
processing rules set out in RFC 3209 :-)


We can tidy as follows...

OLD
  The PKS MUST be preceded by an ERO subobject that
  identifies the LSR that must expand the PKS, so the PKS will not
  be encountered in ERO processing until the LSR that can process
  it.
NEW
  The PKS MUST be preceded by an ERO subobject that
  identifies the LSR that must expand the PKS. This means that
  (following the rules for ERO processing set out in [RFC3209])
  the PKS will not be encountered in ERO processing until the ERO
  is being processed by the LSR that is capable of correctly handling
  the PKS.


Section 2.2, paragraph 1:

 s/ingress/ingress LSR


Not sure this is necessary. Ingress is generally used in related work with 
Ingress LSR being used the first time to help set the scene. Ditto 
egress.



Sections 3.1.1 and 3.1.2

No explicit definitions for Path Key in either section. If the  intent 
is for the language in section 3.1 to serve as the definition  in each of 
these subsections, it would be good to have something like  Path Key: See 
section 3.1.  (Although just reprinting it here would  allow each of the 
formal subobject definitions to stand alone a little  better.)


Hmmm.
This is a more fundamental concept and so is already defined in Section 1

  This document defines the notion of a Path Key that is a token
  that replaces a path segment in an explicit route. The Path Key is
  encoded as a Path Key Subobject (PKS) returned in the PCEP Path
  Computation Reply message (PCRep) ([PCEP]). Upon receiving the
  computed path, the PKS will be carried in an RSVP-TE Path message
  (RSVP-TE [RFC3209] and [RSVP-PKS]) during signaling.

I don't think we need to reproduce the definition or refer back to it from 
later in the document. It is, after all, the only thing that the whole I-D 
is about.



Section 4:

The section covers actions in failure cases, i.e. if the PCE does not 
recognize itself, or if the requesting LSR receives a negative reply.  The 
actions taken in the success case may seem to obvious to state,  but it 
would be good to state them explicitly anyway :-)


OLD
  The retrieval of the explicit path (the CPS) associated with a PKS
  by a PCC is no different than any other path computation request
  with the exception that the PCReq message MUST contain a PATH_KEY
  object and the Path Key bit of the RP object MUST the set.
NEW
  The retrieval of the explicit path (the CPS) associated with a PKS
  by a PCC is no different than any other path computation request
  with the exception that the PCReq message MUST contain a PATH_KEY
  object and the Path Key bit of the RP object MUST the set. On
  receipt of a PCRep containing a CPS, the requesting PCC SHOULD
  use insert the CPS into the ERO that it will signal, in accordance
  with local policy.


Section 5, third bullet point in first list:

Do you mean DoS attacks rather than DNS attacks?


Thanks!


Section 6.1, paragraphs 2 and 3:

Can you either restate the suggested default, or reference the  section? 
Otherwise, this requires a bit of an easter egg hunt on the  part of the 
reader.


Para 2: yes. Should ref Section 2.1
Para 3: I think you mean para 4. Should also ref Section 2.1


6.2, paragraph 1:

If I read this right, you state a normative requirement that another 
draft be updated. That seems an odd use of normative language. In any 
case, am I correct in assuming that someone is ensuring that this  update 
happens?


Eeek!

I think we need to use 2119 language for what happens if the MIB document is 
updated to cover this function, but I don't think we can require that the 
document is updated.


Ops ADs may disagree!


References:

Outdated reference: draft-ietf-ccamp-inter-domain-recovery-analysis  has 
been published as RFC 5298.


Thanks.
Time flies.

Cheers,
Adrian 


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

Re: [Gen-art] Gen-ART LC review of draft-ietf-ospf-multi-area-adj-07

[Adrian Farrel]

If in doubt, expand acronyms.

But see also http://www.rfc-editor.org/rfc-style-guide/abbrev.expansion.txt

Thanks,
Adrian

 Abstract:
 
 Please expand OSPF on first use.
 
 Section 1.3, first paragraph:
 
 Please expand OSPF on first use.


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

[Gen-art] Re: Gen-ART LC review of draft-ietf-ccamp-inter-domain-rsvp-te-06.txt

[Adrian Farrel]

Hi Eric,

Many thanks.


Summary:
===

This document is not ready for publishing as a Proposed Standard.
Some points require clarifications.

Comments:


The following paragraph (section 2) seems inconsistent with the
text in subsequent sections: it seems that it is saying that any
combination of the three methods (contiguous, nested, stitched)
could be used in a _single_ LSP - yet at least on of these is
defined as end-to-end in subsequent text (contiguous).


[SNIP]

Point taken.

What we were trying to convey is that, domain by domain, you may apply any 
one of the techniques.


We can re-work this text to make it clearer and possibly include a (rather 
trite) example.




Still related to the above, but as a side note, the fact that it
is not immediately clear which of these is the intention in this
document is an indication of a potential for some very serious
interoperability issues.  Some of the subsequent text mentions
the potential for a policy failure that SHOULD fail the setup.

In addition to not being absolutely clear (when would it be okay
not to fail, is there a way to indicate that an alternative is
allowed, etc?), this implies that it is possible for a domain to
have a policy (for example, against contiguous LSP setup) that is
going to result in complete non-interoperation with a domain (or
implementation) asking for contiguous LSP setup.

This sort of policy conflict may easily arise if one implementer,
or operator, interprets the specification one way and another (or
others) interprets it another in terms of expected end to end
behavior and combinations of the types of spanning LSPs.


The ability to fail to interoperate at the domain level is intended to be an 
operator choice. If, for whatever reason, the operator only wants to allow 
one of the mechanisms, and the ingress domain insists on another mechanism, 
then it is important to provide for the rejection of the LSP setup.


The most obvious (to me) example, is that an ingress may request a 
contiguous LSP because it wishes to exert maximal control over the LSP's 
path and (in particular) to control when re-optimization takes place. OTOH, 
the operator of a transit domain may decide that only (for example) LSP 
stitching is allowed for exactly the reason that it gives the operator the 
chance to reoptimize their own domain under their own control. Now there is 
a stand-off. The ingress operator has a choice:

- find another path
- relax his requirements
- fail to provide the service.

But the point about implementation is more important.
The choice is not very functional if the ingress LSR is not able to support 
all modes. Fortunately, that is easy to implement (it is only a flag).
The choice is, however, fully functional if the LSRs at the borders of the 
transit domain only support one mechanism (since that must be the mechanism 
that the domain operator is deploying).


We can clarify this choice, but I don;t believe any functional change is 
required.



-
The last two paragraphs in section 2 (preceding the heading for
section 2.1) are confusing and (potentially) contradictory: one
appears to say that signaling extensions (for control/selection
of methods) are in scope while specific details are not, but the
other seems to say otherwise.

I suspect that the word control is where I am getting hung-up.
If it is intended that the specifics of each method are out of
scope in this document - once a method is selected - then it is
hard to see how control [...] of the three signaling mechanisms
is in scope but specific protocol extensions required to signal
each LSP type is not.

Perhaps control and should be removed?


I think the issue is with the associativity of and.

We mean:
  This document describes the RSVP-TE signaling extensions
  required to control which of the three signaling mechanisms
  is used and to select which of the three signaling mechanisms
  is used.

I agree that control and is superfluous.


--
In section 3, under bullet 4a - on page 6 - you use SHOULD in
saying whether or not a PathErr message is to be generated.  Why
- or under what circumstances - would it be appropriate not to do
so?


Hmmm. RFC 3209 includes a variety of reasons to generate a PathErr carrying 
the Routing Problem error. Some of these are related to path computation 
failure (including next hop selection), and the referenced text relates to 
path computation failure. We do not feel that we can redefine (or justify!) 
the behavior described in RFC 3209. In addition, the referenced I-D 
([INTER-DOMAIN-PD-PATH-COMP], also describes this behavior - and needs to be 
fixed to include why this is a MAY.


My opinion is that at a domain boundary we should make the same 
considerations as in RFC 4208 sections 3.1 and 3.2 (note the 

[Gen-art] Re: review of draft-ietf-ccamp-lsp-stitching-06.txt

[Adrian Farrel]

Francis,

Many thanks.

We'll hold on to these comment in case we need to respin. Otherwise, I will 
check during Auth-48 that the RFC Editor has caught them all.


One note in line.

Cheers,
Adrian

Comments: there are only some editorial comments, i.e., things which 
should

be handled by the RFC editor:
- abstract page 2: from from - from
- TOC page 3: for LSP_ATTRIBUTES Object - for the ...?
- 2 page 5: are required - are required to
- 5.1 page 8: LSP ([RFC3473]), to - LSP ([RFC3473]) to
- 5.1.1 page 8: some other e2e LSP. - some other e2e LSPs.?
- 5.1.1 page 8: in the Resv, - in the Resv message,
- 5.1.1.1 page 9: in the Resv Label. - in the Resv message.?
- 5.1.2 page 10: bandwidth, local TE - bandwidth or local TE
- 5.1.2 page 11: a Path Msg - a Path message
- 5.1.2 page 11: a PathErr with the error codes -
  a PathErr message with the error code?
- 5.1.3 page 11: I can't parse this sentence (commas?):
  An e2e LSP traversing an S-LSP, SHOULD record in the RRO for that
  hop, an identifier corresponding to the S-LSP TE link.


Yes. Commas badly placed.

An e2e LSP traversing an S-LSP SHOULD record, in the RRO for that hop, an 
identifier corresponding to the S-LSP TE link.



- 5.2.3 page 14: PCE - Path Computation Element
- 10 page 18: please add , USA after ZIP codes.





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

[Gen-art] Re: Gen-ART review of draft-ietf-ccamp-gmpls-rsvp-te-call-01.txt

[Adrian Farrel]

Suresh,

Many thanks for the review:

Substantial:


* General comment about backward compatibility

I think legacy transit nodes resetting the Call ID to zero on transmission 
is a major issue that needs to be addressed more visibly in the draft.


Why? It is not common practice to include text that describes how to 
circumvent the effects of broken implementations.


The problem we have here is that we are not writing a BCP for RFC3209 or 
RFC3473. And we do not wish to be judgmental (in this I-D) about existing 
implementations. In fact, I have no evidence that any implementations do 
actually get this wrong (no-one will stand up in public and say I am a 
fool), but several people raised the question of what if an implementation 
did this bad thing.


In my view these people were wreckers and were not interested in the 
protocol being successful, but nevertheless, we added the text you are 
commenting on. Basically, it says what might happen in the legacy case with 
broken nodes. I don't think this should have more prominence.



* Section 6.1

The following sentence needs to be tightened.

The text
Note that a Call MAY NOT be imposed ...

needs to be changed to

Note that a Call MUST NOT be imposed ...

since it is a prohibition to do so.


Good catch. Thanks.


Semi-substantial:
=
* Section 5.1
  I did not understand what this sentence means. Does it mean the notify 
message does not have to follow the path of LSPs or it must not follow the 
path of LSPs? Adding some clarifying text on why it is so, may be a good 
idea.

The Notify message is a targeted message and does
 not follow the path of LSPs through the network.


Well, read RFC3473 where the Notify message is defined.

It means does not need to. I will update accordingly.


* Section 6.5 Call Collision

For the Call ID Contention error case, I do not see why we need to check 
the remote source address, instead of always returning an error.


Erm, because then both ends of the call would return an error.
We would end up with no call.
Presumably, both ends of the call would retry and possibly have the same 
effect.


There is no issue with setting up this call: it is just a matter of deciding 
who is in charge. Hence a simple resolution process.



* Section 6.6.5

If a teardown request Notify message is received
 for an unknown Call ID, it is, nevertheless, responded to in the
 affirmative.

Why not return a Call Management/Unknown Call ID error instead?


How would the sender of the call tear respond to the error? Does it mean 
that the call still exists, but that the responder can't correlate the call 
ID, or does it mean that the call should be removed from the sender?


What is the desired effect?

As documented:
- Before
  End A believes call exists
  End B has never heard of call
- After
  End A believes call is gone
  End B does not have the call

As you suggest:
- Before
  End A believes call exists
  End B has never heard of call
- After
  End A removes the call through an error state
  End B does not have the call

Simpler to utilise the mainpath code, reduce the number of code branches, 
and not introduce another error message.

The responder (B) is free to raise an alarm if it wants.


* IANA considerations
  If there are existing implementations it would be nice to suggest values 
for the RSVP objects and error codes to the IANA


If the implementors in the WG are happy to have this go forward without 
suggested values, then so am I.

We have enough problems with contested suggested values as it is!


Minor:
==

* The following text is repeated in both the abstract and the 
introduction. One of them can be removed.


A Call does not provide the actual connectivity for transmitting user
 traffic, but only builds a relationship by which subsequent
 Connections may be made. In GMPLS such Connections are known as Label
 Switched Paths (LSPs).


Why?
The Abstract is stand-alone text and needs to be complete.

The Introduction is typically read without reference to the Abstract.


* Section 4.3.1
  Suggest replacing

In this case the ingress...

with

In the case where the ingress...

since this case has not been defined.


Changed to...
  Network-initiated Calls arise when the ingress (and correspondingly
  the egress) lie within the network and there may be no need to
  distribute additional link capability information over and above the
  information distributed by the TE and GMPLS extensions to the IGP.
...in order to preserve the grammer


Editorial:
==
There is a reference to RFC2747 in the references section but it is not 
referenced anywhere in the draft. I would suggest removing the reference


Good catch. I have added the citation in section 9.1

Thanks,
Adrian 




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

[Gen-art] Re: Gen-ART LC Review of draft-ietf-ccamp-rsvp-te-exclude-route-05.txt

[Adrian Farrel]

Hi Eric,

(Note change in Cheng Yin's email)

(Added Deborah as CCAMP chair)


I am the Gen-ART assigned Last Call Reviewer for this
document.


Oh good, that'll keep us on our toes.


In section 1.1, you say:

This document does not preclude a route exclusion from
listing  arbitrary nodes or network elements to avoid.
The intent is, however, to indicate only the minimal
number of subobjects to be avoided.

This is an aspect of probably the most serious drawback
to what this draft proposes.  I can't easily come up with
scenarios in which it is more difficult to specify the
elements you want a route to include than it is to say
which elements you want it to exclude.


The point really is that if you can compute the full path, you are probably
done and you can send an ERO, but if you either don't care about the path or
can't compute the whole path, then you have to specify the exclusions.

As the Abstract says...
  In some networks where precise explicit paths are not computed at the
  head end it may be useful to specify and signal abstract nodes and
  resources that are to be explicitly excluded from routes.


In fact, it is reasonably easy to see that the complexity
of an include description is on the same order as the
complexity of the desired end-product route.  Not so, at
all, for an exclude description whose complexity is not
bound at all (effectively) since you _could_ describe a
route explicitly as the one route that is left after you
exclude all others (including routes that have loops in
them).


Right!
That is true.
You still assume that the guy who will compute the next piece of path will
use CSPF or similar.
So you don't *need* to specify everything you want to avoid. As you say,
specifying everything you want to avoid is a long list and it is easier to
specify the explicit path.

But, if there are specific things that you want to avoid that might turn up
on the CSPF-computed path (e.g. I would prefer not to go through Haalem)
then these are what you state in the exclusion.

Clearly we did not make it obvious that the ERO is still the primary way of
controlling the route, and I would welcome your suggestion about where we
should best clarify this in the I-D.


What does this document propose as a means to protect an
implementation from another implementations proposing a
literally arbitrarily complex exclusion list?

IMO, a new error code - corresponding to XRO too complex
would be one approach - if an XRO exceeds some measurement
of complexity RECOMMENDED by the specification.

(Of course, this introduces a management consideration,
as it should then be possible to determine tolerance for
complexity of at least the locally managed nodes.)


The error code is a good idea.
The decision can be entirely a local policy matter.
If I don't like your XRO I can reject it. You can retry on a different
route, reduce the XRO, or give up.
I would not like to make a recommendation about what a reasonable XRO is in
an RFC.



In section 2, you include the following sentence:

This subobject might also be appropriate for use within
Explicit Routes or Record Routes, but this is outside the
scope of this document.

I read this is You could do 'X', but this document does
not discuss 'X'.

What's the point in including this sentence?


Hmmm.
Well, other sub-objects we use are identical to ERO sub-objects.
We find ourselves defining a new sub-ibject for exclusions, and we believe
it may well have use in an ERO, but clearly that is not our business.

We could drop this sentence IMHO (and where it shows up in section 1). [You
saw that as well, but you were too polite to mention it ;-]



In section 2.1, you describe the format of a new SRLG object
- which is itself word aligned by inclusion of a two-octet
Reserved field, but which does not word align the SRLG
ID itself by simply putting the Reserved field in the first
word.

I realize this comment comes up frequently and that it is
not usually a problem for modern implementations to deal
with word-alignment problems, but wanted to know what the
authors' thinking was in this case.  Is the Reserved field
purely for padding to a word boundary, or do the authors
anticipate that it might eventually by used for something
else?  If it might be used for something else, do authors
anticipate that something else might scope the SRLG, or be
scoped by it?


All RSVP objects are padded to four-byte boundaries. It is common for
implementations to make this quick check before parsing further.

However, you are completely right about moving the padding to be before the
SRLG I-D. That would also allow easy extension for other SRLG formats in the
future. I need to check with the other authors, but this seems reasonable.

But we may get some push-back from implementations, and since it is not
really a significant issue, perhaps we can let it go?

[Gen-art] Re: GenART review of draft-ietf-mpls-p2mp-oam-reqs-01.txt

[Adrian Farrel]

David: Thanks for your review. See in-line for responses.

MPLS WG: FYI

Ross/Bill: Please let me know if you would like a new revision at this stage

Thanks,
Adrian

- Original Message - 

From: [EMAIL PROTECTED]




I am the assigned Gen-ART reviewer for
draft-ietf-mpls-p2mp-oam-reqs-01.txt.
For background on Gen-ART, please see the FAQ at
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html.

Please wait for direction from your document shepherd
or AD before posting a new version of the draft.

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

Section 2.1

This requirements draft uses RFC 2119 terminology (MUST, SHOULD, etc.).
In addition to incorporation of the RFC 2119 boilerplate (already done),
please explain that these requirements are being stated as requirements
of OAM mechanism and protocol *development*, as opposed to the usual
application of RFC 2119 requirements to an actual protocol, as this
draft does not specify any protocol.


OK. Will add the following text to section 2.1

  This use of RFC 2119 terminology is made to clarify the requirements
  in this document and not to express specific protocol actions or
  behaviors.


Section 2.3

 OAM:  Operations and Management
 OAM: Operations, Administration and Maintenance.

That's an invitation for confusion.  The OAM acronym is not used
in this draft - please remove it from this section.


OK


Section 4.1

The discussion of limits on proactive OAM loading should probably
explicitly say that reactive OAM (dealing with something that has gone
wrong) may violate these limits (i.e., cause visible traffic
degradation) if that's necessary or useful to try to fix whatever has
gone wrong.


Can you explain your point please? When you say may do you mean that in 
your opinion reactive OAM is allowed to cause LSRs to be overwhelmed. I 
can't honestly say that would be a good idea because an overwhelmed LSR will 
not be able to do anything constructive.


I am also confused as to why you suggest placing this text in section 4.1. 
This section is about detecting defects. That is, it is about proactive OAM 
only. Section 4.2 is about diagnosis. We could, I suppose, add a similar 
requirement to section 4.2 (that is, diagnostic OAM similarly MUST NOT 
overwhelm an LSR). Would that be OK?



Also, a wording nit:

  In practice, of course, the requirements in the previous paragraph
  may be overcome by careful specification of the anticipated data
  throughput of LSRs or data links,

overcome -- satisfied or met


The point is that the requirements are not satisfied or met by this process. 
Perhaps avoided would be an acceptable word?





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

[Gen-art] Re: Gen ART review of draft-ietf-ccamp-gmpls-alarm-spec-03.txt

[Adrian Farrel]

Hi,

hat = (chair and co-author)
Thanks for the changes
/hat

hat = co-author
Can we take this opportunity to update the references?

OLD
[GMPLS-UNI] Swallow, G., Drake, J., Ishimatsu, H., and Rekhter, Y.
   GMPLS UNI: RSVP Support for the Overlay Model,
   draft-ietf-ccamp-gmpls-overlay-05.txt, October 2004,
   work in progress.

[GMPLS-ENNI] Papadimitriou, D., Editor,  Generalized MPLS (GMPLS)
RSVP-TE Signaling in support of Automatically Switched
Optical Network (ASON),
draft-ietf-ccamp-gmpls-rsvp-te-ason-04.txt, July 2005,
work in progress.

NEW
[GMPLS-OVERLAY] Swallow, G., Drake, J., Ishimatsu, H., and Rekhter, Y.
   Generalized Multiprotocol Label Switching (GMPLS)
User-Network Interface (UNI): Resource ReserVation
Protocol-Traffic Engineering (RSVP-TE) Support for the
Overlay Model, RFC 4208, October 2005.


/hat

Thanks,
Adrian

- Original Message - 
From: Lou Berger [EMAIL PROTECTED]

To: [EMAIL PROTECTED]
Cc: Adrian Farrel [EMAIL PROTECTED]; gen-art@ietf.org; Lou Berger 
[EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; 
[EMAIL PROTECTED]; [EMAIL PROTECTED]; 
[EMAIL PROTECTED]; [EMAIL PROTECTED]

Sent: Friday, August 11, 2006 11:01 PM
Subject: Re: Gen ART review of draft-ietf-ccamp-gmpls-alarm-spec-03.txt



David,
Much thanks for the comments.  Please see below for in-line 
responses.
Note, the other co-authors on this draft have been included in this 
response.


Lou


- Original Message - From: [EMAIL PROTECTED]
To: gen-art@ietf.org; [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED];
[EMAIL PROTECTED]; [EMAIL PROTECTED]
Sent: Wednesday, August 09, 2006 4:59 PM
Subject: Gen ART review of draft-ietf-ccamp-gmpls-alarm-spec-03.txt



Lou,

I am the assigned Gen-ART reviewer for
draft-ietf-ccamp-gmpls-alarm-spec-03.txt .

For background on Gen-ART, please see the FAQ at
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html.

Please resolve these comments along with any other
Last Call comments you may receive.

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

The draft is generally well-written and to the point.  All
of these comments are minor.
- Section 3.1.  Say why the two-leading-one-bits form is used
for ALARM_SPEC objects in this section in addition to
Section 3.1.4.  It would be ok to move the text from Section
3.1.4 up into Section 3.1.


I've added a forward reference to 3.1.  Note that this comment will
be removed once IANA assigns the class number.


Also, if there's a good explanation
for why C-Type 1 and 2 are Reserved, that explanation should
be added.


sure.


- Section 3.1.1 should give guidance for and examples of appropriate
use of Severity values.


There's a whole body of work on this, and for this reason the
document provides a reference to an RFC that already discusses this
topic.  I think the current text (See [RFC3877] for more information
on severity.) is the best and right about of guidance in this
document.  If you have specific alternative text, we'd be happy to
consider its inclusion.


- Section 3.1.2 has a number of SHOULDs and SHOULD NOTs.  There needs
to be an explanation of why these strong recommendations are
being made (which would imply consequences of not following
the recommendations) and/or a description of what goes wrong
when they're not followed.


I'm not sure I agree with this point, but will add some text nevertheless.


The overall explanation appears
to be a desire to supply enough basic information to allow
the recipient to understand the alarm (this info can be quite
important as the recipient may be dealing with a crisis of
which the alarm is a part).


will cover this in the updated text.


The MAY for the ref
count TLV needs to be explained  (why would it be used?).


This is explained earlier in the document, but sure will add something.


- Section 3.1.2 on p10 discusses adding alarm objects to the
state of LSPs.  The quoted phrase needs to be defined -
I think the addition is to the LSP state communicated by
RSVP Path and Resv messages.


so there seems to be a few points here:

point 1:  clarify which stats are referred to by state of LSPs.

Per your comment, I've changed this to read Path and Resv states of 
LSPs.



point 2 and 3: define the quoted phrases: alarm communication
inhibited state. and administratively down .

These phrase are defined in the last sentence of the paragraph:
These states are indicated by the I and A bits of the
Admin_Status object, see Section 3.2.

Thanks again for the feedback!

Lou

PS in case you're interested there's a preview copy of the updated
text attached.


Thanks,
--David

David L. Black, Senior Technologist
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953 FAX: +1 (508) 293-7786
[EMAIL PROTECTED