Subject: [Netconf] FW: DISCUSS and COMMENT: <draft-ietf-netconf-with-defaults-12.txt>

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Tue, 26 Oct 2010 19:53:31 +0200

Andy, Balazs, 

Please address the question raised by Alaxey in his DISCUSS. 

Thanks and Regards,

Dan

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Alexey Melnikov
Sent: Saturday, October 23, 2010 12:41 PM
To: [email-masked]
Cc: [email-masked];
[email-masked]
Subject: DISCUSS and COMMENT: <draft-ietf-netconf-with-defaults-12.txt>

Discuss:
While I was initially skeptical about usability of this extension, I
think the document is making a compelling argument for having this
extension.

However, there is one question I would like to discuss:

   A NETCONF server implementing the :with-defaults capability:

   o  MUST indicate its basic mode behavior by including the 'basic-
      mode' parameter in the capability URI, as defined in Section 4.4.
   o  MUST support the YANG module defined in Section 5.
   o  SHOULD support the 'report-all' or 'report-all-tagged' defaults
      handling mode.
   o  MAY support additional defaults handling modes.

DISCUSS DISCUSS (this might result in no changes to the document):
Is the goal here to allow servers to advertise what they support, but
pushing complexity of dealing with multiple modes to clients? My
personal experience with other protocols suggest that simpler operations
for clients would result in more widespread deployment of extensions.

So to translate this into something actionable: I am a bit concerned
that various things are optional for compliant servers to support. I
would feel more comfortable changing the SHOULD/MAY to MUSTs (at least
for the SHOULD).
Is this something that was discussed in the WG?

Comment:
I think XSD needs a Normative reference.

---

From: Andy Bierman <[email-masked]>
Date: Tue, 26 Oct 2010 11:22:54 -0700

Hi,

I already did -- will send another email I guess.

Yes, there is a goal here to allow servers to advertise what they support,
But pushing complexity of dealing with multiple modes to clients,
where 'multiple modes' means the client needs to be able to support
all 3 modes in order to support all possible compliant servers.

The WG is not going to get N-1 vendors to change to the way 1 vendor
implemented defaults.  A server has to pick 1 of 3 modes and stick to it.
Why is this too complicated?

Andy

-----Original Message-----
From: Romascanu, Dan (Dan) [mailto:[email-masked]] 
Sent: Tuesday, October 26, 2010 10:54 AM
To: Andy Bierman; [email-masked]
Cc: netconf
Subject: FW: DISCUSS and COMMENT: <draft-ietf-netconf-with-defaults-12.txt>

Andy, Balazs, 

Thanks and Regards,

Dan

-----Original Message-----

Discuss:

Comment:

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Tue, 26 Oct 2010 20:28:21 +0200

Thanks, I found the mails and will follow up with Alexey. 

Dan

> From: Andy Bierman [mailto:[email-masked]] 
> Sent: Tuesday, October 26, 2010 8:23 PM
> To: Romascanu, Dan (Dan); [email-masked]
> Cc: netconf
> Subject: RE: DISCUSS and COMMENT: 
> <draft-ietf-netconf-with-defaults-12.txt>
> 
> Hi,
> 
> Yes, there is a goal here to allow servers to advertise what 
> they support, But pushing complexity of dealing with multiple 
> modes to clients, where 'multiple modes' means the client 
> needs to be able to support all 3 modes in order to support 
> all possible compliant servers.
> 
> The WG is not going to get N-1 vendors to change to the way 1 
> vendor implemented defaults.  A server has to pick 1 of 3 
> modes and stick to it.
> Subject: FW: DISCUSS and COMMENT: 
> <draft-ietf-netconf-with-defaults-12.txt>
> 
> Andy, Balazs, 
> 
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Alexey Melnikov
> Subject: DISCUSS and COMMENT: 
> <draft-ietf-netconf-with-defaults-12.txt>
> 
> Discuss:
> While I was initially skeptical about usability of this 
> extension, I think the document is making a compelling 
> argument for having this extension.
> 
> Is the goal here to allow servers to advertise what they 
> support, but pushing complexity of dealing with multiple 
> modes to clients? My personal experience with other protocols 
> suggest that simpler operations for clients would result in 
> more widespread deployment of extensions.
> 
> So to translate this into something actionable: I am a bit 
> concerned that various things are optional for compliant 
> servers to support. I would feel more comfortable changing 
> the SHOULD/MAY to MUSTs (at least for the SHOULD).